Bei Web Services fallen zwangsläufig kritische, sicherheitsrelevante Daten an. Schon sehr einfache, unbedachte Handlungen öffnen dabei Angreifern Tür und Tor: Ein Befehl oder eine Enterprise Java Bean wird als Web Service veröffentlicht und kann direkt verwendet werden. Ein Klick mit der Maus, und eine Datenbank ist für jeden zugänglich, ohne mühsam Schnittstellen implementieren zu müssen. Wird HTTP als Transportprotokoll verwendet, so können die meisten Firewalls ohne großen Aufwand durchdrungen werden.
Mehrere kritische Punkte stellen im Umfeld von Web Services ein Sicherheitsrisiko dar: So verwenden die meisten Web Services zum Nachrichtenaustausch SOAP und als Transportmedium HTTP. SOAP als Kommunikationsprotokoll und HTTP als Transportprotokoll unterstützen in ihrer Basisform keinerlei Sicherheits-Forderungen, weil beide sehr einfach gehalten werden sollten. Der Nachteil: Sämtliche Daten werden damit im Klartext übermittelt.
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
|
|
Teil 4 |
|
|
Teil 5 |
|
|
Teil 6 |
Kontrolle kaum möglich
Aufgrund ihrer technischen Struktur sind Web Services speziellen Sicherheitsrisiken ausgesetzt. So dienen Web Services selten der Interaktion mit einem Benutzer, im Vordergrund steht die direkte Kopplung von Anwendungs-Servern. Ein Großteil der Kommunikation findet bei Web Services damit 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.
Mit am schwersten wiegt die Tatsache, dass es kaum möglich ist zu kontrollieren, wo ein Web Service abläuft. Er kann sich überall befinden - auch in einer Umgebung mit sehr geringen Sicherheitsanforderungen, die dem Unternehmen, das einen Web Service aufruft, normalerweise nicht genügen würde. Wenn Web Services aber Programme aufrufen können, die „irgendwo“ liegen, - auch in Umgebungen, die keine ausreichenden Sicherheitsmaßnahmen zur Verfügung stellen – dann kann Sicherheit nicht garantiert werden.
Security-Anforderungen
Um geschäftskritische Anwendungen in komplexen und unübersichtlichen Umgebungen zu betreiben müssen bestimmte Sicherheits-Forderungen gewährleistet sein. Web Services sollten garantieren, 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 Web Services müssen ihre Identität also dem jeweiligen Kommunikationspartner nachweisen können und es müssen Mechanismen vorhanden sein, dass nur bestimmte Nutzer auf Web Services zugreifen können. Allerdings soll sich auch nicht jeder Teilnehmer gegenüber jedem anderen identifizieren müssen, sondern Zusicherungen über Identitäten müssen weitergereicht werden können.
Weiterhin dürfen Inhalte nicht manipuliert oder falsche Inhalte als echte präsentiert werden, die Integrität der Daten muss also garantiert sein. Und schließlich muss auch die Vertraulichkeit der übertragenen Daten gewährleistet werden, so dass ein Mitlesen der Daten durch Unbeteiligte unmöglich ist.
Ein zentraler Baustein bei Web Services sind zusätzlich Verbindlichkeit und Unabstreitbarkeit (Non-Repudiation):. Non-Repudiation bedeutet, dass kein an einer Transaktion Beteiligter 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.
Kryptografie und digitale Unterschrift
Zur Realisierung dieser Sicherheitsaspekte gibt es technische Lösungen, die sich in zwei Verfahrensklassen einordnen lassen. Kryptografie und digitale Unterschrift. Während durch kryptografische Bearbeitung der ursprüngliche Nachrichtentext so modifiziert wird, dass er für Dritte nicht lesbar ist, zielt der Einsatz digitaler Unterschriften auf die Bestätigung der Echtheit der inhaltlich unveränderten übermittelten Information.
Vertraulichkeit lässt sich durch klassische Verschlüsselungsmechanismen erreichen, wobei meist das asymmetrische Public-Key-Verfahren eingesetzt wird. Die Verifizierung der Berechtigung (Autorisierung) liegt hauptsächlich in der Domäne digitaler Signaturen. Sie stellen sicher, dass der Sender der ist, für den er sich ausgibt.
Digitale Signaturen gewährleisten auch die Integrität der Daten, decken also Modifikationen auf, die nach dem Versenden vorgenommen wurden. Durch den Vergleich des durch den Autor erstellten und mit versandten Fingerabdrucks mit der durch den Empfänger unter Verwendung derselben mathematischen Funktion erstellten Zusammenfassung lässt sich die Konsistenz von Nachricht und Original ohne großen Aufwand prüfen. Kryptografische Verfahren, Biometrie und digitale Signatur werden in eigenen Beitrag vorgestellt.
Transportsicherheit – SSL/TLS
Wie bei den meisten anderen verteilten Computersystemen können auch bei Web Services Sicherheitsansätze auf allen Schichten des OSI-Schichtenmodells angewandt werden. Im klassischen Web spielt die Transportsicherheit eine relativ große Rolle. Unter Transportsicherheit versteht man das nicht abhörbare und nicht veränderbare Ausliefern von Nachrichten. Dem entspricht in der realen Welt ein Briefumschlag, der verhindert, dass ein Dritter eine Sendung verändern oder lesen kann.
Bei Sicherungsmaßnahmen für Web-Transaktionen kommt heute meist das SSL-Protokoll (Secure Socket Layer) bzw. die standardisierte Weiterentwicklung TLS (Transport Layer Security) zum Einsatz. Diese Protokolle sorgen für einen sicheren Übertragungstunnel zwischen HTTP-Client und HTTP-Server, so dass eine Nachricht während des Transports nicht gelesen oder verändert werden kann. Banken setzen SSL bekanntlich für die Authentifizierung und Verschlüsselung von Konto-Transaktionen ein. Da HTTP auch Web Services transportiert liegt es nahe, hier ebenfalls SSL/TLS zu verwenden.
Technisch realisiert SSL/TLS Sicherheit unter Verwendung symmetrischer Verschlüsselung des kompletten Kommunikationskanals mit vorheriger optionaler wechselseitiger Authentisierung durch Aushandeln eines gemeinsamen Schlüssels. Wie SSL/TSL genau funktioniert lesen Sie im Beitrag Security im Überblick (Teil 5).
Das auf der Transportebene ansetzende SSL/TLS bietet also Vertraulichkeit und Authentifizierung. Für eine Kommunikation zwischen genau zwei Partnern wie einer Bank und seinem Kunden ist SSL/TLS eine gute Lösung. Doch für die umfangreiche Absicherung der Web Services ist SSL/TLS nicht tauglich. Denn die Vertraulichkeit der Daten ist lediglich zwischen zwei Knoten und nicht etwa von Beginn bis Ende der Übermittlungskette gewährleistet.
Im Web Services Umfeld ist es aber spätestens bei der Nutzung von Intermediären meist nicht mehr möglich, die Daten sicher zu übertragen. Auf dem Weg vom Sender zum Empfänger erhält der Intermediär Informationen, die eventuell nicht für ihn bestimmt sind. Für die Gewährleistung von Sicherheit ist es notwendig, dass Teile einer Sendung verschieden behandelt werden können und somit zum Beispiel ein Beteiligter nur einen Teil lesen kann. In komplexen Web Services Szenarien ist es also nicht möglich, eine allgemeine Lösung nur auf Basis von Transportsicherheit zu entwickeln.
XML Signature und Encryption
Da SSL die Sicherheitsprobleme von Web Services nicht grundsätzlich löst, sind andere Mechanismen nötig, um die Security-Anforderungen zu erfüllen. Verschiedene Gremien und Unternehmenszusammenschlüsse haben sich damit beschäftigt, Erweiterungen herkömmlicher Sicherheitslösungen zu definieren, die die Schwachstellen ausmerzen sollen. Diese Erweiterungen basieren auf XML-Ebene.
Mit dem W3C-Standard „XML Signature Syntax and Processing“ soll dem breiten Einsatz von XML-Signaturen in der Praxis der Weg geebnet werden. Charakteristisch für eine XML Signatur ist die Möglichkeit nur Teile eines XML Dokuments zu signieren. Dies erhöht die Flexibilität bei der Erstellung und einer etwaigen Weiterverarbeitung der Information. Zum Beispiel kann ein Nutzer eines Web Services Protokolls wie SOAP nur den Nutzlast-Teil der XML Nachricht verschlüsseln, nicht aber die Informationen, die fürs Routing zum Empfänger benötigt werden.
Die dazugehörige „Decryption Transform for XML Signature“ Recommendation (www.w3.org/TR/xmlenc-decrypt) ermöglicht die Verschlüsselung mit XML Signature. Eine Eigenschaft von XML Signature ist die Sicherstellung der Dokumentenintegrität: XML Signature erkennt, wenn sich ein Dokument geändert hat. Viele Anwendungen erfordern es, dass ein XML-Dokument erst signiert wird und später Teile davon verschlüsselt werden; was zu einer Veränderung des Dokuments führt. „Decryption Transform“ lässt den Empfänger wissen, welche Teile des Dokuments entschlüsselt werden müssen - also wie das Dokument in den ungeänderten Zustand gebracht werden muss, bevor man die Signatur überprüfen kann.
W3C-Standards
Im Zusammenspiel mit kryptografischen Schlüsseln lassen sich durch Signaturen auch Teile der Berechtigungsprüfung realisieren. Im Kern sind Berechtigungsprüfung und Vertraulichkeit jedoch die Domäne von eigenständigen Verschlüsselungsverfahren. Daher werden die XML Signaturen um XML Encryption ergänzt, ebenfalls ein W3C-Standard.
Die XML-Encryption-Spezifikation definiert eine Reihe von Möglichkeiten, wie XML-Dokumente ver- und entschlüsselt werden. Dabei sind folgende Möglichkeiten vorgesehen: Verschlüsselung des gesamten XML-Dokumentes, Verschlüsselung eines einzelnen Elementes und seiner Unterelemente, Verschlüsselung des Inhaltes eines XML-Elementes und Verschlüsselung für mehrere Empfänger.
Einen schnellen Einblick in die laufenden Aktivitäten des W3C zu XML-Signaturen liefert http://www.w3.org/Signature und zur XML-Verschlüsselung http://www.w3.org/Encryption/.
SAML
Aus der Not geboren, für bestimmte Szenarien der Web Service Nutzung keine geeigneten Sicherheitsmechanismen zur Verfügung zu haben, entwickelte eine Gruppe der OASIS (www.oasis-open.org) den SAML Standard (gesprochen „Semmel“ oder „Samuel“). Das Akronym steht für „Security Assertion Markup Language“ („Auszeichnungsspreache für Sicherheitsbestätigungen“) und beschreibt ein XML-basierendes Framework zum Austausch von Sicherheitsinformationen zwischen Geschäftspartnern über das Internet. SAML wurde 2002 von der OASIS standardisiert.
Mit SAML können insbesondere Single-Sign-On-Systeme realisiert werden, bei denen der Nutzer nach einmaliger Anmeldung ohne zusätzliche Registrierung auf weitere, damit verbundene Dienste zugreifen kann. 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 Web Service zugewiesen und in LDAP-Verzeichnissen verwaltet werden.
Es können drei allgemeine Arten von Assertion-Anweisungen verwendet werden, die von getrennten Instanzen ausgestellt und überprüft werden: Authentifizierung, Autorisierung und Attribut. Diese drei Anweisungen werden an verschiedenen Stellen in der Anwendung benutzt, 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 hinzu Public Keys und Zertifikaten. SAML hat auch die Unterstützung für XML Signatures eingebaut, womit es nicht nur für Authentifizierung und Autorisierung, sondern auch für Gewährleistung der Integrität und Non-Repudiation von Nachrichten verwendet werden kann.
WS-Security
Das umfassendste Security-Konzept für Web Services ist WS-Security. „Web Service Security“ (http://www-128.ibm.com/developerworks/library/specification/ws-secure/) kann als Framework betrachtet werden, das alle relevanten Punkte zum Thema Sicherheit bei Web Services beinhaltet. Dazu unterstützt, integriert und vereinheitlicht WS-Security diverse populäre Sicherheitsmodelle, -mechanismen und -technologien, die die Zusammenarbeit einer großen Zahl von Systemen in einer plattform- und sprachunabhängigen Art und Weise ermöglichen sollen.
WS-Security entwickelt also keine neuen Verfahren, sondern fasst bestehende Techniken zusammen. Es bildet damit eine grundlegende Erweiterung des SOAP-Standards um Sicherheitsanforderungen. Ausgearbeitet wurde WS-Security von den Firmen Microsoft, IBM und Verisign und inzwischen an OASIS übermittelt, das für die weitere Entwicklung zuständig ist.
Web Service 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.
Das Konzept 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 die in XML Signature und XML Encryption definierten Kopfzeilen zur Gewährleistung der Integrität, Vertraulichkeit und Authentizität der Nachrichten im Kopfzeilenbereich der SOAP-Nachrichten eingefügt werden können.
WS-Security unterstützt eine feine 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 können zwischen zwei Endpunkten Signaturen je nach Bedarf individuell hinzugefügt werden.
WS-Security bietet auch genügend Raum für Erweiterungen, die bei speziellen Anforderungen helfen können: WS-Policy beschreibt Sicherheitsvorkehrungen und Einschränkungen, WS-Trust ist ein Framework für Vertrauensmodelle, WS-Privacy enthält Datenschutzwünsche, WS-Secure-Conversation behandelt die sichere Kommunikation, WS-Federation beschäftigt sich mit Vertrauensverhältnissen in heterogenen Umgebungen und WS-Authorization handelt von Authorisierungsdaten und -richtlinien.
Die aktuell Version 1.1 von WS-Security des Standards enthält zahlreiche Anpassungen, die auf Kommentare der Nutzer zurückgehen. Unter anderem gibt es zusätzliche Profile für Kerberos, SAML und SOAP mit Anhängen.
Fazit
Die vielen Initiativen zur Schaffung eines Sicherheitskonzeptes für Web Services zeigen die Bedeutung dieses Themas für die IT-Industrie an. Nur mit der Unterstützung von Sicherheitskonzepten zur Verschlüsselung und Authentifizierung sind Web Services überhaupt für die Integration über Unternehmensgrenzen hinweg einsetzbar.
Etablierte Standards wie Verschlüsselungsverfahren bilden eine solide Grundlage für den Aufbau von Web-Service-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 Web Services implementieren möchte, wird sich darin nur schwer zurecht finden. 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 Web Service Transaktionen regelt. (ala)
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
|
|
Teil 4 |
|
|
Teil 5 |
|
|
Teil 6 |