(Un)-Sicherheit bremst Webservices. Webservice-Technologien gelten als Motor für das Wachstum von E-Business. Sicherheitsprobleme halten jedoch viele Unternehmen noch von einem Einsatz ab.

(Un)-Sicherheit bremst Webservices

Marcus Ross, Geschäftsführer Verisign Deutschland: "Es sind weniger mangelhafte Sicherheitstechnologien als der hohe Aufwand an Investitionen und Ressourcen, der Unternehmen noch davon abhält, sich auf Webservices einzulassen."

Foto: Verisign

Webservices erfüllen den Wunsch nach Interoperation heterogener Systeme - und das plattformneutral und herstellerunabhängig. Sie machen das möglich, was bis vor einigen Jahren nur eingeschränkt oder nur über komplizierte Mechanismen (beispielsweise Electronic Data Interchange, kurz: EDI) funktionierte: uneingeschränkter Austausch von IT-Applikationen und Diensten über standardisierte Verfahren zur gemeinsamen Nutzung und Verarbeitung von Daten. Auch die Experten aus der Industrie sind sich über das Potenzial einig. Thomas Siebel, CEO von Siebel Systems, meint dazu: "Kunden werden von einer Sekunde zur anderen miteinander verbunden sein. Webservices bieten eine effektive Applikationsintegration - nahtlos, günstig und schnell einsetzbar." Die neue Softwaretechnologie verspricht also in Zukunft einen intelligenten Umgang mit dem Internet. Wo bisher vor allem Daten miteinander verknüpft wurden, sollen in Zukunft auch Applikationen miteinander verbunden werden.

Alles wunderbar? Wäre da nicht die Kehrseite der Medaille: Die bei Webservices verwendeten Datenaustauschverfahren - wie zum Beispiel das Hyper Text Transfer Protocol (HTTP) - sind nämlich zunächst einmal notwendigerweise offen, und sie sind komplex. Dies bringt vielschichtige Sicherheitsprobleme und potenziell damit verbundene Angriffe auf die Systeme mit sich. Insbesondere lassen sich aufgrund der Dienste-orientierten Vorgehensweise Sicherheitsprobleme nicht mehr allein nur auf Netzwerkebene - etwa mit einer Firewall - lösen.

Protokolle mit Verwundbarkeiten

Bei den Webservices handelt es sich um ein Bündel von Protokollen und Verfahren zum Austausch von Informationen. Webservices stützen sich auf Standards wie Universal Description, Discovery and Integration (UDDI), ein Registratur- und Verzeichnisdienst mit den dazugehörigen Extensible-Markup-Language-Schnittstellen (XML) sowie die Web Services Description Language (WSDL), eine Sprache zur Beschreibung der Funktionen eines Webservice. Das Protokoll, das die meisten Webservices zum Nachrichtenaustausch benutzen, ist das Simple Object Access Protocol (SOAP), das über HTTP oder Simple Mail Transfer Protocol (SMTP) transportiert wird. Alternativ zu SOAP kann auch XML Remote Procedure Call (XML-RPC) zum Datenaustausch verwendet werden.

Das klassische SOAP-Protokoll bietet keinerlei Sicherheitsfunktionalitäten wie Integritäts- oder Vertraulichkeitsschutz. Eine SOAP-Nachricht ist in HTTP als Envelope eingebettet, welcher aus zwei Komponenten, dem Header und dem Body, besteht. Wird SOAP für externe Methodenaufrufe (Remote Procedure Call: RPC) verwendet, ist der Body prinzipiell auf zwei Arten verwundbar: Zum einen kann der Angreifer versuchen, eine Methode aufzurufen, auf die er normalerweise keinen Zugriff hätte, zum anderen ist es ihm möglich, Parameter zu manipulieren. Daher sollte die Applikation eine ausreichende Überprüfung der Parameter (deren Typ und Reihenfolge) durchführen.

Netzwerk-Firewalls ohne Nutzen

Warum klassische Firewalls nicht in der Lage sind, Webservices ausreichend abzusichern, verdeutlicht das Port-80-Problem. Dabei handelt es sich um eine Attacke auf Anwendungsebene, welche von der Firewall nicht erkennbar ist. Verschiedene Produkte am Markt fungieren als Applikationsfilter auf SOAP-Ebene und trennen eventuell schadhaften SOAP-Verkehr ab. So filtert die Firewall Next Generation FP3 (die neueste Version von Checkpoints Firewall-1) die SOAP-Nachrichten mittels Namespace und des aufgerufenen Funktionsnamens. Das Produkt Transaction Minder von Netegrity leistet Zugriffskontrolle, wobei es sich der Benutzer-ID und der URL des Webservices bedient. Die Firewall InterDo von KaVaDo bietet Schutz vor Attacken mittels Parametermanipulation, indem sie jede SOAP-Anfrage auf Konformität mit der WSDL-Beschreibung des angefragten Webservices untersucht. Sicherheit bietet auch der SOAP Content Inspector (SCI) von Xtradyne. Er gewährleistet Zugriffsrechtevergabe anhand der Benutzer-IDs und -Rollen.

SAML schlägt SSL

Sicherheit und Vertraulichkeit bei der Datenübertragung lässt sich ebenfalls über die Secure-Sockets-Layer-Verschlüsselung (SSL) erreichen. Doch Vorsicht! Eine Authentifizierung des Clients mittels Zertifikaten ist unumgänglich, und ein Nachteil bleibt: Auch diese Technologie authentifiziert nur den Transportweg zwischen zwei Endpunkten, die nicht zwingend mit Absender und Empfänger der SOAP-Nachricht identisch sein müssen. Somit kann der Absender einer beim Webservice angekommenen Nachricht nicht mehr sicher ermittelt werden. Eine digitale Signierung oder selektive Verschlüsselung der Komponenten einer SOAP-Nachricht mittels SSL ist nicht möglich, daher kann keine durchgehende Sicherheit der Nachricht gewährleistet werden. Einen Lösungsansatz bietet die Security Assertion Markup Language (SAML) - ein XML-basierter Standard des OASIS-Konsortiums (Organization for the Advancement of Structured Information Standards). Mit Hilfe von SAML lässt sich die Identität eines Benutzers digital signieren. Das signierte SAML-Objekt ist dann im SOAP-Header enthalten. Webservices können somit eine SOAP-Nachricht mit einer Kennung des Absenders erweitern und diese auch verifizieren. SAML an sich ist jedoch kein Verfahren für Authentifizierung und Zugangskontrolle, sondern definiert die Struktur von Dokumenten, die für den Austausch solcher Sicherheitsinformationen benutzt werden können. Diese Sicherheits-Notation erlaubt den Unternehmen, miteinander zu kommunizieren, ohne dass ihre Sicherheitssysteme angepasst werden müssen. Auf SAML basierende kommerzielle Anwendungen bieten bereits Sun Microsystems mit dem Sun ONE Identity Server oder Netegrity mit dem Produkt Affiliate Minder.

Webservices bieten die Möglichkeit, Interaktionen zwischen Anwendungen durchzuführen, verwenden eine gängige Web-Infrastruktur als Basis, nutzen RPC und den EDI-Austausch von Dokumenten, verwenden für den Datenaustausch HTTP unter Einbezug von SOAP, rufen Module an verschiedenen Standorten dynamisch auf, nutzen objektorientierte Methoden und verfügen über XML-Schnittstellen.

SAML und SAML-ähnliche Werkzeuge stellen die relevanten Sicherheitsinformationen in Form von so genannten Token - etwa SAML-Zusicherungen, Kerberos- oder Extensible-Right-Markup-Language-Tickets (XrML), X.509-Zertifikaten - bereit. Mit dem Problem der Einbindung dieser Token in die SOAP-Nachrichten befasst sich WS-Security, eine Spezifikation zur durchgehenden Sicherung von SOAP-Nachrichten. WS-Security definiert innerhalb eines XML-Dokuments einen Rahmen zur Einbettung der Sicherheitsinformation in eine SOAP-Nachricht. Die Security-Token werden hierbei in Blöcken in den Headern von SOAP-Envelopes abgelegt. Des weiteren trägt WS-Security zur Wahrung der Integrität und Vertraulichkeit einer SOAP-Nachricht bei. Hierbei bedient sie sich insbesondere der Sicherheitsstandards XML Encryption und XML Signature. XML Signature definiert die Art und Weise, wie die digitalen Signaturen in XML-Dokumente integriert werden können. Diese tragen zur Sicherung der Datenintegrität bei. Darüber hinaus helfen sie, die Urheberschaft eines Dokuments festzuhalten und zu ermitteln. XML Encryption gewährleistet zuverlässige Datenverschlüsselung vom Sender bis zum Empfänger. Sie definiert insbesondere Regeln zur selektiven Verschlüsselung der XML-Dokumente und Dokumentenblöcke. Die Verwaltung der zertifizierten Schlüssel - eine Herausforderung bei digitalen Signierungs- und Verschlüsselungsverfahren - übernimmt die XML Key Management Specification (XKMS). Sie leitet Operationen mit Public-Key-Zertifikaten an den so genannten XKMS-Responder weiter.

Implementiert ist WS-Security bereits in IBMs Emerging Technologies Toolkit (ETTK) sowie Verisigns Trust Service Integration Kit (TSIK). "Mit TSIK sind wir bereits in der Evaluierungsphase bei Mercedes Online", freut sich Marcus Ross, Geschäftsführer Verisign Deutschland. Mercedes plant, seine Navigationssysteme zum Leben zu erwecken. Künftig sollen Autofahrer über ihr lernfähiges Navigationssystem aktualisierte Informationen erhalten können, die auf einem Webserver bereitgestellt werden. Verisign TSIK sichert dabei die Kommunikation zwischen Auto und Webserver ab.

Webservices werfen eine Menge Sicherheitsfragen auf In welchem Maß muss Sicherheit skaliert werden, um ständig wachsende Ressourcen gegen immer mehr verwundbare Punkte zu schützen? Wie lassen sich Benutzeridentitäten verwalten, und wie kann man prüfen, wer sich am anderen Ende einer Netzwerkverbindung befindet? Wie lassen sich Zugriffsrechte verwalten, so dass bestimmte Benutzer nur auf bestimmte Ressourcen zugreifen können? Wie lässt sich die Vertraulichkeit und Datenintegrität bei Transaktionen und in der Kommunikation sicherstellen?

Quelle: RSA Security

Technik ist nicht alles

So weit die Technologien bereits entwickelt sind, so wenig sollten sich Anwender von Webservices auf sie allein verlassen. Techniklastige Lösungsansätze stellen zwar einen guten ersten Schritt zur Reduzierung des Schadensrisikos bei Service-orientierten Architekturen dar. Sicherheitsbetrachtungen, die keine einmalige und einzelne Maßnahme darstellen, sondern im Systemgesamtrahmen behandelt und eingeführt werden, gehören jedoch ebenso dazu. Erst wenn diese Voraussetzungen geschaffen sind, könnte die Prophezeiung von Thomas Siebel, CEO von Siebel Systems, Wirklichkeit werden: "Künftige Historiker mögen auf das Jahr 2003 zurückblicken als ein Jahr der Wende in der Informationstechnologie, das vielleicht ähnlich bedeutend wie die Kommerzialisierung des Internets Mitte der neunziger Jahre war." Das vergangene Jahr ließ laut Siebel einen Paradigmenwechsel hin zum Business-Process-Computing erkennen - ein neuer Ansatz, der erst durch das Auftreten von Webservices möglich wurde.