Sicherheit in einer serviceorientierten Architektur
Lose gekoppelte Security im Header
Das Aufbrechen monolithischer Anwendungen in Einzelkomponenten als geschäftsorientierte Dienste, die sich gemeinsam nach Bedarf nutzen lassen, wirft die Frage nach einer neuen Art der Absicherung auf. Eine lose gekoppelte diensteorientierte Architektur muss einen Policy-gestützten Sicherheitskontext schaffen und verschiedene Identitäts- und Zugriffsmechanismen koordinieren können.
Serviceorientierte Architekturen (SOA) schaffen Paradigmen, die einen neuen Ansatz für die
verteilte Verarbeitung möglich machen. Die Idee hinter dem Konzept besteht darin, die klassischen
monolithischen Anwendungen in Komponenten aufzubrechen und über eine Abstraktionsschicht
Anwendungsfunktionalität in Form von geschäftsorientierten Services zur Verfügung zu stellen. Diese
Dienste beruhen auf Standards (WSDL, XML sowie auf dem Protokoll SOAP für die Kommunikation im
Netz), sind von der Implementierung unabhängig, lassen sich einfach über das Netzwerk aufrufen und
können von allen Anwendungen gemeinsam verwendet werden. Das Bestechende an den SOA-Prinzipien ist,
dass eine offene Architektur mit lose gekoppelten Services entsteht, wie es im Fachjargon
heißt.
Der Hauptnutzen dieser neuen Form der Anwendungsintegration ist eine deutlich höhere
Flexibilität der IT. Die lose Kopplung der Dienste aber wirft auch neue Fragen bezüglich der
Sicherheit der Architektur auf. Diese beziehen sich im Wesentlichen auf zwei große Bereiche: Zum
einen muss ein allgemein gültiger Sicherheitskontext geschaffen und zum anderen das Problem
verschiedener Identitäts- und Zugriffsmechanismen gelöst werden.
Es hat sich gezeigt, dass die Perimeterabsicherung durch Firewalls, Router und so weiter allein
den Anforderungen des serviceorientierten Geschäftsparadigmas nicht gerecht werden kann:
Unternehmen müssen in der Lage sein, Vertrauensbeziehungen dynamisch aufzubauen und wieder zu lösen
– sowohl innerhalb der Firma als auch mit Partnern und Lieferanten. Dies bedeutet, dass eine SOA
die Implementierung eines flexiblen Sicherheitsmodells benötigt, das ohne "fest verdrahtete" Policy
auskommt.
In herkömmlichen Architekturen sind die monolithischen Anwendungen zumeist als Sicherheitsinseln
konzipiert. 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. Das heißt, die Applikationen laufen in einem eigenen Sicherheitskontext.
Dieses Konzept lässt sich nicht ohne weiteres auf eine SOA übertragen: Dort stehen die Services
jedem so genannten Konsumenten – das können Nutzer, Anwendungen, Dienste sein – frei zur Verfügung,
ohne dass bei der Entwicklung bereits festgelegt ist, wer als Konsument den Dienst aufrufen und
nutzen wird. Die bedeutet aber, dass sich einem Service per Definition auch kein eigener
Sicherheitskontext zuteilen lässt, der über die lose Kopplung hinweg gilt.
Die Kommunikation in einer diensteorientierten Architektur läuft über Nachrichten. Für deren
Übertragung können unterschiedliche Protokolle wie CORBA (Common Object Request Broker
Architecture), RMI (Remote Method Invocation) oder andere genutzt werden, doch haben sich
Webservices und das Protokoll SOAP (Simple Object Access Protocol) auf der Basis von HTTP als
effiziente Technik etabliert. Die meisten Anwendungen setzen bei der Datenübertragung auf HTTPS und
vertrauen damit einer Verschlüsselung auf Transportebene. Die einfachste Absicherung für HTTP ist
SSL (Secure Socket Layer) oder dessen Nachfolger TLS (Transport Layer Security). Sicherheit dieser
Art auf Netzwerkebene ist für einfache Punkt-zu-Punkt-Verbindungen ausreichend.
Doch Integrationsszenarien einer SOA nutzen Services, um einen Prozessablauf abzubilden, und
dabei sind meist mehrere Anwendungen sowie Dienste involviert, und die Kommunikation erfordert den
Austausch vieler Nachrichten über Zwischenstationen oder so genannter Intermediaries. Anstelle
einer Absicherung auf Transportebene muss also die Sicherheit auf Nachrichtenebene gewährleistet
werden. Services bestehen häufig aus mehreren "einfachen" Diensten, die ursprünglich nichts
miteinander zu tun haben. Beim Aufruf eines zusammengesetzten Dienstes enthält die Nachricht
verschiedene Datensätze, die für die Augen unterschiedlicher Empfänger bestimmt sein können. Die
verschlüsselten Nachrichten passieren auf ihrem Weg zum Zielservice meist mehrere zwischengelagerte
Server (Intermediary), die ohne entsprechende Sicherheitsvorkehrungen die Nachricht entschlüsseln
und für den nachfolgenden Aufruf wieder verschlüsseln und an den nächsten Server weiter leiten
würden. Dabei wären sie in der Lage, Sicherheitsinformationen und Daten im Klartext zu sehen und
abzulegen. Um dies zu verhindern, müssen demnach die Teile einer Nachricht für die
unterschiedlichen Empfänger unterwegs auch unterschiedlich gesichert sein.
Eine Hilfestellung dazu bietet das OASIS-Konsortium (Organization for the Advancement of
Structured Information Standards) mit der Spezifizierung der WSS-Sicherheitsbausteine (Web Services
Security). Sie schaffen die Option, das SOAP-Protokoll mit zusätzlichen Sicherheitsinformationen zu
versehen. Der Standard definiert Sicherheits-Token als Erweiterungen des SOAP-Headers. Ein Token
kann Schlüsselpaare, Authentifizierungsinformationen einschließlich einer Signatur, Autorisierung
sowie einen Zeitstempel enthalten und begleitet die Nachricht von Anfang bis zum Ende ihres Wegs.
Hinzu kommen weitere Standards wie PKI (Private Key Infrastructure), WS-Encryption, WS-Signature
und Security Assertion Markup Language (SAML), die dazu beitragen, eine End-to-End-Sicherheit für
die Nachrichten zu ermöglichen. Sicherheitsbausteine für Webservices bilden eine gute Basis, doch
sind einige dieser Bausteine noch nicht endgültig spezifiziert.
Die so genannten komponierten Dienste müssen für die Durchführung ihrer Aufgaben auf
unterschiedliche Backend-Systeme zugreifen, jedes mit eigenen Sicherheitsvorkehrungen wie
Identitätsmechanismen und Sicherheitsrichtlinien. Theoretisch bedeutet das in einer SOA, dass ein
Service sich gegenüber jedem in den Ablauf einbezogenen Backend-System speziell authentifizieren
muss. Der Aufbau beziehungsweise die Implementierung jeweils neuer Sicherheitskontexte sowie die
Harmonisierung mit anderen existierenden Kontexten wären nahezu unmöglich. Die Lösung dafür ist ein
Zugriffs- und Identitätsmanagement nach den Prinzipien des Single-Sign-On (SSO). Dies bedeutet,
dass bei der Anmeldung eines Service-Consumers der Sicherheitskontext für den Dienst erzeugt und
diesem im SOAP-Header beigefügt wird. Der Kontext steht dann den verschiedenen Backends zur
Authentifizierung zur Verfügung.
Die unternehmensweite Absicherung der SOA setzt ein allgemeines Security Framework um. Ein
solcher komponierter Sicherheitsservice ist Bestandteil des Enterprise Service Bus (ESB), der als
zentrale Infrastrukturkomponente einer diensteorientierten Umgebung neben der Kommunikation, dem
Routing und weiteren Querschnittsdiensten für Basisaufgaben auch diesen Service koordiniert.
Der Sicherheitsdienst besteht aus verschiedenen einzelnen Komponenten etwa für die
Authentifizierung, Verschlüsselung, einem PEP (Policy Enforcement Point) sowie PDP (Policy Decision
Point) zur Autorisierung. Zentraler Bestandteil der Lösung sollte ein LDAP-Verzeichnisdienst
(Lightweight Directory Access Protocol) sein, der alle Informationen zu Mitarbeitern, anderen
Teilen einer Unternehmensorganisation und zusätzlich Sicherheitsinformationen wie Zertifikate und
Policies speichert. Der Sicherheitsdienst muss über Policies so konfiguriert sein, dass er mit
Access- und Identity-Management-Lösungen, mit Sicherheitsdiensten Dritter sowie mit allen weiteren
Diensten zusammenarbeitet. Schließlich ist es darüber hinaus empfehlenswert, auch den Enterprise
Service Bus selbst über eine Administrationsschnittstelle zu sichern, die für das Monitoring und
Logging sorgt.
Will ein Unternehmen seine Webservices nach außen zugänglich machen, etwa um die Abbildung von
B2B-Prozessen zu ermöglichen, dann bedarf es eines so genannten föderativen Identitätsmanagements,
das zusätzlich einen Identitätsdienst umfasst. Der externe Consumer muss sich beim Aufruf des
Webservices zusätzlich authentifizieren, und dies erfordert weitere Funktionalität innerhalb eines
Dienstes, damit er den externen Sicherheitskontext versteht und sich mit der externen
Sicherheitsinfrastruktur abgleichen kann. Ein konsistentes Trust-Management wäre jedoch bei
längeren Ketten problematisch, weil jeder Partner in der Regel seine eigene
Sicherheitsinfrastruktur hat.
Die durch WS-Security beschriebenen Konzepte, etwa WS-Trust oder die von OASIS definierte
SAML-Spezifikation, liefern die Basis für den Aufbau von Vertrauensketten. Die Security Assertion
Markup Language (SAML) ist eine XML-basierende Auszeichnungssprache für Sicherheitsbestätigungen.
Sie stellt Funktionen bereit, um sicherheitsbezogene Informationen zu beschreiben und zu
übertragen. In föderativen Lösungen können der Webserviceverbraucher und der -Anbieter mit einem
zusätzlichen Identitätsdienst, der als Trusted Third Party dient, in verschiedenen Kombinationen
miteinander in Beziehung treten.
Vom Standpunkt der Technik und der Standards aus ist die Absicherung einer serviceorientierten
Architektur kein Problem mehr. Vollständige Security Frameworks mit Programmbibliotheken und
Werkzeugen zum Aufbau von Services sind mittlerweile bei allen Anbietern von Infrastrukturlösungen
verfügbar.
Im Allgemeinen gilt auch bei der Absicherung einer serviceorientierten Architektur, das
Gleichgewicht zwischen Security und Performance beziehungsweise Benutzerfreundlichkeit zu finden.
Sicherheit sollte nicht für eine gesamte Infrastruktur oder den ESB ein- oder ausgeschaltet sein,
sondern nur bei Bedarf, gezielt an bestimmten Punkten greifen. Security sollte bereits vor dem
Aufbau einer SOA beginnen, und zwar mit der sicherheitsrelevanten Prüfung der einzelnen darin
abzubildenden Prozesse und dem entsprechenden Design der Teilabläufe. Genauso wichtig ist das
Aufstellen einer sinnvollen und durchsetzbaren Policy, auf deren Basis die Dienste konfiguriert
werden.
Eine Hilfestellung für alle Aspekte dieser schwierigen Aufgabe des Aufbaus einer
serviceorientierten Architektur bieten externe Berater. Sie können beim Aufsetzen einer Strategie
und Roadmap für die SOA, der Analyse von Sicherheitsaspekten sowie in der Umsetzung
unterstützen.
Lesen Sie mehr zum Thema
