Die Anforderungen an die Aspekte beziehungsweise Disziplinen von Security im SOA-Umfeld sind im Prinzip die gleichen wie in jeder anderen IT-Umgebung: Identitäten und Berechtigungen müssen verwaltet, Benutzer authentisiert, Zugriffsberechtigungen überprüft, Zugriffe und Zugriffsversuche aufgezeichnet, Daten mittels kryptografischer Methoden signiert (Integrität) oder verschlüsselt (Vertraulichkeit) werden. All diese Prozesse unterliegen einer Sicherheitsrichtlinie (Policy), deren Einhaltung (Compliance) zu überwachen, zu administrieren und permanent sicherzustellen ist.
Fazit
Es wird empfohlen, bei SOA-Implementierungen die Security-Aspekte von Anfang an in allen Projektphasen einzubeziehen. Durch diese Vorgehensweise lässt sich der häufig anzutreffende Fehler vermeiden, dass Security erst nachträglich einer fast oder ganz fertigen Lösung aufgesetzt wird. Eine solche Vorgehensweise wäre gefährlich, denn es könnte sich herausstellen, dass eine Designänderung erforderlich wird, um Sicherheitslücken zu schließen. Diese wird dann entweder unter Zeitdruck weggelassen oder nicht ausreichend getestet. So entstehen unsichere Systeme, außerdem drohen unnötige Kosten.
Hier lesen Sie …
Leitfaden zur sicheren SOA
SOA ohne Security ist undenkbar. Neben den klassischen Aufgaben gibt es auch spezielle, durch den verteilten Ansatz von SOA bedingte Sicherheitsanforderungen. Es empfiehlt sich, eine in das Gesamtmodell eingebettete Architektur zugrunde zu legen. Folgende Punkte gilt es dabei zu beachten:
Eine Grundsatzentscheidung ist darüber zu treffen, welche Security-Funktionen ihrerseits als Services der Infrastruktur realisiert werden sollen.
Die klassischen Aufgaben der Security müssen nicht neu erfunden werden, sie bekommen allenfalls SOA-spezifische Ausprägungen: Identitäten verwalten, Authentisierung, Autorisierung, Auditing, Kryptografie, Policies und Compliance.
Bedingt durch die Heterogenität einer SOA entstehen zusätzliche Anforderungen an die Umwandlung von Identitäten sowie die Herstellung von Vertrauensbeziehungen (Trust).
Das Einbetten in die Gesamtarchitektur sollte im Rahmen des IT-Service-Managements geschehen.
Die Aufgaben der SOA-Security zerfallen in die drei Bereiche Security-Management, Security-Policy-Infrastruktur sowie die eigentlichen Security-Services.
Die Security-Services fassen die genannten Aufgaben zu Funktionsblöcken zusammen: Identity, Authentication, Authorization/Privacy, Data/Message Protection und Auditing.
Die Policy-Infrastruktur ist verantwortlich für die Administration der Policies (Regeln), ihre Ableitung aus den geschäftlichen Vorgaben, ihre Verteilung an die Laufzeitumgebung, das Herbeiführen regelbasierender Entscheidungen (Policy Decision) sowie deren Umsetzung (Policy Enforcement). Die Regeln sind Bestandteil der Servicebeschreibungen. Sie definieren, wie mit den Services zu kommunizieren ist und welche Randbedingungen dabei einzuhalten sind.
Security-Management beinhaltet die Tools und Schnittstellen, die zur Bereitstellung and Verwaltung einer sicheren und stabilen Laufzeitumgebung zur Verfügung stehen.
Für die Erfolgskontrolle einer SOA-Lösung kommt dabei dem Auditing eine besondere Rolle zu. Es unterstützt unter anderem Security-Audits, welche die Korrektheit der Implementierung des Systems überprüfen.
Unabdingbar für das Zusammenspiel der Komponenten einer SOA-Umgebung ist die Verwendung von standardisierten Formaten und Protokollen: für Security sind dies beispielsweise WS-Trust, SAML, Kerberos, XACML, CBE, PKI.
Da es sich bei SOA typischerweise um das Zusammenspiel verteilter Anwendungskomponenten handelt, kommen allerdings weitere Aufgaben hinzu: Neben der häufigen Umwandlung von Identitäten sowie der Formate (Token), in denen diese präsentiert werden, ist dies der Einsatz von Industriestandards sowie die Wiederverwendbarkeit der Security-Dienste selbst.
Ein Service für den Service
Gerade der letzte Punkt erfordert eine Grundsatzentscheidung: Will man die Sicherheitsfunktionen als Service der Infrastruktur realisieren und somit die einzelnen Anwendungen von dieser Aufgabe weitgehend befreien, oder lassen sich bestimmte Dinge nur im Kontext der Anwendung realisieren? Die Vorteile einer Service-Infrastruktur liegen auf der Hand: Die Anwendungsentwickler sind von der häufig doch recht komplexen Sicherheitsthematik entlastet und können sich ganz auf die Business-Logik konzentrieren. Außerdem müssen sie so das Rad nicht immer wieder neu erfinden.
Idealerweise ist die Sicherheit in eine übergeordnete SOA-Referenzarchitektur eingebettet. Aus Platzgründen kann auf dieses Thema hier nicht weiter eingegangen werden. Wie eine solche Architektur aussehen könnte, lässt sich in einem Whitepaper mit dem Titel "IBM SOA Foundation: Providing what you need to gest started with SOA" nachlesen, das im Internet unter www.ibm.com/software/solutions/soa/soa_and_ibm.html zur Verfügung steht.
Neben den Core-Services enthält dieses Modell unterstützende Module (Supporting Components), unter anderem auch eines für das IT-Service-Management. Darin enthalten sind zahlreiche Überwachungs- und Management-Komponenten sowie alles, was für die Sicherheit notwendig ist. Hier knüpft eine SOA-Security-Referenzarchitektur an, die aus den drei logischen Blöcken "Security-Services", "Security-Policy-Infrastructure" und "Security-Management" besteht und im Folgenden weiter aufgeschlüsselt und erläutert wird.
Security-Services
Zentrale Security-Services können von verschiedenen Komponenten genutzt werden. Neben den Endbenutzern und den Diensteanbietern sind dies beispielsweise Infrastrukturkomponenten wie Gateways, Proxies, Anwendungsserver, Datenbankserver und Betriebssysteme. Durch Mehrfachverwendung der Dienste erreicht man Konsistenz und Einsparung von Kosten. Die Liste der Services selbst entspricht den klassischen Disziplinen, wichtig sind die Schnittstellen und der Abstraktionsgrad:
• Identity Services umfassen Benutzerverzeichnisse sowie gegebenenfalls deren Abgleich (falls es mehrere davon gibt), Provisionierung von Benutzerdaten, verbunden mit der dazugehörenden Identity-Management-Funktionalität, sowie - besonders verbreitet im SOA-Umfeld - die Unterstützung voneinander unabhängiger Systeme, sei es im gleichen Unternehmen oder unternehmensübergreifend (Identity Federation).
• Authentication Services sollen unterschiedliche Verfahren (zum Beispiel Passwort, Zertifikat, Token, Biometrie) und Protokolle (etwa Kerberos) bereitstellen, mit deren Hilfe sich ein Benutzer ausweisen kann. Im SOA-Umfeld (speziell bei Web-Services) kann dies sowohl bei einem Service-Consumer als auch bei einem Service-Provider geschehen. Auch eine Umwandlung einer einmal festgestellten Identität auf ein anderes Format kommt häufig vor.
• Authorization & Privacy Services ermöglichen die Entscheidung, ob ein Zugriff eines Benutzers auf eine bestimmte Ressource erlaubt ist. Grundlage hierfür ist eine Policy, die Bezug nimmt auf die Identität des Benutzers sowie dessen relevante Attribute. Die Aufgaben sind verteilt zwischen Policy Decision Point (PDP - Entscheidungsfindung) und Policy Enforcement Point (PEP - Entscheidungsdurchsetzung).
• Data & Message Protection Services schützen die eigentlichen Nachrichten beziehungsweise Teile (Elemente) davon vor Einsichtnahme (Confidentiality), Manipulation (Integrity), Fälschung des Absenders und Wiederholung einer Nachricht. Dies kann auf Basis des Transportkanals geschehen (zum Beispiel SSL, was jedoch nicht typisch für SOA ist) oder auf Basis der einzelnen Nachrichtenpakete oder ausgewählter Elemente.
• Audit-Services bieten eine zentrale Infrastruktur zum Erstellen, Speichern und Verwalten von relevanten Ereignissen. Dies können beispielsweise Anmeldeversuche, Verletzungen einer Policy, Ausfälle von Security-Servern oder Zugriffe auf sensitive Daten sein. Eine Auditing-Policy legt das Verhalten dieser Dienste fest.
Damit die hier genannten Dienste auch wirklich wieder verwendbar sind, müssen unbedingt geeignete Standards verwendet werden. Als Beispiel sei der Bereich Web-Services Security genannt. Näheres zum diesem Thema lesen Sie im Artikel "Im Dschungel der SOA-Security-Standards" in dieser Ausgabe.
Security Policy Infrastructure
Policies im Kontext einer SOA sind idealerweise in einer Top-Down-Struktur formuliert, wobei sich auf der obersten Ebene die Business-Policies befinden. Diese werden jeweils zu service-spezifischen Richtlinien verfeinert, aus denen wiederum die Anforderungen an das Verhalten der Infrastruktur entstehen. Soweit möglich, sollten diese Verfeinerungen automatisiert werden. Ist eine zentrale Service-Registry vorhanden, lässt sich diese als Speicher für die Policies verwenden, von dem sie weiterverteilt werden. Es muss jedoch festzustellen sein, welches die jeweils gültigen Policies sind. Außerdem sind Änderungen zu protokollieren, damit immer klar ist, welche Policies wann aktiv waren.
Im Kontext der Security-Policy-Infrastruktur lassen sich die Regeln grob in folgende Kategorien unterteilen:
• Interaction Policies beschreiben, wie mit den Services zu kommunizieren ist. Dazu gehören das Festlegen der Erreichbarkeit des jeweiligen Dienstes (Protokoll, Adresse), die Definition der Anforderungen in Bezug auf den Schutz der Daten (Verschlüsselung, Signaturen) sowie die notwendigen Identitätsdaten des Nutzers.
• Provider Policies umfassen im weitesten Sinne die Bedingungen, unter denen ein Service zur Verfügung steht (Authentifizierung, Autorisierung, Datenschutz, Auditierung).
• Service-Metadaten kommen ins Spiel, wenn mehrere Dienste mit unterschiedlichen Provider-Policies zusammenspielen. In ihnen finden sich Trust-Beziehungen sowie Angaben dazu, wie die Weitergabe (gegebenenfalls nach Umformung in ein anderes Format) von Identitäten und Attributen zu erfolgen hat.
Daneben gehören zur Security Policy Infrastruktur noch die Funktionen Policy-Management, Policy Decision Points, Policy Enforcement Points sowie Policy Transformation & Distribution.
Unter Policy-Management verstehen wir in diesem Zusammenhang das Erzeugen, Löschen, Verwalten und Importieren/Exportieren der gerade beschriebenen Policies. Ein Policy Decision Point (PDP) verwendet diese Policy-Daten, um eine Entscheidung darüber herbeizuführen, ob der gerade erfolgende Request zugelassen werden soll oder nicht. Diese Entscheidung wird wiederum einem Policy Enforcement Point (PEP) zur Verfügung gestellt, der die eigentlichen Zugriffe überwacht und über die Mittel verfügt, diese zu gestatten oder zu unterbinden. Durch diese Arbeitsteilung ist es möglich, mit einem zentralen PDP mehrere - auch verschiedene - spezialisierte PEPs zu betreiben, deren Mechanismen der Art des jeweiligen Zugriffs angepasst sind (zum Beispiel HTTP-Proxys für HTTP-Requests oder Kernel-Exit für Unix-Systemaufrufe).
Policy Transformation & Distribution beschreibt, in welchen Formaten die zu verteilenden Policies zu formulieren und gegebenenfalls zu transformieren sind. Soweit möglich, sollten hier Standards wie WS-Policy, WS-Security Policy oder XACML verwendet werden. Die Verteilung der Policies muss ebenfalls abgesichert erfolgen. Schließ-lich werden in einer SOA-Umgebung spezielle Tools und Schnittstellen benötigt, um die Stabilität und Sicherheit der Laufzeitumgebung zu gewährleisten. (ave)