Sichere Kommunikation in der Föderation
(Web-)Services als User
In dem Maße, wie Service-orientierte Architekturen Unternehmen zu mehr Innovationen und Agilität verhelfen, führen sie zu neuen Herausforderungen bezüglich Sicherheit und Governance. Mit richtlinienbasierten Schutzkonzepten, die neue Web-Security- und Federation-Techniken adaptieren, können Sicherheitsverantwortliche gegensteuern und IT-Services als neue "User" in das Sicherheits-Management einbinden.
Ungeachtet ihrer wachsenden Verbreitung stehen Service-orientierte Architekturen (SOA) und Web-Services in der Kritik. Denn die Vorteile vereinfachter Integration und der Mehrfachnutzung von Services beim Aufbau überbetrieblicher Prozessketten gibt es nicht gratis. Insbesondere in Sachen Sicherheit müssen sich die Unternehmen neuen Anforderungen stellen. Eine zum Jahreswechsel vorgestellte 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 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-Registry, die Registrierung 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 vornehmen kann: von der einfachen Dienstunterbrechung bis hin zur Datenverfälschung, -verzögerung, -löschung oder -erzeugung sowie zum Mitlesen sensibler Daten.
Vereinfachend ausgedrückt gelten sämtliche Web/Internet-relevanten Risikoszenarien, da das Service-Zugriffsprotokoll SOAP (Simple Object Access Protocol) 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. Letztlich muss über eine Anzahl von Mittlern (Intermediaries) zwischen den beteiligten beiden Endpunkten der Prozesskette ein ausreichender Sicherheitskontext aufrechterhalten werden.
Security-Basisaufgaben beim Web-Services-Betrieb
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 M2M-Verfahren (Machine-to-Machine), die automatisiert ohne weitere Anwendereingriffe ablaufen.
Traditionelle Perimeterschutzmaßnahmen wie Virenscanner, Firewalls bis hin zu Web-Filtertechniken auf Anwendungsebene verlieren deshalb nicht ihre grundlegende Bedeutung. Die sichere Kommunikation zwischen Web-basierten 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-Levels und deren Überwachung sowie die Verbindlichkeit verteilter Transaktionen durch die Aufbewahrung von Log-Daten.
Praktische Erfahrung vorhanden
Die gute Nachricht lautet, dass für diese Aufgaben mittlerweile eine Vielzahl bewährter Praxiserfahrungen, Standards und Techniken verfügbar ist. Weniger erfreulich ist, dass das Zusammenspiel der einzelnen "Sicherheitsbausteine" für den Betrieb und die Überwachung föderativer Web-Services sorgfältigst zu planen ist. WS Security beispielsweise erweitert die "gewöhnlichen" Web-Services-Protokolle um eine Art Behälter für sicherheitsrelevante Informationen, wobei übr XML Encryption für die Vertraulichkeit und XML Signature für die Integrität sorgen. Verschlüsselung und digitales Signieren sind bekannte Fingerübungen, wenngleich im Detail stets zu klären ist, in welcher Reihenfolge die Schritte abzulaufen haben und/oder 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 (Certification Authority, CA) einer PKI (Public Key Infrastructure) zur Verfügung stellt.
Weitaus aufwändiger ist die Beantwortung 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 - ausgetauscht, um die durchgängige Sicherheit zu bewerkstelligen. Dabei werden im Vergleich zu klassischen Anwendungsarchitekturen die Frage der Zugriffsberechtigung nicht mehr im System verdrahtet, sondern Authentifizierung und Autorisierung getrennt als eine Art wiederverwendbarer Dienst auf der Anwendungsebene angegangen.
Credentials und SAML
Allgemein muss sich ein Service-Konsument gegenüber einem zuvor meist unbekannten Service-Provider authentisieren. Dies geschieht mittels eines Identifikations- und Berechtigungsnachweises (Credentials). Damit belegt der Anfragende, 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 ein zentraler Security-Token-Service (STS) verantwortet. Konkret hat sich zum Aufbau einer solchen Architektur für die Identity Federation die von CA maßgeblich geprägte SAML (Security Assertion Markup Language) 2.0 als der bedeutendste Standard entwickelt. Durch die volle Unterstützung von Microsoft im Rahmen des neuen Geneva-Frameworks zur Implementierung 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ürdigen 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. Das SAML Token legt des Weiteren unmissverständlich fest, dass ein Subjekt von einer Instanz zu einem bestimmten Zeitpunkt authentifiziert beziehugnsweise identifiziert wurde. Ü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.
Föderation von Sicherheitsinformationen
Die genannten Techniken liefern alle notwendigen Bausteine, um die End-to-End-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-Tokens in den Richtlinien für Autorisationsentscheidungen nutzen. Spezielle Web-Service-Security-Lösungen unterstützen IT-Abteilungen dabei, die einzelnen Bausteine in eine gemeinsame Sicherheitsarchitektur einzubetten und durch den zentralen Management- sowie Konfigurationsansatz die Betriebsaufwände gering zu halten.
Es wird die Grundlage zur Steuerung eines richtlinienbasierten Sicherheits-Managements gelegt, in dessen Rahmen getreu dem Web-Service-Gedanken Sicherheitslogik entlang der kompletten Prozesskette orchestriert und durchgesetzt wird. Teile einer Prozesskette lassen sich auf diesem Weg ebenso wie einzelne Services im Rahmen der End-to-End-Sicherheit Federation-tauglich gestalten.
Letztlich wird hier durch die Föderation der Sicherheitsinformationen für Services technisch umgesetzt, was für das konventionelle Wirtschaftsleben eine Selbstverständlichkeit ist: Man will wissen, mit wem man Geschäfte macht, ob das Gegenüber ein verlässlicher Partner ist und ob alle Gesetze oder Rahmenbedingungen eingehalten werden. Allerdings werden die Geschäfte hier nicht von Personen, sondern von Web-Services durchgeführt.
Lesen Sie mehr zum Thema
