Konzepte der WS-Security
Sicherheit in der SOA
Eine serviceorientierte Architektur (SOA) schafft durch die Bereitstellung von lose gekoppelten Diensten eine IT-Infrastruktur, die flexibel auf die sich ständig ändernden Anforderungen der Geschäftsprozesse reagieren kann. Dabei muss neben den funktionalen Aspekten auch eine flexible Security-Infrastruktur Beachtung finden, da Veränderungen in den Geschäftsprozessen auch maßgebliche Auswirkungen auf die Security haben. Beispielsweise bedarf das Einbeziehen von neuen Geschäftspartnern oder die Einbindung von sensiblen Daten in unternehmenskritische Prozesse einer adäquaten und standardisierten Security-Lösung.
Als Basistechnik für die Security von SOAPbasierenden (ursprünglich: Simple Object Access Protocol) Nachrichten hat sich mittlerweile der von OASIS verabschiedete Standard Webservices-Security etabliert. WS-Security besteht aus einem ganzen Paket von Spezifikationen und zahlreichen Mechanismen, die sich abhängig vom Einsatzszenario verschiedenartig kombinieren lassen.
Basiskonzepte
WS-Security als Erweiterung des SOAP-Protokolls wurde im März 2004 von der OASIS standardisiert. Mittlerweile gilt sie als ausgereift und produktionstauglich. Dabei definiert WS-Security keine neue Technik, sondern setzt auf bereits existierende Standards auf, beispielweise XML Encryption, XML Signature, X.509-Zertifikate oder diverse Algorithmen aus der Kryptografie. Die Grundkonzeption fußt auf Nachrichtmechanismen, sodass anstelle einer transportorientierten Absicherung eine End-to-End Security realisiert werden kann - beispielsweise durch ein SSL-Protokoll. Dieser Ansatz ist notwendig, um eine Punkt-zu-Punkt-Kommunikationsstruktur innerhalb einer SOA zu vermeiden und damit auch asynchrone Nachrichten oder den Einsatz von Zwischenstationen (zum Beispiel ESBs) zu ermöglichen.
Ziel von WS-Security ist es, die Anforderungen hinsichtlich Integrität, Vertraulichkeit, Authentizität der Nachricht und des Senders zu erfüllen und gleichzeitig offen für Erweiterungen zu sein. Folgende Grundmechanismen sind Bestandteile von WS-Security: Security Token, Verschlüsselung, Signatur und Timestamps.
Security Token: Die Authentifizierung des Senders ist eine Grundvoraussetzung für die Zugriffskontrolle (Access Control) auf der Serviceseite, aber auch wichtig für Accounting- und Auditing-Zwecke. Die für eine Authentifizierung notwendigen Identifikationsnachweise (Credentials) werden in Form von Security Tokens innerhalb der Nachricht transportiert. Die Authentifizierung selbst ist nicht Bestandteil von WS-Security, sondern ein nachfolgender Prozess beim Service-Provider. Für die verschiedenen Token-Formate stellt die OASIS separate Spezifikationen in Form von WS-Security-Profilen zur Verfügung. So regelt das "Username Token Profile" die Verfahrensweise der weitverbreiteten Authentifizierungsmethode von Endbenutzern über eine User-ID und das zugehörige Kennwort.
Die Identifikation von Anwendungen oder Geschäftsprozessen erfolgt üblicherweise auf Basis von Zertifikaten, wodurch die Verwaltung von Passwörtern auf der Client-Seite entfallen kann. Der Umgang mit Zertifikaten für eine zertifikatsbasierende Authentifizierung ist wiederum im "X.509 Certificate Token Profile" spezifiziert. Darüber hinaus existieren weitere Profile, zum Beispiel für die Verwendung von SAML- (Security Assertion Markup Language) oder Kerberos-Token.
Die XML-basierenden oder binären Security Token sind nicht nur für eine Authentifizierung nötig, sondern zudem die Grundlage für den Transport oder für die Referenzierung von Schlüsseln (Keys), die in der Kryptografie zum Einsatz kommen.
Verschlüsselung: Um eine Vertraulichkeit von sensiblen Daten zu erreichen, nutzt man kryptografische Verschlüsselungen. Da SOAP ein XML-basierendes Protokoll ist, definiert die WS-Security keinen neuen Standard, sondern verwendet die "XML-Encryption"-Spezifikation der W3C. Die verschlüsselten Daten und ihre Metainformationen sind dabei wiederum als XML-Strukturen in die Nachricht eingebettet. Die Elemente Envelope, Header und Body dürfen laut SOAP-Spezifikation jedoch nicht verschlüsselt werden, da diese die Grundstruktur der Nachricht vorgeben und somit immer lesbar sein müssen.
Grundsätzlich unterscheidet man die symmetrische und die asymmetrische Verschlüsselung. Bei der symmetrische Verschlüsselung (Secret-Key-Verfahren) wird ein gemeinsamer Key für die Ver- und Entschlüsselung verwendet, der in einem gesicherten Austauschverfahren (Out-of-Band) immer beiden Parteien zur Verfügung stehen muss. Dagegen sind bei einer asymmetrischen Verschlüsselung (Public-Key-Verfahren) jeweils unterschiedliche Schlüssel für die Ver- und Entschlüsselung eingesetzt, was den Aufwand hinsichtlich der Schlüsselverteilung minimiert: Der Private Key bleibt beim Besitzer, und der Public Key lässt sich frei verteilen. Allerdings ist das Public-Key-Verfahren erheblich langsamer als das Secret-Key-Verfahren. Daher treten in der Praxis beide Ansätze in Kombination als Hybridverfahren auf. Der Client generiert einen symmetrischen Key (Session Key) und verwendet diesen für die symmetrische Verschlüsselung von großen Datenmengen. Anschließend wird der symmetrische Key mittels eines asymmetrischen Verfahrens verschlüsselt und eingebettet in die Nachricht dem Service zur Verfügung gestellt.
Signatur: Für den Nachweis der Integrität einer Nachricht kommen Signaturen zum Einsatz. Sie bieten die Möglichkeit, unberechtigte Modifikationen der Nachricht wie das Verändern, Löschen oder Hinzufügen von Daten zu erkennen. Die Realisierung innerhalb von WS-Security basiert auf dem Standard "XML Digital Signature" des W3Cs. Das Prinzip der Signaturen beruht auf dem Erstellen von Prüfsummen mit speziellen Digest-Algorithmen. Die Ergebnisse sind in die Nachricht eingefügt und werden zum Teil verschlüsselt übertragen. Die Serviceseite erstellt ebenfalls die Prüfsummen und vergleicht diese mit den vom Client gesendeten Werten. Da in XML verschiedene Schreibweisen logisch identisch sind, ist eine Normalisierung der Daten vor der Prüfsummenbildung notwendig. Für diesen Zweck nutzt man ebenfalls vom W3C standardisierte XML-Canonicalization-Algorithmen.
Außerdem bieten Signaturen die Möglichkeit, die Authentizität des Senders festzustellen. Diese juristisch verwendbaren Informationen lassen sich für die Realisierung von Verbindlichkeiten (Nichtabstreitbarkeit) heranziehen.
Timestamp: Der Dienstleistungsgedanke innerhalb einer SOA besagt, dass die Services eine definierte Leistung erbringen und somit eine zustandslose Interaktion (stateless) unterstützen sollen. Das Prinzip dieser Session-losen Kommunikation bietet jedoch Raum für Replay-Attacken, indem ein Angreifer Nachrichten oder Nachrichtenteile wiederholt sendet. Um solche Angriffe abzuwehren, muss die Einmaligkeit von Nachrichten sichergestellt sein. Zu diesem Zweck enthält jede Nachricht eine eindeutige Message-ID, die der Service hinsichtlich ihrer Einmaligkeit überprüfen muss. Dazu ist es notwendig, die bereits empfangenen Message-IDs zu speichern. Dabei sind der Gültigkeitszeitraum und damit die Aufbewahrungsdauer der einzelnen Message-IDs auf der Serviceseite von einem in der Nachricht enthaltenen Timestamp begrenzt.
Neben der Verwendung einer allgemeinen Timestamp-Struktur im Security-Header bietet auch das Username-Token ein eigenständiges Timestamp-Handling an, um ein unerlaubtes Wiederverwenden von Authentifizierungsdaten zu verhindern. In der Regel tritt die im Rahmen der WS-Addressing-Spezifikation definierte Message-ID als Nachrichtenidentifikation auf. Username-Tokens enthalten dagegen einen kryptografischen Zufallswert (Nonce).
Innerhalb einer SOA decken die einzelnen Grundmechanismen Security-Token, Verschlüsselung, Signatur und Timestamp jeweils nur einen Teilaspekt der Security ab. Erst das Zusammenspiel aller Mechanismen ergibt eine vollständige Security-Lösung. Dabei ist es durchaus üblich, die auf Nachrichten basierende Security (WS-Security) mit der transportorientierten Security (SSL) zu kombinieren. Das Szenario im Bild links verdeutlicht die Notwendigkeit eines Zusammenspiels der verschiedenen Mechanismen.
Authentifizierung: Jede Zugriffskontrolle auf der Serviceseite setzt eine Authentifizierung des Clients voraus. Die dafür notwendigen Identifikationsnachweise sind der Serviceseite bekannt zu geben. Im Fall einer User-ID und Kennwortmethode stellt die WS-Security den Mechanismus des Username-Tokens zur Verfügung. Dabei sind Kennwörter sehr sensible Daten, deren Lesbarkeit während des Transports unbedingt zu vermeiden ist. Selbst das in der Username-Token-Spezifikation definierte Digest-Verfahren, in dem das Kennwort nur als Prüfsumme (Digest) übertragen wird, sollte stets mit einer Verschlüsselung ablaufen. Bei der Verwendung einer lesbaren Prüfsumme bestände die Gefahr einer Brute-Force-Attacke. Dieser Angriff beruht auf dem erschöpfenden Ausprobieren aller oder vieler Möglichkeiten, da Kennwörter hinsichtlich Länge und verwendeten Zeichensatz eingeschränkt sind.
Zudem benötigt die Serviceseite bei einer Verwendung eines Kennwort-Digests für die Authentifizierung das Kennwort im Klartext. Daher ist dieser Ansatz in vielen Fällen nicht anwendbar oder erfordert bei der Verwaltung der Kennwörter zusätzliche Security-Maßnahmen.
Vertraulichkeit: Um das Ausspionieren des Kennworts während des Transports zu verhindern, muss das Username-Token in der Nachricht verschlüsselt sein. In einigen Fällen ist dafür die Verwendung des weitverbreiteten SSL-Protokoll ausreichend. Dabei ist jedoch zu beachten, dass aufgrund des Point-to-Point-Prinzips von SSL ein Einsatz von Zwischenstationen etwa eines Enterprise Service Bus (ESB) nicht möglich ist. Bei SSL ist ein Datenschutz nach dem Transport nicht mehr gegeben.
Dagegen bietet der Verschlüsselungsmechanismus von WS-Security eine nachrichtenbasierende Methode an. In diesem Fall sind die Originaldaten mittels XML Encryption verschlüsselt und ersetzt. Zusätzlich werden Metainformationen beispielsweise über verwendete Algorithmen oder Keys in die Nachricht hinzugefügt. Die so aufbereitete Nachricht kann jetzt auch über ein ungesichertes Protokoll (zum Beispiel HTTP) laufen, ohne dass die Vertraulichkeit von sensiblen Daten gefährdet ist.
Integrität: Derzeit besteht im geschilderten Beispielszenario keine Verknüpfung zwischen den im SOAP-Header befindlichen Username-Token und den Daten im SOAP-Body. Dadurch besteht die Gefahr, dass sich entscheidende Teile der Nachricht austauschen lassen. Beispielsweise könnten die verschlüsselten Benutzerinformationen im Header mit einer verfälschten Serviceanfrage versehen werden. Durch die Verwendung von Signaturen ist dieses Problem jedoch lösbar. Die in WS-Security verwendeten Signaturmechanismen dienen untern anderem als Klammer für mehrere Datenblöcke. Dadurch ist es möglich, die Integrität von einzelnen Daten wie auch die Integrität der gesamten Nachricht bestehend aus mehreren örtlich getrennten Datenblöcke zu überprüfen. Im Zusammenhang mit einer nachrichtenbasierenden Security sind Signaturen somit ein elementarer Baustein und betreffen nicht nur das Thema der digitalen Unterschriften.
Einmaligkeit der Nachricht: Um ein wiederholtes Senden der Nachricht zu verhindern (Replay-Attacke), ist die Einmaligkeit der Nachricht auf der Serviceseite zu prüfen. Dazu wird der Nachricht in einer standardisierten Form eine Message-ID hinzugefügt. Der vom W3C definierte WS-Addressing-Standard umfasst unter anderem die Angabe einer Message-ID, die zum Erkennen der Einmaligkeit der Nachricht dienen kann. Die innerhalb der WS-Security definierte Timestamp-Struktur übernimmt durch die Angabe einer Erstellungs- sowie einer Verfallszeit die Definition eines Gültigkeitszeitraums. Damit ist die Aufbewahrungsdauer der Message-IDs auf der Serviceseite begrenzt.
Abschließend müssen sowohl die Message-ID als auch die Timestamp-Angabe an die bereits existierenden Datenblöcken (Benutzerinformation und Nachrichtendaten) gekoppelt sein. Dazu erweitert man die Signaturklammer, sodass sich bei der Integritätskontrolle die neuen Elemente mit einbeziehen lassen.
Signaturen und ihre Aufgaben
Webservices unterstützen aufgrund ihrer nachrichtenbasierenden Infrastruktur die Möglichkeit, beliebige Zwischenstationen (Intermediaries) zwischen den Kommunikationsendpunkten einzufügen. Mithilfe dieser Intermediaries-Architektur lassen sich die Webservices hinsichtlich ihrer Funktionalität erweitern. Zudem ist diese Architektur die Grundlage für die Trennung von Verantwortlichkeiten bezüglich der Implementierung von Serviceeigenschaften, insbesondere der nichtfunktionalen Anforderungen (Quality of Services). Im Rahmen eines Serviceaufrufs müssen die Anfrage- und Antwortnachrichten jeweils die zwischengeschalteten Stationen passieren. Dabei erhält jede Station entsprechend ihrer spezifischen Aufgabe die Eingabedaten aus der Nachricht und reichert diese bei Bedarf mit weiteren Daten an. Entsprechend ist es notwendig, dass bestimme Teile der Nachricht für die Stationen lesbar und veränderbar sind. So lassen sich Routing-Funktionen innerhalb eines ESBs durch WS-Addressing-Daten aus der Nachricht steuern.
Zur Sicherstellung von Vertraulichkeit und Integrität der Nachricht auf der einen Seite und der Les- und Erweiterbarkeit der Nachricht auf der anderen Seite ergeben sich an die verwendeten Security-Mechanismen erhöhte Anforderungen. Eine Verschlüsselung der gesamten Nachricht beispielsweise durch die Verwendung des SSL-Protokolls würde den flexiblen Einsatz von Zwischenstationen verhindern. Zudem verlangt der SOAP-Standard, dass die Elemente Envelope, Header und Body innerhalb der Nachricht unverschlüsselt vorliegen.
Signaturen übernehmen mehrere wichtige Aufgaben, um im Rahmen dieser lose gekoppelten Infrastruktur eine allumfassende Security zu gewährleisten. Neben der allgemein bekannten Aufgabe hinsichtlich einer digitalen Unterschrift bieten Signaturen die entscheidenden Mechanismen, um die Integrität und Authentizität von Teilen der Nachricht zu überprüfen. Aufgrund der elementaren Rolle von Signaturen ist es wichtig, deren Grundprinzipien zu kennen.
Datenintegrität
Signaturen bieten unter anderem die Möglichkeit, eine Datenintegrität von einzelnen Datenblöcken nachzuweisen. Dadurch sind Manipulationen (Verändern, Löschen und Hinzufügen von Daten) erkennbar. Zu diesem Zweck wird von den relevanten Datenblöcken jeweils eine Prüfsumme (auch Message Digest genannt) mit einem speziellen kryptografischen Hash-Algorithmus (etwa SHA1, MD5) erstellt. Die Hash-Algorithmen sind Einwegfunktionen (unumkehrbar), die eine Reproduktion der Originaldaten aus den Hash-Wert verhindern. Zudem dürfen sich Daten nicht mit dem gleichen Hash-Wert errechnen lassen (kollisionsfrei).
Um einen Hash-Wert zu überprüfen, führt die Gegenseite die Prüfsummenbildung erneut aus und vergleicht die eigene Prüfsumme mit der empfangenen Prüfsumme. Sind beide Werte identisch, so ist die Integrität der Daten gegeben, anderenfalls liegt die Wahrscheinlichkeit einer Manipulation vor. Allerdings kann das Verfahren keine Auskunft über die Art der Manipulationen geben, da Signaturen nur ein Richtig oder ein Falsch als Ergebnis zurückgeben können.
Da das Prinzip von Signaturen auf die Prüfsummenbildung durch zwei verschiedenen Parteien (Sender und Empfänger) beruht, ist die gleiche Repräsentation der Bezugsdaten eine Grundvoraussetzung. Damit es beispielsweise infolge von verschiedenen XML-Schreibweisen nicht zu unterschiedlichen Prüfsummen kommt, benötigt man als Zwischenschritt eine XML-Normalisierung (Canonicalization).
Allein der Nachweis der Integrität von einzelnen Datenblöcken hinsichtlich der Überprüfung der gesamten Nachricht ist jedoch nicht ausreichend. Zusätzlich muss die Zusammengehörigkeit der einzelnen Datenblöcke gesichert sein. Zu diesem Zweck sind die Hash-Werte aller Datenblöcke zusammengefasst, um eine gemeinsame Prüfsumme zu bilden. Dies verbindet die Datenblöcke unabhängig von ihrer Position innerhalb der Nachricht kryptografisch. Die gemeinsame Prüfsumme bildet somit die Möglichkeit, die Authentizität der Nachricht als Ganzes zu kontrollieren. Zudem lassen sich Manipulationen an den Hash-Werten der einzelnen Datenblöcke erkennen. Damit die gemeinsame Prüfsumme während des Transports nicht verändert werden kann, ist diese mittels eines kryptografischen Verschlüsselungsalgorithmus gesichert. Für die Realisierung einer Nachrichtenauthentizität kann eine symmetrische Verschlüsselung (zum Beispiel HMAC) zum Einsatz kommen. Dabei wird der vom Sender und Empfänger gemeinsam genutzte Key entweder im Vorfeld ausgetauscht oder zur Laufzeit vom Sender erzeugt und anschließend dem Empfänger über die Nachricht verschlüsselt übergeben.
Signaturen bieten neben der Datenintegrität und Nachrichtenauthentizität zusätzlich die Möglichkeit, den Sender der Nachricht oder Teile der Nachricht zu authentifizieren. Diese Eigenschaft heißt allgemein auch digitale Unterschrift. Dazu bedient man sich statt einer symmetrischen Verschlüsselung der gemeinsamen Prüfsumme eines asymmetrischen Algorithmus (Public-Key-Verfahren). Der Sender verwendet dabei seinen Private Key zum Verschlüsseln des Hash-Werts. Der verschlüsselte Hash-Wert kann wiederum nur mithilfe des dazugehörigen Public Keys gelesen werden. Ein Zertifikat für den Public Key gibt Auskunft über den Besitzer des Private Keys. Wenn das Zertifikat und damit der Public Key vertrauenswürdig sind, ist man somit in der Lage, die Senderauthentizität zu ermitteln.
Lesen Sie mehr zum Thema
