Die Analysten sind sich sicher: Auch wenn neue Sicherheitsstandards speziell für SOA entwickelt werden, so sind doch individuelles Wissen, Richtlinien und Prozesse nötig, damit die Sicherheitsvorkehrungen für SOA effektiv durchgesetzt werden können. Die zusätzlichen Schichten mit erforderlichen Services erhöhen allerdings die Komplexität noch weiter. Damit wiederum können auch Sicherheitslecks im Unternehmen leichter ausgenutzt werden. Um eine potenzielle Gefährdung dieser lose gekoppelten, föderierten Systeme zu mindern, wurden Sicherheitsspezifikationen aufgestellt, anhand derer Web-Service-Informationen zwischen einzelnen Elementen sicher ausgetauscht werden können.
Die Experton Group rät IT-Verantwortlichen, einen Blick auf die "sieben Ps" zu werfen, die das Herzstück eines jeden Projekts oder Services im Unternehmen bilden. Diese sieben Faktoren sind bei Überlegungen zur SOA-Sicherheit von ausschlaggebender Bedeutung. Sie lauten: Prozesse, Personen, Plattform, Produkte, Planung, Projekte und Portfolios.
1. Prozesse: Die SOA-Sicherheit muss während des ganzen Lebenszykluses des SOA-Projekts berücksichtigt werden. Die Sicherheitsstrategie muss sich auf die SOA genauso wie auf alle anderen Infrastruktur-Elemente beziehen. Aufgrund der zusammengefügten Natur der SOAs, wobei jeder Service dynamisch jeden anderen Service aufrufen kann, sollte die Sicherheit für jeden Prozess eigens bedacht werden - sowohl als eigenes Element als auch als rekursiver Teil eines jeden potenziellen Geschäftsprozesses.
Besonderes Augenmerk sollte die IT auf die Kommunikation und die Authentifikation zwischen Trust Domains legen. Schließlich ist es wahrscheinlich, dass verschiedene Dienste mit anderen Services in verschiedenen Trust Domains interagieren. Diese sich entwickelnden Anwendungen müssen als integrierter Prozess innerhalb des Software-Enwicklungslebenszykluses auf Sicherheit getestet werden.
2. Personen: In den SOA-Lebenszyklus sind viele Personen einbezogen, und jede Person und jede Personengruppe muss aus der Sicherheitsperspektive beleuchtet werden. Identitäts-Management-Systeme können leicht einbezogen werden, um Menschen zu authetifizieren. Sie können für interne und externe User verschieden sein. Alle Personen sollten nicht nur durch Zugangsservices ermittelt werden. Auch das Verhalten sollte durchleuchtet werden, genauso wie der Kontext, in dem eine Person einen Service in Anspruch nimmt.
In diesen Fällen reicht eine Aufgaben-basierte Sicherheit in den Standard-Identitäts-Management-Systemen nicht aus. Denn der Kontext des Verbrauchers kann sich durch verschiedene Unter-Services ändern. Angriffe können vermieden werden, wenn Applikationen vor Sicherheitslücken durch Chiffrierung, Netzwerk-Schutz und Rechte-Management geschützt sind.
SOAs sorgen für Komplexität
3. Plattformen: Die Plattform, auf der eine Anwendung läuft, kann verwundbar sein. SOAs fügen der Plattform einige Schichten an Komplexität hinzu, da viele SOAs wahrscheinlich in einer virtuellen Umgebung existieren. Es gibt zwei Fälle: Entweder läuft ein einziger Service auf mehreren Plattformen, oder eine einzige Plattform setzt auf mehreren Diensten auf. Weitere Komplikationen treten auf, wenn die verschiedenen Services, die auf derselben Plattform laufen, auf verschiedenen virtuellen Teilbereichen mit unterschiedlichen Trust Leveln laufen.
Die meisten Sicherheitsprodukte haben bisher noch nicht auf diese zusätzlichen Schichten an Komplexität reagiert. IT-Entscheider sollten davon ausgehen, dass die Hacker hart daran arbeiten, diese "Nähte" auszunutzen, und die Sicherheitsanbieter dazu drängen, Schutz für virtuelle Domains und Mechanismen zum Aufspüren von Bedrohungen zu erstellen. Die CIOs müssen ständig schauen, wo sich virtuelle und reale SOA-Services verwundbar zeigen.
4. Produkte: Angebote für die Sicherheit von SOAs entstehen gerade erst. Darum sollten die Entscheider genau auf die Entwicklungen in diesem Bereich achten. Die meisten großen Management-Anbieter haben angekündigt, die SOA-Sicherheit zu unterstützen, darunter BMC und IBM. Zum einen müssen sich Produkte für die SOA-Security in ein allgemeines Sicherheitskonstrukt integrieren lassen, zum anderen haben SOAs spezifische Bedürfnisse. Dazu gehören die Analyse von XML-Dokumenten und SOA-spezifischen Sicherheitsprotokollen. Die IT sollte dabei auch die SOA-Sicherheitslösungen, die sie vorschlägt und ausgibt, als "Produkte" betrachten und fördern: mit geeigneten Marketing- und Verkaufsbemühungen sowie den nötigen Ressourcen.
5. Planung: SOAs sind mit mehr Schichten rekursiver Services verbunden. Dadurch ist detaillierte Planung wichtig, um sicherzustellen, dass Personen, Prozesse und Produkte richtig koordiniert werden. Die Personen müssen für die richtige Nutung von SOAs und für die Sicherheitstaktik geschult werden. Es müssen Produkte entwickelt werden, die sowohl SOA-spezifisch sind als auch mit dem allgemeinen Sicherheitsrahmen und den operationellen Management-Prozessen verknüpft werden können.
Es liegt in der Natur der SOAs, eine dynamische Wiederverwendung von Services zu erlauben, um sich schnell an sich verändernde Geschäftsprozesse anzupassen. Deshalb muss die Planung kontinuierlich stattfinden, um die anhaltende Bedrohung neuer Sicherheitsrisiken zu senken.
6. Projekte: Rund um SOA-Initiativen werden in der Regel spezifische Projekte gebaut. Bei jedem dieser Projekte muss man an Sicherheit denken und entsprechende Lösungen integrieren. Wenn die IT-Verantwortlichen die Sicherheit zum Bestandteil des ganzen Lebenszykluses machen, ist es einfach, die Finanzierung bei jedem Projekt zu sichern. CIOs sollten das Aufsehen, das kürzlich die Sicherheitslücken im Business und in der Regierung erregten, nutzen, um sicherzustellen, dass die Sicherheit durch alle Projekte hindurch gefördert und finanziert wird. Manchmal kann Geld aus einem bestimmten Projekt eingesetzt werden, um die Sicherheit in der ganzen Infrastruktur weiterzuentwickeln, besonders wenn das Projekt selbst eine hohe Sichtbarkeit hat.
Sicherheits-Elemente wiederverwenden
Die Finanzmittel sollten auch Labor-Einrichtungen und Tests umfassen, so dass die wunden Stellen der Sicherheit in einer sicheren Umgebung untersucht werden können, bevor sie in die Produktion gehen. IT-Entscheider und Abteilungsleiter sollten zusammenarbeiten, um den Mitteln für die Sicherheit bei sichtbaren SOA-Projekten Vorrang einzuräumen. Sofern möglich, sollten Elemente der SOA-Sicherheit bei zukünftigen SOA-Initiativen wiederverwendet werden.
7. Portfolios: Die CIOs sollten die Sicherheit auf die Liste der IT-Infrastruktur-Bestände setzen, die im Portfolio der Produkte und Services verfolgt werden. Security-Elemente, die als Ressourcen im Zusammenhang mit SOA-Initiativen hinzugefügt werden, werden meistens besser finanziell unterstützt. In manchen Fällen sind Security-Elemente SOA-spezifisch. Andere Elermente wiederum können breit eingesetzt werden: im ganzen Netzwerk, im Identity-Management und in anderen Infrastruktur-Elementen, die nicht zwingend SOA-spezifisch sind. Diese Portfolios sollten auch spezielle Business-Erforderungen berücksichtigen.
Eine Risiko-Analyse kann herausfinden, wie hoch das Risiko ist, wenn es keine Sicherheitselemente gibt. Alle IT-Portfolios, inklusive der SOA-Sicherheitselemente, müssen periodisch überprüft und priorisiert werden. Bei Bedarf muss man sie modifizieren, um sie mit dem Business in Einklang zu bringen.
The Experton Group beruft sich bei ihrer Studie "Securing Service-Oriented Architectures" auf ihre eigenen Erfahrungen, die unter anderem aus einem Kooperationsnetzwerk von Analysten aus den USA stammen.