7 SOA und Security
7.5 Security-Implementierungen
7.5.1 Architekturpattern
Lösungen, die heute auf Basis einer SOA implementiert werden, sind auch immer verteilte Systeme. Zurzeit werden diese Lösungen meist noch ausschließlich unter-nehmensintern genutzt, aber es ist abzusehen, dass diese Beschränkung in nicht allzu ferner Zukunft fallen wird.
Services werden also zukünftig über Unternehmensgren-zen hinweg verwendet werden. Somit sind die auch bis-her geltenden Basisanforderungen wie Authentifizierung, Autorisierung, Integrität, Vertraulichkeit und Nichtab-streitbarkeit auf verteilte Anwendungen im SOA-Umfeld anzuwenden.
Zur Umsetzung dieser Sicherheitsaspekte gibt es eine Reihe von akzeptierten Security-Standards aus dem Umfeld einiger etablierter Standardisierungsgremien.
Diese Standards können schon bei der Implementierung der Services genutzt werden, sind aber relativ komplex in
der Anwendung und haben zu viele Freiheitsgrade bei der Umsetzung.
Aus diesem Grund haben sich neben der Implementie-rung der sicherheitsrelevanten Funktionen direkt in der Applikation zwei Ansätze herausgebildet, die auf diesen Security-Standards basierend die Implementierung einer sicheren SOA ermöglichen wollen:
Security as Infrastructure versucht dabei, die sicher-heitsrelevanten Dienste als Teil der Infrastruktur zu implementieren, häufig als sogenannte „Appliance“, die an zentraler Stelle zum Einsatz kommen muss.
Security as a Service greift den SOA-Gedanken auf und stellt die Sicherheitsfunktionen zentral als Service bereit. Diese können dann von allen anderen Kompo-nenten einer SOA genutzt werden.
Mit Embedded Security bezeichnet man in diesem Umfeld den Ansatz, die Security-Funktionen durch die Applikation selbst zu implementieren. Dies kann sowohl bei verteilten als auch monolithischen Imple-mentierungen erfolgen. Dieser Ansatz kann selbstver-ständlich auch in einer SOA umgesetzt werden, dies ist aber nicht empfehlenswert.
Client
+ Unabhängig von Infrastruktur - Keine zentrale Administration
- Jeweils proprietare Lösung der Security (Kompatibität)
- Keine Trennung von Applicationen und Security
+ Wiederverwendbarkeit der Security + Zentrale Management der Security
+ Applikationslogik und Security sind getrennt - Vertrauen zum Security Service muss vorhanden sein
+ Applikation und Security sind getrennt
+ Security Implementierungist individuell bekannt - Security Implementierungist nur individuell bekannt
- Individuelle Infrastruktur gefährdet die Kompatibilität
Abbildung 52: Entwurfsmuster für SOA Security
„Security as a Service“ bietet dabei eine nahtlose Inte-gration des SOA-Gedankens und wird im Folgenden als bevorzugte Lösung beschrieben. Dies setzt allerdings voraus, dass die zugrundeliegende Infrastruktur bereits den Sicherheitsanforderungen entspricht. Lücken an dieser Stelle haben daher Lücken in den darauf aufsetzen-den Diensten zur Folge. Ausserdem ist zu berücksichtigen, dass die Verfügbarkeit und die Performance dieser Servi-ces höchsten Anforderungen genügen muss. Performance Probleme bei den Security Services beeinträchtigen alle Applikationen, die diese einbinden.
7.5.2 Security Services für eine SOA
Bei der Definition der notwendigen Dienstgruppen kann auf Erfahrungen mit schon im Einsatz befindlichen ver-teilten Systemen zurückgegriffen werden. Im Folgenden sind nur die Security-relevanten Dienstgruppen aufge-führt. Hier hat sich eine Aufteilung in folgende Bereiche als sinnvoll erwiesen:
Security Services: In den Security Services befinden sich alle grundlegenden Funktionen, hier werden die
Crypto-Algorithmen und Basisprotokolle angeboten.
Außerdem werden hier an zentraler Stelle die im Sys-tem nutzbaren Authentifizierungsprotokolle zur Verfü-gung gestellt. Die Bandbreite reicht dabei von User-ID/
-Passwort über die Unterstützung von Smartcards bis zu biometrischen Verfahren. Die Art und Qualität des Authentifizierungsverfahrens wird dabei meist in der dann etablierten Session des Benutzers abgelegt. Diese Information steht danach für die Autorisierung zur Verfügung.
Auch die Autorisierungsverfahren werden auf dieser Ebene implementiert. Diese haben einen Sonderstatus im System, da sie sowohl zur personenbezogenen Autorisie-rung genutzt werden als auch für die AutorisieAutorisie-rung der einzelnen Services untereinander (keine Benutzerinterak-tion). Die Autorisierung wird meist als Policy Enforcement bezeichnet, da die Entscheidungen häufig auf Policies basieren, in denen die Security-Anforderungen des Service hinterlegt sind. Diese werden gegen die Benutzerinfor-mationen und eventuell weitere (Meta-)Daten wie z. B.
die Qualität der Authentifizierung geprüft. Erst dann wird entschieden, ob der Zugriff gestattet wird.
Application Layer
Application 1 Application n
Session Federation
SSO
Provisioning Logging
Reporting Monitoring
Auditing Profile
Rollen
AuthZ AuthN
PKI
Crypto
Session Session
Session Session
Value-Added Services
Security Services
Data Virtualization Layer
Abbildung 53: Beispielimplementierung einer SOA
Value-added Services stellen Dienste wie Benutzer, Rollen und Profile Management zur Verfügung. Wenn notwen-dig, ist hier die Public-Key-Infrastruktur (PKI) angesiedelt.
Das Benutzermanagement ist kein originärer Security Ser-vice, es ist aber für den sicheren und effizienten Betrieb unabdingbar. Das Benutzermanagement kümmert sich um die workflowgestützte automatisierte Provisionie-rung der Benutzer auf alle nachgelagerten Systeme. Dies bezieht die attributgestützte Rechtevergabe in Form von Zuweisung von Policies und/oder Rollen mit ein. Neben dem zeitnahen und vollständigen Anlegen der Benutzer auf allen vorgesehen Systemen ist das zeitnahe Entzie-hen (De-Provision) des Benutzers fast noch wichtiger. Die hierzu notwendige Workflow Engine sollte als Basisdienst der SOA vorhanden sein, dieser wird von den Security Services genutzt.
Mittels des Rollenmanagements werden die in den Systemen vorhandenen Rollen erfasst, vereinheitlicht und in ein globales Rollenmodell gewandelt. Dabei muss es möglich sein, sowohl ein flaches Rollenmodell für einfache Implementierungen als auch komplexere mehrdimensionale Modelle abbilden zu können. Werden im Rollenmanagement auch Systemrollen gehalten, muss hier eine Abbildung auf das jeweilige Zielsystem definiert werden können.
Die definierten Rollen können nun mittels des Benutzer-managements für die Zuweisung und – sehr viel wichti-ger – für den Entzug von Rechten genutzt werden.
Das Profile Management verwaltet die Sicherheitsanfor-derungen der einzelnen Services und Applikationen mit Bezug auf unterschiedliche Kontexte. In einem Profil sind alle für einen zu implementierenden Service notwendi-gen Subservices und ihre Kommunikationsbeziehunnotwendi-gen verzeichnet. Damit können ihnen, basierend auf dem durch die Risikoanalyse ermittelten Bedrohungspotenzial, Sicherheitsmechanismen unterschiedlicher Güte und/
oder spezielle Verfahrensweisen zugewiesen werden.
Zur Verschlüsselung oder Signierung von Nachrichten werden Zertifikate benötigt. Diese können von einer
eigenen PKI erstellt werden oder von einem externen Dienstleister bezogen werden. Es ist darauf zu achten, dass die PKI eine Schnittstelle zur Integration in Webser-vices-Protokolle hat.
Session Services: Der Session Service beschäftigt sich mit der Generierung und dem Verwalten der User Sessions, dem Single Sign-on und dem Single Log-out. Der Session Service ist kein originärer Security Service, da aber im Besonderen der Punkt Single Log-out Auswirkungen auf die Security des Gesamtsystems hat, soll er hier erwähnt werden.
Muss man über Unternehmensgrenzen hinaus tätig werden und akzeptiert die Forderung nach durchgehen-der Authentifizierung und Autorisierung, werden die Federation Services benötigt. Prinzipiell geht es darum, autonomen Organisationen ohne zentrale Instanz die Zusammenarbeit zu ermöglichen, indem ein Mechanis-mus gefunden wird, mit dem existierende Benutzerkon-ten mit Zustimmung des Benutzers in Relation gesetzt werden können. Der Federation Service arbeitet eng mit dem Session Service zusammen, um auch organisations-übergreifend Sessions aufbauen zu können.
Logging Services: Jede Aktion innerhalb des Systems muss protokolliert werden, dies schließt Aufrufparameter und Rückgabewerte ein.
Der Logging Service ist kein originärer Security Service.
Da jedoch häufig kein einheitliches Logging-Verfahren existiert und auch die Formate sich unterscheiden, wird hier die Forderung nach einem einheitlichen, übergreifen-den und revisionssicher implementierten Logging Service aufgestellt.
Monitoring Services: Dieser Service dient der Überwa-chung aller Aufrufe, dem Tracing im Fehlerfall sowie der Überwachung der Services. Er ist als Service implemen-tiert, um ihn auch auf dem Service-Level (ohne Benutzer-interaktion) im Zugriff zu haben.
Audit Services dienen der Speicherung aller relevanten Informationen wie Service-Aufrufe, Ergebnisse etc. Die
gesamte Historie ist abgelegt und kann im Rahmen inter-ner oder exterinter-ner Prüfungen abgerufen werden.
Reporting Services: Basierend auf den Logging-Daten müssen (nahezu) beliebige Reports möglich sein. Dieser Service ist damit die Grundlage für die Entwicklung eines Management-Cockpits für die Sicherheitslage. Der Zugriff darf dabei natürlich nur berechtigten Benutzern gestat-tet sein. Dieser Dienst ist als Service ausgelegt, um ihn anderen Services zur Verfügung stellen zu können. Hier werden Benachrichtigungsmechanismen wie E-Mail oder SMS implementiert.
Häufig sind weite Teile der oben angesprochenen Services durch Identity- und Access-Management-Systeme imple-mentiert. Das Identity Management System kümmert sich dabei um die Bereitstellung der Benutzer und aller relevanten Informationen. Das Access Management System kümmert sich um die Bereiche Authentifizierung und Autorisierung. Idealerweise stützen sich dabei beide auf dieselben Basisdienste und passen sich auch in das Monitoring-, Audit- und Reporting-Framework ein.
Die eigentliche Herausforderung einer solchen Architek-tur besteht in der Einbindung der bestehenden Appli-kationen und Standardprodukte in neue SOA-basierte Dienste. Diese Kombination erschwert die Umsetzung von Sicherheitsaspekten auf Ebene der einzelnen Dienste. Als Ausweg bietet sich hier die Kapselung der Altanwendun-gen mit anschließender Integration in das Gesamtkonzept an. „Security as a Service“ stellt dabei einen vielverspre-chenden Lösungsansatz zur Umsetzung dar, mit dem die Anwendungen im SOA-Umfeld erstellt werden können.
Sollten sich im Laufe der Entwicklung oder des Betriebes Neuerungen bei den Security-Komponenten ergeben, sind diese durch den modularen Aufbau sofort im Gesamtsys-tem präsent und können sofort eingebunden werden.
7.5.3 Lösungsansätze
In diesem Abschnitt werden mögliche Lösungsansätze aufgezeigt. Diese können dabei den verschiedenen Schichten Geschäftsprozess, Applikation und Middleware
(die Ebene Netzwerk wird hier nicht eigens betrachtet) zugeordnet werden.
Geschäftsprozess
Schon auf der Geschäftsprozessebene sind die Anforde-rungen bezüglich Vertraulichkeit, Integrität und Verfüg-barkeit zu formulieren. Wie bereits erwähnt müssen sich dazu die Fachbereiche und die IT-Abteilungen auf eine gemeinsame Sprache und Metrik verständigen. Einen wichtigen Messparameter stellt das Risiko dar. Um diesen Parameter ermitteln zu können, muss man z. B. im Risiko-management verankerte Schadens- und Häufigkeitsklas-sen verwenden und einen Bedrohungskatalog entwickeln, der sowohl von den Fachbereichen als auch von den IT-Abteilungen verstanden und akzeptiert wird.
Applikation
Im Übergang zu einer SOA werden bestehende Applika-tionen häufig mit Webservice-Schnittstellen versehen, um in eine SOA-Umgebung eingebunden werden zu können. Diese Schnittstellen bieten andere Angriffsmög-lichkeiten als im Umfeld herkömmlicher Applikationen;
diese müssen analysiert werden. Typische Angriffe auf XML-Basis können durch den Einsatz von Web Application Firewalls, die auch als XML Gateways fungieren, verhin-dert werden. Ob ein XML Filtering als Security Service oder als Komponente der Infrastruktur realisiert wird, hängt von mehreren Parametern wie Kosten, Zeit für die Umset-zung, Anforderungen an die Wiederverwendbarkeit des XML-Filters oder die Verfügbarkeit ab.
Zudem ist zu überlegen, ob auf Applikationsebene eine Verschlüsselung oder Signatur notwendig ist. In Bezug auf Webservices kann die Verschlüsselung auf SOAP- bzw. XML-Ebene erfolgen. Dabei können auch nur Teile der Nachricht verschlüsselt oder signiert werden. Die Verschlüsselung oder Signatur kann sowohl von der Applikation selbst oder durch entsprechende Webservices vorgenommen werden.
Middleware
Wenn die Umsetzung einer SOA schon etwas fortge-schritten ist, wird der Einsatz eines Enterprise Service Bus (ESB) meist unvermeidlich, um die implementierten Services verwalten zu können. Der ESB wird als Ver-mittlerschicht zwischen den Webservices eingesetzt.
Dadurch entstehen eine ganze Reihe neuer Fragestellun-gen bezüglich der Sicherheit, die mithilfe der Fragestellun-genannten Security Services gelöst werden können. Hier einige Beispiele:
Bei asynchroner Kommunikation werden Queues oder Buffer als Zwischenspeicher für Messages verwendet.
Diese können vertrauliche Daten beinhalten, die vor unautorisiertem Zugriff geschützt werden müssen.
Aus diesem Grund kann es notwendig sein, Buffer des ESB zu verschlüsseln.
Für Transaktionssicherheit muss der ESB zustand-sorientiert arbeiten. Weiter müssen Transaktionen geeignet autorisiert werden. Hier benötigt man Authentisierung und rollenbasierte Vergabe von Berechtigungen – nicht nur für Personen, sondern auch für Webservices.
Auf Service-Ebene ist die Kommunikation zu regeln, z. B. kann eine Kommunikation zwischen zwei Services nicht erlaubt sein. Die Kommunikationskanäle werden hier durch Regeln oder Policies des ESB konfiguriert.
Webservices rufen über den ESB andere Webservices ab. Hier ist die Authentizität von Webservices, z. B.
über kryptografische Methoden (auch auf XML-Basis), sicherzustellen.
Die genannten Lösungsansätze müssen zudem in die Unternehmenskultur passen und durch operative Prozesse (ITIL-Prozesse wie Patch-, Config-, Change- und Incident-Management) unterstützt werden.