Security für Business Services

Sicher ist sicher
Kommentare

Serviceorientierte Architekturen (SOA) sollen zu einem Paradigmenwechsel in der Unternehmensanwendungslandschaft führen: Anwendungen werden nicht mehr isoliert entwickelt und später über aufwendig implementierte Schnittstellen miteinander verknüpft, sondern von vornherein als Service gekapselt, der Komponenten querschnittlich zur Verfügung stellt. Auf dem Weg dorthin gibt es viele Herausforderungen, von denen das Thema Sicherheit zu den wesentlichen gehört. Über sich abzeichnende Standards auf diesem Gebiet und deren Umsetzung in aktuellen Produkten, insbesondere Web Services Gateways, informiert dieser Beitrag.

Web Services entwickeln sich zu einem De-facto-Standard, um Funktionalitäten von Geschäftsanwendungen plattformübergreifend anderen Anwendungen zur Verfügung zu stellen. Neue Anwendungen lassen sich auf Basis solcher Web-Services-Bausteine aufbauen, indem auf existierende Funktionalitäten zurückgegriffen wird. Solche Services können synchron sein (einfaches Request/Response-Schema wie bei Remote Procedure Calls), sie können aber auch asynchron sein (Aufruf und späterer Callback, z.B. bei langlaufenden Workflow Services). Sie können einfach lesende Funktionen implementieren (z.B. Börsenkurse oder Wetterinformationen liefern) oder transaktionalen Charakter haben (z.B. Reisebuchungen). Schon heute lassen sich auf Basis von Web Services Orchestrierungsstandards wie BPEL (Business Process Execution Language) benutzen, um Geschäftsprozesse von Anfang bis Ende abzubilden, auszuführen und zu verwalten. Bei der Verwendung von Web Services im professionellen Umfeld stößt man schnell auf das Thema Sicherheit.

• Wie stellt man sicher, dass niemand die übertragenden Daten liest?
• Wie stellt man nun sicher, dass ein Service Consumer berechtigt ist, bestimmte Funktionen eines Service Providers aufzurufen?
• Wie stellt man sicher, dass Daten auf dem Weg zwischen Consumer und Provider nicht verändert werden?
• Wie lassen sich solche Sicherheitsanforderungen erfüllen, wenn die Web Services aus existierenden Business-Funktionen generiert werden, in denen keine Sicherheitsprüfungen implementiert sind?
• Wie kann die Nutzung von Web Services automatisch geloggt werden?

Die Web-Services-Standards wie SOAP und WSDL bieten hier zunächst keine Out-of-the-box-Lösungen; das ist bislang eines der Haupthindernisse bei der Implementierung von Geschäftsprozessen auf Basis einer serviceorientierten Architektur. Daher wurden aufbauend auf den Basis-Standards von Web Services weitere Standards definiert, um die oben genannten Fragen abzudecken. Eine der einfachsten Möglichkeiten, ein Mindestmaß an Sicherheit einzuführen, ist die Kommunikation über https. Hierbei wird SSL als Zwischenschicht im Protokollstack zwischen http und TCP gelegt, indem durch Verschlüsselung auf Basis ausgetauschter (zertifizierter) Schlüssel die Verbindungsdaten gegen Abhören auf der Transportebene gesichert werden.

WS-Security

In der nächsten Stufe bietet OASIS WSSecurity als Erweiterung der Basis-Standards SOAP und WSDL die Möglichkeit, den Austausch von SOAP-Nachrichten zwischen dem Service Requester und dem Service Provider auf Ebene der Nachrichten selbst zu verschlüsseln, gegen Veränderungen zu sichern (Integrität) sowie eine gegenseitige Authentifizierung durchzuführen. Basierend auf den W3C-Standards XML Encryption und XML Digital Signatures wird der SOAP Request zunächst signiert, verschlüsselt und, mit einem Authentifizierungs- Token versehen, über die Leitung an den Service-Provider geschickt. Hier wird der Authentifizierungs-Token geprüft, die Nachricht entschlüsselt und die Signatur geprüft, bevor der eigentliche Service-Aufruf erfolgt. Bei der Übertragung der SOAP-Nachricht an den Service- Requester erfolgt die gleiche Prozedur. Der Authentifizierungs-Token kann ein einfacher Username/Password-Token sein oder aber signierte Tokens wie X.509-Zertifikate. Die Tokens werden bei der Kommunikation in die Header der auszutauschenden SOAP-Nachrichten gestellt. Listing 1 zeigt, wie dies bei einem Username-Token aussieht.

<?xml version=“1.0“ encoding=“utf-8“?>
<S11:Envelope xmlns:S11=“...“ xmlns:wsse=“...“ xmlns:
wsu=“...“ xmlns:ds=“...“>
<S11:Header>
<wsse:Security xmlns:wsse=“...“>
<wsse:UsernameToken wsu:Id=“Example“>
<wsse:Username> ... </wsse:Username>
<wsse:Password Type=“...“> ... </wsse:Password>
<wsse:Nonce EncodingType=“...“> ... </wsse:
Nonce>
<wsu:Created> ... </wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</S11:Header>
<S11:Body wsu:Id=“MsgBody“>
<tru:getBalance xmlns:tru=“http: //samplebank.
com/ws“>
65712356
</tru:getBalance>
</S11:Body>
</S11:Envelope>

In der Praxis machen das nicht die Services selbst (um insbesondere die Implementierung der Sicherheit von der Entwicklung der in den Services darzustellenden Business-Logik zu trennen). Stattdessen können auf JAX-RPC basierende Service Interceptors ausgehende SOAP-Calls mit den Authentifizierungs- Tokens versehen, bevor sie nach draußen gehen, sowie umgekehrt bei eingehenden Nachrichten den Authentifizierungs-Token prüfen, bevor der eigentliche Service aufgerufen wird. Diese Prüfung erfolgt beispielweise gegen ein LDAP-konformes Verzeichnis.

Authentifizierung mit SAML

Ein weiterer wichtiger Standard beim Einsatz von Web Services ist die Security Assertion Markup Language SAML. Hierbei wird der Prozess der Prüfung von Authentifizierung (wer ist der Service-Requester?) und Autorisierung (was darf der Service-Requester) nicht dem einzelnen Web Service aufgebürdet, sondern einem zentralen Sicherheitsservice. Das Ergebnis ist ein so genannter optional signierter SAML-Token, der ebenfalls in WS-Security-Aufrufen übertragen werden kann und dem der Service vertrauen kann. Die Idee ist dabei, dass dadurch Sicherheitskontexte von einem aufgerufenen Service auf einen evtl. von diesem aufgerufenen Service „weitergereicht“ werden können. SAML-Tokens unterscheiden sich also von Username/ Passwort- oder X.509-Tokens dahingehend, dass sie die Authentifizierung bereits enthalten. Eine weitere Anwendung besteht in der Nutzung eines Single-Sign-on- Dienstes als SAML-Security Service. Hat sich beipielsweise der Nutzer einer Portal- Anwendung bereits gegenüber einem Single- Sign-on-Dienst authentifiziert und ruft diese Anwendung einen Web Service auf, wird dem SOAP-Request ein SAML-Token mitgeliefert, der dem empfangenden Service mitteilt, dass der User bereits authentifiziert und autorisiert ist und weitere Prüfungen nicht notwendig sind.

Auf Basis dieser Technologien gibt es heute schon Software-Produkte, die Policy-basiert Web Services sichern. Als Beispiel sei hier der Oracle Web Services Manager genannt, der als eine Art Web Services Firewall fungiert.

Abb. 1: Der Oracle Web Services Manager

Aufmacherbild: padlock icon von Shutterstock / Urheberrecht: Palau

[ header = Policy-basierte Sicherung von Web Services ]

Policy-basierte Sicherung von Web Services

Die Implementierung der Business-Funktionalitäten wird in den Services von den Sicherheits-Policies getrennt. Dadurch können diese zentral administriert und automatisch allen Services zur Verfügung gestellt werden. Die Web Services selbst müssen nicht angepasst werden, wenn sich diese Policies ändern. Eine solche Policy kann typischerweise beinhalten:

• Entschlüssele die ankommende Nachricht
• Extrahiere die Anmelde-Daten des Nutzers
• Prüfe die Authentifizierung des Nutzers über ein zentrales Verzeichnis (z.B. Password- Check gegen ein LDAP-Verzeichnis oder Prüfung eines SAML-Tokens, der beispielweise von einem Single Signon Server ausgegeben worden ist)
• Prüfe die Autorisierung des Nutzers (darf er die angeforderte Operation des Web Service nutzen)
• Protokolliere den Service-Aufruf im Logfile
• Leite den Service-Aufruf an den eigentlichen Service weiter, wenn alles okay ist
• Protokolliere andernfalls einen Fehler und gebe einen Fehler als Rückgabenachricht an den Service Requester

Grundsätzlich können solche Service Manager, durch die alle Service-Aufrufe gehen, in zwei verschiedenen Konfigurationen genutzt werden, die hier schematisch dargestellt worden sind.

Abb. 2: Schematische Darstellung der Sicherung von Web Services

Web Services Management Gateway

Mithilfe des Web Services Management Gateway wird ein zentraler Proxy-Service zur Verfügung gestellt, der typischerweise innerhalb einer Demilitarisierten Zone (DMZ) im Unternehmensnetzwerk implementiert wird. Alle Service Requests, die eine besondere Sicherung benötigen, gehen an diesen Proxy-Service und enthalten die Request-Daten für den eigentlichen Service (hier Business-Service genannt) in den Parametern. Die Details dieser Business Services sind nach außen komplett abgeschirmt. Der Proxy-Service gibt nach Abarbeitung der Policies den Request weiter (bzw. gibt einen Fehler zurück). Die Antwort des Business Service wird ebenso nicht direkt an den Requester zurückgegeben, sondern ebenfalls über den Proxy-Service, der gegebenenfalls die Antwort verschlüsselt und signiert. Des Weiteren kann ein Web Services Management Gateway auch genutzt werden, um Protokollanpassungen für Nicht- SOAP-Services vorzunehmen. So kann z.B. eine XML-über-http-Nachricht in einen Java-Messaging-Service-(JMS-)Aufruf umgewandelt werden. Weiterhin können Routing Policies hinterlegt werden, nach denen die Requests an die Business Services weitergeleitet werden. Die Policies werden über ein zentrales, browserbasiertes Tool administriert, in einer datenbankbasierten Registry gespeichert und von dort an die Proxy-Services per Push weitergeleitet.

Web Services Agents

Alternativ zu den Gateways gibt es auch die Möglichkeit, die Policies über so genannte Web Services Agents zu implementieren. Auch hier werden Policies zentral verwaltet und per Push an die Services verteilt. Diese Policies werden aber dezentral in den Prozessräumen
der Business-Services-Host-Rechner durch einen zwischen dem SOAP Interface und den Business Services geschalteten Software Agent selbst durchgeführt. So kann beispielsweise die Verschlüsselung und Integrität der Kommunikation bis zum Service-Endpunkt gewahrt werden. Der Nachteil ist, dass keine Transformation oder Rerouting stattfi nden kann.

Überwachung der Web-Services-Aufrufe

Die Überwachung der Nutzung von Web Services wird durch Logging und Auditing ermöglicht, die von Gateways und Agents gewährleistet werden. So lassen sich z.B. Versuche, nichtautorisiert Dienste zu nutzen, schnell erkennen. Des Weiteren lassen sich technische Performance-Statistiken auswerten (wie z.B. die durchschnittlichen Ausfall- oder Antwortzeiten).

Zusammenfassung

Web Services sind auf dem besten Weg, unternehmensinterne Business-Funktionen als Dienst zur Verfügung zu stellen und herkömmliche monolithische Anwendungen abzulösen. Das Thema Sicherheit ist bisher ein Stolperstein auf dem Weg dorthin gewesen. Hier erlauben Standards wie WS-Security die Kommunikation mit den Services im Hinblick auf Verschlüsselung, gegenseitige Authentizität der Beteiligten sowie Integrität der Nachrichten. Zusätzlich erlaubt SAML die Authentifi zierung gegenüber solcher Services im Rahmen von Single-Sign-on-Verfahren. Web Services Manager können heute bereits diese Standards implementieren und setzen zentral verwaltbare Security-Policies als eine Art Service-Firewall durch (entweder als zentraler Proxy- Service oder aber als Agents auf den Business-Services-Host-Rechnern selbst) und protokollieren die Benutzung dieser Services. Diese Technologien stellen einen wichtigen Schritt dar, um auch Unternehmen in sicherheitssensiblen Branchen, wie z.B. dem Finanzwesen oder dem öffentlichen Dienst, die Nutzung von serviceorientierten Architekturen zu ermöglichen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -