Sichere Kommunikation für SOAP-basierte Web Services

Transkript

1 Whitepaper SOA Security Framework Sichere Kommunikation für SOAP-basierte Web Services Holger Junker, BSI, Die Sicherheitsanforderungen an SOA Infrastrukturen und den darin stattfindenden sicheren und vertrauenswürdigen Geschäftstransaktionen über multiple Parteien besitzen meist zumindest einen hohen Schutzbedarf und ergeben sich aus der Summe herkömmlicher Herausforderungen unter Berücksichtigung SOA-spezifischer Besonderheiten. Dies betrifft neben der Problematik verteilter Strukturen, realisiert durch offene Formate, auch Administrations- und Beherrschbarkeitsaspekte. Die Realisierung eines Geschäftsprozesses über eine Vielzahl lose gekoppelter Services erfordert beispielsweise mehr Authentisierungsvorgänge, eine jederzeit gewährleistete Vertraulichkeit sowie eine höhere Integrität als in einem monolithischen System. Ein Prozess-Design über Unternehmensgrenzen hinweg und zwischen quasi anonymen Teilnehmern verstärkt diese Sicherheitsanforderungen an Services und Lösungen. Dieses Whitepaper stellt das Konzept des SOA Security Frameworks (SSF) vor, welches mit einem Proxy-Ansatz die zentrale Komponente für die Sicherheit in einer SOA bildet. Konzept eines SOA Security Frameworks Ein SOA Security Framework (SSF) bietet die technische Grundlage, mit dessen Hilfe bestehende Sicherheitsanforderungen in einer SOA umgesetzt und Kommunikationswege von Web Services und die Dienste selbst abgesichert werden können. Zur technischen Umsetzung der Anforderungen und Vorgaben bietet das SOA Security Framework analog zur organisatorischen Sicht eine Security-Sicht, welche die Administration, Verteilung und Orchestrierung der Security-Logik in einem Gesamtsystem abbildet. Kernkomponente ist die Umsetzung der Sicherheitsrichtlinie, die an die lokalen Komponenten (Connectoren) verteilt wird, damit diese die Einhaltung der Richtlinie forcieren.

2 Anforderungen an ein SSF Grundsätzlich gelten für die Absicherung von SOA-Infrastrukturen zunächst ähnliche Anforderungen wie bei der Absicherung herkömmlicher Systeme teilweise in SOAtypischen Ausprägungen. Wie bei herkömmlichen Systemen üblich, müssen Identitäten und Berechtigungen verwaltet, Benutzer authentisiert, Zugriffsberechtigungen überprüft, Zugriffe und Zugriffsversuche aufgezeichnet und Daten mittels kryptographischer Methoden signiert (Sicherstellung von Integrität) oder verschlüsselt (Gewährleisten von Vertraulichkeit) werden. Gerade in verteilten Umgebungen werden zudem systemweite Sicherheitsrichtlinien (Policies) benötigt, deren Einhaltung (Compliance) es permanent zu überwachen gilt. Der Grundgedanke von SOA wirft dabei weitere Anforderungen auf, die durch die Integration verteilter und teilweise heterogener Systeme zu beachten sind. Zu nennen sind an dieser Stelle bspw. die Umwandlung von Identitäten und deren Formate, der Einsatz von offenen Standards und die Gewährleistung der Wiederverwendbarkeit von Security Diensten. Solche Anforderungen können durch einen Framework-Ansatz erfüllt werden, der mindestens folgende sicherheitsspezifische Funktionalitäten bietet. 1. Verwaltungen von Identitäten (Identity Management), 2. Authentisierung und Autorisierung, 3. Absicherung der Nachrichten (Message Protection) - Kryptographie (Verschlüsselung und Signaturen) und Datenschutz (Privacy), 4. Sicherheitsrichtlinien Durchsetzung und Entscheidung (Enforcement und Decision). Architekturansatz Die Umsetzung einer Sicherheitsrichtlinie bzw. -mechanismen für die Dienste in einer SOA kann prinzipiell auf drei Arten erfolgen: durch die Anwendungslogik, durch die Verwendung von Security-Services (Security als Service), durch eine Proxyschicht vor den Services (Security als Infrastruktur). In einem Nicht-SOA-Umfeld wird die Sicherheit durch Schutzmaßnahmen des Computersystems und einer Sicherheitslogik in den Anwendungen monolithisch abgebildet. Dies ist in einem SOA-Umfeld jedoch meist nicht praktikabel. Eine Anforderung an eine Service-orientierten Architektur ist die Wiederverwendbarkeit von Services und die Zentralisierung derselben. Aus diesem Grund müssen u.a. die Berechtigungsverwaltung und die Security-Administration außerhalb der Service-Logik erfolgen. In einer SOA-Infrastruktur liegt es nahe, Sicherheit ebenso wie Anwendungslogik als wiederverwendbare Services bereitzustellen. Security-Services bedeutet dabei die Bereitstellung von Sicherheitsmechanismen in Form von Diensten, die von allen Anwendungen/Komponenten über standardisierte Schnittstellen genutzt werden können. Über ein solches Konzept lassen sich viele Sicherheitsanforderungen effizient realisieren. Ein solches Konzept trägt insbesondere der Wiederverwendbarkeit Rechnung, da viele Sicherheitsmechanismen von verschiedenen Anwendungen gleichartig genutzt werden können. Beispiele hierfür sind Signaturen mittels Digital Signature Services (DSS), Public-

3 Key-Infrastruktur (PKI) via XKMS oder ein zentraler Loggingmechanismus. Security als Infrastruktur wird im Gegensatz zu den SOA-Security-Services genutzt, wenn Sicherheitsmechanismen von der Anwendungslogik getrennt werden sollen. Häufig ist es wünschenswert, Systeme und Aufrufe durch eine Infrastrukturkomponente (Appliance oder Proxy Ansätze) zu schützen. Ein Proxy ist als Dienstprogramm zu verstehen, welches als Mittler zwischen Netzen, Anwendungen und Services fungiert. Durch den Einsatz von Proxies für die Umsetzung der SOA-Sicherheit kann eine vollständige Plattform- und Systemunabhängigkeit erreicht werden. In diesem Szenario befinden sich Proxies zwischen den einzelnen Knoten der Architektur, so dass sie sicherheitsrelevante Informationen innerhalb der Nachrichten hinzufügen, bearbeiten oder kontrollieren. Durch die Verwendung dieses Konzeptes wird eine klare Trennung zwischen Anwendungs- und Sicherheitslogik geboten. Abbildung 1: Security as Infrastructure mittels vorgeschalteten Connectoren Anforderungen wie Vertraulichkeit, Integrität, Authentizität und Verbindlichkeit können durch die Verwendung von WS-Security-Standards (WS-Security, XML-Encryption und Signature, etc.) auf Nachrichtenebene umgesetzt werden. Dafür bietet sich die Implementierung von lokalen Proxy-Agenten im Sinne einer Infrastruktur an. Für die Authentisierung bietet SAML 2.0 standardisierte Methoden, die eine Interoperabilität von Authentisierungsinformationen ermöglichen. Ein entsprechendes Entity- und Credential- Mapping vorausgesetzt, sind somit auch Federation-Ansätze umzusetzen. Ebenso für die Autorisierung für Service Aufrufe ermöglicht die zentrale Komponente die Verwaltung von Rollen und Rechten für den Zugriff. Am Policy-Enforcement-Point (vor oder auf den Service-/Backendsystemen) kann auf deren Basis die Zugriffsentscheidung getroffen werden. Liegt keine entsprechende Berechtigung vor, lehnt der Agent den Zugriff auf eine Ressource ab. Bei der Integration von Legacy-Systemen kann der Agent zusätzlich eine Nachrichtentransformation vor dem System vornehmen. Eine Änderung des Alt-Systems ist nicht notwendig, da der Agent das System im erwarteten Format anspricht. Als Basis für die kryptographischen Sicherheitsmechanismen dienen dabei insbesondere X.509-Zertifikate. Diese werden entweder intern durch das SSF generiert und verwaltet oder durch die Anbindung einer externen PKI integriert. Security Workflow Sowohl für Service-Clients als auch für Service-Provider bietet das SSF die Möglichkeit, einen sog. Security Workflow zu definieren. Ein solcher Security Workflow beschreibt die anzuwendenden Sicherheitsmechanismen und kann auf der Grundlage der folgenden Basisdienste modelliert werden: Ver- und Entschlüsselung von XML-Nachrichten durch XML-Encryption (auf X-Path- Basis oder vollständig) Signieren und verifizieren signierter XML-Nachrichten durch XML-Signature (auf X- Path-Basis oder Envelope) SAML basierte Authentisierung von XML Nachrichten (SAML 1.1 & 2.0)

4 Hinzufügen/Überprüfen des Authentication Statements (SAML-Token zu SOAP-Nachrichten) Abgleich mit erlaubten Entitäten innerhalb der Entitätsverwaltung HTTP to SOAP Transformation Syntaktische Prüfung von SOAP-Nachrichten Aufruf externer Web Services auf Basis von WSDL-Beschreibungen (Nutzung von Security as a Service als Teil des Security Workflows) Erzeugen von Fehlermeldungen Diese Security Workflows werden zentral definiert und anschließend an die lokalen Komponenten (Connectoren) der Service-Clients bzw. -Provider verteilt. Die Connectoren fungieren als ein Policy Enforcement Point (PEP) und garantieren die Einhaltung der Workflows. Beispielszernario Zur Veranschaulichung der Verwendung des SSF soll nun das Beispielszenario eines Buchhändlers (vgl. folgende Abbildung) herangezogen werden. Hier soll exemplarisch die Schnittstelle zwischen Händler und Zahlungsservice Provider betrachtet werden. Abbildung 2: Beispielszenario (Quelle: SOA Security Kompendium des BSI) Folgende Anforderungen werden an diese Schnittstelle gestellt: 1. Die Integrität der Daten muss gewahrt werden. 2. Einhaltung der Datenschutzbestimmungen im Umfeld der personenbezogenen

5 Daten. 3. Kreditkartendaten als sehr sensitive Daten müssen vertraulich behandelt werden. 4. Die Authentizität/Identitätsnachweis der Informationsempfänger muss sichergestellt werden. 5. Die Authentizität/Identitätsnachweis der Informationssender muss sichergestellt werden. 6. Die Nachweisbarkeit und die Verbindlichkeit der Kommunikation muss gewährleistet sein. Im Folgenden wird die Security Policy zur Erklärung der Transformationsschritte - in eine pseudocode-ähnliche Definition übersetzt. Anschließend wird daraus ein Security Workflow geniert, so wie er in diesem Fall im SSF ablaufen würde. 1. Integrität wird durch den SOA-Security Standard XML-Signature/WS-Security erreicht, hierzu muss die Nachricht mit dem privaten Schlüssel des Absenders signiert werden. Dies wird durch die SSF-Workflow-Funktion signsoapenvelope erreicht. 2. Datenschutzbestimmungen von personenbezogenen Daten umfasst den Schutz gegen - Veränderung der Daten (vgl. Punkt 1. Integrität) - Datendiebstahl bzw. unberechtigte Kenntnisnahme der Daten. Dies fordert die Vertraulichkeit der Daten, welche durch den SOA-Security Standard XML-Encryption/WS-Security erreicht wird. Hierzu müssen die zu Schützenden Daten der Nachricht mit dem öffentlichen Schlüssel des Empfängers verschlüsselt werden. Dies wird durch die SSF-Workflow- Funktion encryptxpathforcertificate erreicht. 3. Vertraulichkeit von Kreditkartendaten (vgl. Punkt 2. Vertraulichkeit) 4. Authentizität/Identitätsnachweis der Empfänger wird durch den SOA-Security Standard XML-Encryption/WS-Security erreicht, da nur der Empfänger mit Hilfe seines privaten Schlüssels die Nachricht entschlüsseln kann (vgl. Punkt 2. XML- Encryption/WS-Security). 5. Authentizität/Identitätsnachweis des Senders wird durch die SOA-Security Standard - XML-Signature/WS-Security erreicht, da nur der Sender der Nachricht über den privaten Schlüssel zur Signaturerstellung verfügt (vgl. Punkt 1. XML- Signature/WS-Security). - SAML erreicht. Hierzu müssen die Identitätsinformationen des Absenders in standardisierter Form der Nachricht hinzugefügt werden. Dies wird durch die SSF-Workflow-Funktion SAMLAddUserAuth (SAML 2.0) erreicht. 6. Nachweisbarkeit und die Verbindlichkeit wird durch den SOA-Security Standard XML-Signature/WS-Security erreicht (vgl. Punkt 1. XML-Signature/WS-Security). Insgesamt müssen also die SSF-Funktionen SAMLAddUserAuth (SAML 2.0), signsoapenvelope und encryptxpathforcertificate mit einer geeigneten Konfiguration verwendet werden. Nun wird der Workflow unter Zuhilfenahme der Workflow-Komponente im Administrationsbereich des Connectors generiert (vgl. folgende Abbildung 3). Dies geschieht durch Auswahl der entsprechenden Funktionen in Drop-Down Boxen, sowie der

6 entsprechenden Konfiguration der Funktionen. Aus Gründen des Umfangs soll hier nicht auf die Konfiguration (Parametrisierung) der Funktionen eingegangen werden. Als Eingangsfunktion (Entry) wird ein Listener (AppServer listener #1) gewählt. Dieser öffnet auf dem Application Server einen Port nach Wahl und übernimmt eingehende Nachrichten. Da im Rahmen des Workflows eine Signatur erfolgen soll, muss nun die entsprechende Entität dem Workflow bekannt gegeben werden. Dies erfolgt über die Funktion SetSecRTEntity. Will man nun in der nächsten Auswahlbox eine Funktion wählen, so erhält man nur Funktionen, welche auf http-objekten operieren, die SOAP-spezifischen Funktionen werden nicht angezeigt. Dieses kontextsensitive Verhalten verhindert, dass der Administrator, welcher den Workflow definiert syntaktische Fehler begehen kann. Um die SOAP-Funktionen nutzen zu können, muss die http-nachricht als SOAP-Nachricht interpretierbar gemacht werden. Hierzu wird die Funktion ExtractFromRequest genutzt. Anschließend werden die SOA-Security Funktionen SAMLAddUserAuth (SAML 2.0), signsoapenvelope und encryptxpathforcertificate wie oben definiert aufgerufen. Zum Abschluss wird aus der SOAP Nachricht wiederum eine http-nachricht (EnvelopeInRequest) und diese wird über die Funktion Proxy an den Empfänger weitergeleitet. Die folgende Abbildung zeigt das Ergebnis der Workflowdefinition. Abbildung 3: Workflowdefinition Analog muss anschließend die Absicherung der Response, also die Nachrichtenentschlüsselung, Prüfung der SAML-Nachrichtenbestanteile und der Signatur auf der Seite des Service-Providers erfolgen. Wurden die entsprechenden Workflows konfiguriert, so können diese automatisiert verteilt werden. Hier können sie dann für die Verwendung ausgewählt werden. Ist jeweils der Connector bei Händler und Zahlungsservice Provider eingestellt, so ist ohne Neustart die Konfiguration aktiv und die gewünschte Absicherung der Nachrichten findet statt. Resümee und Ausblick Das SOA Security Framework ist ein Werkzeug für die ganzheitliche Absicherung von Diensten und deren Kommunikation in einer SOA, welches individuell den jeweiligen

7 Anforderungen angepasst werden kann. Darüber hinaus besteht die Möglichkeit, das SSF um weitere Sicherheitsmechanismen zu erweitern wie z.b. die Funktionalität einer SOAP-/ WebService-Firewall. Das SOA Security Framework wird durch das BSI unter freier Lizenz zur Verfügung gestellt. Weitere Informationen hierzu liefert die Webseite des BSI: Fragen und Anregungen richten Sie bitte an