Service-orientierte Architekturen (SOA) enthalten einen neuen Ansatz für das verteilte Computing, der die klassischen monolithischen Anwendungen aufbricht. Hierbei stellt eine Abstraktionsschicht Anwendungsfunktionalität als geschäftsorientierte Services zur Verfügung. Diese auf Standards beruhenden Dienste sind orts- sowie implementierungsunabhängig, und sie können einfach über das Netzwerk aufgerufen und gemeinsam verwendet werden. Doch gerade diese Eigenschaften einer offenen Architektur mit nur lose gekoppelten Diensten gehen auf Kosten der Sicherheit, die damit zu einer der größten Herausforderungen bei der Einführung einer solch prozessorientierten Umgebung wird.
Hier lesen Sie …
Fazit
Die Sicherheitsrisiken in einer SOA kommen im Wesentlichen dadurch zustande, dass lose gekoppelte Services im Gegensatz zu monolithischen Anwendungen keinen allgemein gültigen Sicherheitskontext haben und die nachrichtenorientierte Kommunikation über SOAP durch SSL-Verschlüsselung nicht ausreichend geschützt ist. Die durch Web-Service Security beschriebenen Konzepte, etwa WS-Security als Erweiterung von SOAP-Header, WS-Trust oder die von der Liberty Alliance definierte SAML-Spezifikation, liefern die Basis für den Aufbau von Vertrauensketten für den Einsatz von Web-Diensten. Die unternehmensweite Absicherung einer Service-orientierten Architektur kann nach Single-Sign-On-Prinzipien erfolgen und von einem zentralen Sicherheitsdienst gesteuert werden.
Eine dienste-orientierte IT-Landschaft abzusichern ist eine wesentlich komplexere Aufgabe als dies bei Client/Server-Systemen der Fall ist. Zu den Risiken, die bei jeder Kommunikation über offene Netzwerke bestehen, kommen weitere spezifische Sicherheitsaspekte hinzu, die sich im Wesentlichen auf zwei große Bereiche beziehen: das Fehlen eines allgemein gültigen Sicherheitskontextes und verschiedener Identitäts- und Zugriffsmechanismen sowie Policies bei den heterogenen Backend-Systemen.
Sicherheit als Service
Herkömmliche monolithische Anwendungen besitzen einen eigenen Sicherheitskontext: Alle Informationen, die ein Client braucht, um sich gegenüber einer sicheren Umgebung zu authentifizieren, sind innerhalb der Anwendung etabliert, gelten für die gesamte Anwendung und werden zentral gesteuert. Dieser übergreifende Sicherheitskontext fehlt jedoch in einer SOA, traditionelle Sicherheitsmaßnahmen greifen somit nicht mehr. Die Komponenten oder Services, die mithilfe von Logik Prozesse abbilden, haben ursprünglich nichts miteinander zu tun und befinden sich zu verschiedenen Zeiten auf verschiedenen Systemen - besitzen also keinen eigenen Sicherheitskontext, der über die lose Kopplung hinweg gilt. Sie können auf unterschiedliche Backend-Systeme mit eigenen Sicherheitsrestriktionen, also Identitätsmechanismen und Sicherheits-Policies, zugreifen.
Das bedeutet wiederum, dass bei der Nutzung eines zusammengesetzten Services dieser sich gegen jedes in den Vorgang einbezogene Backend-System gesondert authentifizieren muss. Der Aufbau beziehungsweise die Implementierung jeweils neuer Sicherheitskontexte sowie die Harmonisierung mit anderen existierenden Kontexten sind sehr aufwendig.
Gefährliche Offenheit
Noch kritischer ist die Situation, wenn ein Unternehmen seine Systeme über Web-Service-Schnittstellen für Partner öffnet, um das Abbilden von B2B-Prozessen zu ermöglichen. Der externe Dienstenutzer muss sich beim Aufruf des Web-Services zusätzlich authentifizieren, was weitere Funktionalität innerhalb des Dienstes erfordert, damit dieser den externen Sicherheitskontext versteht und mit der externen Sicherheitsinfrastruktur abgleichen kann. Ein konsistentes Trust-Management aber ist bei längeren Ketten sehr problematisch, weil jeder Partner in der Regel seine eigene Sicherheitsinfrastruktur hat.
Eine weitere grundlegende Charakteristik einer Service- orientierten Architektur, nämlich die nachrichtenorientierte Kommunikation zwischen den Komponenten, wirft ebenfalls neue Sicherheitsfragen auf. Zwar lassen sich dafür unterschiedliche Nachrichtenprotokolle wie CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation) oder andere einsetzen, doch haben sich Web-Services und das Protokoll SOAP (Simple Object Access Protocol) auf der Basis von HTTP (Hypertext Transfer Protocol) als sehr effiziente Techniken für SOAs etabliert. Die offenen Standards wie XML (Extensible Markup Language), WSDL (Web Service Description Language) oder UDDI (Universal Description, Discovery and Integration) sowie SOAP, auf denen die Webdienste aufbau-en, enthalten aber per se keine inhärente Sicherheitsinfrastruktur.
Schutzmechanismen
Die einfachste Absicherung für HTTP ist SSL (Secure Sockets Layer) oder dessen Nachfolger TLS (Transport Layer Security), doch sind diese Sicherheitsstandards auf einfache Punkt-zu-Punkt-Verbindungen ausgerichtet. Bei einer kleinen Anzahl von Web-Services sind die Sicherheitsprobleme noch überschaubar und lassen sich durch SSL lösen. Doch bei einer großen Anzahl von Diensten und deren Verknüpfungen durch die Prozesskomposition im Rahmen einer SOA sind die Anforderungen viel komplexer. Im Fall eines zusammengesetzten Dienstes werden die verschlüsselten Nachrichten auf zwischengelagerte Server (Intermediarys) geleitet, dort entschlüsselt, für den nachfolgenden Aufruf wieder verschlüsselt und an den nächsten Server weitergeleitet. Auf den Intermediaries ist die Sicherheitsinformation im Klartext abgelegt und stellt ein zusätzliches Sicherheitsrisiko dar.
Zur Absicherung von Web-Services hat das OASIS-Konsortium (Organization for the Advancement of Structured Information Standards) die WSS-Sicherheitsbausteine (Web-Services Security) spezifiziert. Eine Erweiterung des SOAP-Protokolls stellt WS-Security dar, hinzu kommen weitere technische Spezifikationen. Dabei ist immer zu beachten: Sicherheitsbausteine für Web-Services bilden eine gute Basis, doch sind einige dieser Bausteine noch nicht endgültig spezifiziert.
Kontext für Sicherheit
Die notwendige Sicherheit für eine diensteorientierte Umgebung muss ein Unternehmen innerhalb seiner existierenden Sicherheitsinfrastruktur umsetzen, und zwar möglichst nach den Prinzipien des Single-Sign-On (SSO). Der erforderliche Sicherheitskontext wird bei der Anmeldung durch den Nutzer erzeugt und dem Dienst mitgegeben. Dieser stellt dann den Kontext jedem Backend-System zur Verfügung, auf das er zugreift. Zentraler Bestandteil einer SSO-Lösung sollte ein Verzeichnisdienst auf LDAP-Basis (Lightweight Directory Access Protocol) sein, der alle Informationen zu Mitarbeitern, anderen Teilen einer Unternehmensorganisation und zusätzlich Sicherheitsinformationen wie Zertifikate und Policies speichert.
Sicherheitsmechanismen sollten als zentralisierte Komponente zur Verfügung stehen - am besten als eigener Sicherheitsservice, der über Policies so konfiguriert ist, dass er mit allen weiteren Diensten sowie Access- und Identity-Management-Lösungen und mit den Security-Diensten Dritter zusammenarbeiten kann.
Wo ist Sicherheit relevant?
Um die richtige Balance zu finden, empfiehlt es sich, bereits vor dem Aufbau einer SOA die Sicherheitsrelevanz einzelner Prozesse zu prüfen, unternehmensweite Sicherheits-Policies aufzusetzen und dementsprechend Sicherheitsaspekte schon beim Design eines Teilablaufes zu beachten. (ave)