"Ohne Sicherheit sind Web-Services eine Totgeburt", urteilt Phillip Hallam-Baker, Principal Scientist beim Sicherheitsspezialisten Verisign. Der Experte sieht in Web-Services "den Traum unserer Generation zur Verwirklichung von reibungslosem E-Commerce", weil sie eine Möglichkeit darstellen, Schnittstellen-Kosten zu reduzieren und den Zugriff auf Legacy-Systeme zu vereinfachen. Zudem hätten sie das Potenzial, Softwareentwicklungs- und Wartungskosten für die Anwender zu reduzieren.
So verlockend dies auch klingen mag, ohne ausreichende Sicherheitsmechanismen werden Anwender wohl nicht so ohne weiteres mitspielen, glauben die Analysten sowohl von Evans Data Corp. als auch der Hurwitz Group. Sie sehen in fehlender End-to-end-Security das größte Hindernis für die Akzeptanz von Web-Services in Unternehmen. Auch Mark Bauhaus, Vice President Java Web Services bei Sun Microsystems, räumt ein, das Thema Sicherheit sei derzeit noch eine "große Herausforderung", die es zu meistern gelte.
Vielfältige Anforderungen
Die besonderen Sicherheitsanforderungen für Web-Services erklären sich durch den speziellen Charakter des dahinter stehenden Ansatzes. In einem White Paper definiert IBM Web-Services als "in sich abgeschlossene und selbstbeschreibende modulare Applikationen, die über das Internet veröffentlicht, lokalisiert und aufgerufen werden können. Sie führen Funktionen aus, die von einfachen Abfragen bis hin zu komplexen Geschäftsanwendungen reichen können."
Was diese Definition nicht erwähnt, ist zum einen der Umstand, dass das Zusammenspiel der einzelnen Softwaremodule per definitionem unabhängig von der darunter laufenden Plattform möglich ist. Ein Großteil der Kommunikation findet mehr oder weniger automatisch zwischen verschiedenen Rechnern oder Anwendungen statt - im Gegensatz zum bisherigen Modell sind Menschen nur noch bei vergleichsweise wenigen Transaktionen direkt involviert. Hinzu kommt, dass sich ein Web-Service nahezu überall befinden kann, auch in einer Umgebung, deren Sicherheitsanforderungen unter Umständen nicht so hoch sind, wie es sich ein Unternehmen vielleicht wünschen würde. Hallam-Baker erklärt: "Im Grunde machen Web-Services nichts anderes als das, was Anwendungen immer getan haben: Sie rufen Subroutinen auf. Der Unterschied liegt darin, dass die Subroutinen heute wer weiß wo sind. Darin liegt die Herausforderung."
Damit in einem derart komplexen und wenig übersichtlichen Umfeld geschäftskritische Abläufe abgebildet werden können, bedarf es eines hohen Maßes an Sicherheit. Die Integrität und die Authentizität übertragener Informationen sowie die Vertraulichkeit von Transaktionen müssen gewahrt bleiben, damit Inhalte nicht manipuliert oder falsche Inhalte als echte präsentiert werden. Außerdem ist es notwendig, die Identität und die Autorisierung der an einem Prozess teilnehmenden Einheiten zu überprüfen, aufgrund derer sie auf Informationen zugreifen oder Dienste nutzen können. Einen wichtigen Baustein für die Sicherheit von Web-Services stellt zusätzlich das Thema Verbindlichkeit oder Unabstreitbarkeit (englisch Non-Repudiation) dar: Es muss sichergestellt werden, dass keiner der an einer Transaktion Beteiligten diese im Nachhinein abstreiten kann.
SSL nur eingeschränkt tauglich
Verschiedene Ansätze werden in diesem Zusammenhang diskutiert. Bei Transaktionen im Web-Umfeld kommt häufig das Protokoll Secure Sockets Layer (SSL) zum Einsatz, um HTTP-Übertragungen abzusichern. Banken setzen das Verfahren, das Authentifizierung und Verschlüsselung unterstützt, beispielsweise ein, um ihren Kunden den sicheren Online-Zugriff auf ihre Konten zu ermöglichen. Da HTTP auch Web-Services transportiert, würde es nahe liegen, hier ebenfalls SSL zu verwenden.
"Dazu ist SSL aber nur bedingt tauglich", warnt Mark O''Neill, Chief Technology Officer beim Sicherheitsspezialisten Vordel. Da SSL den kompletten Datenstrom verschlüsselt, würden wichtige Routing-Informationen, die mit Hilfe des Simple Object Access Protocol (Soap) ebenfalls übertragen werden, nicht mehr ausgelesen werden. Außerdem ist SSL nur für Punkt-zu-Punkt-Verbindungen geeignet, ermöglicht kein Signieren der Informationen.
Web-Services selbst sehen keine Mechanismen vor, um die genannten Anforderungen zu erfüllen. Verschiedene Gremien beschäftigen sich deshalb damit, auf Basis der Extensible Markup Language (XML), die sich zum Quasi-Standard für Web-Services entwickelt hat, Erweiterungen zu definieren, die wenn schon nicht alle, so doch einige der Schwachstellen ausräumen.
Die von der Organization for the Advancement of Structured Information Standards (Oasis) im November 2002 in Version 1.0 verabschiedete Spezifikation Security Assertions Markup Language (SAML) beispielsweise stellt eine Möglichkeit für Web-Services dar, sich gegenseitig zu identifizieren und Informationen bezüglich ihrer Authentizität auszutauschen. Das geschieht in Form so genannter Security Assertions, die Anwendern, Applikationen oder einem Web-Service zugewiesen und in LDAP-Directories vorgehalten werden können.
Generell unterscheidet man drei verschiedene Arten von Assertions (Authentication, Attribute und Authorization), die von getrennten Instanzen ausgestellt und überprüft werden. Assertions bestätigen die Identität einer Person oder eines Objekts, außerdem lassen sich mit ihrer Hilfe bestimmte statische oder dynamische Eigenschaften (zum Beispiel Position in einer Firma oder Kontostand eines Kunden) definieren und überdies festhalten, welche Rechte ihm zugewiesen und welche Sicherheitsregeln damit verknüpft sind.
Notwendigkeit digitaler Identitäten
Mit SAML lassen sich Single-Sign-on-Systeme realisieren: Nach einmaligem Anmelden an einem System kann der Nutzer auf weitere, damit verbundene Dienste zugreifen, ohne sich erneut anmelden zu müssen. Die SAML-Spezifikation bildet die Grundlage für die Arbeit der von Anbietern wie Sun, Cisco, RSA Security oder General Motors initiierten Liberty Alliance, die sich zum Ziel gesetzt hat, eine herstellerneutrale, offene Lösung für föderierte digitale Identitäten zu erarbeiten. Liberty hat bereits eine technische Spezifikation entwickelt, die derzeit in Version 1.1 vorliegt und bei Oasis zur Standardisierung eingereicht wurde, um sie in einer nächsten Version von SAML zu integrieren
Ein ähnliches Ziel wie Liberty verfolgen Microsoft und IBM mit der "Global XML Web Services Architecture" (GXA). Diese setzt auf dem von beiden Unternehmen gemeinsam mit Verisign entworfenen Sicherheitskonzept "WS-Security" auf, das inzwischen ebenfalls zur Standardisierung an Oasis weitergeleitet wurde. WS-Security erweitert Soap um Funktionen wie Verschlüsselung und digitale Signaturen. IBM und Microsoft wollen eigenen Angaben zufolge SAML damit nicht ersetzen, sondern vielmehr ergänzen.
WS-Security fußt auf den beiden eng miteinander verwandten Techniken XML Signature und XML Encryption. Mit diesen lässt sich sicherstellen, dass die Integrität und Vertraulichkeit von Transaktionen gewahrt bleibt. Während Verschlüsselung hauptsächlich dazu dient, Übertragungen vor neugierigen Blicken zu schützen, lässt sich mit Hilfe digitaler Signaturen überprüfen, ob eine Nachricht auch tatsächlich vom richtigen Absender abgeschickt wurde. Vertraulichkeit und Integrität sind deswegen wichtig, weil mehrere Parteien an einer Transaktion beteiligt sein können. Jede darf nur diejenigen Teile einer Nachricht zu sehen bekommen, die tatsächlich für sie bestimmt sind.
Die Spezifikationen für XML Signature und XML Encryption hat das World Wide Web Consortium (W3C) bereits als Empfehlungen veröffentlicht. Sie besitzen damit also den Status von Standards und wurden nach Angaben des Gremiums auch schon in Produkte implementiert. Beide Verfahren bieten die Möglichkeit, entweder das komplette Dokument oder aber nur Teile davon zu signieren beziehungsweise zu verschlüsseln.
Komplette Verschlüsselung nicht erwünscht
Diesen Aspekt hält Sun-Manager Bauhaus für besonders wichtig, denn "es ist nicht wünschenswert, alles zu verschlüsseln". Besonders für den bereits erwähnten Fall, dass Web-Services Routing-Funktionen von Soap nutzen, würde die teilweise Verschlüsselung eine sinnvolle Alternative zu SSL darstellen. Gateways wären in der Lage, die für das Routing wichtigen Informationen auszulesen, alle sonstigen zu übertragenden Daten blieben ihnen jedoch verborgen.
An einem weiteren, besonders für die Verschlüsselung und Signierung wichtigen Standard feilen W3C und Internet Engineering Task Force (IETF) derzeit noch: XML Key Management Specification (XKMS) beschreibt Protokolle für das Erzeugen, Verteilen und Registrieren von öffentlichen Schlüsseln. Anders ausgedrückt, stellt die Technik Public-Key-Infrastructure-(PKI-)Funktionen für Web-Services bereit, "ohne den Anwender mit der Komplexität einer PKI-Lösung zu belasten", erklärt Verisign-Mann Hallam-Baker.
Sein Unternehmen bietet seit über einem Jahr einen XKMS-Service an, den Kunden mit Hilfe eines "Trust Service Integration Kit" nutzen können. In enger Verbindung zu SAML steht außerdem die XML Access Control Markup Language (XACML). Damit lässt sich definieren, wer auf welche Informationen in Dokumenten zugreifen kann und wie sich diese Informationen übermitteln lassen.
Gesamtbild noch lückenhaft
Die genannten Ansätze zur Absicherung von Web-Services machen deutlich, dass der Industrie viel an diesem Thema liegt und mit Hochdruck an der Entwicklung von Sicherheitslösungen gearbeitet wird. Sun-Spezialist Bauhaus beklagt jedoch die "für Entwickler und Unternehmen gleichermaßen überwältigende Anzahl von Standards und Spezifikationen". Er fordert daher eine Vereinfachung, damit sich Anwender besser zurechtfinden.
Außerdem bleibt das Gesamtbild noch lückenhaft: So existiert bisher kein standardisiertes Verfahren, das das Problem der Verbindlichkeit beziehungsweise der Unwiderrufbarkeit von Web-Services-Transaktionen regelt. Nach Ansicht von Brian Roddy, Vice President Engineering bei Reactivity, stellen existierende Spezifikationen wie XML Signature oder WS-Security jedoch "gute Werkzeuge" dar, um dieses Problem zu lösen. Der Hersteller hat unter der Bezeichnung Web-Services Non-Repudiation (WSNR) eine eigene, darauf aufsetzende Spezifikation entwickelt, die er vorantreiben und als Norm etablieren will.
Vordel-CTO O''Neill weist zudem darauf hin, dass der Einsatz von Web-Services eine Herausforderung für Firewalls darstellt. Derzeit können diese nur so konfiguriert werden, dass sie Soap-Messages entweder komplett blocken oder aber durchlassen. In einer Situation, in der Web-Services über die Grenzen von Unternehmensnetzen hinweg miteinander kommunizieren, sollten Firewalls aber Soap-Messages tatsächlich verstehen können, um von Fall zu Fall über ihre Zulässigkeit entscheiden zu können.
Im Rahmen eines Projekts mit dem US-Provider Qwest hat sich auch Microsoft eingehender mit den drängenden Sicherheitsfragen beschäftigt, die nicht unbedingt durch WS-Security gelöst werden. Qwest bietet bereits eine große Anzahl von Web-Services, die zunehmend auch wichtige Geschäftsabläufe unterstützen. 48 Programmierer haben innerhalb von drei Monaten mit Qwest das Common Services Framework (CSF) erarbeitet, das unter anderem eine Möglichkeit bieten soll, eine einheitliche Sicherheitslösung für die eingesetzten Web-Services bereitzustellen.
Wie Frederick Chong, Software Design Engineer bei Microsoft, beschreibt, stellt CSF eine Art Vermittlungsstelle für Web-Services dar. Diese werden dort zusammen mit individuellen Zugriffsregeln registriert. Kunden von Qwest, die einen Web-Service abonnieren wollen, müssen sich zunächst ebenfalls registrieren lassen. Über eine CSF-Laufzeitumgebung können die Web-Services genutzt werden: Sie setzt die zuvor festgelegten Sicherheitsregeln durch, protokolliert und überwacht die Transaktionen und ist für das Routing der Nachrichten zuständig.
Aus Sicht von Chong handelt es sich bei CSF um ein "sehr flexibles Modell", das es Qwest erlaubt, das bestehende LDAP-Directory weiter zu nutzen und zudem die vorhandenen "RSA-Cleartrust"-Produkte einzubinden. Ungelöst blieben Aspekte wie die Ende-zu-Ende-Vertraulichkeit oder Integrität der Übertragungen. Auch ist die Unabstreitbarkeit der Transaktionen zum jetzigen Zeitpunkt noch nicht umgesetzt. Ob Microsoft CSF als Produkt auch anderen Anwendern bereitstellen wird, ist unklar.
Aus Sicht von Andrew Nash, Director of Technology and Standards bei RSA Security, könnte eine separate Sicherheitslösung viele Probleme lösen, ohne die Komplexität unnötig zu erhöhen. Ähnlich wie Firewalls, die Geräte innerhalb eines Unternehmensnetzes absichern, vermöchte so ein System zwischen Web-Services innerhalb einer vertrauten Umgebung und solchen in unsicheren Zonen zu vermitteln. "Das würde Unternehmen die Möglichkeit geben, Regeln zu definieren, die gleichermaßen für alle Web-Services gelten", erläutert der Spezialist.
So wäre denkbar, dass eine bestimmte Gruppe von Web-Services untereinander mit relativ geringer Sicherheit kommuniziert. Sobald eine Transaktion jedoch einen definierten vertrauten Bereich oder sogar das Unternehmensnetz verlässt, greift die Komponente ein und fügt auf Basis bestimmter Regeln Sicherheitsmerkmale ein, ein Kerberos-Ticket oder Ähnliches. Aus Sicht von Nash würde diese Vorgehensweise vieles vereinfachen, weil sich die Entwickler der jeweiligen Anwendungen um Sicherheit überhaupt nicht zu kümmern bräuchten.
Dem stimmt Verisign zu: Mit "Trust Gateway" will der Hersteller im Juni eine Lösung auf den Markt bringen, die genau nach diesem Prinzip funktioniert. Über eine zentrale Konsole legen Administratoren dabei fest, welche Sicherheitsparameter für Web-Services-Transaktionen gelten sollen, das Gateway setzt diese dann auf Basis von WS-Security um. Im dritten Quartal will Vordel mit einer ähnlichen Security-Appliance nachziehen, die es gemeinsam mit Chrysalis-IST entwickelt.
RSA selbst hat mit "Bsafe Secure-WS" unlängst ein Produkt vorgestellt, das Unternehmen beim Entwickeln von sicheren Web-Services auf Basis von WS-Security unterstützt. Es stellt Ver- und Entschlüsselung, Signierung und Überprüfung von Soap-Messages gemäß der WS-Security-Spezifikation dar und ist für verschiedene Authentifikationsverfahren oder SAML-Assertions erweiterbar.
Angeklickt
- Ohne aureichende Sicherheitsmechanismen werden Web-Services die Unternehmensgrenzen nicht überschreiten.
- Die Herausforderung liegt in der Integrität und Authentizität der ausgetauschten Informationen sowie in der Vertraulichkeit und Verbindlichkeit von Transaktionen.
- XML-basierende Standardisierungsbemühungen forcieren zwar die Security-Themen, ausgereifte Verfahren für alle Aspekte gibt es aber noch nicht.
- Um Web-Services trotz der momentan noch fehlenden Sicherheitsstandards zu etablieren, gehen Hersteller pragmatisch vor.
Sicherheitsstandards
Security Assertions Markup Language (SAML):
XML-Framework, das eine Möglichkeit für Web-Services darstellt, sich gegenseitig zu identifizieren und Informationen bezüglich ihrer Authentizität auszutauschen. Das geschieht in Form so genannter Security Assertions, die Anwendern, Applikationen oder einem Web-Ser-vice zugewiesen und in LDAP-Directories vorgehalten werden können.
XML Encryption:
Legt eine Syntax für die Verschlüsselung von XML-Dokumenten fest. Die vom W3C verabschiedete Spezifikation sieht vor, dass auch nur Teile eines Dokuments verschlüsselt werden. Voraussetzung für WS-Security (siehe unten).
XML Signature:
Vom W3C verabschiedete Norm zur digitalen Signatur von XML-Dokumenten, die auch Bestandteil von WS-Security ist. Damit lässt sich sicherstellen, dass ein Dokument auch tatsächlich vom angegebenen Sender verfasst wurde.
XML Key Management Specification (XKMS):
XML Encryption, XML Signature und ihre kombinierte Anwendung in WS-Security erfordern kryptografische Schlüssel. XKMS beschreibt Protokolle für das Erzeugen, Verteilen und Registrieren von öffentlichen Schlüsseln, stellt also Funktionen einer Public Key Infrastructure (PKI) für Web-Services bereit.
XML Access Control Markup Language (XACML):
Steht in enger Verbindung zu SAML und ermöglicht das Definieren von Zugriffsrechten für bestimmte Dokumente. Legt außerdem fest, wie diese Informationen übermittelt werden.
WS-Security:
Von IBM, Microsoft und Verisign erarbeitete Spezifikation, die Soap um Funktionen wie Verschlüsselung und digitale Signaturen erweitert. WS-Security soll IBM und Microsoft zufolge SAML nicht ersetzen, sondern vielmehr ergänzen. WS-Security fußt auf den beiden eng miteinander verwandten Techniken XML Signature und XML Encryption.