War die Koordination und Integration übergreifender E-Business-Prozesse bislang eine mühevolle und kostspielige Sisyphos-Arbeit, so versprechen Webservices neue Wege der Zusammenarbeit im Internet. Mit ihnen kann man externe Dienste aufrufen und deren Funktionen nutzen, als ob es systeminterne Module wären.
Außenstehende können Webservices verwenden, ohne die dahinterliegende Software-Infrastruktur zu kennen. Unabhängig von Programmiersprache oder Betriebssystem, lokal oder irgendwo im Internet, suchen sich Anwendungen dynamisch die benötigten Funktionen und setzen sie ein. Das funktioniert, weil die Schnittstelle jedes Dienstes standardisiert ist. Die Software-Module kommunizieren miteinander über Internet-Protokolle wie TCP/IP oder HTTP .
Webservices sind weder eine neue Programmiersprache noch das Produkt eines einzigen Software-Herstellers. Es handelt sich vielmehr um einen Standard des W3C, auf den sich Software-Hersteller wie IBM, HP, SAP und Microsoft geeinigt haben. Dieser setzt sich aus SOAP, UDDI und WSDL zusammen, die alle auf XML beruhen.
Den größten Nutzen werden Webservices im B2B-Bereich bringen, da sie die Abwicklung von Bestell- und Liefervorgängen sowie anderen Geschäftsprozessen deutlich vereinfachen. Eine Anwendungsintegration lässt sich über Webservices erheblich einfacher implementieren als über eventuell bereits bestehende EDI-Schnittstellen. Für Business-Anwendungen bedeutet dies, dass die leidige Frage nach der Integrations-Software zwischen zwei proprietären Systemen, der so genannten Middleware, entfällt.
Grundsätzliche Sicherheitsprobleme
Webservices sind eine hochleistungsfähige Technologie - wären da nicht die Sicherheitsbedenken, die eine massive Verbreitung derzeit behindern, wie eine Studie von Cap Gemini Ernst & Young zeigt. Zu ähnlichen Erkenntnissen kommt eine aktuelle Umfrage der Meta Group. Danach beschäftigen sich zwar 78 Prozent aller deutschen Unternehmen mit dem Thema Webservices, konkrete Projekte betreiben aber nur 20 Prozent der befragten IT-Verantwortlichen. Als Hauptgrund für die zögerliche Umsetzung nannten 81 Prozent der Unternehmen Bedenken hinsichtlich der Datensicherheit.
Die Vorbehalte der Firmen sind nicht aus der Luft gegriffen. Denn anders als andere Technologien sind Webservices mit spezifischen Sicherheitsproblemen konfrontiert, die sich durch ihren Charakter erklären. Im Vergleich zu klassischen Webanwendungen erhöhen vor allem zwei Punkte das Sicherheitsrisiko:
Webservices dienen selten der Interaktion mit einem Benutzer. Im Vordergrund steht die direkte Kopplung von Anwendungs-Servern. Ein Großteil der Kommunikation findet somit automatisch zwischen Rechnern und Applikationen statt. Menschen sind nur noch bei wenigen Transaktionen beteiligt. Dies erhöht das Sicherheitsrisiko, da Manipulationen schnell bis in die Backend-Systeme durchschlagen.
Weitaus schwerer wiegt die Tatsache, dass es kaum möglich ist zu kontrollieren, wo ein Webservice abläuft. Er kann sich überall befinden, auch in einer Umgebung mit sehr geringen Sicherheitsanforderungen, die dem aufrufenden Unternehmen normalerweise nicht genügen würden.
Sicherheitsanforderungen
Um geschäftskritische Anwendungen in komplexen und unübersichtlichen Umgebungen zu betreiben, müssen bestimmte Sicherheitsforderungen erfüllt sein. Webservices müssen gewährleisten, dass die Integrität und Authentizität der ausgetauschten Informationen sowie die Vertraulichkeit und Verbindlichkeit von Transaktionen gegeben ist.
Für jeden Geschäftsprozess muss eindeutig feststellbar sein, wer sich dahinter verbirgt (Authentizität) und ob der Teilnehmer berechtigt ist, auf die Information zuzugreifen und diese zu verwenden (Autorisierung). Nutzer und Anbieter eines Webservice weisen ihre Identität also gegenüber dem jeweiligen Kommunikationspartner nach, und bestimmte Mechanismen stellen sicher, dass nur zugelassene Nutzer auf Webservices zugreifen können. Allerdings soll sich auch nicht jeder Teilnehmer gegenüber jedem anderen identifizieren müssen - statt dessen werden Zusicherungen über Identitäten weitergereicht, eine Vertrauenskette wird aufgebaut.
Weiterhin dürfen Inhalte nicht manipulierbar sein, die Integrität der Daten muss also stets garantiert sein. Und schließlich soll die Vertraulichkeit der übertragenen Daten durch Verschlüsselung gewährleistet sein, so dass ein Mitlesen der Daten durch Unbeteiligte unmöglich ist.
Ein zentraler Baustein bei Webservices sind zusätzlich die Schlagwörter Verbindlichkeit und Unabstreitbarkeit (Non-Repudiation). Non-Repudiation bedeutet, dass keiner der an einer Transaktion Beteiligten diese im Nachhinein abstreiten kann. Sowohl Sender als auch Empfänger einer Nachricht müssen zweifelsfrei nachweisen können, dass erstens der Sender die Nachricht auch wirklich verschickt hat, und dass zweitens der Empfänger die gleiche Nachricht auch wirklich erhalten hat.
Sicherheitsrisiko SOAP und HTTP
Die meisten Webservices verwenden zum Nachrichtenaustausch SOAP (Simple Object Access Protocol). SOAP ist ein mit XML-Syntax arbeitendes Kommunikationsprotokoll für Webservice-Anwendungen, die Dienste nachfragen oder anbieten. Das Protokoll verwendet als Transportmedium in erster Linie HTTP und ist unabhängig von der verwendeten Programmiersprache sowie dem jeweiligen Betriebssystem.
SOAP als Kommunikationsprotokoll und HTTP als Transportprotokoll unterstützen in ihrer Basisform keinerlei Sicherheitsmechanismen, da die Zielsetzung bei der Festlegung des Standards Einfachheit war. Der Nachteil: Sämtliche Daten werden im Klartext übermittelt, so dass jeder den HTTP-Verkehr, also auch die transportierten SOAP-Nachrichten, mitlesen kann. Beide Protokolle bieten auch keine Konzepte für die Anforderungen im Bereich Authentifizierung, Autorisierung und Datenintegrität.
Ein zusätzliches Sicherheitsproblem entsteht durch die Übertragung von Informationen und Anfragen an Webservices über HTTP. Da der HTTP-Verkehr normalerweise über den Port 80 einer Firewall übertragen wird, können Angriffe an der Firewall vorbeigeleitet werden. Die Manipulation eines HTTP-GET- oder POST-Parameters stellt aus der Sicht der Anwendung einen Angriff dar, aus Firewall-Sicht handelt es sich aber um eine legale HTTP-Transaktion. Die Schwäche entsteht durch die Möglichkeit der Programmsteuerung über SOAP-Nachrichten, die an der Firewall vorbeigeschleust werden. Dies kann zu Datenspionage, Datendiebstahl oder zur Störung des Betriebs von Anwendungen führen.
Die wichtigsten Security-Ansätze: SSL
Einige der Security-Anforderungen für Webservices lassen sich mit vorhandenen Techniken realisieren. Bei Sicherungsmaßnahmen für Webtransaktionen kommt heute meist das SSL-Protokoll zum Einsatz. Es sorgt für einen sicheren Übertragungstunnel zwischen HTTP-Client und HTTP-Server.
SOAP-Nachrichten können anstatt über HTTP auch über Secure HTTP transportiert werden. Dabei wird HTTP mit dem SSL-Zusatzprotokoll verbunden. Da HTTPS die ganze Übertragung mittels Public-Key-Verfahren codiert, ist der gesamte Nachrichtenaustausch verschlüsselt und ein fremdes Mitlesen unmöglich. Da der Client eine Nachricht auch unterschreiben und der Webservice seine Identität gegenüber dem Client beweisen kann, ist auch eine Authentifizierung via SSL realisierbar. SSL-Client-Zertifikate oder eine grundlegende Authentifizierung über HTTP lassen sich relativ einfach einsetzen, da sie für den Webservice selbst transparent sind.
Das auf der Transportebene ansetzende SSL bietet also Vertraulichkeit und Authentifizierung. Doch für die umfangreiche Absicherung der Webservices ist SSL nicht tauglich, denn die Vertraulichkeit der Daten ist lediglich zwischen zwei Knoten und nicht etwa von Beginn bis Ende der Übermittlungskette gewährleistet. Da SSL nur den Tunnel authentifiziert und nicht die SOAP-Nachricht, ist der Absender zum Beispiel nicht mehr sicher zu ermitteln, sobald die Nachricht beim Service ankommt. Für den Nachrichtenaustausch, bei dem die Nachricht zuverlässig den Empfänger erreicht beziehungsweise die Unzustellbarkeit der Nachricht dem Sender gemeldet wird, gibt es bei HTTP und HTTPS keine Lösung.
Vor allem aber braucht die neue Generation von Webservices wie oben erwähnt zusätzlich noch weitere Eigenschaften neben Vertraulichkeit und Authentifizierung. Deshalb muss SSL durch zusätzliche Sicherheitsmaßnahmen ergänzt werden.
SAML
Da SSL die Sicherheitsprobleme von Webservices nicht grundsätzlich löst, sind andere Mechanismen nötig. Verschiedene Gremien und Unternehmenszusammenschlüsse beschäftigen sich derzeit damit, Erweiterungen zu definieren, die die Schwachstellen beseitigen sollen. Diese Erweiterungen basieren auf der Ebene von XML, das sich zum Quasi-Standard für Webservices entwickelt hat.
Die Security Assertions Markup Language (SAML) ist eines dieser Verfahren, mit dem sich Webservices gegenseitig identifizieren. SAML ermöglicht insbesondere die Realisierung von Single-Sign-On-Systemen.
SAML wurde Ende 2002 von der Organization for the Advancement of Structured Information Standards (OASIS) standardisiert. Grundsätzlich liefert es einen Rahmen für die Definition von Benutzerauthentifizierungen, Autorisierungen, Berechtigungen und Profilinformationen in XML-Dokumenten. Dies geschieht in Form von "Security Assertions", die Nutzern, Anwendungen oder einem Webservice zugewiesen und in LDAP-Verzeichnissen verwaltet werden. Drei getrennte Instanzen stellen drei allgemeine Arten von Assertion-Anweisungen aus und überprüfen diese: Authentifizierung, Autorisierung und Attribut. Diese drei Anweisungen benutzt man an verschiedenen Stellen in der Anwendung, um festzustellen, wer die Anfrage stellt, was angefordert wird und ob die Anfrage genehmigt wurde oder nicht.
Eine der Stärken von SAML ist dabei seine Fähigkeit, mit beliebigen Sicherheitssystemen interoperieren zu können. SAML unterstützt beinahe alles, beginnend mit Passwörtern über Hardware-Tokens bis hin zu Public Keys und Zertifikaten. SAML hat auch die Unterstützung für XML-Signatures eingebaut, womit es sich nicht nur für Authentifizierung und Autorisierung einsetzen lässt, sondern auch für die Gewährleistung der Integrität und die Unbestreitbarkeit von Nachrichten.
Auf der SAML-Spezifikation setzt die Liberty Alliance auf. Die Allianz aus etwa 160 Unternehmen - darunter Sun, Cisco, RSA und General Motors - will eine herstellerunabhängige offene Lösung für digitale Identitäten erarbeiten und hat mit der Version 1.1 bereits eine technische Spezifikation entwickelt. Sie soll in die nächste Version von SAML integriert werden.
WS-Security
Ein alternatives Konzept zu SAML ist WS-Security. Web Service Security kann als umfassendes Framework betrachtet werden, das alle relevanten Punkte zum Thema Sicherheit bei Webservices beinhalten soll. Der Standard wurde von Microsoft, IBM und Verisign ausgearbeitet und inzwischen an OASIS übermittelt, die für die weitere Entwicklung zuständig ist.
WS-Security definiert einen Rahmen zur Einbettung von Benutzer- und Sicherheitsinformationen in eine SOAP-Nachricht. Es liefert keine fertige Lösung für alle Sicherheitsproblembereiche, sondern stellt lediglich das Fundament dar, auf das bestimmte Sicherheitsspezifikationen aufbauen.
WS-Security ist so ausgelegt, dass es eine breite Palette von Sicherheitsmodellen wie SSL, SAML, Kerberos oder Public-Key-Infrastrukturen (PKI) zulässt. Zusätzlich erweitert WS-Security SOAP um Verschlüsselungs- und Signaturfunktionen, die auf XML Signature und XML Encryption basieren. Dabei beschreibt WS-Security, wie sich die dort definierten Kopfzeilen zur Gewährleistung der Integrität, Vertraulichkeit und Authentizität der Nachrichten im Kopfzeilenbereich der SOAP-Nachrichten einfügen lassen.
WS-Security unterstützt eine detaillierte Auflösung bei der Anwendung von digitalen Signaturen, indem es zulässt, dass jede einzelne SOAP-Kopfzeile und der eigentliche Inhalt der Nachricht unabhängig voneinander digital signiert werden können. Somit lassen sich zwischen zwei Endpunkten Signaturen je nach Bedarf individuell hinzufügen.
Auf WS-Security setzt die "Global XML Webservices Architecture" (GXA) von Microsoft und IBM auf, die eine Alternative zu der von Sun geführten Liberty Alliance darstellen soll. Dabei bildet WS-Security die Basis für andere Sicherheitsspezifikationen:
WS-Policy soll Sicherheitsvorkehrungen und Einschränkungen beschreiben
WS-Trust wird ein Framework für Vertrauensmodelle
WS-Privacy enthält Datenschutzmechanismen
WS-Secure-Conversation behandelt die sichere Kommunikation
WS-Federation beschäftigt sich mit Vertrauensverhältnissen in heterogenen Umgebungen
WS-Authorization handelt von Authorisierungsdaten und -richtlinien.
Weitere Ansätze: XKMX und XACML
Während WS-Security und SAML weit gehend einsatzfähig sind, befindet sich die XML Key Management Specification (XKMS) noch im Ausarbeitungsstadium. XKMS wird vom W3C und der Internet Engineering Task Force (IETF) vorangetrieben und soll eine Public-Key-Infrastruktur für Webservices zur Verfügung stellen. XKMS sorgt insbesondere für Kompatibilität unter verschiedenen PKIs. In der Spezifikation werden sowohl der Austausch als auch die Überprüfung von Zertifikaten mit Hilfe von XML beschrieben. Dabei kümmert sich X-KISS um die Authentifizierung der Zertifikate mittels Abfrage beim entsprechenden PKI-Dienstleister, während X-KRSS für das Management der Zertifikate - also die Ausstellung, Widerrufung und Wiederherstellung von Zertifikatsschlüsseln - zuständig ist.
Eng verwandt mit SAML ist die eXtensible Access Control Markup Language (XACML). XACML ermöglicht die Definition von Zugriffskontrollmechanismen auf Grundlage von Richtlinien, die in XML ausgedrückt werden. Durch Erstellen von XACML-Regeln kann man festlegen, wer welche Zugriffsrechte für ein bestimmtes XML-Dokument beziehungsweise Teile davon hat.
Will ein Benutzer oder ein Computer ("Requester") auf eine Ressource zugreifen und eine bestimmte Operation wie Lesen oder Löschen durchführen, übermittelt dieser seine Anfrage an einen PEP (Policy Enforcement Point). Der PEP, bei dem es sich um ein Dateisystem oder einen Webserver handeln kann, ist mit dem Schutz dieser Ressource beauftragt und erstellt daraufhin eine Anfrage - basierend auf den Attributen des Subjekts und anderen relevanten Informationen. Anschließend schickt PEP diese Anfrage an einen PDP (Policy Decision Point), der die für diese Anfrage relevanten Richtlinien (geschrieben in XACML-Policy-Sprache) abruft und feststellt, ob gemäß der dort definierten Regeln Zugriff gewährt werden darf. Diese Antwort wird anschließend an den PEP übermittelt, der dem Requester die Entscheidung mitteilt.
Produkte für sichere Webservices
Eine ganze Reihe von Firmen bietet auf Basis der vorgestellten Standards Lösungen für Webservices an. Wir stellen hier einige der erhältlichen Tools vor.
RSA hat mit Bsafe Secure-WS ein Tool vorgestellt, das Firmen beim Entwickeln von sicheren Webservices auf Basis von WS-Security hilft. Das Produkt unterstützt Verschlüsselung, Signierung und Überprüfung von SOAP-Nachrichten nach der WS-Security-Spezifikation und ist um Authentifikationsverfahren und SAML-Assertions erweiterbar.
Ebenfalls auf WS-Security stützt sich die Microsoft-Werkzeugsammlung Webservices Enhancements WSE 1.0. Die Tools integrieren sich in die Entwicklungsumgebung Visual Studio.NET und erweitern das .NET-Framework um die Möglichkeit, Funktionen in Webservices einzubauen, die unter anderem deren Sicherheit und Zuverlässigkeit erhöhen. Sicherheitstechnisch liefert WSE Funktionen zum Verschlüsseln und Signieren der SOAP-Nachrichten.
Mit dem TransactionMinder von Netegrity können IT-Verantwortliche Richtlinien für ein breites Spektrum an Authentifizierungsverfahren einsetzen. Dynamische Autorisierungsrichtlinien lassen sich unter Einbezug aller in einem XML-Dokument enthaltenen Informationen festlegen. Darüber hinaus registriert TransactionMinder alle mit der Dokumentenübertragung verbundenen Aktivitäten und trägt diese in ein Audit Log ein. Administratoren können durch dieses Log auf Berichtfunktionen zugreifen.
VeriSign Trust Gateway basiert ebenfalls auf der WS-Security-Spezifikation. Eine integrierte Software-Komponente, die dem Application Server vorgeschaltet ist, soll alle ein- und ausgehenden SOAP Messages überprüfen, schützen und weiterleiten. Um das Security Gateway zu verstärken, hat VeriSign zusätzlich eine PKI-Komponente hinzugefügt, die für Geschäftspartner Zertifikate erstellt. Mit diesen sollen sich ausgetauschte Nachrichten in Echtzeit authentifizieren lassen. Verisign bietet auch einen XKMS-Service an, den Kunden mit dem "Trust Service Integration Kit" nutzen können.
Fazit
Die vielen Initiativen zur Schaffung eines Sicherheitskonzepts für Webservices verdeutlichen die Bedeutung dieses Themas für die IT-Industrie. Nur mit der Unterstützung von Sicherheitskonzepten zur Verschlüsselung und Authentifizierung sind Webservices überhaupt für die Integration über Unternehmensgrenzen hinweg einsetzbar.
Etablierte Standards wie HTTPS bilden eine solide Grundlage für den Aufbau von Webservice-Architekturen. Dank der Erweiterbarkeit von XML ist es gelungen, das bislang sehr unsichere SOAP um wirksame Sicherheitsmaßnahmen zu ergänzen. Standards wie SAML und vor allem WS-Security ordnen sich nahtlos in bereits bestehende Sicherheitskonzepte ein.
Aus praktischer Sicht ist allerdings die große Vielfalt an Standards und Spezifikationen zu bemängeln. Ein durchschnittliches Unternehmen, das sichere Webservices implementieren möchte, wird sich darin nur schwer zurechtfinden. Zudem ist bei den derzeitigen Bemühungen immer noch eine erhebliche Lücke offen: Zurzeit existiert kein Verfahren, das das Problem der Verbindlichkeit und der Unabstreitbarkeit von Webservice-Transaktionen regelt. Dennoch erwarten Gartner-Analysten, dass bis zum Jahresende zumindest ein solides Fundament für sichere Webservices geschaffen sein wird. (mha)