Web-Services stehen zurzeit im Mittelpunkt des Interesses, weil sie einen einfachen und preiswerten Zugang zu verteiltem Computing ermöglichen. Vor allem die Verwendung verbreiteter Standards wie XML und HTTP (siehe Kasten "Grundlagen") wird als großer Fortschritt gefeiert. Doch lassen Web-Services hinsichtlich der Sicherheit noch viele Wünsche offen.

Nach Meinung von Laura Koetzle, Analystin bei Forrester Research, gehen viele Lösungsansätze an den wirklichen Problemen vorbei. Auf der einen Seite werde es erst in ferner Zukunft möglich sein, über Web-Services mit beliebigen Firmen zusammenzuarbeiten, und nur Techniker mit dem Kopf in den Wolken spekulierten heute schon darüber. Auf der anderen Seite habe der Zug definitiv den Bahnhof verlassen: Einzelne Entwickler basteln nach Einschätzung der Analystin intensiv an Web-Services, ohne den Sicherheitsaspekt zu berücksichtigen. Tools wie Microsofts Visual Studio .NET, das bereits Anfänger in die Lage versetzt, Web-Service-Interfaces für kritische Daten zu schreiben, vergrößern das Risiko für Unternehmen.

Daher führt mangelnde Sicherheit die Liste der von Anwendern geäußerten Bedenken gegenüber der neuen Technik an. Eine Umfrage der CW-Schwesterpublikation "Infoworld" ergab, dass die überwiegende Mehrheit der Teilnehmer Web-Services aus diesem Grund zunächst nur intern einsetzen möchte. "Web-Services sind heute noch relativ unsicher", urteilt auch Matthias Wilhelmi, Senior Berater bei Secunet in Berlin. Mit Hilfe von zusätzlichen Maßnahmen lässt sich seiner Meinung nach jedoch ein hoher Sicherheitsstandard erreichen. Bei der Sicherung von Web-Services handelt es sich um ein besonders komplexes Problem. Diese bestehen nämlich aus drei oder vier Schichten, die geschützt werden müssen. Ein Hacker hat somit mehr Wahlmöglichkeiten, wo er angreifen will, und der Anwender muss mehr Verteidigungsaufwand betreiben als bei anderen Anwendungen.

Unterschiede zu üblichen Architekturen

Im Vergleich mit herkömmlichen verteilten Architekturen sind einige wichtige Unterschiede zu berücksichtigen. So konzentrieren sich die Sicherheitsinfrastrukturen großer Firmen heute meist auf die Interaktion zwischen Mensch und Maschine. Im Gegensatz dazu geht es bei Web-Services in der Regel um eine Interaktion zwischen Applikationen, so dass sich der Nachweis der Identität (Authentisierung) anders gestalten muss - besonders wenn Web-Services zwischen zwei Systemen mit unterschiedlichem Authentisierungsverfahren verwendet werden.

Außerdem sitzen bisherige verteilte Systeme meist hinter einer Firewall. Für Web-Services gewinnt Verschlüsselung an Bedeutung, wenn sie diese Grenze überschreiten. Weiterhin verschlimmert sich das Problem von Schuldzuweisungen im Fehlerfall: Wenn verschiedene Teilnehmer einen Web-Service nutzen, wer kann dann sagen, warum genau eine Transaktion misslungen ist und wer die Verantwortung dafür übernimmt, den Schaden zu beheben?

Die größten Sicherheitsbedenken gibt es dort, wo Web-Services eine Firewall durchdringen. Der HTTP-Verkehr, also auch die über HTTP transportierten Web-Services, werden normalerweise über den Port 80 einer Firewall übertragen. Dieser Zugang entpuppt sich als problematisch: Er ist zwar sehr einfach, doch ohne Verschlüsselung kann jeder mitlesen, mit Verschlüsselung dagegen gehen die Daten ungefiltert durch die Firewall.

Die Grenzen von HTTPS

Als Ausweg empfiehlt Lars Weimer, Senior Advisor bei der Ernst & Young IT-Security GmbH in Frankfurt am Main, die Daten innerhalb einer "demilitarisierten Zone", aber noch vor der Bearbeitung der Web-Services-Anfrage auf schädlichen Code zu prüfen (deep packet inspection). Aus Sicherheits- und Performance-Gründen ist eine Inspektion auf oder vor der Firewall nicht zu empfehlen. Die rechenintensive Überprüfung wird von den üblichen Systemen heute noch nicht im nötigen Umfang unterstützt.

Häufig verwenden Firmen für die Verschlüsselung das Secure Hypertext Transfer Protocol (HTTPS, siehe Kasten "Grundlagen"). Es sorgt für eine Art sicheren (sogar authentisierten) Tunnel zwischen HTTP-Client und HTTP-Server. Das reicht jedoch nicht immer aus. Oft sind HTTP-Client und -Server eben nicht die Endpunkte der Applikation. Eine Ende-zu-Ende-Verschlüsselung wäre dann nicht gegeben. Zudem codiert das Protokoll ausnahmslos alles und erlaubt keine elementweise Verschlüsselung. "Viele Anwendungen tunneln HTTP über SSL. Zusammen mit Server- und Client-Zertifikaten bei SSL lässt sich damit eine rudimentäre Sicherheit erreichen, aber keine Sicherung einzelner Transaktionen", urteilt Secunet-Berater Wilhelmi.

Sicherung einzelner Transaktionen

Bankfachliche Anwendungen etwa erfordern zusätzlich zu einem HTTPS-Tunnel eine eigene digitale Signatur für jede Transaktion. Sonst könnte sich am Client ein Trojaner zwischen eigentlicher Anwendung und der Übertragung per HTTPS einklinken sowie von dort Parameter auslesen und manipulieren. Die Sicherung jeder einzelnen Transaktion hat den Vorteil, dass man dann wenigstens einen Protokolleintrag als Beweismittel in der Hand hat. Allerdings belastet dieses Vorgehen den Server mit einem großen Rechenaufwand. Eine entsprechend hohe Performance muss gewährleistet werden. Manche Sicherheitsimplementierungen verlängern auch die Antwortzeit, die aber für Web-Services besonders wichtig ist.

Eine weitere Gefahr geht von der inneren Struktur der Web-Services selbst aus. Sie enthalten nämlich Beschreibungen ihrer eigenen Funktionen. Wenn diese Beschreibungen falsch sind - und das wird nicht überprüft -, führt der Web-Service ganz andere Operationen aus, als der Anwender glaubt. Er mutiert quasi zu einem Trojanischen Pferd.

Oft wird übersehen, dass auch die Programmierung eine neue Qualität bekommt. "Es geht da nicht nur um den Zugriff auf einen Web-Server, sondern es wird eine Klassenmethode angestoßen", erläutert Wilhelmi. Das Problem dabei ist: Parameter in Funktionsaufrufen erzeugen in vorhandenen, nachträglich webifizierten Anwendungen leicht Buffer Overflows, wenn das Überprüfen der Geltungsbereiche schlampig oder gar nicht gemacht wurde. Das heißt: Will man Anwendungen, die nicht für eine Nutzung im Internet entwickelt wurden, als Web-Service anbinden, ist eine gründliche Prüfung der Parameter nötig.

Mehrstufige Web-Services

Schwierigkeiten bereiten darüber hinaus mehrstufige Web-Services. Um etwa eine Kreditkartenbuchung zu revidieren, dürfen dazwischenliegende Web-Services nur gewisse Informationen sehen, die beispielsweise für das Routing wichtig sind. Andere Daten wie Kreditkartennummer und Betrag darf nur die allerletzte Instanz erfahren. So ist nach Angaben von Ernst&Young-Mitarbeiter Weimer auch ein mehrstufiges Authentisierungs- beziehungsweise Verschlüsselungsverfahren vonnöten.

Die Vielfalt der Probleme und die hohe Zahl von Web-Services, die Unternehmen womöglich bald betreiben werden, lassen nur einen Schluss zu: In Zukunft werden ganzheitliche Sicherheitsansätze gefragt sein. Bisher hat es mehr schlecht als recht funktioniert, für jede Applikation eine eigene Sicherheitslösung zu entwickeln; in jeden einzelnen Web-Service spezielle Security-Features zu integrieren wird wohl nicht möglich sein.

Abstrakte Sicherheitsschicht

Die Marktforscher von Forrester empfehlen deshalb, eine abstrakte Sicherheitsschicht für Web-Services zu entwickeln: Dazu gehören Sicherheitsregeln für die Firma sowie Sicherheitsdienste, auf die die Web-Services ihrerseits zugreifen können. Da verschiedene Web-Services unter Umständen unterschiedliche Sicherheitsanforderungen haben, sollten die Dienste verschiedene Abstufungen von Authentisierung, Autorisierung und Verschlüsselung erlauben. Auf diese Weise ließen sich Granularität und Einheitlichkeit unter einen Hut bringen. Für die Einführung der neuen Technologie empfiehlt sich ein gesunder Pragmatismus. Es gilt, einen Mittelweg zu finden zwischen der Naivität eines völlig ungesicherten Einsatzes und einem rigiden Verbot nach dem Motto "Ohne Sicherheit keine Applikationen".

Genauso wie Web-Services unabhängig sind von der darunter liegenden Technologie, sollte das auch für die Sicherheit von Web-Services gelten. Darum ist es sehr wichtig, dass die Sicherheitsprodukte Standards wie WS-Security oder die Security Assertion Markup Language (SAML) unterstützen (siehe Kasten "Die wichtigsten Standards"). Grob gesagt bietet WS Security einen Rahmen für starke Authentisierung und Verschlüsselung, während SAML und XML for Access Control Lists (XACL) starke Autorisierung ergänzen. Noch sind die meisten Spezifikationen nicht fertig - mit Ausnahme von XML Signature (siehe CW 12/02, Seite 20: "W3C verabschiedet XML-Sicherheitsstandard").

Im Grunde genommen muss die Standardentwicklung erst weiter fortschreiten, bevor Systeme für die Sicherung von Web-Services entwickelt werden können. Einige proprietäre Lösungen gibt es jedoch bereits am Markt, zum Beispiel den "Traffic Manager" von Array Networks. Gegenüber den Clients außerhalb der Haus-DV agiert dieser Proxy wie ein Web-Server, gegenüber den Servern drinnen verhält er sich wie ein externer Client. Der Traffic Manager empfängt alle Anfragen und versendet alle Antworten nach draußen. An sicherheitsrelevanten Funktionen bietet das Produkt ein beschleunigtes Verschlüsseln sowie Authentisierung, Autorisierung und die Möglichkeit, Aktionen zurückzuverfolgen (Auditing).

Auch Baltimore Technologies sieht mit dem auf einer Public Key Infrastructure (PKI) basierenden "Unicert" samt Zertifikaten für die Authentisierung und dem Produkt "Select Access" für die Autorisierung dem Zeitalter von Web-Services optimistisch entgegen. Nach Angaben von Jan Vekemans, Direktor Benelux Central & Eastern Europe bei Baltimore in Brüssel, sollen die Produkte den Standard XKMS unterstützen (siehe Kasten "Die wichtigsten Standards"). Microsofts "Passport" dagegen tauge wenig für die Authentisierung von Web-Services, da es keine grundlegenden Sicherheitsfunktionen beinhalte und mehr Wert auf Bequemlichkeit lege. Auch Microsoft selbst schätzt das offenbar ähnlich ein: Passport konzentriere sich gegenwärtig mehr auf die Authentisierung von Endnutzern als von Applikationen oder Computern. Zudem existiere kein sicherer Weg, User ID und Passwort einzugeben.

Bewertung der Standards

Während sich die Produkte von Array und Baltimore dem Problemfeld Authentisierung und Autorisierung widmen, sollen die Security Appliances "SG800" von Blue Coat Systems den Port 80 absichern. Sie bieten die Möglichkeit, auch Inhalte zu analysieren. Nach Angaben von Clive Lutley, Area Manager für Deutschland, Österreich und die Schweiz bei Blue Coat Systems, können die Geräte Port-80-Datenverkehr von bestimmten Websites für ausgewählte Nutzer zulassen. Die durchgelassenen Daten werden auf Viren überprüft, der Rest gelangt erst gar nicht ins Netz.

Über die Qualität der Standards gehen die Meinungen auseinander. Während Befürworter WS Security attestieren, es decke die wichtigsten Bereiche ab, bemängeln Kritiker das Fehlen einiger an sich bekannter Sicherheitsaspekte. Die Vorschläge bezögen sich auf Einzelprobleme, ließen aber offen, wie sich das nachher alles zusammenfügen lassen solle, heißt es. Zum Beispiel gebe es Überlappungen zwischen dem Verschlüsselungsstandard XML Encryption und der XML Key Management Specification (XKMS). Solange an den Spezifikationen noch gearbeitet wird, besteht immerhin die Hoffnung, dass berechtigte Kritik in das Ergebnis einfließt.

Hinter den Kulissen geht das Tauziehen jedoch weiter. Eigentlich genießen die geplanten Standards eine hohe Akzeptanz. So wollen nach Angaben von Baltimore-Manager Vekemans 80 bis 90 Prozent der Hersteller den Interoperabilitätsstandard SAML verwenden, den er als "Esperanto für Web-Services" bezeichnet. Allerdings könnte Microsoft, ein nicht unbedeutender Abweichler, den Erfolg des Standards behindern. Die Redmonder wollen nur Teile von SAML 1.0 unterstützen. Mit diesem halbherzigen Bekenntnis ist derzeit noch unklar, wie (und ob) Microsofts Implementierung von SAML mit den Produkten anderer Hersteller zusammenarbeitet. Bleibt zu hoffen, dass sich der Softwarehersteller bald eines Besseren besinnt und die Durchsetzung offener Standards nicht weiter blockiert.

Die wichtigsten Standards

Security Assertion Markup Language (SAML):

XML-Framework für den Austausch von Authentisierungs- und Autorisierungsinformationen zwischen verschiedenen Systemen und Services. Eine Art Single-Sign-on für Web-Services.

XML Encryption:

Legt eine Syntax für die Verschlüsselung von XML-Dokumenten fest. Eine Verschlüsselung von Teilen eines Dokuments ist möglich. Voraussetzung für WS-Security.

XML Signature:

Spezifiziert Regeln für digitale Unterschriften unter XML-Dokumente und die Verarbeitung von Signaturen. Fließt ebenfalls in WS-Security ein. Wurde schon verabschiedet.

XML Key Management Specification (XKMS):

XML Encryption, XML Signature und ihre kombinierte Anwendung in WS-Security erfordern kryptografische Schlüssel. XKMS beschäftigt sich mit der Frage, wie diese Schlüssel sicher an Clients übergeben werden können.

WS-Security:

Die Web-Services-Security-Spezifikation wurde von IBM, Microsoft und Verisign ins Leben gerufen. Sun hat sich inzwischen dazugesellt. WS-Security ist ein Framework für die Sicherung von Soap-Nachrichten: Es beschreibt den Austausch signierter und verschlüsselter Nachrichten in einer Soap-Umgebung. Bei Oasis eingereicht. Die Spezifikation unterstützt mehrstufige Web-Services (Intermediaries).

XML for Access Control Lists (XACL):

Versteckt gewisse Teile eines XML-Dokuments vor einem Benutzer oder legt sie offen. Anhand hinterlegter Rollen und Profile sind Teilzugriffe möglich. Quelle: Forrester Research

Grundlagen

Extensible Markup Language (XML):

XML entstand in den 90er Jahren als Textformat für das Vorhalten und Beschreiben von Informationen. Der selbstbeschreibende Charakter erleichtert die Verarbeitung durch Softwareapplikationen. Es kann zudem einfach von einer Anwendung an eine andere übertragen werden, da es sich über HTTP transportieren lässt. So hat sich XML zu einem der wichtigsten Tools für den Austausch von Daten zwischen Applikationen gemausert.

Simple Object Access Protocol (Soap):

Soap entwickelte sich Mitte 2000 als Technologie für entfernte Aufrufe zwischen Applikationen. Microsoft, IBM, Userland und Developmentor haben das Protokoll im Standardisierungsgremium W3C vorgeschlagen. Inzwischen gilt Soap als De-facto-Sprache für Web-Services. Zur Codierung verwendet es XML. Eigene Sicherheitsmechanismen kennt Soap nicht, die mit der Standardisierung befasste Arbeitsgruppe klammert das Thema sogar bewusst aus. Die XML-Sicherheitsmechanismen taugen jedoch auch für entfernte Funktionsaufrufe und den Nachrichtenaustausch mit dem Soap-Format.

Secure Sockets Layer (SSL) und Secure HTTP (HTTPS):

SSL wurde ursprünglich von Netscape entwickelt und dient heute der Verschlüsselung und Authentisierung für Web-Server und Browser. Die Kombination von HTTP mit SSL wird HTTPS genannt. Normalerweise bestätigt HTTPS die Identität des Servers gegenüber einem Client und bietet Ende-zu-Ende-Verschlüsselung für HTTP. HTTPS soll die Vertraulichkeit von Web-Services sicherstellen, stößt aber dabei teilweise an Grenzen.

HTTP Basic Authentication:

Basic Authentication ist eine aus User-ID und Passwort bestehende Authentisierung für Web-Ressourcen. Für Web-Services ist das nicht stark genug, da sich Benutzername und Passwort leicht entschlüsseln lassen.

Quelle: Martin Nystrom, Cisco

Abb: Schichtenmodell für Protokolle

Die Soap-Sicherheitsmechanismen greifen an zwei Punkten im ISO-OSI-Referenzmodell: XML Encryption und XML Signature sichern die Anwendungsschicht, während HTTPS auf der Protokollschicht operiert. Quelle: Mario Jeckle/Objektspektrum