Wenn der Web-Service zum User wird
Sichere Wechsel in der Föderation
Im selben Maße wie service-orientierte Architekturen (SOAs) Unternehmen zu mehr Innovationen und Agilität verhelfen, führen sie zu neuen Herausforderungen in puncto Sicherheit und Governance. Mit richtlinienbasierenden Schutzkonzepten, die neue Web-Security- und Federation-Techniken adaptieren, können die Sicherheitsverantwortlichen gegensteuern und IT-Services als neue "User" in das Sicherheits-Management einbinden.
Ungeachtet ihrer wachsenden Verbreitung stehen service-orientierte Architekturen und
Web-Services in der Kritik. Denn die Vorteile einer vereinfachten Integration und die
Mehrfachnutzung von Services beim Aufbau überbetrieblicher Prozessketten gibt es nicht umsonst.
Besonders in Sachen Sicherheit müssen sich die Unternehmen neuen Anforderungen stellen. Eine Studie
von GMG Insights belegt diese Entwicklung nachdrücklich. Laut der Untersuchung "Global Report on
SOA/Web Services Security Initiatives", die in Kooperation mit CA erstellt wurde, berichtete nahezu
jeder IT-Manager, dass die SOA/Web-Services seines Unternehmens bereits mehrfach Ziel von Angriffen
waren. 43 Prozent bezeichneten deshalb Sicherheit als den kritischsten Punkt im Rahmen einer
SOA-Implementierung. 57 Prozent bestätigten des Weiteren, dass aufgrund der Sicherheitsproblematik
in ihrer Organisation die Adaption von Web-Services langsamer voranschreite.
Die Ursache hierfür liegt in der Natur service-orientierter Infrastrukturen: Die
unkontrollierbare Verbreitung der dynamisch genutzten Web-Services erhöht den Betriebs- und
Überwachungsaufwand. Zugleich fallen im Rahmen service-orientierter Infrastrukturen zusätzliche
Schwachstellen ins Gewicht. Technische Bestandteile, wie Service-Registratur, die Registration oder
Deregistrierung von Services, die Suche nach Services sowie die Verbindungsaufnahme und
Kommunikation zwischen Services, sind lohnenswerte Objekte für einen Angreifer, der hier die ganze
Palette von Angriffen – von der einfachen Dienstunterbrechung bis hin zur Datenverfälschung,
Datenverzögerung, Datenlöschung oder Datenerzeugung oder zum Mitlesen sogar sensibler Daten –
ausüben kann.
Vereinfachend ausgedrückt gelten sämtliche Web/Internet-relevanten Risikoszenarien, da das
Service-Zugriffsprotokoll SOAP die Protokolle der Internet-Anwendungs- und Transportarchitektur
(vornehmlich TCP und HTTP) nutzt. Hinzu gesellt sich mit dem Standard XML zur Repräsentation der
Daten ein weiterer Angriffspunkt für Manipulationen. Dass an dieser Stelle komplexe
Service-Prozessketten zu betrachten sind, die nicht mehr unter einer einheitlichen Verwaltung und
Kontrolle stehen, erschwert die Aufgabe zusätzlich. Schlussendlich muss über eine Anzahl von
Intermediären zwischen den beteiligten beiden Endpunkten der Prozesskette ein ausreichender
Sicherheitskontext aufrechterhalten werden.
Grundsätzlich unterscheiden sich die sicherheitsbezogenen Aufgaben im
SOA-/Web-Services-Betrieb allerdings kaum von den bekannten Anforderungen traditioneller
Anwendungen. Sie umfassen die Punkte der Berechtigung (Autorisierung zur Nutzung) der
Vertraulichkeit (Schutz vor unberechtigtem Lesen), Integrität (unverändertes Eintreffen der
Nachricht), Glaubwürdigkeit (Authentifizierung), Verbindlichkeit (Nicht-Abstreitbarkeit) sowie
Verfügbarkeit und Ausfallschutz. Im Unterschied zu den bisherigen Schutzmaßnahmen müssen sie die
Sicherheit über komplexe Prozessketten garantieren, deren Services von verschiedenen Anbietern aus
unterschiedlichen Bereichen (Domänen) stammen. Und: Man beschäftigt sich hier häufig mit
MtM-Verfahren (Machine-to-Machine), die automatisiert ohne weitere User-Eingriffe ablaufen.
Traditionelle Perimeter-Schutzmaßnahmen wie Virenscanner, Firewalls bis hin zu
Web-Filtertechniken auf Anwendungsebene verlieren deshalb nicht ihre grundlegende Bedeutung. Die
sichere Kommunikation zwischen web-basierenden Anwendungselementen und Services verlangt allerdings
zusätzlich eine
zentralisierte Zugangskontrolle für Transaktionen zwischen föderativen Applikationen,
den Schutz der Vertraulichkeit der übermittelten Nutz- und Kontrolldaten auf Nachrichtenebene
durch Chiffrierung,
den Schutz der Integrität der übermittelten Nutz- und Kontrolldaten durch digitale
Signaturen,
die Sicherung der Ende-zu-Ende-Verfügbarkeit durch Service Level und deren Überwachung sowie
die Verbindlichkeit verteilter Transaktionen durch Aufbewahrung von Log-Daten.
Die erfreuliche Botschaft lautet, dass für diese Aufgaben mittlerweile eine Vielzahl
bewährter Praxiserfahrungen, Standards und Techniken verfügbar sind. Weniger erfreulich ist, dass
das Zusammenspiel der einzelnen "Sicherheitsbausteine" für den Betrieb und die Überwachung
föderativer Web-Services sorgfältig zu planen ist. WS Security beispielsweise erweitert die "
gewöhnlichen" Web-Services-Protokolle um eine Art Behälter für sicherheitsrelevante Informationen,
wobei über XML Encryption die Vertraulichkeit und über XML Signature die Integrität realisiert
werden.
Verschlüsselung und digitales Signieren sind bekannte Fingerübungen, wenn auch im Detail
stets zu klären ist, in welcher Reihenfolge die Schritte zu geschehen haben und welcher Part der
Nachricht wie behandelt werden soll. Das Management der Signier- und Chiffrierschlüssel lässt sich
über die XML Key Management Specification (XKMS) bewerkstelligen, die ein Standardprotokoll zur
Zertifizierungsautorität einer PKI (Public Key Infrastructure) zur Verfügung stellt.
Weitaus aufwändiger (und spannender) ist das Lösen der Fragen nach Berechtigung und
Glaubwürdigkeit. Schließlich liegt es in der Natur überbetrieblicher Service-Ketten, dass
Informationen zu Autorisierung und Authentifizierung zwischen den beteiligten Sicherheitsdomänen
auszutauschen sind. Mit der Identity Federation (Föderation von Identitäten) steht ein tragfähiges
Konzept zur Problemlösung parat, das dem grundlegenden SOA-Ansatz der losen Kopplung folgt. Ähnlich
wie sich verschiedene Services per Nachrichtenaustausch zu einem vollständigen Geschäftsprozess
orchestrieren, werden im Rahmen der Föderation Informationen zur Identität – gleich ob Mensch oder
Maschine – gewechselt, um die Ende-to-Ende-Sicherheit zu bewerkstelligen.
Allgemein muss sich ein Service-Konsument gegenüber einem zuvor meist unbekannten
Service-Provider authentisieren. Dies geschieht mittels eines Identifikations- und
Berechtigungsnachweises (Credential). Mit diesem weist der Anfragende nach, dass er auf bestimmte
Ressourcen zugreifen oder ausgewählte Aktionen auslösen darf. Die Credentials werden typischerweise
als Security Token (in gesicherter Form!) gespeichert, dessen Ausgabe, Prüfung, Erneuerung und
Entwertung von einer zentralen Security Token Service (STS) verantwortet wird. Konkret hat sich zum
Aufbau einer solchen Architektur für das Identity Federation die von CA maßgeblich geprägte SAML
(Security Assertion Markup Language (SAML) 2.0 als der bedeutendste Standard entwickelt. Durch die
volle Unterstützung von Microsoft im Rahmen des neuen Geneva-Framework zum Implementieren von
Verbundsicherheitsszenarien gab die von OASIS (Organization for the Advancement of Structured
Information Standards) definierte XML-Auszeichnungssprache einen zusätzlichen Schub, während es um
die ähnlich gelagerte Initiative WS-Federation deutlich stiller wurde.
In so genannten Assertions ("vertrauenswürdige Aussagen") zu Personen, Maschinen und Services
ermöglicht SAML die Informationen zu Authentifizierung, Autorisierung etc. in einem SAML Token zu
spezifizieren und über verschiedene Vertrauensbereiche zu transportieren. Dies setzt natürlich
voraus, dass zum einen die Assertions von einer vertrauenswürdigen Autorität (STS) erstellt werden
und sich zum anderen die jeweiligen SOA-Einheiten in ihrem jeweiligen Sicherheitskontext
identifizieren lassen.
Über Attribute lassen sich dem Subjekt ausgewählte Rechte zuweisen, die der PDP (Policy
Decision Point) zur Entscheidung heranziehen kann, ob eine Autorisierung besteht. Veranlasst und
durchgesetzt wird die Sicherheitsrichtlinie von dem PEP (Policy Enforcement Point). Dieser erzeugt
aus der Service-Anfrage an einen Service eine SAML-Nachricht mit Informationen zum nachfragenden
Service und zum nachgefragten Dienst an den PDP. Dort werden die erforderlichen Schritte zur
Überprüfung beim Richtlinien-Server eingeleitet. Anhand des Ergebnisses legt der PDP fest, ob die
Nachricht an einen Web-Service geblockt wird, ob sie passieren darf und welche Berechtigung sie
besitzt. Um Autorisierungsinformationen zwischen Services verschiedener Prozesse und
Sicherheitskontexte standardisiert auszutauschen oder zu delegieren, wurde SAML mit XACML
(eXtensible Access Control Markup Language) ein Vokabular zur Definition von Autorisierungsregeln
einschließlich deren Auswertung zur Seite gestellt.
Die genannten Techniken liefern alle notwendigen Bausteine, um die Ende-to-Ende-Sicherheit
föderativer Web-Services mit Leben zu füllen. WS Security mit XML Encryption und XML Digital
Signature schützt die Vertraulichkeit und Integrität der Nachrichten, über XKMS lassen sich
PKI-Infrastrukturen einbinden und die SAML-Token in den Richtlinien für Autorisationsentscheidungen
nutzen. Lösungen wie CA SiteMinder, CA Federation Manager oder CA SOA Security Manager unterstützen
IT-Abteilungen dabei, die einzelnen Bausteine in eine gemeinsame Sicherheitsarchitektur einzubetten
und durch den zentralen Management- sowie Konfigurationsansatz den Betriebsaufwand gering zu
halten. Es wird die Grundlage zur Steuerung eines richtlinienbasierenden Sicherheits-Managements
gelegt, in dessen Rahmen, getreu dem Web-Service-Gedanken, Sicherheitslogik entlang der kompletten
Prozesskette orchestriert und durchgesetzt wird.
Kurt Denk ist Director Solution Sales bei CA in Darmstadt.
Lesen Sie mehr zum Thema
