SOA-Security-Kompendium

Transkript

1 Sicherheit in Service-orientierten Architekturen Version 2.0

2 In Zusammenarbeit mit: Postfach Bonn Tel.: Internet:

3 Inhaltsverzeichnis Inhaltsverzeichnis Einleitung...9 Motivation...9 Zielbestimmung und Geltungsbereich...10 Aufbau des Kompendiums...10 Grundlagen - Einführung in SOA und Web Services...12 Abstrakte Charakteristika Service-orientierter Architekturen...12 Ziele und Vorteile von SOA...15 Konkrete Umsetzungen...16 Beispielszenario...20 Sicherheitsaspekte Service-orientierter Architekturen...22 Allgemeine Sicherheitsziele...22 Kategorien von Sicherheitsgefährdungen...25 Konkrete Gefährdungen und geeignete Sicherheitsmaßnahmen in einer SOA...27 Sicherheitsgefährdungen und Gegenmaßnahmen veranschaulicht am Beispielprozess...41 Technologien und Standards...45 Überblick über die Web Service Spezifikationen...45 Grundlegende Web Service-Standards...48 Dienste beschreiben und auffinden...57 Grundlegende Sicherheitsstandards...75 Dienstkommunikation absichern...89 Messaging-Nachrichten zustellen Reliable-Messaging Transaction Specifications Dienste orchestrieren und choreographieren Weitere Standards Interoperabilität Security Management Governance, Risk- & Compliance-Management Sichere SOA Migration SOA Lifecycle Management Darstellung des Zusammenhangs Sicherheitsmanagement, GRC, SOA Migration und SOA Lifecycle Management Konzepte für Sicherheit in Service-orientierten Architekturen SOA Security Framework Policy Management Trust Management Identitätsmanagement in SOA Sichere Dienstkomposition zur Abbildung von Geschäftsprozessen Sicherheit und Interoperabilität mit WS-I

4 Inhaltsverzeichnis Sichere SOA Technologien in der Praxis Sicherheit von Portalen als Schnittstelle zu SOAs Methoden und Möglichkeiten der XML-/WS-*-Filterung Sicherheit SOA-spezifischer Repositories Sichere Dienstbeschreibungen mit BPEL Sicherheit REST-basierter SOAs Sicherheitstests in SOA Anwendungsszenarien Resümee und Ausblick Resümee Ausblick Forschungsbedarf Anhang Übersicht über die Standards Code-Beispiele Abkürzungsverzeichnis Glossar Referenzen Abbildungsverzeichnis Abbildung 1: Schematische Darstellung der Consumer-Provider-Beziehung...12 Abbildung 2: Aufbau einer XML-basierten SOAP Nachricht...17 Abbildung 3: Ablauf eines Dienstaufrufs unter Verwendung einer zentralen Registry...19 Abbildung 4: Web Service-Protokollstack für die unterschiedlichen Phasen der Servicesuche bzw. nutzung...19 Abbildung 5: Beispielszenario einer Service-orientierten Architektur unter Verwendung externer Dienste...21 Abbildung 6: Beispielszenario einer Service-orientierten Architektur unter Verwendung externer Dienste...42 Abbildung 7: Überblick über die Web Service Spezifikationen...46 Abbildung 8: Aufbau einer SOAP Nachricht...53 Abbildung 9: Klassische Verwendung von SOAP...54 Abbildung 10: Verhältnis von UDDI zu anderen Protokollen und Standards im Web ServiceUmfeld [UDDI]...62 Abbildung 11: Nachrichtenkommunikation bei WS-Discovery [WS-Discovery]...66 Abbildung 12: Darstellung der Zusammenhänge zwischen WS-Policy und WSPolicyAttachment[WSPO]...69 Abbildung 13: Einbindung von Policies in ein WSDL-Dokument [WSPAtt]

5 Inhaltsverzeichnis Abbildung 14: Einbettung einer Policy mit verschiedenen Assertions in ein WSDL-Dokument...73 Abbildung 15: Struktur eines GetMetaData Aufrufs mit WS-MetadataExchange...74 Abbildung 16: Enveloped Signature...78 Abbildung 17: Enveloping Signature...78 Abbildung 18: Detached Signature...79 Abbildung 19: Bestandteile des SAML 2.0 Standards...81 Abbildung 20: XACML Architektur (vgl. [XACML_IBM])...84 Abbildung 21: SPML Domain Model Elements [SPML]...87 Abbildung 22: Interaktion zwischen einem Client und einem XKMS-Service (Schlüsselaustausch) in Anlehnung an [XKMS]...89 Abbildung 23: Einbindung von Sicherheitsmechanismen in den Header einer SOAP Nachricht durch WS-Security...92 Abbildung 24: WS-Trust Szenario...96 Abbildung 25: Beispiel für WS-Routing Abbildung 26: Notification Pattern Abbildung 27: Brokered Notification Pattern Abbildung 28: Darstellung der Funktionsweise von WS-ReliableMessaging [WSRM] Abbildung 29: Detaillierte Darstellung des Ablaufs von WS-ReliableMessaging [WSRM] Abbildung 30: Zusammenspiel der einzelnen Komponenten bei WS-Coordination Abbildung 31: Szenario WS-AtomicTransaction Abbildung 32: Darstellung eines in WSFL beschriebenen Work Flow/ Prozesses einer Ticketbestellung [WSFL] Abbildung 33: WS-CDL Funktionsweise (vgl. [WS-CDL]) Abbildung 34: Aufbau einer elektronischen Geschäftsbeziehung mit ebxml in Anlehnung an [ebxml2] Abbildung 35: Schematischer Aufbau einer SCA Komponente Abbildung 36: Einordnung SOA Governance Abbildung 37: PDCA-Cycle mit Komponenten Abbildung 38: Einordnung SOA-Risiken Abbildung 39: Darstellung des Risikomanagement-Prozesses Abbildung 40: Schrittweise SOA Migration (vgl. [Gi 2008]) Abbildung 41: Vorgehen SOA Migration Abbildung 42: SOA Maturity Model Abbildung 43: Typische gewachsene Anwendungslandschaft einer Organisation und deren Interaktion Abbildung 44: Arbeitsweise eines Wrapper Service

6 Inhaltsverzeichnis Abbildung 45: Abbilden der Sicherheitsmechanismen des Wrapper Service auf die Altanwendung Abbildung 46: Nutzung eines gemeinsamen Security Service von Wrapper Service und Anwendung Abbildung 47: Aufbau DMZ (vgl. [Ka 2008]) Abbildung 48: SOA Lebenszyklus Abbildung 49: IT-System Lebenszyklus Abbildung 50: Darstellung des V-Modells XT[VModellXT] Abbildung 51: Nutzungszyklus eines Web Service Abbildung 52: Übersicht der Lebenszyklen Abbildung 53: Darstellung der Zusammenhänge Abbildung 54: Darstellung der Zusammenhänge SOA Governance und Security Framework Abbildung 55: Architekturansätze Abbildung 56: Sicherheit als integraler Bestandteil der Infrastruktur einer SOA Abbildung 57: Sicherheit als eigenständiger Service Abbildung 58: Sicherheit als integraler Bestandteil der mit einem WS-Interface versehenden Anwendung Abbildung 59: Basiskomponenten für das Policy Management Abbildung 60: Abstraktionsebenen von Policies (vgl. [PMgmt]) Abbildung 61: Lokale Speicherung von Policies und separate Administration (vgl. [PMgmt]) Abbildung 62: Lokale Speicherung von Policies mit zentralisierter Administration (vgl. [PMgmt]) Abbildung 63: Zentrale Speicherung und Administration der Policies (vgl. [PMgmt]) Abbildung 64: Zentrale Administration sowie zentrale und dezentrale Speicherung der Policies (vgl. [PMgmt]) Abbildung 65: Dynamische Nutzung eines Dienstes unter Berücksichtigung von Sicherheitsanforderungen Abbildung 66: Auswahl einer Option zur Verschlüsselung Abbildung 67: Sicheres Late Service Binding Abbildung 68: Policy Enforcement Point als Bibliothek Abbildung 69: Policy Enforcement Point als Modul Abbildung 70: Policy Enforcement Point als Gateway Abbildung 71: Direktes Vertrauen zwischen einem Client und einem Dienst Abbildung 72: Vertrauensbeziehungen in einer Domäne mit zentralen Sicherheitsdiensten Abbildung 73: Direktes Vertrauen zwischen einem Dienst und einer Partnerdomäne

7 Inhaltsverzeichnis Abbildung 74: Indirektes Vertrauen zwischen einem Dienst und einer Partnerdomäne Abbildung 75: Lebenszyklus einer digitalen Identität Abbildung 76: Prinzip des anwendungsspezifischen Identitätsmanagements Abbildung 77: Prinzip der zentralisierten Verwaltung von Identitäten Abbildung 78: Prinzip des föderativen Identitätsmanagements Abbildung 79: Prinzip des benutzerzentrischen Identitätsmanagements Abbildung 80: Rollen und Beziehungen im Identity Metasystem Abbildung 81: Nutzung von Diensten in einer abgesicherten Umgebung Abbildung 82: Nutzung von Diensten einer Sicherheitsdomäne Abbildung 83: Nutzung von Diensten in verschiedenen Sicherheitsdomänen Abbildung 84: Transportorientierte Umsetzung der Verschlüsselung und Integrität Abbildung 85: Nachrichtenbasierte Umsetzung der Verschlüsselung und Integrität Abbildung 86: Übersicht über die WS-I Profile Abbildung 87: WS-I Basic Security Profile Abbildung 88: WS-I Attachments Profile Abbildung 89: Simple SOAP Binding Abbildung 90: Darstellung Reliable Secure Profile Abbildung 91: Darstellung WS-I Kerberos Token Profile Abbildung 92: Darstellung WS-I REL Token Profile Abbildung 93: Darstellung WS-I SAML Token Profile Abbildung 94: WS-I Testing Tool Architektur Abbildung 95: Monitor Systemkonfigurationen (vgl. [Br 2003]) Abbildung 96: Analyzer Tool Abbildung 97: WS-Security-Gateway Deployment Abbildung 98: Architektur eines WS-Security-Gateways Abbildung 99: Zentraler BPEL Workflow Abbildung 100: Zentraler BPEL Workflow entschlüsselt Nachrichten komplett Abbildung 101: Zentraler BPEL Workflow leitet verschlüsselte Nachrichtenteile weiter Abbildung 102: V-Modell zur Darstellung der Testmethoden in Anlehnung an V-Modell XT[VModellXT] Abbildung 103: Kriterien für Schwachstellen-Tests[BSI 2003] Abbildung 104: Anwendungsszenario im Überblick Abbildung 105: Beispielprozess für die betrachteten Anwendungsszenarien Abbildung 106: Produkt anfragen

8 Inhaltsverzeichnis Abbildung 107: Angebot erstellen Abbildung 108: Bestellung ausführen Abbildung 109: Versand Abbildung 110: Bestellung prüfen Abbildung 111: Produkt bestellen Abbildung 112: Umsatzsteuervoranmeldung Abbildung 113: Verfügbarkeit prüfen Abbildung 114: Bestellung prüfen Abbildung 115: Technische Systeme im Beispielprozess Tabellenverzeichnis Tabelle 1: Beschreibung der MEPs und ihre Fehlerbehandlung...59 Tabelle 2: Auflistung der Metadatenformate für WS-MetadataExchange...74 Tabelle 3: Sicherheitspezifikationen und deren Anwendung hinsichtlich der Umsetzung von Sicherheitsanforderungen...90 Tabelle 4: Übersicht über die Spezifikationen des WS-Resource Frameworks Tabelle 5: Vor- und Nachteil der Top-down Vorgehensweise Tabelle 6: Vor- und Nachteile der Bottom-up Vorgehensweise Tabelle 7: Gegenüberstellung einiger Eigenschaften von monolithischen Systemen und SOA Tabelle 8: Beispiele für Inkompatibilitäten hinsichtlich der Umsetzung von Sicherheit in einer SOA Tabelle 9: Standardszenarien und ihre Vertrauensbeziehungen Tabelle 10: Mechanismen zur Etablierung von Vertrauen Tabelle 11: Einordnung der Identitätsmanagementmodelle Tabelle 12: Identifizierte Herausforderungen innerhalb und außerhalb des Scopes WS-I Basic Security Profile Tabelle 13: Identifizierte Bedrohungen innerhalb und außerhalb des Scopes vom WS-I Basic Security Profile Tabelle 14: Optionen zur Absicherung auf der Transportebene Tabelle 15: Optionen zur Absicherung auf der Nachrichtenebene Tabelle 16: WS-I Profile und referenzierte Dokumente Tabelle 17: Vergleich der Standards ebxml und UDDI (vgl. [SM 2005]) Tabelle 18: Übersicht über die beschriebenen Standards Tabelle 19: Glossar

9 1 Einleitung 1.1 Motivation Mit der fortschreitenden Bedeutung und Realisierung von Service-orientierten Architekturen gewinnen auch neue Sicherheitstechnologien und -maßnahmen deutlich an Relevanz. Traditionelle Sicherheitsmechanismen sind nicht 1:1 auf IT-Architekturen übertragbar, die konsequent das Prinzip der Service-Orientierung verfolgen. Vielmehr müssen neue Sicherheitskonzepte und -lösungen entwickelt werden, die speziell die Sicherheitsziele hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit von Daten in Service-orientierten Architekturen gewährleisten. Service-orientierte Architekturen (SOA) beschreiben einen allgemeinen Ansatz zur Realisierung verteilter Systeme, um Organisationen mittels IT bei der Durchführung ihrer Geschäftsprozesse effizient zu unterstützen. Die Durchführung der einzelnen Aktivitäten innerhalb eines Geschäftsprozesses wird dabei von Diensten übernommen, die über mehrere Organisationen verteilt sein können. Die Konzepte von SOA versprechen viele bestehende Probleme bei der Integration und Interaktion unterschiedlicher Teilsysteme zu lösen. Dieses Potenzial wurde in der Praxis sowohl von Unternehmen als auch Behörden (nachfolgend unter Organisation subsumiert) erkannt. Viele Organisationen planen eine zukünftige Migration hin zu einer Service-orientierten Architektur bzw. haben schon heute gewisse Service-basierte Strukturen für Geschäftsprozesse etabliert. SOA ist einer der modernsten Trends der IT und aufgrund seiner geschäftsprozessnahen Ausrichtung insbesondere im Bereich des Managements sehr beliebt. Verhältnismäßig wenig Beachtung wird jedoch den Sicherheitsaspekten in einer SOA geschenkt insbesondere in den Bereichen, wo solche sicherheitsrelevanten Anforderungen auftreten, die in konventionellen IT-Systemen bislang nicht beachtet wurden oder in dieser Form nicht relevant waren. Schließlich befinden sich im Hintergrund von SOAs auch immer entsprechende Geschäftsprozesse, die durchaus kritisch und daher schutzbedürftig sein können. Neben der Sicherheit von einzelnen Service-Anfragen (bzgl. Vertraulichkeit, Authentifizierung, usw.) sind auch übergreifende Aspekte wie z.b. Transaktionssicherheit von Bedeutung. Insbesondere wenn eine Service-orientierte Architektur nicht nur innerhalb einer Organisation verwendet, sondern auch nach außen hin geöffnet wird, kommen zusätzliche Sicherheitsanforderungen hinzu. Derzeit entworfene IT-Systeme auf Basis einer Service-orientierten Architektur werden zunächst meistens unter rein funktionalen Gesichtspunkten entworfen. Sicherheitsfunktionalität wird i.d.r. nachträglich und beschränkt für die einzelnen Komponenten entwickelt. Als Folge dessen wird zumeist ein ganzheitliches Sicherheitskonzept verfehlt und viele SOA-spezifische Sicherheitsanforderungen bleiben unerfüllt. Es fehlt sowohl an einem angemessenen Sicherheitsbewusstsein, einem ganzheitlichen Sicherheitskonzept als auch Best Practice-Ansätzen für diese relativ neue ITArchitektur. Dieser Umstand ist oftmals sogar Ursache für das Scheitern großer und vielversprechender IT-Vorhaben. Damit IT-Systeme gemäß dem SOA-Paradigma in Organisationen unter Einhaltung der jeweiligen Sicherheitsanforderungen realisiert und betrieben werden können, ist es erforderlich, ein angemessenes Sicherheitsbewusstsein zu schaffen und geeignete Lösungsmöglichkeiten für Sicherheit aufzuzeigen. 9

10 1.2 Zielbestimmung und Geltungsbereich Mit der ersten Version des s wurde ein frei verfügbares Nachschlagewerk geschaffen, das wichtige Standards, Konzepte und Lösungen auf diesem aktuellen Gebiet beschreibt. Die Weiterentwicklung des s trägt dem großen Interesse und der steigenden Relevanz bezüglich Sicherheitsthemen auf dem Gebiet von Service-orientierten Architekturen Rechnung. Da die unterschiedlichen Zielgruppen (Projektleiter, IT-Verantwortliche, Software-Architekten, Entwickler, usw.) in besonderem Maße an konkreten Sicherheitsmaßnahmen interessiert sind, werden diese in der zweiten Version des s verstärkt herausgearbeitet. In diesem Zusammenhang liegt ein besonderer Fokus auf dem Management von Sicherheit in SOA sowie der Betrachtung praxisrelevanter, etablierter und innovativer SOA Sicherheitstechnologien. Mit dem SOA-Security Kompendium 2.0 stellt das BSI ein umfangreiches Grundlagenwerk zur Sicherheit in Service-orientierten Architekturen (SOA) zur Verfügung. Das Kompendium vermittelt einen ganzheitlichen Überblick über die für eine erfolgreiche Implementierung einer sicheren SOA umzusetzenden Sicherheitsmaßnahmen und zu berücksichtigenden Standards, Protokolle und Technologien. Experten erhalten zudem eine wertvolle Quelle mit detaillierten technischen Beschreibungen vielfältiger Sicherheitsaspekte und deren Zusammenhänge in Service-orientierten Architekturen. Durch Bewertungen aktueller Verfahren und Lösungen in der Praxis erhalten IT-Verantwortliche die nötige Unterstützung, um Entscheidungen bei der Wahl geeigneter Sicherheitsmaßnahmen zu treffen und diese effizient umzusetzen. Folgende Ziele werden insbesondere mit der Weiterentwicklung dieses Kompendiums verfolgt: 1. Die Notwendigkeit und Relevanz neuer Sicherheitstechnologien und lösungen für Service-orientierte Architekturen wird klar dargelegt. 2. Es entsteht ein umfassendes Nachschlagewerk auf dem Gebiet SOA Security, das alle relevanten Standards und Technologien beschreibt. 3. Konkrete Sicherheitsmaßnahmen werden detailliert erläutert und unterstützen Organisationen bei der Realisierung eines angemessenen Sicherheitsniveaus in Serviceorientierten Architekturen. 4. Zentrale Themen wie bspw. Risiko-, Compliance- und Security-Management werden verstärkt behandelt, da diese einen entscheidenden Einfluss auf den Erfolg und die Nachhaltigkeit von Sicherheitsmaßnahmen haben. 5. Es werden zukünftig relevante, technisch anspruchsvolle und innovative SOA Sicherheitsthemen aus der Wissenschaft und Forschung beleuchtet und es werden signifikante Trends und Entwicklungen aufgezeigt. 1.3 Aufbau des Kompendiums Mit dem Kapitel 2 ( Grundlagen ) soll dem Leser ein leichter Einstieg in die Themen SOA, Web Services und SOA Security gegeben werden. Es werden generelle Zusammenhänge erklärt sowie die allgemeinen Ideen und Funktionsweisen von Service-orientierten Architekturen beschrieben. 10

11 Darauf aufbauend findet im dritten Kapitel ( Sicherheitsaspekte Service-orientierter Architekturen ) eine Betrachtung allgemeiner als auch spezieller Risiken und ITSicherheitsbedrohungen in einer SOA statt. In einer tabellarischen Übersicht werden dabei den jeweiligen Gefahren entsprechende Gegenmaßnahmen zugeordnet. Kapitel 4 ( Technologien und Standards ) stellt dem Leser die wichtigsten Standards, Protokolle, Technologien und Standardisierungsorganisationen auf dem Gebiet der Serviceorientierten Architekturen vor. Es wird das nötige Grundwissen vermittelt, indem Aufgaben und Zusammenhänge einzelner Standards und Protokolle näher erläutert werden. Ausgewählte Beispiele sollen darüber hinaus zu einem besseren Verständnis beitragen. Das Kapitel 5 ( Security Management ) beinhaltet die Beschreibung von Modellen, Verfahren und Lösungen zur effizienten Umsetzung von sicheren Service-orientierten Architekturen sowie deren Management. Während die Kapitel zwei und vier vorwiegend dem Leser die notwendigen theoretischen Grundlagen einer SOA näher bringen, hat dieses Kapitel zum Ziel, dem Leser das nötige Wissen zu vermitteln, um Fallstricke bei der Umsetzung von Sicherheitsmaßnahmen zu vermeiden sowie ein effizientes Vorgehen zu ermöglichen. Innerhalb des Kapitels 6 ( Konzeptionelle Sicherheit ) wird u.a. verstärkt die sichere und interoperable Kommunikation zwischen Diensten beschrieben, die auch über Vertrauensgrenzen sichergestellt werden muss. Ein wesentlicher Aspekt ist dabei die sichere Verwaltung von digitalen Identitäten. Neben Modellen, Standards und Technologien werden aktuelle Identitätsmanagementlösungen in diesem Kapitel vorgestellt und bewertet. Kapitel 7 ( Sichere SOA-Technologien in der Praxis ) betrachtet die Nutzung von sicheren SOA Technologien bzw. Tools und beschreibt konkrete Beispiel-Anwendungsszenarien. In Kapitel 8 ( Resümee und Ausblick ) werden allgemeine Erkenntnisse hinsichtlich SOA Security kurz zusammengefasst sowie zukünftige SOA-Sicherheitsthemen und Trends betrachtet. 11

12 2 Grundlagen - Einführung in SOA und Web Services Geschäftsprozesse basierend auf einer SOA stellen sich als komplexe Gebilde dar, bei denen eine Vielzahl von Komponenten, Systemen und Applikationen involviert sind. In vielen Fällen erstrecken sich solche Prozesse sogar über Organisationsgrenzen hinweg. Ziel dieses Kapitels ist es, eine Einführung in SOA-Architekturen zu vermitteln und diese anhand typischer Szenarien in Organisationen zu verdeutlichen. Neben grundlegenden Prinzipien wird insbesondere auf die Realisierung von SOA mittels Web Services eingegangen. 2.1 Abstrakte Charakteristika Service-orientierter Architekturen Service-orientierte Architekturen (SOA) sind in aller Munde. Zahlreiche Softwarehäuser bieten derzeit Infrastrukturlösungen für SOA an. Dabei ist das Konzept keineswegs neu und wurde bereits teilweise im Rahmen von Enterprise Application Integration (EAI) Projekten verfolgt. Die Architektur moderner IT-Systeme orientiert sich immer stärker an den Geschäftsprozessen, die diese Systeme unterstützen bzw. abbilden. Aufgrund von Aspekten wie Modularität und Wiederverwendbarkeit ist es nicht sinnvoll, die dazu erforderlichen Applikations-Logiken monolithisch im jeweiligen Programm zu realisieren. Vielmehr bietet es sich an, Geschäftsprozesse durch eine Aneinanderreihung von Aufrufen voneinander unabhängiger Services zu modellieren ( Komposition von Services ). Abbildung 1: Schematische Darstellung der Consumer-ProviderBeziehung Service-orientierte Architekturen unterscheiden sich wie folgt von traditionellen ArchitekturAnsätzen: Funktionalitäten und Aufgaben werden nicht wie bei herkömmlichen Systemen innerhalb einer einzelnen Anwendung, sondern als lose gekoppelte, unabhängige, austauschbare Dienste über standardisierte Schnittstellen von einem Service Provider angeboten. Der Service Consumer erhält als Antwort des Service-Requests eine Service Response (vgl. Abbildung 1). Der generische Lebenszyklus eines einfachen Dienstes stellt sich zusammenfassend wie folgt dar: 12

13 1. Publish/Register: Ein Service Provider publiziert einen Dienst und registriert ihn in einem öffentlich zugänglichen Verzeichnis (Service-Repository). 2. Find: Ein Consumer greift mit einer Suchanfrage auf das Service-Repository zu, um einen geeigneten Dienst aufzufinden. 3. Bind: Der Consumer erhält vom Verzeichnisdienst die Adresse, unter welcher der Dienst aufgerufen werden kann, sowie die dazu erforderlichen Parameter, um den Dienst korrekt anzusprechen. 4. Execute: Der Consumer führt den Service-Aufruf unter der zuvor erhaltenen Adresse und unter entsprechender Wahl der Eingangsparameter aus. Als Ergebnis liefert der Dienst die Ergebnisparameter. Service-orientierte Architekturen stellen insbesondere ein großes Potenzial für Behörden dar, die u.a. verschiedene Dienste für Bürgerinnen und Bürger anbieten (Bürgerservice). Die Möglichkeit, mittels SOA diese Dienste miteinander zu verbinden und zu neuen Angeboten zu kombinieren, kann viele Vorteile mit sich bringen. Bürgerinnen und Bürger können zum Beispiel durch die angebotenen Mehrwertdienste profitieren, während die Behörden durch die gemeinsame Nutzung bestimmter Dienste Synergieeffekte erzielen und damit Kosten einsparen. Die exemplarisch genannten Vorteile durch den Einsatz Service-orientierter Architekturen gelten jedoch nicht nur für Behörden, sondern können auch auf andere Institutionen und Unternehmen der Wirtschaft übertragen werden. Da die meisten konventionellen IT-Systeme jedoch Individuallösungen mit proprietären Schnittstellen sind, ist die Realität von der Idealvorstellung weit entfernt. Als Folge dessen resultieren immense Aufwände bei der Integration verschiedener Systeme, häufige Neuentwicklungen und hohe Kosten. Die Lösung dieser Problematik besteht in einer Systemarchitektur, bei der Dienste im Fokus der Betrachtungen stehen. Konkrete Anwendungsfälle von SOA finden sich bereits heute u.a. auch im E-Government (zum Beispiel das Angebot eines virtuellen Rathauses, welches Meldeauskünfte, Grundstücksanfragen, KFZ-Anmeldungen und weitere Dienste ermöglicht), dem Finanzwesen oder in Service-Zentren. Insbesondere große Unternehmen der freien Wirtschaft haben schon früh die Signifikanz und das Potenzial dieses neuen Architekturprinzips erkannt. Aber auch in anderen Anwendungsgebieten stellen Service-orientierte Architekturen einen vielversprechenden Ansatz dar. So wird der SOA-Ansatz u.a. im Bereich des GridComputing (vgl. OpenGrid) mit großem Interesse verfolgt und bekommt aus diesem Forschungsbereich auch eine Vielzahl von Anregungen und Weiterentwicklungen. Auch für die Verarbeitung großer Mengen von Geo- oder Infrastrukturdaten bringt SOA viele Vorteile mit sich. Geodaten können zum Beispiel weiterhin auf effiziente Weise lokal verwaltet und dennoch in aggregierter Form mittels Web Services zur Nutzung in Portalen angeboten werden. Anschauliche praktische Beispiele für Services in einer Service-orientierten Umgebung sind in dem nachfolgend beschriebenen Bestellprozess zu finden: Ein Bestellvorgang eines Kunden bei einem Online-Händler kann durch das Zusammenspiel einzelner Services abgebildet werden. So sorgt der Service Verfügbarkeit prüfen für die Ermittlung der am Lager befindlichen Mengen an Ware. Angefragt über ein standardisiertes Format greift der Service auf ein Warenwirtschaftssystem zu und antwortet dem Web-Portal mit der Service Response. Wie in diesem Beispiel können Services auch Schnittstellen zu weiteren Systemen anbieten. Für den Service Consumer (bspw. ein Web-Portal) bleibt die Logik sowie die detaillierte Funktionalität der in Teilprozessen aufgerufenen Services verborgen. Auch organisationsübergreifende Services sind z.b. bei der Kredit- und Bonitätsprüfung durch eine externe Organisation möglich. Soll ein solcher Service einer 13

14 Kreditanstalt genutzt werden, so wird der Service in den internen Bestellprozess hineinmodelliert und ist dadurch Teil des internen Vorgangs. SOA ist somit auf oberster Ebene ein Managementkonzept, dessen Infrastruktur an den Anforderungen des Geschäftsprozesses ausgerichtet wird und das die strikte Trennung von Prozesslogik (Ablauf eines Prozesses) und Prozessfunktionen (Aufgaben in Prozessen) fordert. Einzelne Services werden wie Programmmodule bedarfsgerecht zusammengefügt. Der Geschäftsprozess ergibt sich durch die Orchestrierung, d.h. durch Aufrufe von lose gekoppelten Services in einer festgelegten Reihenfolge. Das eingesetzte Systemarchitekturkonzept muss daher in der Lage sein, Funktionen in Form von geeigneten Services bereitzustellen. Bei Systemarchitekturen nach dem SOA-Konzept stehen nicht Softwarekomponenten, Protokolle, Standards oder technische Implementierungsdetails im Mittelpunkt. Vielmehr orientieren sich Service-orientierte Architekturen an den abzubildenden Geschäftsprozessen und deren fachlichen Details, die in Form von Diensten modelliert werden. In der Literatur gibt es keine eindeutige Definition von SOA. Dennoch lassen sich gemeinsame Schlüsselmerkmale benennen, die nach verbreiteter Meinung Service-orientierte Architekturen definieren. Standardisierte Service-Schnittstellen Ein wesentliches Merkmal Service-orientierter Strukturen ist die Verwendung von standardisierten Schnittstellen und Beschreibungen. Beschrieben werden muss, wie der Service genutzt werden kann, welche Daten-(Typen) benötigt werden und wie bestimmte Richtlinien verwendet werden können. Lose Kopplung Services sollen lose gekoppelt zu einem Prozess zusammengefügt werden können. Dies setzt ein Minimum an Abhängigkeiten zwischen einzelnen Services voraus. Es gilt der Grundsatz, gerade soviel Abhängigkeiten zu schaffen wie notwendig, so dass Änderungen nach Möglichkeit nur lokale Auswirkungen haben und Komponenten leicht ausgetauscht werden können. Funktionsabstraktion Um eine lose Kopplung zu ermöglichen, sollen Services nach außen von Details der konkreten Funktionalität und Implementierung abstrahieren. Lediglich die nach außen angebotenen und beschriebenen Funktionen werden gekapselt angeboten. Wiederverwendbarkeit Ein Grundgedanke ist die Wiederverwendbarkeit von Services in einem späteren Prozessschritt von anderen Teilnehmern oder sogar für weitere Verwendungszwecke. Diese Forderung muss bereits bei der Entwicklung Berücksichtigung finden. Service-Autonomie Ein Service soll in der Lage sein, autark zu funktionieren. Das bedeutet, dass die für den Service Verantwortlichen über Implementierung, Betrieb und Wartung weitgehend alleine und unabhängig entscheiden können. Es handelt sich also nicht um ein technisches Merkmal sondern um Eigenschaften der Organisation, die Services betreibt. Zustandslosigkeit des Service (Statelessness) Services folgen dem Dienstleistungsgedanken, d.h. dem Erbringen einer definierten Leistung. Diese kann auch die kontinuierliche Speicherung von Daten beinhalten, allerdings nur, wenn 14

15 explizit verlangt. Ansonsten sind Services zustandslos, d.h. sie halten keine persistenten Daten, um eine Statusverwaltung zwischen Serviceaufrufen durchzuführen. Auffindbarkeit des Service Um einen Service zu nutzen, muss dieser auffindbar sein. In der Regel erfolgt dies über Service-Repositories. Ein Repository steht allen Consumern und Providern zur Verfügung und beinhaltet Beschreibungen von Serviceschnittstellen und -implementierungen. Es speichert alle Informationen, welche ein Consumer benötigt, um einen Service aufzurufen. Orchestrierbarkeit der Service Orchestrierung wird das Vorgehen genannt, einzelne Services aus fachlichen Gesichtspunkten heraus zu größeren Einheiten, den Geschäftsprozessen, zu verbinden. Da das Ziel der SOA die Abbildung des fachlichen Geschäftsprozesses ist, ist die Orchestrierbarkeit eine weitere Forderung an die Dienste einer SOA. Services sollen in der Lage sein, einzelne Aufgaben in einem Gesamtprozess effektiv zu erfüllen. Die Unabhängigkeit von der Komplexität und den Ausmaßen des jeweiligen Prozesses stellt dabei eine der zentralen Anforderungen dar. In der einschlägigen Literatur lassen sich zudem zahlreiche weitere Forderungen und Definitionen finden. Die dargestellten Kriterien sollen an dieser Stelle ausreichen, um SOA und Services praktikabel zu definieren. 2.2 Ziele und Vorteile von SOA Primäre Ziele beim Einsatz von bzw. der Migration zu einer SOA sind die erhöhte Flexibilität von Geschäftsprozessen und die damit einhergehende Kostenersparnis. Weiterhin trägt die einfachere Einbindung bestehender Alt-Systeme (Legacy-Systeme) maßgeblich zur Kostensenkung bei. Kernaufgaben der Organisation, wie etwa die Umsetzung kundengerechter Prozesse oder die Anpassung an veränderte Marktbedingungen, können durch die strikte Trennung zwischen dynamischer Geschäftsprozesslogik und statischen Geschäftsfunktionen besser erfüllt werden. So können neue Zulieferer durch standardisierte Schnittstellen effizient eingebunden und Workflows für Mitarbeiter, Kunden und Partner schneller optimiert werden. Weiterhin ist der Vorteil der Wiederverwendbarkeit einzelner Services in diesem Kontext nicht zu vernachlässigen. Einsparungen von Systemen, Lizenzgebühren, Personal, etc. sind durch gemeinsame Nutzung oder gar Outsourcing bestimmter Funktionen möglich. Enterprise Application Integration (EAI) ist ein Konzept zur organisationsweiten Integration der Geschäftsfunktionen entlang der Wertschöpfungskette, die über verschiedene Applikationen auf unterschiedlichen Plattformen verteilt sind und die im Sinne der Datenund Geschäftsprozessintegration verbunden werden können. Auf das Wesentliche reduziert ist EAI ein rein technischer Ansatz zur Integration von Anwendungssystemen. Die Hauptaufgabe besteht in der heterogenen Integration der verschiedenen Altsysteme. Hierzu haben die verschiedenen Hersteller hauptsächlich proprietäre Produktsuiten entwickelt, deren Einsatz ein sehr hohes Spezialistenwissen erfordert. Gegenüber EAI ist SOA in hohem Maße standardisiert und bietet auch die technischen Möglichkeiten zur Abbildung eines fachlichen Geschäftsprozesses. Auch die Einbindung bestehender Systeme im Sinne von EAI lässt sich mit einem Service-orientierten Ansatz realisieren. Gerade bei der Integration von Anwendungen aus Altsystemen (sog. LegacyAnwendungen) über Services lässt sich eine Flexibilisierung von monolithischen Systemen erreichen. Auf diese Weise kann auch eine schrittweise Migration großer Legacy Systeme 15

16 erfolgen. Organisationen benötigen nicht den gefürchteten Big-Bang, sondern migrieren Schritt für Schritt. Auch die Integration zentraler Dienste spielt eine wichtige Rolle beim Einsatz von SOA. Mit der Service-Orientierung wird es möglich, Dienste wie Identity Management oder auch Public Key Infrastruktur (PKI) auf standardisierte Weise systemweit zur Verfügung zu stellen. Die Bereitstellung von Authentifizierungs- und Autorisierungsmechanismen als Service ermöglicht Anwendungen oder anderen Services den Zugriff auf Authentifizierungsdaten von Nutzern, um somit Single Sign-On-Methoden zu realisieren. Lokalisierung und Validierung von Zertifikaten kann in SOA-Umgebungen von zentralen Zertifikatsmanagement-Diensten übernommen werden. Hierbei tritt der Vorteil der Kapselung der Service-Komplexität in besonderem Maße hervor. Der Service Consumer muss ausschließlich die Service-Schnittstelle kennen, er benötigt jedoch keine Kenntnis über die Details der dahinter liegenden Implementierung. Bei konsequenter Umsetzung bringen Service-orientierte Architekturen eine Reihe von Vorteilen mit sich, von denen zusammenfassend folgende genannt seien: Flexibilität (z.b. durch einfache Austauschbarkeit von Services), Wiederverwendbarkeit von Services (höhere Produktivität) und Vermeidung monolithischer Systeme (Reduktion der Komplexität bei der Implementierung), Hohe Dynamik: schnelle Anpassung an neue Gegebenheiten und verbesserte Möglichkeiten zur Restrukturierung, da die Softwarekomponenten frei von Prozesslogik sind und diese statt dessen in der Orchestrierung der Services zu einem Geschäftsprozess enthalten ist, Kostengünstige Integration zentralisierter Dienste wie PKI oder Identity Management (z.b. für ein Single-Sign-On), Verbesserte Nachhaltigkeit der IT einer Organisation und Optimale Anpassung an die abzubildenden Geschäftsprozesse und somit leichter zugänglich für Management und Fachabteilungen. Durch die neuen Möglichkeiten und die damit verbundenen Technologien ergeben sich aber auch eine Reihe möglicher Nachteile. In erster Linie ist diesbezüglich die Konfrontation mit neuen sicherheitsspezifischen Herausforderungen, z.b. mit Blick auf die sichere organisationsübergreifende Nutzung von Identitäten oder die sichere Kommunikation zwischen Diensten zur automatisierten Durchführung von Geschäftsprozessen, zu nennen. Auch kann die Umsetzung SOA-basierter Systeme durchaus mit hohen Migrationskosten und einem weitreichenden Zeithorizont verbunden sein. Insgesamt wird SOA der Tatsache gerecht, dass Geschäftsprozesse einer Organisation und die zugehörigen IT-Landschaften immer stärker miteinander gekoppelt sind. Im Gegensatz zu früheren Ansätzen stehen bei SOA die fachlichen Aspekte und insbesondere die Geschäftsprozesse im Mittelpunkt. 2.3 Konkrete Umsetzungen Grundsätzlich ist SOA ein Architekturkonzept, welches keine konkrete technische Realisierung oder bestimmte Methoden vorschreibt. So kann eine SOA mit CORBA, Enterprise Java Beans, Web Services oder anderen Technologien umgesetzt werden. Es haben sich allerdings Web Services zur Realisierung durchgesetzt. Im Folgenden liegt daher der Fokus vorwiegend auf Web Services. Des Weiteren werden hauptsächlich Web Services 16

17 behandelt, die das Nachrichtenaustauschprotokoll SOAP sowie entsprechende Web Service Protokolle und Standards (z.b. WS-Security) nutzen. Sie werden insbesondere dann eingesetzt, wenn Geschäftsprozesse automatisiert abgewickelt werden sollen, mehrere Organisationen bzw. Teilnehmer involviert sind und ein hohes Maß an Sicherheit erforderlich ist. REST-basierte Web Services, die hingegen eher einen Ressourcen-zentrierten Ansatz verfolgen, verstärkt für Mashups (Vermaschung von verschiedenen Medieninhalten) genutzt werden und weniger Sicherheitsmöglichkeiten bieten, werden lediglich am Rande in Kapitel 7 betrachtet. Ein Web Service ist eine auf XML (extensible Markup Language) basierende Anwendung, die definierte Methoden über eine standardisierte Schnittstelle anbietet und über eine URI (Uniform Resource Identifier) eindeutig identifizierbar macht. Als Kommunikationsprotokoll dient SOAP (W3C Recommendation), mit dem Daten zwischen Systemen ausgetauscht werden können. SOAP verwendet XML zur Datenrepräsentation sowie in den meisten Fällen HTTP/TCP für den Transport. Im bildlichen Sinne stellt SOAP einen offenen Umschlag (Envelope) dar. Der Inhalt unterteilt sich in einen Nachrichtenkopf (Header) und einen Nachrichtenkörper (Body). Im Header werden Metainformationen zum Datentransport sowie Informationen zu Absender und Empfänger der SOAP Nachricht gespeichert. Im Body können als Inhaltsdaten der Nachricht Methodenaufrufe bzw. deren Antwort eingefügt werden. Abbildung 2: Aufbau einer XMLbasierten SOAP Nachricht Web Services finden immer größere Verbreitung. Insbesondere im Kontext Serviceorientierter Architekturen sind die entsprechenden Protokolle sehr attraktiv und bilden die am häufigsten verbreitete Realisierungstechnologie für SOAs. Web Services können somit als State-of-the-Art zur Umsetzung von SOA bezeichnet werden. Beispiel: Die Suchanfrage SOA Einsteiger eines Kunden über ein Web-Portal wird als Web Service an das Warenwirtschaftssystem eines Buchhändlers geschickt. In diesem Fall wird die 17

18 Methode ItemInStock mit den Parametern SOA Einsteiger des Web Service aufgerufen. Dieser exemplarische SOAP Request ist gleichzeitig ein Beispiel dafür, dass der SOAP Header optional ist. SOAP Request: <?xml version="1.0"?> <soap:envelope xmlns:soap=" <soap:body> <ItemInStock xmlns=" SOA Einsteiger </ItemInStock> </soap:body> </soap:envelope> SOAP Response: Der Web Service antwortet mit zwei gefundenen Items im SOAP Body. <?xml version="1.0"?> <soap:envelope xmlns=" <soap:header> <ReqId xmlns=" </ReqId> </soap:header> <soap:body> <ItemResponse xmlns=" <title value="soa Einsteiger"> <Item value="1">soa für Einsteiger</Item> <Item value="2"> SOA Grundlagen Serviceorientierung für Einsteiger </Item> </title> </ItemResponse> </soap:body> </soap:envelope> Populäre Beispiele für Web Services sind z.b. die von Google oder Amazon, welche über ihre Services vergleichbare Funktionalitäten wie über ihr Webportal anbieten. Neben dem (Web-) Service Request des Service-Consumers und dem (Web-) Service Response des Service-Providers seien an dieser Stelle noch weitere Elemente der Web Service-Architektur genannt. 18

19 Abbildung 3: Ablauf eines Dienstaufrufs unter Verwendung einer zentralen Registry Wie bereits erwähnt, müssen Web Services beschrieben, veröffentlicht und auffindbar gemacht werden. Dafür kann der Service Provider den Web Service bei einem Verzeichnisdienst (Service-Repository) bekannt machen und den Service selbst sowie die verfügbaren Methoden beschreiben. Der Service Consumer kann den Service anschließend über den Verzeichnisdienst finden und mit Hilfe der Beschreibung aufrufen. Als Standards haben sich dafür UDDI (Universal Description, Discovery and Integration) und WSDL (Web Services Description Language) etabliert. UDDI ist ein Standard für Verzeichnisdienste und bietet Möglichkeiten zum Einstellen, Suchen und Auffinden von Web Services. Vereinfacht entspricht die Funktionsweise von UDDI der eines Telefonbuchs. Das Suchen eines Web Services erfolgt über eine SOAP Schnittstelle. Die Antwort enthält einen Verweis auf ein Dokument im WSDL Format. WSDL ist der Standard zur Beschreibung von Web Services. Neben Funktion, Syntax und Struktur werden darin auch zur Verfügung gestellte Methoden (bspw. Verfügbarkeit prüfen aus dem Beispielszenario) beschrieben. Auf Basis dieser Informationen ist der Service Consumer in der Lage, den Service zu nutzen. Abbildung 4: Web Service-Protokollstack für die unterschiedlichen Phasen der Servicesuche bzw. -nutzung Ein weiteres Konzept, welches im Rahmen von SOA und Web Services von zentraler Bedeutung ist, ist der Enterprise Service Bus (ESB). Der Begriff des ESB beschreibt im Grunde eine Kommunikationsinfrastruktur, welche den nachrichtenbasierten Informationsaustausch der Services steuert. Der Begriff ESB ist nicht eindeutig definiert. 19

20 Oftmals bietet ein ESB ein zentrales Service Repository sowie Werkzeuge zur Datenkonvertierung. Grundsätzlich ist die Integration und Migration von bestehenden Systemen eine Herausforderung. Konzepte wie der ESB fokussieren bei der Integration vornehmlich auf Applikationen wie CMS (Content Management Systems), ERP (Enterprise Resource Planning) oder Document Mangement Systems. Zudem gilt es Anwendungen wie Identity Management Systeme, Metaverzeichnisse und PKI in der SOA-Umgebung verfügbar zu machen. Benutzerdaten, Rechte, Rollen und Zertifikate können systemweit für Services zur Verfügung stehen. Für ein Single Sign-On (SSO) an unterschiedlichen Services wird ein Mapping der Credentials benötigt, welches Daten aus bestehenden Systemen wie LDAP oder Active Directory verwendet und Legacy Systeme mit den geforderten Formaten und Anmeldeinformationen bedient. Hintergrund ist, dass eine Entität meist unterschiedliche Credentials (Username/Passwort, Token, X.509, etc.) zur Anmeldung an unterschiedlichen Systemen, Ressourcen und Services benötigt. Über ein zentrales Mapping können diese Informationen auf den vorliegenden Daten abgebildet werden. Die lokale Anmeldung und die damit verbundene Autorisierung kann mit diesem Wissen automatisch erfolgen, und SSO Mechanismen können umgesetzt werden. Eine vorhandene PKI kann durch die Nutzung eines Zertifikats-Management-Services abgebildet werden und somit Zertifikatslokalisierung und Validitätsprüfung jedem Service zur Verfügung stellen. So wird ein Zertifikatsmanagement in verteilten Umgebungen möglich, welches über standardisierte Schnittstellen einen Zertifikatsservice zur Verfügung stellt. Die Anforderung oder Prüfung eines benötigten Zertifikats erfolgt als Service-Aufruf und ermöglicht so die sichere Kommunikation (Verschlüsselung, Signatur) oder Authentifizierung (bspw. via SAML) zwischen Services und Systemen. 2.4 Beispielszenario Nachdem der Begriff SOA sowie konkrete Umsetzungen in den vorangegangenen Abschnitten dargestellt wurden, erfolgt in diesem Abschnitt eine kurze Beschreibung eines Beispielprozesses (siehe Abbildung 5). In weiteren Kapiteln des Kompendiums (siehe Kapitel 3.4 und Kapitel 7.7) dient der Beispiel-Geschäftsprozess ferner dazu, relevante Sicherheits- und Administrationsaspekte für eine Service-orientierte Architektur zu veranschaulichen. Als Beispielszenario soll der Bestellprozess bei einem Online-Händler betrachtet werden. Ein Kunde meldet sich am Web-Portal des Händlers an und lässt sich die gewünschten Artikel auflisten. Der Service Verfügbarkeit prüfen wird angesprochen und liefert die am Lager befindlichen Mengeninformationen an das Web-Portal. Des Weiteren liefert der Service Angebot erstellen unter Berücksichtigung des Kundenstatus (bspw. Rabatte, Konditionen, etc.) den kundenindividuellen Preis der Produkte. Anschließend gibt der Kunde die Bestellung der gewünschten Artikel auf. Bei Zahlung hier via Kreditkarte wird ein externer Service des Kartenproviders aufgerufen und die Bonität des Kunden anhand der Kreditkartennummer geprüft. Im Positivfall wird das Produkt, sofern es verfügbar ist und die Zahlung akzeptiert wurde, zum Versand gegeben. Der Service Versand und Rechnungserstellung übermittelt dabei alle benötigten Informationen inkl. der Liefer- und Rechnungsadresse des Kunden an das Versandsystem. 20

21 Zusätzlich lässt sich das hier beschriebene, bereits organisationsübergreifende Szenario, nochmals erweitern. So findet im Fall, dass ein bestimmtes Produkt nicht verfügbar ist und der Kunde sich für eine Bestellung entschieden hat, eine automatisierte Bestellung bei dem Produzenten statt. Der Dienst Produkt bestellen übermittelt dazu die nötigen Produktinformationen (Artikelnr., Menge, usw.) in einem standardisierten Format an den Produzenten, der daraufhin die Bestellung ausführen kann. Im unten abgebildeten Beispielszenario ist zudem ein Dienst Umsatzsteuervoranmeldung auf Seiten des Händlers vorhanden, der relevante Informationen zur Umsatzsteuer elektronisch an das Finanzamt übermittelt. B2C B2B B2B Kunde H ä n d le r P ro d u k t A n fra ge V e r f ü g b a r k e it p rü fe n Z a h lu n g sse r v ic e P r o v id e r G 2B P r o d u ze n t F in a n za m t A n ge b o t e r s t e lle n B e s t e llu n g au fge b e n B e s t e llu n g p rü fe n A d re ssd ate n p rü fe n B e s t e lla b le h n u n g e r h a lt e n B e s t e llu n g a u sfü h re n K r e d it k a r t e v a lid ie r e n B e s t e llin f o r m a t io n e r h a lt e n P r o d u kt au f Lage r? Z a h lu n g s f ä h ig k e it p rü fe n P ro d u k t b e s t e lle n V e rsan d in f o r m a t io n e r h a lt e n B e s t e llu n g a u sfü h re n V e rsan d u n d R e ch n u gss t e llu n g U m satzste u erv o r a n m e ld u n g B e s t e u e r u n gs v e rfa h re n Abbildung 5: Beispielszenario einer Service-orientierten Architektur unter Verwendung externer Dienste 21

22 3 Sicherheitsaspekte Service-orientierter Architekturen Dieses Kapitel verfolgt das Ziel, einen möglichst umfassenden Überblick über die allgemeinen Risiken und IT-Sicherheitsbedrohungen in einer SOA zu geben. In einer tabellarischen Form werden dabei den jeweiligen Gefährdungen entsprechende Gegenmaßnahmen zugeordnet. Bevor nachfolgend jedoch eine Betrachtung konkreter Bedrohungen und Sicherheitsmaßnahmen erfolgt, wird zunächst einleitend zum besseren Verständnis eine Kategorisierung von relevanten Sicherheitszielen und Gefährdungen vorgenommen. Gegliedert nach den Gefährdungskategorien sind in Abschnitt 3.2 dann die konkreten Bedrohungen und Sicherheitsmaßnahmen jeweils aufgeführt. Sie sollen ITVerantwortlichen helfen, bei der Umsetzung möglichst alle Sicherheitsaspekte zu berücksichtigen und wirksame Gegenmaßnahmen zu ergreifen. Auf eine ausführliche Beschreibung der Angriffsszenarien und Abwehrmaßnahmen wird aus Gründen der Übersichtlichkeit bewusst verzichtet. Eine detaillierte Betrachtung erfolgt innerhalb der entsprechenden nachfolgenden Kapitel des Kompendiums. 3.1 Allgemeine Sicherheitsziele Bevor im weiteren Verlauf des Kapitels die Bedrohungen und Sicherheitsmaßnahmen beschrieben werden, soll zunächst geklärt werden, welche allgemeinen Sicherheitsziele für eine Service-orientierte Architektur relevant sind. Prinzipiell gelten für Service-orientierte Architekturen die gleichen Sicherheitsziele wie für traditionelle Infrastrukturen. Allerdings sind zum Erreichen der Sicherheitsziele mitunter SOA-spezifische Voraussetzungen sowie Gefährdungen zu berücksichtigen, die besondere Sicherheitsmaßnahmen erfordern. Nachfolgend werden die Sicherheitsziele und die damit verbundenen Herausforderungen innerhalb Service-orientierter Architekturen beschrieben. Relevante Sicherheitsziele: Vertraulichkeit Defininition: Vertraulichkeit fordert eine Geheimhaltung von sensitiven Daten, um einen unberechtigten Zugriff auf Informationen zu unterbinden. Es muss gewährleistet werden, dass nur authentifizierte und autorisierte Entitäten auf geschützte Informationen zugreifen können. Diese Forderung umfasst das Lesen, Modifizieren und Löschen von Daten. Vertraulichkeit kann durch die Verwendung von Kryptografie erreicht werden. Besondere Herausforderung bei SOA: Zur Gewährleistung der Vertraulichkeit ist eine Sicherung auf Nachrichtenebene durchzuführen. So kann sichergestellt werden, dass auch in komplexen Abläufen über eine Vielzahl von Zwischensystemen (und damit verbundenen Zwischenspeicherungen) die Vertraulichkeit gegenüber Unberechtigten gewahrt bleibt. Insbesondere im Kontext komplexer Geschäftsprozesse muss es möglich sein, Teile von Nachrichten lediglich bestimmten Empfängern zugänglich zu machen. Eine Sicherung einzelner Nachrichtenelemente ist gefordert. Als Beispiel sei eine Bestellung genannt, die 22

23 neben Artikelstammdaten weitere Angaben zum Kreditrahmen des Kunden enthält. Mittels Verschlüsselung können diese vertraulichen Angaben geschützt werden, so dass nur autorisierte Teilnehmer innerhalb des Geschäftsprozesses diese einsehen können. Verfügbarkeit Defininition: Verfügbarkeit fordert, dass die benötigten Informationen und Ressourcen ohne Einschränkungen für berechtigte Entitäten (zum Zugriff/zur Nutzung) bereitgestellt werden. Um einen ordnungsgemäßen Betrieb und damit die korrekte Abwicklung von Geschäftsprozessen zu gewährleisten, muss eine Organisation garantieren, dass die Verfügbarkeit sichergestellt wird. Es ist häufig der Fall, dass die Vertraulichkeit und Integrität gewährleistet wird, aber durch einen Angriff auf die Verfügbarkeit eines Systems nicht mehr auf die benötigten Informationen zugegriffen werden kann. Besondere Herausforderung bei SOA: In Service-orientierten Architekturen werden Geschäftsprozesse oftmals bereichs- bzw. sogar organisationsübergreifend realisiert. Demzufolge ergibt sich eine gewisse Abhängigkeit hinsichtlich der Verfügbarkeit von Diensten, die nicht im eigenen Zugriffs- und Verantwortungsbereich liegen. Vor diesem Hintergrund ist insbesondere die Forderung zu erfüllen, dass auch bei Ausfall dieser Systeme andere Teile der Architektur weitestgehend unberührt bleiben. Bei der Implementierung und Nutzung von zentralen Komponenten in einer SOA ist ferner darauf zu achten, dass die Funktionsfähigkeit im Falle eines Ausfalls bspw. durch lokal gesicherte Logik und Policies sichergestellt wird. Andernfalls könnte dies schwerwiegende Auswirkungen auf die Organisation haben, die unter Umständen nicht mehr in der Lage ist, Geschäftsprozesse ordnungsgemäß durchzuführen. Neben geeigneten Sicherheitsmaßnahmen zur Bekämpfung von Angriffen, können zur Sicherstellung einer hohen Verfügbarkeit bewährte Konzepte wie zum Beispiel LoadBalancing oder Application-Server-Management umgesetzt werden. Da in der Planungsphase einer Architektur nur bedingt festgelegt werden kann, wie viele Consumer zukünftig auf einen Service zugreifen werden, sollte im Hinblick auf die Verfügbarkeit die Skalierbarkeit der Systeme berücksichtigt werden. Über die Zeit sind veränderte Nutzungsbedingungen ebenfalls zu berücksichtigen. Erweiterte Sicherheitsziele: Neben den o.g. drei grundlegenden Sicherheitszielen werden in der Literatur häufig weitere Sicherheitsziele wie die folgenden genannt: Authentifizierung Authentifizierung hat zum Ziel, eine behauptete Identität zu überprüfen/verifizieren. Bevor Personen oder Computersysteme beispielsweise Zugriff auf sensible Daten erhalten, müssen sie in der Regel einen Nachweis erbringen, dass ihre behauptete Identität authentisch ist. Ein Nachweis kann auf verschiedene Arten erfolgen: durch Wissen (z.b. geheimes Passwort), durch Besitz (z.b. individuellen geheimen Schlüssel) oder durch ein individuelles Merkmal (z.b. Fingerabdruck). In der Praxis wird auch häufig zur Erhöhung der Sicherheit eine Kombination der genannten Nachweismethoden genutzt. Während die Authentifizierung in einem herkömmlichen System relativ einfach beherrscht werden kann, ändert sich dies in einer verteilten Infrastruktur. Im Gegensatz zu einem 23

24 monolithischen System, in dem die Authentizität meist über ein zentrales Login an einem definierten Punkt sichergestellt wird, ist man in einer SOA mit einer Vielzahl von Authentifizierungen verschiedener Services konfrontiert. Ein kritischer Geschäftsprozess erfordert die Authentizität sämtlicher Service-Aufrufe, bspw. innerhalb einer Supply-Chain. Bei einer losen Kopplung sind zudem Fälle denkbar, in denen sich Service Consumer gegenüber bislang unbekannten Service-Providern authentifizieren müssen. Authentifizierungslösungen müssen in der Lage sein, benötigte Federation-Konzepte technisch abzubilden und zudem eine Interoperabilität von Authentifizierungsangaben und formaten zu gewährleisten. Dies betrifft nicht nur die Inter-Service Kommunikation, sondern auch die Anbindung von Legacy-Systemen. Findet eine Migration schrittweise statt, werden Services als Middleware für den Zugriff auf Altsysteme eingesetzt. Dies bedeutet auch, dass solchen Services ein Zugriff auf die Altsysteme mit Hilfe von entsprechenden Credentials (in den benötigten Formaten) gestattet sein muss. Autorisierung Die Autorisierung stellt sicher, dass eine Entität befugt ist, auf die angeforderten Informationen oder Ressourcen zuzugreifen. Typischerweise wird die Autorisierung durch die Verwendung von Rollen und Gruppen umgesetzt. Bei jedem Zugriff auf geschützte Informationen oder Ressourcen sollte überprüft werden, ob die Berechtigungen diesen Zugriff erlauben. Wie bereits bei der Authentifizierung dargestellt, vervielfachen sich in Service-orientierten Strukturen die sog. Policy Enforcement Points, an denen die Mechanismen zur Einhaltung der Berechtigungen umgesetzt werden. Nicht ein einzelnes Rechtesystem muss entsprechend konfiguriert werden, sondern es müssen Regeln und Rollen für sämtliche Services definiert und durchgesetzt werden. Entsprechend leistungsfähig muss die Administrationskomponente sein, die in der Lage sein muss, ein zentrales Management von Rechten und Rollen zur Verfügung zu stellen, das jederzeit beherrschbar ist. Will man eine Autorisierungsprüfung auf Web Service-Ebene nutzen, so muss hier sichergestellt werden, dass die Nachrichten für Web Services von dem Sicherheitssystem lesbar und verarbeitbar sind. Hierdurch entstehen neue Anforderungen an die Definition der Benutzerrechte (Verwendung von bestimmten standardisierten XML-basierten Sprachen). Zudem sind in Abhängigkeit der individuell vorhandenen Architektur und Organisation entsprechende Administrationskonzepte technisch umzusetzen. Verbindlichkeit Verbindlichkeit fordert, dass Aktionen, die von einer bestimmten Entität ausgeführt werden, im Nachhinein nicht abgestritten werden können. Zudem sollte gewährleistet werden, dass die Entitäten eine Bestätigung für die jeweils ausgeführten Aktionen erhalten. Bei einem SOA-Szenario ist die Verbindlichkeit eine wichtige Forderung, die erfüllt werden muss, wenn geschäftskritische Prozesse abgewickelt werden. Gerade wenn verschiedene Teilnehmer involviert sind, ist die Verbindlichkeit von getätigten Aktionen (Bestellungen, Aufträge, etc.) eine wesentliche Bedingung zur elektronischen Abwicklung von Transaktionen. In diesem Zusammenhang muss auch eine Vielzahl rechtlicher Aspekte berücksichtigt werden. 24

25 3.2 Kategorien von Sicherheitsgefährdungen Innerhalb des BSI-Grundschutzes wurden fünf allgemeine Gefährdungskategorien definiert, denen jeweils konkrete Gefährdungen zugeordnet sind. Sie beschreiben nicht nur ITspezifische Gefährdungen, sondern betrachten gesamtheitlich mögliche Sicherheitsrisiken für Organisationen. Nachfolgend werden zunächst die allgemeinen Gefährdungskategorien zusammen mit ihren besonderen Auswirkungen auf eine Service-orientierte Architektur beschrieben. Innerhalb des Abschnitts 3.3 erfolgt dann eine gezielte Betrachtung konkreter Bedrohungen der jeweiligen Kategorien. Während sich die Bedrohungen der Kategorie Höhere Gewalt innerhalb Service-orientierter Architekturen im Vergleich zu traditionellen Architekturen kaum anders auswirken, können insbesondere vorsätzliche Handlungen eine erhöhte Gefahr für Service-basierte Architekturen bedeuten. Neben SOA-spezifischen Angriffen, können altbekannte Angriffsszenarien weitreichende, zu realisierende Sicherheitsmaßnahmen erforderlich machen. Gefährdungskategorien: Vorsätzliche Handlungen Definition: Im Folgenden werden unter vorsätzlichen Handlungen allgemein die Vorgänge zur bewussten Verletzung der Vertraulichkeit, Integrität und Verfügbarkeit von Objekten/Ressourcen (in der Regel elektronischer Daten) verstanden. Neben allgemeinen Angriffsmethoden werden insbesondere die SOA-spezifischen Attacken betrachtet. Besondere Auswirkung innerhalb einer SOA: In einer Service-orientierten Architektur, in der verteilt Dienste und Ressourcen genutzt werden, müssen neue und weitreichende Sicherheitsmaßnahmen zum Schutz vor Angriffen ergriffen werden. Eine 1:1 Übertragung der Sicherheitsmaßnahmen aus traditionellen Architekturen ist nicht möglich. Während in traditionellen Architekturen häufig zum Schutz des internen Netzwerks und der Prozesse eine Firewall genügte, ist dies aufgrund der organisationsübergreifenden Geschäftsprozesse nicht mehr ausreichend. Dienste müssen von anderen Organisationen von außen nutzbar sein, d.h. eine Kommunikation muss ins interne Netzwerk zugelassen und durch weitere, neue Maßnahmen abgesichert werden. Es müssen geeignete Authentifizierungs-, Autorisierungs- und Verschlüsselungsmechanismen sowie Technologien zum Einsatz kommen, die auf die neuen Anforderungen ausgerichtet sind. Insbesondere die nachrichtenbasierte Kommunikation zwischen den Web Services und den beteiligten Systemen wie z.b. Registries/Repositories erfordert neue Schutzmaßnahmen. Viele Angriffe auf Service-orientierte Architekturen zielen auf die Standards und Protokolle ab, die zur nachrichtenbasierten Kommunikation zwischen den Web Services genutzt werden. Im Abschnitt 3.3 werden daher im Fokus einige Angriffe beschrieben, die in Zusammenhang mit XML und SOAP stehen. Organisatorische Mängel Definition: Unter organisatorischen Mängeln werden fehlende oder unzureichende Abläufe sowie Regelungen in einer Organisation aufgefasst. 25

26 Besondere Auswirkung innerhalb einer SOA: Organisation ist ein sehr wichtiger Aspekt in einer Service-orientierten Architektur. Aufgrund der mitunter komplexen Prozesse und der Abwicklung über verteilte Dienste ist es von großer Bedeutung, klare Organisationsstrukturen und Verantwortlichkeiten innerhalb einer Organisation zu haben. Die Themen Governance und Compliance spielen insbesondere im Bereich der Service-orientierten Architekturen eine große Rolle. Unter Umständen können viele unterschiedliche Dienste in der Organisation existieren, die jedoch jederzeit beherrschbar sein müssen. Es darf nicht die Übersichtlichkeit verloren gehen und es muss jederzeit der Zustand der einzelnen Komponenten im Gesamtsystem nachvollziehbar sein. Des Weiteren ist zu gewährleisten, dass Organisationsrichtlinien oder rechtliche Regelungen korrekt durch die jeweils verantwortlichen Personen umgesetzt werden. Vor diesem Hintergrund ist es wichtig, klare Verantwortlichkeiten zu definieren und Zugriffsrechte technisch umzusetzen. Zum Beispiel sollten nur bestimmte Personen Sicherheitspolicies verändern können, da eine bewusste oder unbewusste Änderung weitreichende Konsequenzen auf die Sicherheit und damit die Geschäftsprozesse einer Organisation haben könnte. Die Regelung von rechtlichen Aspekten ist besonders wichtig, wenn in Kooperation mit anderen Organisationen Geschäftsprozesse durchgeführt werden. Menschliche Fehlhandlungen Definition: Zu menschlichen Fehlhandlungen werden sowohl bewusste als auch unbewusste Handlungen von Personen gezählt, die sich negativ auf die Sicherheit einer Organisation auswirken. Besondere Auswirkung innerhalb einer SOA: Menschliche Fehlhandlungen können unter bestimmten Umständen innerhalb einer Serviceorientierten Architektur einen größeren Schaden als in traditionellen Architekturen verursachen. In Service-orientierten Architekturen ist die Wiederverwendbarkeit von Diensten ein wesentliches Ziel. Wird durch bewusstes oder unbewusstes Handeln einer Person die Funktionsweise eines wichtigen Dienstes, der z.b. für mehrere Geschäftsprozesse genutzt wird, beeinträchtigt, kann dies zu einem großen Schaden für die Organisation führen. Zur Umsetzung von geeigneten Sicherheitsmaßnahmen ist es wichtig, dass das verantwortliche IT-Personal über das nötige Know-How auf dem Gebiet SOA-Security verfügt. Vor dem Hintergrund der vielen verschiedenen Standards und Sicherheitstechnologien stellt dies jedoch eine echte Herausforderung dar. Technisches Versagen Definition: In dieser Kategorie werden allgemeine Hard- und Softwarefehler sowie Fehler in Protokollen betrachtet. Besondere Auswirkung innerhalb einer SOA: Fallen in einer Service-orientierten Architektur einzelne Dienste oder Systemkomponenten aus oder werden aufgrund von Sicherheitslücken kompromittiert, kann sich dies ggf. negativ auf verschiedene Geschäftsprozesse auswirken. Da innerhalb eines Geschäftsprozesses in der Regel mehrere Dienste und Zwischensysteme beteiligt sind, ist die Gefahr eines Ausfalls innerhalb einer SOA besonders groß. Des Weiteren werden in einer SOA oftmals viele 26

27 verschiedene Systeme integriert, wodurch die Zahl an potentiellen Sicherheitslücken in der Software und den verwendeten Protokollen steigt. Insbesondere bei der Integration von Legacy-Anwendungen, bei denen ggf. keine Updates mehr gepflegt werden, ist die Gefahr eines Angriffs auf vorhandene Sicherheitslücken relativ groß. Höhere Gewalt Definition: Als höhere Gewalt werden alle negativen Zustände und Aktivitäten bezeichnet, die nicht beeinflussbar sind und unerwartet eintreten können (z.b. Naturkatastrophen). Besondere Auswirkung innerhalb einer SOA: Allgemein haben Bedrohungen der Kategorie höhere Gewalt ähnliche Auswirkungen auf eine SOA wie auf eine traditionelle Architektur. Unabhängig von der realisierten Architektur sollte ein Notfallvorsorgekonzept existieren, das geeignete Maßnahmen für solche Fälle definiert und dabei die besonderen Gegebenheiten einer Service-orientierten Architektur berücksichtigt. Da innerhalb einer SOA Geschäftsprozesse oftmals unternehmens- bzw. behördenübergreifend durchgeführt werden, sind im Vorfeld die notwendigen rechtlichen Regelungen zwischen den beteiligten Organisationen zu treffen, die den Ausfall von Diensten (d.h. die Nichterfüllbarkeit von Leistungen) behandeln. 3.3 Konkrete Gefährdungen und geeignete Sicherheitsmaßnahmen in einer SOA In den vorherigen Abschnitten wurde allgemein auf die besonderen Auswirkungen von Gefährdungen in SOA hingewiesen. Nachfolgend werden konkrete Gefährdungen erläutert und entsprechende Sicherheitsmaßnahmen gegenübergestellt. Dabei werden nicht nur SOAspezifische Bedrohungen betrachtet. Oftmals handelt es sich bei den nachfolgenden Ausführungen um allgemeine Bedrohungen bzw. Angriffe, die jedoch in besonderem Maße sicherheitsrelevante Vorkehrungen bzw. Reaktionen in einer Service-orientierten Architektur erfordern. Im Fokus der Betrachtungen steht verstärkt die Kategorie vorsätzliche Handlungen, in der zahlreiche SOA-spezifische Angriffe erläutert werden. Bei den anderen vier Gefahrenkategorien werden lediglich besonders sicherheitsrelevante Aspekte für Serviceorientierte Architekturen hervorgehoben und beschrieben. Weitere konkrete Bedrohungen, die generell für IT-Architekturen gelten, sind in den IT-Grundschutzkatalogen [IT-GSK] aufgeführt und werden an dieser Stelle daher nicht weiter betrachtet Vorsätzliche Handlungen/Angriffe Unterschiedliche Angriffe verfolgen häufig das gleiche Ziel und erfordern ähnliche Gegenmaßnahmen. Wenn möglich wurden daher zwecks Übersichtlichkeit in der nachfolgenden tabellarischen Darstellung Angriffe/Bedrohungen eines Typs gruppiert. 27

28 Web Service Interface Probing Bedrohung/Gefahr innerhalb einer SOA: WSDL-Dokumente stellen in einer Web Service basierten Architektur wichtige Informationen über Schnittstellen bereit, so dass bestimmte Dienste leicht genutzt bzw. integriert werden können. Die WSDL-Dokumente können jedoch auch Angreifern dazu verhelfen, verschiedenste Schwachstellen herauszufinden. Nachfolgend werden zwei typische Methoden vorgestellt, wie Angreifer Informationen beschaffen können, die ggf. eine unberechtigte Nutzung eines Dienstes erlauben oder weitere Aktionen eröffnen: WSDL-Scanning/WSDL Enumeration WSDL-Dateien werden meist automatisiert von Tools/Frameworks erstellt, die in der Regel neben den notwendigen Angaben noch weitere, teils sicherheitskritische Informationen integrieren. Eine Analyse der WSDL-Datei ist daher oftmals das erste Ziel eines Angriffes. Das Scannen eines WSDL-Interfaces kann z.b. Parametertypen liefern, die das Erstellen einer korrekten Anfrage an unnötigerweise offene Funktionen des jeweiligen Dienstes ermöglichen. Bei schlechter Programmierung auf Provider-Seite kann dann möglicherweise ein direkter und unberechtigter Zugriff auf schützenswerte Daten des Dienstes erfolgen. Häufig nutzen Angreifer Informationen über Methodennamen in der WSDL Datei auch, um weitere, nicht veröffentlichte Methodennamen zu erraten (Beispiel: Angreifer schließt von veröffentlichter Methode requeststockquote auf unveröffentlichte Methode requeststocktrade ). WSDL Parameter Tampering/Error Interface Probing Besitzt ein Angreifer die nötigen Informationen, um SOAP Nachrichten zu erstellen, so kann er die Übermittlung von verschiedenen Parametern innerhalb der Nachrichten testen. Fehlermeldungen, die der Angreifer von einer XML-verarbeitenden Komponente des Service-Providers zurück erhält, können viele sensible Informationen enthalten (z.b. Angaben über verwendetes Framework, Libraries, interne Systemstruktur, etc.). Darüber hinaus kann der Angreifer ggf. über Fehlercodes feststellen, ob Eingaben geprüft oder bestimmte Aktionen ungefiltert durchgeführt werden. Findet keine Filterung statt, können so genannte Injection Attacks durchgeführt werden, die eine erhebliche Bedrohung für die Backend-Anwendungen darstellen (s. Malicious Morphing/Message Tampering). Geeignete Gegenmaßnahme: Bei der Generierung von WSDL-Dateien ist darauf zu achten, dass durch verwendete Tools/Frameworks keine zusätzlichen Informationen in die Dateien integriert werden, die womöglich sicherheitskritisch sind. D.h. hier sollte zunächst eine entsprechende Prüfung und bei Bedarf die nötige Konfiguration durchgeführt werden, bevor WSDL-Dateien veröffentlicht werden. SOAP Nachrichten sollten generell keine Fehlermeldungen mit detaillierten Informationen an Nutzer (potentielle Angreifer) weitergeben. D.h. die Meldungen sollten so allgemein/generisch gestaltet sein, dass sie keine Informationen über eingesetzte Anwendungen, Frameworks und Versionsnummern enthalten bzw. einen Rückschluss auf diese zulassen. Sollen Dienste nur von bestimmten, dem Service Provider bekannten Nutzern gesucht und aufgerufen werden können, bietet es sich an, die WSDL-Dateien (bzw. deren Repositories) 28

29 mittels einer vorherigen Nutzerauthentifizierung vor direktem und unberechtigtem Zugriff zu schützen. Angriffe auf das XML Parsing System Bedrohung/Gefahr innerhalb einer SOA: Da in Web Service basierten Architekturen in der Regel Nachrichten in XML übermittelt werden, haben es Angreifer häufig auf die Schwächen von XML-Parsern abgesehen. Ein XML-Parser wird benötigt, um nach Erhalt einer SOAP Nachricht die relevanten Informationen wie Methodennamen und Parameter zu extrahieren. Da für diesen Verarbeitungsschritt entsprechende Ressourcen (Zeit, Rechenleistung, etc.) bereitgestellt werden müssen, ist das Parsen von Nachrichten ein beliebtes Angriffsziel. Durch Übermittlung von speziell präparierten XML-Nachrichten versuchen Angreifer das Parsen zu erschweren und möglichst viele Ressourcen zu beanspruchen. Zur Folge hat dies eine Verlangsamung der Funktionsweise oder schlimmstenfalls einen kompletten Ausfall des Dienstes (Denial of Service). Die vom Angreifer übermittelten XML-Nachrichten können dabei auf verschiedene Weise präpariert und für einen Parser problematisch sein. Zum Beispiel können rekursive Strukturen integriert sein, die viele verschachtelte Elemente aufweisen. Es können jedoch auch extrem große XML-Dokumente übertragen werden, die zu einem hohen Ressourcenverbrauch führen und damit eine potentielle Gefahr für einen Denial of Service oder Buffer Overflow darstellen. Folgende Begriffe bzw. Angriffe werden häufig im Zusammenhang mit XMLParsing Attacken beschrieben: XML Entity Expansion und Recursion Attacks, XML Document Size Attack, XML Document Width Attack, XML Document Depth Attack, XML Wellformedness-based Parser Attacks, Jumbo Payloads, Recursive Elements, MetaTags Jumbo Tag Names, Coercive Parsing, XML Bombs. Geeignete Gegenmaßnahme: Generell sollten vor der Verarbeitung der eigentlichen Nachricht Validierungen (gegen XML Schema sowie XPath Validierungen) durchgeführt werden, um Parameterinhalte zu prüfen und sicherzustellen, dass die Parameter korrekt und für den gewünschten Zweck eingesetzt werden. Gegen die Übermittlung von zu großen Nachrichteninhalten kann eine Überprüfung der Inhaltsgröße durchgeführt werden. Treten generell Probleme bei zu großen Dateien auf, so ist es sinnvoll, eine maximale akzeptierte Größe für Dateien festzulegen (eine Filterung kann z.b. auf dem Gateway erfolgen). External Reference Attacks Bedrohung/Gefahr innerhalb einer SOA: nnerhalb von XML-Dateien ist es möglich, auf externe Daten zu referenzieren. Unter bestimmten Umständen kann dies jedoch eine ernsthafte Bedrohung darstellen. Nachfolgend wird an zwei bekannten Angriffen beschrieben, wie eine Referenzierung auf externe Daten ausgenutzt werden kann. Schadhafte XML Schemata/Schema Poisoning Mittels XML Schemata kann überprüft werden, ob bestimmte XML Daten konform zu diesem XML Schema vorliegen (d.h. Daten wie gewünscht übermittelt werden). Gelingt es 29

30 einem Angreifer externe XML Schemata zu kompromittieren bzw. zu manipulieren, die zur Validierung von Nachrichten eingebunden werden, bedeutet dies eine große Gefahr für die IT-Infrastruktur. Angreifer können dann in übermittelten Nachrichten z.b. Parameter manipulieren (Parameter Tampering) oder schadhaften Code einbetten. Die Nachricht wird jedoch aufgrund des manipulierten XML-Schemata als valide angesehen und akzeptiert. XML External Entity Attacks (XXE) XML Dokumente werden meist automatisch während des Verarbeitungsvorgangs erstellt (z.b. innerhalb einer Weiterleitung). Dabei können in das Hauptdokument durch entsprechende Referenzierung bestimmte Daten aus externen Quellen geladen werden. Erlangt ein Angreifer Zugriff auf die externen Daten und kann diese ersetzen/manipulieren, kann er schadhafte Inhalte einschleusen. Für das Einschleusen ist es nicht erforderlich, dass der Angreifer den Dienst aufrufen und Nachrichten übermitteln kann. Seine manipulierten Daten werden automatisch während der Verarbeitung eingebettet, wenn berechtigte Nutzer den Dienst aufrufen. Geeignete Gegenmaßnahme: Allgemein sollten nur (XML-)Dateien von sicheren und vertrauenswürdigen Stellen geladen werden. XML-Schemata könnten z.b. lediglich einmal geladen und anschließend lokal auf dem Gateway/System gespeichert werden. Nach Möglichkeit sollte das Nachladen von referenzierten externen Entitäten allgemein blockiert werden, um das potentielle Einfügen von schadhaften Inhalten zu unterbinden. SOAP Flooding Attack Bedrohung/Gefahr innerhalb einer SOA: Bei diesem Angriff werden wiederholt in einer hohen Frequenz SOAP Nachrichten (Requests) an den jeweiligen Web Service gesendet. Dieser stößt aufgrund der großen Anzahl an Requests an seine Kapazitätsgrenzen, so dass eine Verarbeitung nicht mehr möglich ist. Ziel eines solchen Angriffs ist somit ein Denial of Service, der mitunter zu verschiedensten sicherheitskritischen Systemzuständen führen kann. Geeignete Gegenmaßnahme: SOAP Flooding Attacken sind mit den herkömmlichen Netzwerk-Flooding Attacken wie z.b. SYN-Flooding zu vergleichen. Aus diesem Grund können auch ähnliche Gegenmaßnahmen ergriffen werden. Durch Einsatz eines Intrusion Detection Systems (z.b. Anwendung von Heuristiken) können wiederholt gesendete Nachrichten erkannt und direkt blockiert werden. Message Eavesdropping Bedrohung/Gefahr innerhalb einer SOA: Message Eavesdropping bezeichnet das unberechtigte Mitlesen/Mitschneiden von Nachrichten. Konkret werden durch einen Angreifer SOAP Nachrichten abgefangen und analysiert. Diese Nachrichten können bei unzureichenden Sicherheitsmechanismen unter Umständen Zugriff auf sensible Daten erlauben. Aber auch bei angewendeten Sicherheitsmaßnahmen können abgefangene Nachrichten für den Angreifer wertvolle Informationen preisgeben. Ein Angreifer kann z.b. mittels eines Fingerprinting Systems das verwendete Framework zur Generierung der SOAP Nachrichten herausfinden und im 30

31 Anschluss ggf. bekannte Schwachstellen dieses Frameworks ausnutzen. Des Weiteren ist es denkbar, dass Informationen zum Trust Management gewonnen werden, die dem Angreifer dazu dienen, Authentifizierungsmechanismen zu umgehen. Geeignete Gegenmaßnahme: Bei der Übertragung von sensiblen Daten sollten immer Verschlüsselungsmethoden eingesetzt werden, die nach Bedarf entweder die gesamte Nachricht oder nur bestimmte Elemente verschlüsseln. Zudem sollten generierte Nachrichten nur so viele MetaInformationen wie nötig enthalten, so dass einem potentiellen Angreifer keine Anhaltspunkte für mögliche Attacken gegeben werden. Malicious Morphing/Message Tampering Bedrohung/Gefahr innerhalb einer SOA: Malicious Morphing ist eine bestimmte Form einer Man-in-the-Middle Attacke. Der Angreifer modifiziert dabei den Inhalt oder die Struktur einer Nachricht und kann auf diese Weise bei dem Service Provider die Integrität von Daten als auch die Funktionsweise von Systemkomponenten gefährden (z.b. durch einen Denial-of-Service). Message Tampering beschreibt hingegen allgemein das Manipulieren von Nachrichten. Geeignete Gegenmaßnahme: Die Strukturen sollten gegen ein Schema validiert werden, um die Nachrichten zu erkennen und abzuweisen, die nicht dem gewünschten Format entsprechen. Zudem können XML-Signaturen eingesetzt werden, so dass Nachrichten, die auf der Kommunikationsstrecke manipuliert wurden, erkannt werden. Routing Detours Bedrohung/Gefahr innerhalb einer SOA: Die WS-Routing Spezifikation bietet eine Möglichkeit, SOAP Requests über mehrere Zwischenstationen in einer komplexen Umgebung zu leiten. Umgesetzt wird dies durch integrierte Routing-Informationen im SOAP Nachrichtenkopf (Header). Ist es einem Angreifer gelungen, eine Zwischenstation zu kompromittieren, kann er die RoutingInformationen manipulieren und somit vertrauliche Daten umleiten. Durch die Möglichkeit der Umleitung von Nachrichten dienen Routing Detours Angriffe oftmals als Basis für Man-in-the-Middle Attacken. Geeignete Gegenmaßnahme: Generell sollten XML Signaturen und Verschlüsselungsmechanismen eingesetzt werden, um die Integrität der Routing-spezifischen Felder sowie die Vertraulichkeit und Integrität des eigentlichen Inhalts einer Nachricht zu schützen. Hat ein Angreifer jedoch eine Zwischenstation kompromittiert und besitzt Zugriff auf das nötige Schlüsselmaterial zur Signatur und Verschlüsselung, könnte er ggf. unbemerkt Inhalte fälschen (falls keine spätere Validierung der Nachrichtenstruktur und -inhalte stattfindet). Aus diesem Grund sind die Zwischenstationen in besonderem Maße zu schützen (bspw. durch vorgelagerte SicherheitsAppliances). 31

32 Identity Spoofing Bedrohung/Gefahr innerhalb einer SOA: Replay Attack Bei einer Replay-Attacke werden Nachrichten, die von einem Web Service akzeptiert werden, nochmals verwendet. Ein Angreifer fängt dazu in der Regel valide Nachrichten von Nutzern ab und sendet sie erneut an den Web Service. Dabei spielt es keine Rolle, ob die Nachrichten verschlüsselt sind. Replay Angriffe werden meist als Basis für weitere Angriffe wie z.b. Denial of Service oder Man-in-the-Middle Attacks benutzt. Häufig dienen sie Angreifern dazu, Authentifizierungsmechanismen zu umgehen, indem abgefangene, akzeptierte Nachrichten mit Authentifizierungsinformationen erneut an den Dienst versendet werden. Session Hijacking Ziel des Session Hijackings ist das Erhalten von Nutzerprivilegien für ein System, einen Dienst oder eine Anwendung. Manche Web Services benutzen Sessions und verwenden dafür eine eindeutige Identifikationsnummer. Gelingt es einem Angreifer, Nachrichten mit einer Session-ID abzufangen, kann dieser die entsprechende ID nutzen, um an der entsprechenden Transaktion teilzunehmen. Geeignete Gegenmaßnahme: Um einen Denial-of-Service mittels Replay-Attacken zu verhindern, können vorgelagerte Appliances und Intrusion Detection Systeme eingesetzt werden, welche die Rate der übersendeten Nachrichten an einen Dienst bzw. von einer bestimmten Adresse beschränken. Nachrichten, die von Angreifern bzw. einer (Bot-)Anwendung stammen, werden somit abgelehnt. Session Hijacking kann verhindert werden, indem starke Authentifizierungsmechanismen/protokolle eingesetzt werden. Allgemein sollten nach Möglichkeit immer Authentifizierungsdaten verschlüsselt übertragen werden, so dass ein Angreifer nicht einfach einen Sicherheitstoken extrahieren und selbst verwenden kann. Bei einer Verschlüsselung wären jedoch Replay-Attacken potenziell möglich. Der Angreifer muss den Inhalt einer Nachricht nicht zwangsweise kennen, sondern könnte eine abgefangene Nachricht mit den enthaltenen Authentifizierungsdaten lediglich erneut an den Dienst übermitteln. Um die Authentifizierung mittels Replay-Angriffen zu verhindern, können z.b. integrierte Zeitstempel validiert sowie Hash- und Nonce-Werte überprüft werden. XML Signature Element Wrapping Attack Bedrohung/Gefahr innerhalb einer SOA: XML-Signaturen werden dazu eingesetzt, um die Integrität von Nachrichten zu schützen (bzw. überprüfbar zu machen). Über Identifier werden Signaturen in XML-Dokumenten referenziert, die sich an verschiedenen Stellen im Dokument befinden können. Bei einer Wrapping Attacke versucht der Angreifer durch Verschieben und Hinzufügen von Elementen eine Nachricht zu fälschen und den Integritätsschutz durch Signaturen zu umgehen. Zum Beispiel kann ein Angreifer einen neuen Nachrichtenrumpf (Body) in die Nachricht einfügen und den bereits vorhandenen Nachrichten-Body verschieben. Die Signatur bleibt aufgrund der entsprechenden Referenz weiterhin gültig. Dies führt dazu, dass bestimmte SOASoftwarekomponenten später die Signatur zwar überprüfen (und als gültig ansehen), jedoch den manipulierten Body weiterverarbeiten. 32

33 Geeignete Gegenmaßnahme: Nach Möglichkeit sollte eine Signatur auf die komplette Nachricht angewendet werden, so dass ein solcher Angriff von vornherein nicht durchführbar ist. Können jedoch z.b. aufgrund von erheblichen Performance-Vorteilen bei großen Nachrichten nur bestimmte Elemente signiert werden, ist es von großer Relevanz, neben dem referenzierten Namen die korrekte Position von signierten Inhalten mittels einer kontextabhängigen Semantik zu überprüfen. D.h. es wird der absolute Pfad des signierten Elements geprüft. Weicht dieser von den Erwartungen ab, muss die Nachricht abgelehnt werden. Code Injection Attacks Bedrohung/Gefahr innerhalb einer SOA: In der Kategorie Code Injection Attacks sind verschiedene Angriffe zusammengefasst, die das gemeinsame Ziel haben, durch Einbettung von schadhaftem Code, bestimmte Aktionen durch den Web Service zu initiieren bzw. Kommandos auszuführen. SQL Injection Ein Angreifer kann z.b. über ein Formular auf einer Webseite SQL Befehle übermitteln, die dann in eine SOAP Nachricht eingebettet werden. Leitet der Web Service ohne vorherige Prüfung der übermittelten Daten die SQL Befehle an eine Datenbankanwendung weiter, so kann dies unter Umständen zu einem unberechtigtem Zugriff auf die Datenbank und Manipulationen von Datenbankeinträgen führen. XPath Injection XPath Injection funktioniert ähnlich wie SQL Injection. In einer vergleichbaren Form werden mit XPath Anfragen an ein XML-Dokument formuliert. Gelingt es dem Angreifer XPath Ausdrücke durch Eingaben (z.b. über ein Webformular) zu übermitteln, die von dem Web Service ungefiltert für Abfragen an XML-Dateien genutzt werden, so entsteht ein Sicherheitsrisiko. Unter Umständen erhält der Angreifer beispielsweise Einsicht in vertrauliche Daten. LDAP Injection LDAP Injection funktioniert nach dem gleichen Prinzip wie SQL Injection und XPath Injection. Ein Angreifer versucht durch Eingabe von LDAP Ausdrücken eine korrekte LDAP Anfrage zu generieren, die ungefiltert ausgeführt wird und somit vertrauliche Informationen eines LDAP Repositories preisgibt. Cross-Site-Scripting Bei einer Cross-Site-Scripting Attacke übermittelt der Angreifer Script-Code (wiederum z.b. über eine Webseite), der in XML eingebettet wird. Wird der Script-Code ungefiltert an eine Webanwendung weitergeleitet, können sich Sicherheitsrisiken auf Seiten der Nutzer dieser Webanwendung ergeben. Dies ist dann der Fall, wenn die Webanwendung den schadhaften Script-Code übernimmt und z.b. über eine Webseite an den Nutzer ausliefert. Der ScriptCode wird in der Clientsoftware (üblicherweise Browser) des Nutzers ausgeführt und kann verschiedene Aktionen durchführen, z.b. kann eine Session-ID an den Angreifer übermittelt werden, so dass dieser sich unrechtmäßig bei der Webanwendung authentifizieren kann. Geeignete Gegenmaßnahme: Allgemein sollten nie Eingaben ohne vorherige Prüfung weitergeben werden. Um Injection Attacks zu vermeiden, ist es daher notwendig, Eingabeparameter auf schadhaften Code zu 33

34 filtern. Empfohlen wird zudem, Strings als Eingabetyp nach Möglichkeit komplett zu vermeiden und zudem Integer-Werte auf deren Länge zu überprüfen. Malicious Software/Viren/Trojanische Pferde (Content Injection) Bedrohung/Gefahr innerhalb einer SOA: Über SOAP Nachrichten können Viren, Trojanische Pferde oder weitere Schadsoftware übertragen werden. Der schadhafte Code kann zum einen eingebettet als Parameter (s. Code Injection Attacks) in den Nachrichten enthalten sein und zum anderen als Binary SOAP Attachment übermittelt werden. Wird die Schadsoftware auf Systemen des Service-Providers ausgeführt, kann sie die entsprechenden Systeme infizieren oder Hintertüren einrichten. Geeignete Gegenmaßnahme: Nachrichten sollten auf schadhafte Inhalte gescannt werden. Viele Hersteller bieten bspw. Gateways an, die bereits eine Scanning Engine integriert haben und somit Schadsoftware wie Viren erkennen können. Ausnutzen von Schwachstellen in Backend Anwendungen Bedrohung/Gefahr innerhalb einer SOA: Allgemein kann SOAP verwendet werden, um entfernte Prozeduraufrufe an Backend Anwendungen zu übermitteln, so dass deren Funktionalität genutzt werden kann. Durch die Öffnung der Systeme für die entfernte Nutzung können jedoch auch erhebliche Sicherheitsrisiken entstehen. Insbesondere Legacy-Systeme enthalten oftmals schwerwiegende Sicherheitslücken (z.b. Anfälligkeit für Buffer Overflows), die somit leicht ausgenutzt werden können. Geeignete Gegenmaßnahme: Durch vorgeschaltete Authentifizierungs- und Autorisierungsmechansimen sollten zunächst die Angriffschancen auf die Backend Anwendungen eingeschränkt werden. Dennoch ist weiterhin zu gewährleisten, dass Nutzer, die authentifiziert und autorisiert sind, keine möglichen Angriffe auf diese Systeme durchführen können. Die Backend Anwendungen sind (sofern noch verfügbar) durch regelmäßige Updates abzusichern. Zudem können XMLNachrichten gefiltert werden, um Übermittlung von schadhaftem Code bzw. die Ausführung von kritischen Kommandos zu unterbinden. Brute-Force/Dictionary Attack Bedrohung/Gefahr innerhalb einer SOA: Durch Brute-Force (systematisches Ausprobieren sämtlicher Buchstaben- und Zahlenkombinationen) oder mittels eines Wörterbuchs (Dictionary Attack) versucht der Angreifer Login-Daten bzw. Authentifizierungsdaten zu erraten. Zum Beispiel errät ein Angreifer Login-Daten für einen Identity Service Provider, wodurch er ein Single Sign-On Token erhält, das z.b. die Anmeldung an einem Banking Service ermöglicht. 34

35 Geeignete Gegenmaßnahme: Nach Möglichkeit sollten stärkere Authentifizierungsverfahren als Benutzername/PasswortKombinationen verwendetet werden, beispielsweise Smartcards bzw. Public-KeyInfrastrukturen. Ist dies nicht realisierbar, sollten die Login-Daten zumindest gewisse Richtlinien befolgen. Beispielsweise kann festgelegt werden, dass ein Passwort mindestens 8 Zeichen lang sein muss, aus Groß- und Kleinbuchstaben bestehen, sowie Ziffern und Sonderzeichen enthalten muss. Zudem könnte ein Intrusion Detection System genutzt werden, das die zahlreichen Login-Versuche protokolliert und weitere Anfragen von der jeweiligen Absenderadresse sperrt. Identity Service Spoofing Bedrohung/Gefahr innerhalb einer SOA: Neben dem Fälschen einer Identität von Nutzern besteht die Gefahr, dass ein Angreifer die Identität eines Service-Providers fälscht. Nutzer gehen davon aus, dass es sich um einen vertrauenswürdigen Diensteanbieter handelt und übermitteln Daten an den angebotenen Dienst. Je nach übermittelten Daten erhält der Angreifer somit vertrauliche Daten des Nutzers, die er ggf. zur Nutzung des wahren Dienstes einsetzen kann. Geeignete Gegenmaßnahme: Vergleichbar mit Web-Spoofing und so genannten Phishing-Attacken sollte ein Nutzer nur die Dienste aufrufen, denen er vertrauen kann bzw. die ihre vorgegebene Identität authentisch nachweisen können (Service Authentication). Angriffe auf Registries/Repositories Bedrohung/Gefahr innerhalb einer SOA: In Registries (Diensteverzeichnissen) werden Informationen (Metadaten) zu Diensten veröffentlicht, wie z.b. Service Policies, Adressierung oder Schnittstellen-Informationen. Gelingt es dem Angreifer durch Ausnutzen von Schwachstellen, Zugriff auf ein Diensteverzeichnis zu erlangen, kann er Dienstanfragen umleiten, Policies ändern oder weitere unberechtigte Aktionen durchführen. Angriffe auf Datenbanken/Repositories können wie unter Code Injection Attacks) beschrieben, z.b. mittels SQL-Injection oder LDAP Injection durchgeführt werden. Geeignete Gegenmaßnahme: Generell sollte der Zugriff auf Repositories (die nicht öffentlich sind) mittels entsprechender Authentifizierungs- und Autorisierungsmechanismen gesteuert werden. Um Angriffe auf Repositories im Backend (z.b. Datenbanken) zu verhindern, sind die Inhalte von Nachrichten zu überprüfen und ggf. zu filtern. Schadhafter Code bzw. Kommandos werden somit nicht weitergeleitet, wodurch eine Manipulation von Repositories verhindert werden kann. 35

36 Angriffe auf verwendete Protokolle ( geerbte Bedrohungen ) Bedrohung/Gefahr innerhalb einer SOA: Service-orientierte Architekturen erben je nach Einsatz bestimmter Protokolle (z.b. HTTP, TCP, FTP...) deren Schwachstellen und Bedrohungen. Generell ist die Gefahr groß, wenn Systeme und Protokolle für einen Zweck eingesetzt werden, für den sie ursprünglich nicht entwickelt wurden. Geeignete Gegenmaßnahme: Allgemein sollten möglichst standardisierte Protokolle eingesetzt werden, die auch für den entsprechenden Anwendungszweck entwickelt wurden. Insbesondere ältere Protokolle verfügen jedoch häufig nicht über ausreichende Sicherheitsmechanismen und müssen daher mittels zusätzlicher Technologien abgesichert werden. FTP ist zum Beispiel ein Protokoll, das keine sicheren Schutzmechanismen hinsichtlich der Authentizität, Integrität oder Vertraulichkeit von Nachrichten bietet, so dass diese Funktionalitäten auf andere Weise bereitgestellt werden müssen. Directory traversal attacks Bedrohung/Gefahr innerhalb einer SOA: Der Angriff Directory traversal attack ist ein bekannter Angriff, der im Zusammenhang mit Webservern bzw. Webanwendungen häufig auftaucht. Durch Erraten oder Anpassen bekannter Hyperlinks/URLs versucht dabei ein Angreifer direkt auf bestimmte Ressourcen zuzugreifen, die eigentlich nicht dafür vorgesehen sind. Dieser Typ Angriff ist auf Web Services übertragbar. Analog zu dem Aufrufen von Hyperlinks versucht ein Angreifer durch Austesten/Erraten bestimmte Web Services aufzurufen, die nicht explizit veröffentlicht wurden. Geeignete Gegenmaßnahme: Allgemein ist zu empfehlen, dass ein Zugriff auf Ressourcen nur mit den dafür benötigten Rechten und nach einer vorausgegangenen Authentifizierung erfolgen darf. Demzufolge sind entsprechende Authentifizierungsmechanismen zu implementieren, sowie strikte Zugriffsregeln (Policies) zu definieren und umzusetzen. Als weitere Maßnahme wäre der Einsatz eines Intrusion Detection Systems möglich, das ein Austesten von Web Service Anfragen erkennt. Kryptoanalyse Bedrohung/Gefahr innerhalb einer SOA: Mit dem Begriff Kryptoanalyse wird allgemein die Analyse von kryptographische Verfahren bezeichnet. Ziel ist dabei oftmals, die Verfahren zu brechen und damit umgesetzte Sicherheitsmechanismen in IT-Systemen oder Netzwerken zu umgehen. Geeignete Gegenmaßnahme: Im Falle eines Algorithmus, der gebrochen wurde, muss schnellstmöglich das gesamte System umgestellt werden, um die Sicherheit des gesamten Prozesses zu gewährleisten. Es sollten nur anerkannte Standardalgorithmen verwendet werden, da die einzelnen Web Service Sicherheitsstandards von ihnen abgeleitet werden. 36

37 3.3.2 Organisatorische Mängel Unzureichende Berücksichtigung von Sicherheitsaspekten im SOA Design Bedrohung/Gefahr innerhalb einer SOA: Häufig wird bei der Planung von Service-orientierten Architekturen das Thema Sicherheit nicht ausreichend berücksichtigt. Ein nachträgliches Implementieren von Sicherheitsmechanismen kann problematisch werden, viele Veränderungen an der Architektur nach sich ziehen und somit hohe Kosten verursachen. Zudem können durch eine im Nachhinein eingeführte und daher häufig nicht optimal realisierbare Lösung erhebliche Performance-Probleme entstehen, welche die Durchführung der Geschäftsprozesse beeinträchtigen. Geeignete Gegenmaßnahme: Es ist wichtig, dass das Thema Sicherheit als wesentlicher Baustein für eine solide Serviceorientierte Architektur angesehen wird und von Beginn an bei dem Design der SOA berücksichtigt wird. Die Modellierung der Geschäftsprozesse sowie die Entwicklung entsprechender Services sollte daher in enger Zusammenarbeit mit SOA Security Experten abgestimmt bzw. durchgeführt werden. Fehlende oder unzureichende Regelungen/keine klare Abgrenzung von Verantwortlichkeiten Bedrohung/Gefahr innerhalb einer SOA: Existieren innerhalb einer Organisation keine klaren Regelungen und Verantwortlichkeiten, sind sichere Geschäftsprozesse langfristig nicht zu gewährleisten. Zum Beispiel werden Sicherheitsmaßnahmen aufgrund fehlender oder mangelhafter Zuordnung von Verantwortlichkeiten nicht bzw. nicht ordnungsgemäß umgesetzt. Geeignete Gegenmaßnahme: Existieren innerhalb einer Organisation keine klaren Regelungen und Verantwortlichkeiten, sind sichere Geschäftsprozesse langfristig nicht zu gewährleisten. Zum Beispiel werden Sicherheitsmaßnahmen aufgrund fehlender oder mangelhafter Zuordnung von Verantwortlichkeiten nicht bzw. nicht ordnungsgemäß umgesetzt. Fehlendes Notfallvorsorgekonzept/Sicherheitskonzept/fehlender Business Continuity Plan Bedrohung/Gefahr innerhalb einer SOA: Treten unerwartete Ereignisse ein (z.b. kompletter Stromausfall, technischer Defekt einer zentralen Komponente, usw.), kann dies schwerwiegende Auswirkungen auf die durchzuführenden Geschäftsprozesse haben. Neben einer Beeinträchtigung des allgemeinen Betriebs (Erbringen bestimmter Leistungen), kann die Sicherheit stark gefährdet sein, weil z.b. wichtige Sicherheitskomponenten betroffen sind. Fehlt in diesem Fall ein Sicherheitsbzw. Notfallvorsorgekonzept, können geeignete Sicherheitsmaßnahmen ggf. nicht zeitnah durchgeführt werden und ein erheblicher Schaden für die Organisation entsteht. 37

38 Geeignete Gegenmaßnahme: Generell ist es wichtig, nötige Sicherheitsvorkehrungen im Vorfeld zu treffen, um im Notfall schnellstmöglich den ordnungsgemäßen Betrieb wiederaufnehmen und geeignete Sicherheitsmaßnahmen unverzüglich durchführen zu können. Daher sollten alle möglichen Risiken zunächst analysiert, bewertet und zusammen mit den jeweiligen Sicherheitsmaßnahmen in einem Sicherheitskonzept dokumentiert werden. Unzureichendes Sicherheitsmanagement Bedrohung/Gefahr innerhalb einer SOA: Insbesondere bei der Komplexität einer großen, viele Dienste umfassenden Serviceorientierten Architektur ist die Gefahr groß, dass die Übersichtlichkeit über die verwendeten IT-Systemkomponenten verloren geht und die Architektur nicht mehr beherrschbar ist. Demzufolge steigt auch das Risiko, dass die Sicherheit mit der Zeit nicht mehr auf dem aktuellen Stand ist bzw. neuen Anforderungen nicht gerecht wird. Durch bewusst (z.b. durch Angriffe) als auch unbewusst durchgeführte Aktionen (z.b. unbewusstes Löschen von Daten durch mangelnde Zugriffssteuerung) kann für die Organisation in diesen Fällen ein großer Schaden entstehen. Geeignete Gegenmaßnahme: Es müssen Prozesse innerhalb der Organisation implementiert werden, die ein fortwährend hohes Sicherheitsniveau gewährleisten. Dies kann durch Anwendung eines umfassenden Governance- und Compliance-Frameworks erfolgen, das Organisationen bei der Umsetzung geeigneter Maßnahmen durch eine strukturierte Vorgehensweise unterstützt Menschliche Fehlhandlungen Fehlendes Sicherheitsbewusstsein (Awareness)/Verantwortungsbedürfnis/Kenntnis Bedrohung/Gefahr innerhalb einer SOA: Durch fehlendes Sicherheitsbewusstsein, Verantwortungsbedürfnis oder mangelnde Kenntnis können innerhalb von Organisationen große Sicherheitsprobleme entstehen. Die besten Sicherheitsmechanismen und -technologien sind wirkungslos, wenn sie falsch eingesetzt oder umgangen werden. Geeignete Gegenmaßnahme: Die Mitarbeiter sollten hinsichtlich relevanter Sicherheitsthemen sensibilisiert werden. Dies kann über Schulungen, Workshops, Informationskampagnen sowie weitere Aufklärungsaktivitäten erfolgen. Wichtig ist, dem Mitarbeiter die Tragweite seines Handelns und die Notwendigkeit bestimmter Sicherheitsabläufe nahe zu bringen, so dass ein verantwortungsbewusster Umgang mit dem Thema Sicherheit erzielt wird. 38

39 Falsche oder ungenügende Implementierungen/Sicherheitskonfigurationen Bedrohung/Gefahr innerhalb einer SOA: Es gibt viele Möglichkeiten, durch aktuelle Authentifizierungs-, Integritäts- und Verschlüsselungsmechanismen sowie Technologien den nötigen Schutz zu gewährleisten. Allerdings müssen diese Maßnahmen korrekt eingesetzt bzw. konfiguriert werden. Beispielsweise erhöhen XML-Signaturen nur die Sicherheit hinsichtlich der Integrität, wenn sie auf die richtigen Elemente innerhalb der XML-Datei angewendet werden und eine korrekte Signaturprüfung bei der Verarbeitung der Nachrichten stattfindet. Geeignete Gegenmaßnahme: Die verantwortlichen Mitarbeiter müssen über das nötige technische Wissen verfügen und dieses in der Praxis angemessen umsetzen können. Da insbesondere auf dem Gebiet der Service-orientierten Architekturen die Technik schnell fortschreitet, ist eine kontinuierliche Weiterbildung hinsichtlich aktueller Standards, Protokolle, Architekturansätze und Technologien zwingend erforderlich. Social Engineering Bedrohung/Gefahr innerhalb einer SOA: Social Engineering bezeichnet einen Angriff, bei dem der Faktor Mensch die wesentliche Rolle spielt. Ein Angreifer bringt durch gezieltes Vortäuschen falscher Tatsachen einen Mitarbeiter dazu, sicherheitsrelevante Informationen zu verraten, die dem Angreifer z.b. Zugriff auf vertrauliche Daten ermöglicht. Geeignete Gegenmaßnahme: Mitarbeiter sind hinsichtlich solcher Angriffe zu informieren und zu sensibilisieren (siehe Fehlendes Sicherheitsbewusstsein (Awareness)/Verantwortungsbedürfnis/Kenntnis) und auf ihre Pflichten in diesen Fällen hinzuweisen Technisches Versagen Fehlerhafte Hardware Bedrohung/Gefahr innerhalb einer SOA: Fallen Hardwarekomponenten aus, können ggf. bestimmte Geschäftsprozesse nicht mehr durchgeführt werden. Werden mehrere Services auf einer Hardware betrieben (wenn auch isoliert z.b. mittels Virtualisierungstechnik), kann ein Ausfall des entsprechendes Gerätes einen erheblichen Schaden verursachen. Geeignete Gegenmaßnahme: Für wichtige Dienste sollten redundante Hardwarekomponenten bereitgestellt werden, um eine Fortführung des Betriebs auch bei Ausfall einzelner Hardwarekomponenten zu gewährleisten. Allgemein sollten regelmäßig Sicherungen der genutzten Systeme stattfinden, so dass ein bestimmter Dienst nach einem Hardwareschaden bei Bedarf schnell auf einer Ersatz-Hardware eingerichtet und betrieben werden kann. Innerhalb des Sicherheitskonzepts 39

40 sind Maßnahmen für den Fall eines Hardwaredefekts zu definieren und in diesem Zuge z.b. Ansprechpartner und Bezugsquellen für Ersatzhardware zu nennen. Fehlerhafte Software Bedrohung/Gefahr innerhalb einer SOA: Fallen Softwarekomponenten aus, können ggf. bestimmte Geschäftsprozesse nicht mehr durchgeführt werden. Generell ist die Gefahr hoch, dass in einer Software Programmierfehler enthalten sind. Einige dieser Programmierfehler können kritisch sein, z.b. eine Anwendung anfällig für Buffer Overflows oder Denial of Service Angriffe machen. Geeignete Gegenmaßnahme: Es sollten in regelmäßigen Abständen Softwareupdates/Patches eingespielt werden, um entdeckte Sicherheitslücken zu schließen. Da in der Regel nicht jeder Dienst auf einer eigenen Hardwarekomponente betrieben wird, ist es wichtig, dass sich Dienste, die auf einem System/Rechner betrieben werden, nicht gegenseitig beeinträchtigen. Über den Einsatz von Virtualisierungstechnik kann ein solcher isolierter Betrieb stattfinden. D.h. arbeitet ein bestimmter Dienst nicht mehr korrekt, wird die Funktionsweise eines anderen Dienstes auf demselben System nicht berührt. Dabei ist zu beachten, dass je nach Konfiguration eine gegenseitige Beeinträchtigung durch die gemeinsame Nutzung von Hardwareressourcen (z.b. Prozessor, Hauptspeicher) auch beim Einsatz von Virtualisierungstechnik möglich ist. Daher sollte eine Konfiguration gewählt werden, die den Zugriff auf die gemeinsamen Hardwareressourcen klar regelt und eine gegenseitige Beeinflussung ausschließt. Fehlerhafte Protokolle/unsichere Algorithmen Bedrohung/Gefahr innerhalb einer SOA: Ähnlich zu Software können kryptographische Verfahren und Protokolle Sicherheitsschwächen beinhalten, die durch Angreifer ausgenutzt werden können. Insbesondere Protokolle, die bereits viele Jahre alt, aber immer noch weit verbreitet sind (z.b. SMTP), verfügen häufig über keinerlei Sicherheitsmechanismen. Des Weiteren werden Computersysteme immer leistungsfähiger, so dass bestimmte Schlüssellängen und Algorithmen unter Umständen nicht mehr die nötige Sicherheit bieten. Geeignete Gegenmaßnahme: Allgemein sollten nach Möglichkeit nur standardisierte und ausreichend erprobte Protokolle und Algorithmen zum Einsatz kommen. Es ist darauf zu achten, dass nur aktuelle Schlüssellängen und kryptographische Verfahren eingesetzt werden, die ein ausreichendes Maß an Sicherheit bieten. Müssen bestimmte Protokolle innerhalb der Architektur genutzt werden, die keine angemessenen Sicherheitsmechanismen vorsehen, so ist die Sicherheit über den Einsatz von zusätzlichen Technologien bzw. entsprechenden Protokollen zu gewährleisten. 40

41 3.3.5 Höhere Gewalt Naturkatastrophen/Ausfall wichtiger Infrastrukturkomponenten/schwerwiegende Vorfälle Bedrohung/Gefahr innerhalb einer SOA: Treten Naturkatastrophen oder andere schwerwiegende Vorfälle ein, kann dies unter Umständen die Existenz einer Organisation bedrohen. Neben den eigenen Prozessen können insbesondere bei einer Service-orientierten Architektur Prozesse von anderen Organisationen betroffen sein, wenn diese auf bereitgestellte Dienste angewiesen sind. Geeignete Gegenmaßnahme: Vorsorglich sollte ein Business Continuity Plan erarbeitet werden, der die Risiken für das Eintreten solcher schwerwiegenden Bedrohungen analysiert und Empfehlungen zu möglichen Notfallmaßnahmen enthält. 3.4 Sicherheitsgefährdungen und Gegenmaßnahmen veranschaulicht am Beispielprozess Der nachfolgende Abschnitt des Kapitels beschreibt exemplarisch an ausgewählten Diensten mögliche Bedrohungen und Sicherheitsmaßnahmen innerhalb eines Geschäftsprozesses (s.abbildung 6). Kapitel 7.7 betrachtet den dargestellten Geschäftsprozess und die vorhandenen unterschiedlichen Teilnehmer-Beziehungen dann nochmals ausführlicher und geht insbesondere auf die verschiedenen Anwendungsszenarien wie B2B, B2C, usw. ein. 41

42 B2C B2B B2B Kunde H ä n d le r P ro d u k t A n frage V e r f ü g b a r k e it p rü fe n Z a h lu n g sse r vic e P r o v id e r G 2B P r o d u ze n t Fin a n za m t A n ge b o t e r s t e lle n B e s t e llu n g au fge b e n B e s t e llu n g p rü fe n A d re s sd ate n p rü f e n B e s t e lla b le h n u n g e r h a lt e n B e s t e llu n g au sfü h re n K r e d it k a r t e v a lid ie r e n B e s t e llin f o r m a t io n e r h a lt e n P r o d u kt au f La g e r? Za h lu n g s f ä h ig k e it p rü f e n P ro d u kt b e s t e lle n V e rsan d in f o r m a t io n e r h a lt e n B e s t e llu n g au sfü h re n V e rsan d u n d R e ch n u gss t e llu n g U m sa tzste u erv o r a n m e ld u n g B e s t e u e r u n gs v e rfah re n Abbildung 6: Beispielszenario einer Service-orientierten Architektur unter Verwendung externer Dienste Der Beispiel-Geschäftsprozess zeigt den Ablauf einer Bestellung, bei dem mehrere Organisationen beteiligt sind, die jeweils bestimmte Aufgaben erfüllen. Technisch werden dabei die Aufgaben, die durch Einsatz von IT automatisierbar sind, mittels Web Services durchgeführt. Aufgrund dieser verteilten Aufgabenerfüllung ergeben sich für den jeweiligen Web Service bestimmte Sicherheitsanforderungen. Nachfolgend wird die Bedeutung von individuellen Sicherheitsmaßnahmen an ausgewählten Web Services des Beispielprozesses veranschaulicht. Verfügbarkeit überprüfen Bei diesem Service könnte es verschiedene Angriffsszenarien geben, die eine erfolgreiche Ausführung verhindern oder Daten manipulieren. Ein Angreifer könnte sich bspw. zwischen das Portal und den Service einklinken und anstelle des Service Informationen an das Portal weiterleiten. Somit könnten falsche Informationen an den Kunden weitergeleitet werden, die eine Bestellung verhindern, falls angegeben wird, dass ein vorhandener Artikel nicht verfügbar ist. Um solche Angriffe zu verhindern, sollte darauf geachtet werden, dass die Integrität der Daten nicht verletzt und die Authentizität der Services überprüft wird. 42

43 Zudem wäre es problematisch, wenn ein Angreifer sehen könnte, welcher Kunde bestimmte Produkte bestellt hat. Möglicherweise kann ein Angreifer auch umfangreiche Informationen über die Lagerbestände des Unternehmens gewinnen. Um diese Probleme zu lösen, sollte ein hinreichendes Maß an Vertraulichkeit gewährleistet sein. Selbstverständlich muss auch die grundlegende Sicherheitsanforderung Verfügbarkeit umgesetzt werden, da ohne diese das Portal keine Informationen über aktuelle Lagerbestände an den Kunden weiterreichen könnte. Angebot erstellen Bei der Erstellung von Angeboten für bestimmte Kunden werden Daten aus der Kundenverwaltung verwendet, um spezielle Konditionen einzubinden. Es könnte der Fall sein, dass spezielle Kunden besondere Rabatte auf Produkte des Händlers angeboten bekommen. Diese Informationen stellen natürlich für Konkurrenten eine interessante Information dar, und ein potentieller Angreifer könnte versuchen, die Kommunikation abzuhören oder unautorisierte Anfragen an den Service zu senden. Mit dem Abhören der Kommunikation könnte ein Angreifer Informationen über den Status eines Kunden gewinnen und generelle Informationen über die Vertriebsstrategie des Unternehmens erhalten. Mit Hilfe von Verschlüsselung kann bei diesen Angriffen die Sicherheitsanforderung Vertraulichkeit umgesetzt werden und somit ein Auslesen von vertraulichen Daten verhindert werden. Im Falle von unberechtigten Aufrufen eines Service sollte garantiert werden, dass diese verworfen und keinesfalls beantwortet werden. Um eine Schutzmaßnahme gegen solche Angriffe umzusetzen, muss die Integrität der Daten und die Authentizität des Anfragenden gewährleistet werden. Bei diesem Szenario ist aus Kundensicht die Verbindlichkeit des erstellten Angebots interessant, da er annimmt, die gewünschten Daten zum genannten Preis zu erhalten. Sollte im Nachhinein ein anderer Preis für die Produkte verlangt werden, würde dies zu Verstimmungen beim Kunden führen. Da auch dieser Prozessschritt eine Voraussetzung für die folgenden Schritte ist, ist er für den Gesamtprozess unabdingbar. Ist die Verfügbarkeit des Service gefährdet, so ist keine Beauftragung möglich und es kommt zu wirtschaftlichen Schäden. Bestellung prüfen Bei diesem Service werden relevante Informationen des Auftrags überprüft, um sicherzustellen, dass alle Daten korrekt erfasst wurden. Hierfür muss garantiert werden, dass die Integrität der Daten nicht verletzt wurde. Kompromittierte Daten hätten falsche, unerwünschte und fehlerhafte Auftragserfüllungen zur Folge, die nicht zuletzt in rechtlichen Auseinandersetzungen enden können. Im Zuge der Auftragsabwicklung werden auch personenbezogene Daten verarbeitet. Somit muss sichergestellt werden, dass diese Daten gemäß den gültigen Datenschutzbestimmungen des jeweiligen Landes bearbeitet werden. Rechtliche Probleme sowie Missbrauch dieser Daten durch Dritte wären mögliche Folgen einer Verletzung des Datenschutzes. Kreditkarte validieren Im Rahmen der Validierung von Kreditkarten haben wir es mit sehr sensitiven Daten zu tun. Diese müssen auf angemessene Art und Weise vor Angreifern geschützt werden, die durch Gewinnung dieser Informationen in der Lage wären, diese für ihre eigenen Zwecke zu verwenden. Generell wird bei der Validierung überprüft, ob die eingegebenen Informationen korrekt sind und ob die benötigte Bonität vorhanden ist. Beim Versand der Daten an den 43

44 Service muss sichergestellt werden, dass die Authentizität gewährleistet ist und die Informationen somit an eine vertrauenswürdige Stelle weitergeleitet werden. Falsche Aussagen zur Bonität des Kunden sind ebenso schädlich wie Kreditkartendaten des Kunden in den falschen Händen. Es muss auch darauf geachtet werden, dass die Informationen nicht auf dem Transportweg von einem Angreifer manipuliert werden können, was selbstverständlich einen wirtschaftlichen Schaden für das Unternehmen zur Folge hätte. Versand und Rechnungsstellung Auch bei diesem Service werden personenbezogene Daten weitergeleitet, in diesem speziellen Fall an die Versandabteilung des Unternehmens. Ist die Vertraulichkeit nicht garantiert, ist der Datenschutz verletzt. Eine nicht vorhandene Integrität würde falsche Liefer- und Rechnungsdaten zur Folge haben. Im Falle einer erfolgreichen nicht autorisierten Bestellung könnte erheblicher wirtschaftlicher Schaden für das Unternehmen entstehen. Zusätzlich sollte bei diesem Service auch die Problematik des Wiedereinspielens von abgefangenen Nachrichten (so genannte Replay-Angriffe) berücksichtigt werden, so dass verhindert wird, dass bereits versendete Bestellungen erneut bearbeitet werden. 44

45 4 Technologien und Standards Dieses Kapitel beschreibt in den folgenden Abschnitten die grundlegenden Technologien und Standards, die genutzt werden, um die Konzepte und Ziele im SOA-Umfeld umzusetzen. Basierend auf einem Überblick über die Web Service Spezifikationen werden die Web Service Standards der folgenden Themenkomplexe näher erläutert: Grundlegende Web Service-Standards, Dienste beschreiben und auffinden, Dienstkommunikation absichern, Nachrichten zustellen (Messaging), zuverlässige Nachrichtenübermittlung (Reliable Messaging), Transaktionssicherheit (Transaction Specifications), Interoperabilität und Dienste orchestrieren und choreographieren. Der Aufbau der Kapitel folgt einem einheitlichen Grundmuster: Definition des Standards, Beschreibung der Grundlagen, Definition von Schemata, Benennung von Szenarien und Einsatzgebieten und einer Empfehlung zur Anwendung. Die Standards werden hinsichtlich der Anwendung in vier Klassen eingeordnet: Empfehlen (1): Standards werden empfohlen, wenn sie sich in der Praxis bewährt haben. Anregen (2): Angeregt zur Nutzung werden Standards, wenn sie für den jeweiligen Anwendungsfall nützlich sind. Beobachten (3): Unter Beobachtung stehen Standards, wenn sie der gewünschten Entwicklungsrichtung hinsichtlich einer sicheren SOA folgen, aber z.b. noch nicht den erforderlichen Reifegrad besitzen. Nicht Empfehlen (4): Standards werden nicht empfohlen, wenn sie sich in der Praxis nicht bewährt haben, sicherheitsspezifische Probleme aufweisen, nicht am Markt akzeptiert oder veraltet sind. Diese Aufteilung erlaubt es dem Leser, entsprechend seines Wissens bzw. Interesses, unterschiedlich tief in die Materie einzusteigen. Sowohl Codebeispiele zur Umsetzung, Literaturreferenzen als auch eine Gesamtübersicht der beschriebenen Standards, deren Versionierung und Klassifizierung zur Anwendung sind im Anhang zu finden. 4.1 Überblick über die Web Service Spezifikationen Auf dem Gebiet der Service-orientierten Architekturen existieren eine ganze Reihe von Standards, die jeweils bestimmte Aspekte einer SOA adressieren und wichtige 45

46 Funktionalitäten spezifizieren. Während zu den Anfangszeiten Service-orientierter Architekturen die Standards noch überschaubar waren und bei den Themen SOA sowie Web Services hauptsächlich von den Standards XML, SOAP, WSDL und UDDI die Rede war, ist es mittlerweile schwer, die nötige Übersicht zu behalten. Im Laufe der Zeit wurden viele neue Standards entwickelt, die jeweils bestimmte Probleme lösen, bestehende Standards erweitern, neue Funktionalitäten beschreiben und letztlich einen Teil zum optimalen Betrieb Serviceorientierter Architekturen beitragen. Die meisten der Standards sind so entworfen, dass sie aufeinander aufbauen bzw. sich gegenseitig erganzen und damit eine Art Protokollstack bilden. So findet sich beispielsweise auf der untersten Ebene SOAP, welches grundlegend das Format zum Austausch von Nachrichten beschreibt. Jegliche weitere Funktionalitat, wie z.b. die Garantie, dass eine Nachricht auch beim Empfanger ankommt, wird durch weitere Spezifikationen umgesetzt, die dazu den SOAP Header um zusatzliche Elemente erganzen. Oftmals greifen auch verschiedene Spezifikationen ineinander und bilden erst zusammen den gewunschten Effekt, wie beispielsweise im Falle von WS-Policy und WS-SecurityPolicy. Während WS-Policy lediglich das Gerust fur Serviceanforderungen jeglicher Art bildet, fullt WS-SecurityPolicy dieses mit konkreten Anforderungen bezuglich der Sicherheit des Service aus. Abbildung 7 gibt einen groben Uberblick uber den Web Service Protokollstack und ordnet die einzelnen Standards entsprechend ihren Aufgaben in verschiedene Kategorien ein, wobei kein Anspruch auf Vollstandigkeit erhoben werden kann. Abbildung 7: Überblick über die Web Service Spezifikationen Im folgenden werden die in Abbildung 7 dargestellten Kategorien kurz erläutert: Grundlegende Web Service Standards: XML stellt zumeist die Grundlage für andere SOA und SOA Security Standards dar. Des Weiteren wird SOAP als StandardProtokoll für die nachrichtenbasierte Kommunikation zwischen Web Services genutzt. In der Abbildung wird dieser Zusammenhang verdeutlicht, indem diese Kategorie als durchgängige Ebene dargestellt wird, auf der die anderen Blöcke (Kategorien mit Standards) aufsetzen. 46

47 Dienste orchestrieren und choreographieren: Service-orientierte Architekturen werden auf der Basis von Geschäftsprozessen entworfen und umgesetzt, um diese bestmöglich zu unterstützen. Zur Beschreibung und (automatisierten) Ausführung von Prozessen ist es daher naheliegend, dass mittlerweile verschiedene Standards für diese Aufgabe entwickelt wurden. Bekanntester und in der Praxis am meisten verwendeter Standard ist BPEL (Business Process Execution Language). Dienste beschreiben und auffinden: Diese Kategorie enthält vorwiegend Standards, mit denen Informationen über andere Daten bzw. Objekte (so genannte Metadaten) bereitgestellt werden können. Das heißt sie werden meist dafür verwendet, Eigenschaften von Objekten zu definieren. Die Spezifikation WSDL (Web Services Description Language) wird beispielsweise genutzt, um Informationen über Web Services auf standardisierte Weise zu veröffentlichen, damit diese aufgefunden und genutzt werden können. Dienstkommunikation absichern: Diese Kategorie enthält Spezifikationen, die das Ziel haben, die Kommunikation zwischen den Teilnehmern einer SOA abzusichern. Auf der Nachrichtenebene bildet WS-Security einen entscheidenden Standard, da er elementare Mechanismen zur Wahrung der Vertraulichkeit und Integrität von Nachrichten innerhalb Service-orientierter Architekturen definiert. Darüber hinaus bieten Spezifikationen wie WS-Trust und WS-Federation Mechanismen und Protokolle, um die Kommunikation auf der Ebene der verschiedenen Teilnehmer einer SOA abzusichern, beispielsweise durch den Aufbau von Förderationsstrukturen und den Abruf von Sicherheitstoken. Grundlegende Sicherheitsstandards: In dieser Kategorie befinden sich Sicherheitsstandards, die sich neben den Standards der Kategorie Dienstkommunikation absichern auf dem Gebiet der Service-orientierten Architekturen etabliert haben. SAML ist zum Beispiel ein etablierter Standard, um Authentifizierungs- und Autorisierungsdaten zwischen verschiedenen Sicherheitsdomänen auszutauschen. Standards für Transaktionen: Ähnlich wie im Bereich der Datenbanken soll das Prinzip der Transaktionen auf dem Gebiet der Service-orientierten Architekturen angewendet werden. Standards dieser Kategorie beschäftigen sich daher mit der Koordination und Ausführung von Aktionen zwischen verschiedenen Diensten. Messaging Nachrichten zustellen: Neben dem grundlegenden Standard SOAP existieren weitere Standards, die zur effizienten nachrichtenbasierten Kommunikation in Service-orientierten Architekturen zum Einsatz kommen. WSAddressing, WS-Eventing und WS-Notification sind die bekanntesten Vertreter dieser Kategorie. Standards zur zuverlässigen Zustellung von Nachrichten: Um einen zuverlässigen Nachrichtenaustausch zu gewährleisten, wurden Standards definiert, die innerhalb dieser Kategorie zusammengefasst werden. Bekanntester Vertreter ist der Standard WS-ReliableMessaging. In Abbildung 7 ist zu erkennen, dass die beiden Standards WS-SecurityPolicy und WSDL jeweils zwei Kategorien zugewiesen sind. Generell ist eine eindeutige Zuordnung von Standards nicht immer möglich, da oftmals verschiedene Aspekte innerhalb eines Standards betrachtet werden. 47

48 4.1.1 OASIS SOA Referenzmodell und SOA Referenzarchitektur Für die Entwicklung und Nutzung von diversen Standards auf einem Gebiet ist es allgemein wichtig, dass Entwickler und Architekten ein gemeinsames Verständnis hinsichtlich der Begriffe, Komponenten und deren Beziehungen in der jeweiligen Domäne haben. Um dieses Ziel auf dem Gebiet der Service-orientierten Architekturen zu erreichen, wurde im Oktober 2006 von der Standardisierungsorganisation OASIS ein Rahmenwerk veröffentlicht, das auf einer hohen Abstraktionsstufe grundlegende Entitäten und deren Beziehungen definiert, die auf jede Service-orientierte Architektur zutreffen. Die Veröffentlichung des Referenzmodells [OASIS_Mod] war somit ein wichtiger Schritt, um die bis dahin existierende Begriffsverwirrung hinsichtlich Service-orientierter Architekturen aufzulösen bzw. einzudämmen. Aufgrund des hohen Abstraktionsgrades des Modells werden unabhängig von bestimmten SOA-Technologien grundlegende Eigenschaften einer SOA definiert und Unterschiede zu bisherigen Konzepten für verteilte Systeme erläutert. Die OASIS Spezifikation ermöglicht weniger technisch versierten Lesern ein Verständnis hinsichtlich der Grundprinzipien einer SOA und bietet IT-Architekten eine allgemeine Unterstützung bei der Entwicklung Service-orientierter Architekturen. Um Architekten darüber hinaus bei der Entwicklung und Umsetzung einer SOA zu unterstützen, wurde im April 2008 von OASIS ein neues Dokument (Public Review Draft 1) veröffentlicht, das eine SOA-Referenzarchitektur [OASIS_Arch] spezifiziert. Die Spezifikation nutzt konsequent die Begriffsdefinitionen und Konzepte des Referenzmodells und beschreibt eine mögliche Vorlage, die zur Umsetzung einer konkreten Service-basierten Architektur dienen kann. Die Referenzarchitektur besitzt drei Sichten (Views), die jeweils grundlegende Aspekte für Service-orientierte Architekturen beleuchten: Business via Service view: Sie legt die Grundlage, um Geschäftsprozesse Service- basiert ausführen zu können. Realizing Services view: Diese Sicht adressiert die Anforderungen, um eine Service- orientierte Architektur umzusetzen. Owning Services Oriented Architecture view: Innerhalb dieser Sicht werden SOA- Governance und -Management Aspekte betrachtet. Zusammengefasst kann festgehalten werden, dass sowohl das Referenzmodell als auch die Referenzarchitektur von OASIS eine gute Basis bilden, um ein Grundverständnis von Service-orientierten Architekturen zu erhalten. Die beiden Spezifikationen helfen darüber hinaus insbesondere dabei, nachfolgende Beschreibungen der Spezifikationen innerhalb des Kompendiums leichter einordnen und verstehen zu können. 4.2 Grundlegende Web Service-Standards In den nachfolgenden Abschnitten werden die Standards XML, SOAP, SwA und MTOM behandelt. 48

49 4.2.1 XML Definition XML (extensible Markup Language) stellt eine Auszeichnungssprache dar, die von SGML (Standard Generalized Markup Language) abgeleitet und vom W3C als "SGML for the Web" konzipiert wurde [XML]. SGML war ein erster Versuch, die logische Struktur eines Dokumentes zu beschreiben und stellt einen ersten Ansatz dar, Dokumente plattformunabhängig zu speichern. XML ist lediglich eine Untermenge von SGML und deutlich weniger komplex. Da XML jedoch die wichtigsten Elemente und Prinzipien von SGML beinhaltet, ist diese Sprache in der Praxis sehr wichtig und Basis für die Definition vieler existierender Markup-Sprachen. Bei der XML-Spezifikation handelt es sich somit um eine Metasprache, die es erlaubt, eigene Sprachen zu schaffen, die auf bestimmte Anwendungsgebiete ausgerichtet sind. Diese beinhalten dann bereichsspezifische Elemente und Einschränkungen, um eine standardisierte und möglichst effiziente Nutzung auf dem jeweiligen Anwendungsgebiet zu erreichen Grundlagen Die Grundfunktion von XML besteht darin, eigene Auszeichnungssprachen zu definieren und somit Regeln für die informationelle Struktur von Dokumenten bereitzustellen. MarkupSprachen besitzen anwendungsspezifische Elemente (sog. Tags), mit denen Informationen bzw. Daten ausgezeichnet und somit strukturiert gespeichert werden können. Im Gegensatz zur Markup-Sprache HTML, die auch aus Tags, deren Verschachtelungen und Attributen besteht, können in XML neue Tags und Attribute definiert werden, während HTML einen fest definierten Satz an Tags und Attributen bietet. Allgemein bestehen XML-Dokumente aus Elementen, Attributen und Werten. Dabei können Elemente selbst wiederum weitere Elemente besitzen und somit Informationen in Dokumenten hierarchisch abbilden. Die Daten (meist einfacher Text), die sich in den Elementen und Attributen wiederfinden, werden durch den hierarchischen Dokumentenaufbau zwar teilweise verschachtelt, gleichzeitig jedoch vollständig und eindeutig strukturiert. Um Elemente zu identifizieren, werden diese mit Bezeichnern versehen. Die Bezeichner befinden sich in einem öffnenden und schließenden Tag. Attribute spezialisieren oder ergänzen den Inhalt von Elementen. Die Werte von Attributen bestehen aus einfachem Text. Im Kontext von XML spielen folgende Begriffe eine zentrale Rolle: XML-Schema und DTD Mit XML-Schemata und DTDs (Document Type Definition) läßt sich die Struktur eines XML-Dokuments definieren. Das heißt, es wird genau festgelegt, wie beispielsweise die Reihenfolge, Verschachtelung und Attributinhalte von Elementen innerhalb eines XML-Dokuments aussehen müssen. Über eine URI (Uniform Resource Identifier) wird auf die relevante DTD oder das XML-Schema innerhalb des XML Dokuments referenziert. Im Gegensatz zu XML-Schemata sind DTDs nicht in XML formuliert, sondern besitzen wiederum eine eigene formale Syntax, die für den Menschen schwerer lesbar bzw. verständlich ist. Des weiteren sind DTDs nicht erweiterbar, unterstützen nur einen 49

50 Datentyp und bieten nicht die Möglichkeit der Vererbung. Diese Nachteile haben u.a. dazu geführt, dass XML-Schemata eingeführt wurden und in der Praxis heute weit verbreitet sind. Wohlgeformte und valide XML-Dokumente Ein XML Dokument wird allgemein als wohlgeformt bezeichnet, wenn es der festgelegten XML-Syntax entspricht. D.h. das Dokument beachtet alle grundlegenden Regeln, die direkt aus der XML-Spezifikation hervorgehen. Hierzu zählt z.b., dass es nur genau ein Wurzelelement innerhalb des Dokuments geben darf und dass nur zulässige Zeichen verwendet werden. Die Bezeichnungen der Elemente müssen immer jeweils einen Start- und Ende-Tag besitzen, etc.. Wohlgeformte Dokumente müssen nicht notwendigerweise interpretierbar sein, lediglich die Struktur muss festgelegten Regeln folgen. Bei positiver Prüfung gegen eine DTD oder ein XML-Schema wird ein XMLDokument als valide bzw. gültig bezeichnet. Eine Validitätsprüfung kann z.b. mittels frei verfügbarer Tools oder über Webseiten mit einem Validierungsdienst (z.b. des W3C) durchgeführt werden. Konzept der Namensräume Da XML-Anwender eigene Element-Typen (Tags) definieren können, sind z.b. bei der Benutzung fremder DTDs oder Schemata Mehrdeutigkeiten oder Namenskollisionen möglich. Zur Lösung dieser Probleme wurde vom W3C das Konzept der Namensräume eingeführt. Mit Namensräumen kann der genaue Kontext eines XML-Elements festgelegt werden. Während eine DTD oder ein XML-Schema die gesamte Struktur eines Dokuments beschreibt, verfügt ein Namensraum lediglich über eine Menge von Namen, die einer bestimmten DTD oder einem XML-Schema zugeordnet sind. Durch die inhärente hierarchische Strukturierung und die strikte Trennung zwischen Struktur und Präsentation bietet XML viele Vorteile. Zum einen können XML-basierte Daten leicht ausgelesen und verarbeitet werden und zum anderen ist eine unterschiedliche Aufbereitung bzw. Darstellung der Daten für verschiedene Zwecke oder Ausgabegeräte aufgrund der Layout-Unabhängigkeit mit relativ wenig Aufwand realisierbar Schemata Das folgende Beispiel zeigt einen Auszug aus einer XML-Schema Definition (XSD-Datei): <xsd:schema xmlns:xsd=" <xsd:annotation> <xsd:documentation xml:lang="de"> Projektverzeichnis für das BSI. </xsd:documentation> </xsd:annotation> <xsd:element name="projektverzeichnis" type="projektverzeichnistype"/> <xsd:element name="comment" type="xsd:string"/> <xsd:complextype name="projektverzeichnistype"> <xsd:sequence> <xsd:element name="stammdaten" type="stammdaten"/> <xsd:element name="optional" type="freidaten"/> <xsd:element name="comment" type="kommentar /> <xsd:element name="items" type="items"/> </xsd:sequence> </xsd:complextype> 50

51 <xsd:complextype name="stammdaten"> <xsd:sequence> <xsd:element name="nummer" <xsd:element name="bezeichnung" <xsd:element name="auftragnehmer" <xsd:element name="scope" </xsd:sequence> </xsd:complextype> [...] </xsd:schema> type="xsd:decimal"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> Szenarien XML kommt mittlerweile in vielen Bereichen der Informationstechnologie vor. Die Anzahl der Programme und Anwendungen, die XML verstehen, nutzen und verarbeiten können, steigt kontinuierlich. XML wird z.b. für die folgenden Aktivitäten genutzt: Beschreibung von Datenstrukturen (XML-Schema) und Zusammenhängen, Austausch von Daten zwischen Programmen oder Diensten (z.b. Austausch von Wetterdaten und Aktualisierung von Daten in Datenbanken), Verwaltung von Daten (Content Management oder Synchronisation), Konvertieren von Datenformaten, z.b. XML mit XSLT. In der Praxis ist XML insbesondere als universelles Datenaustauschformat auf unterschiedlichen Gebieten beliebt Empfehlung zur Anwendung Die Nutzung von XML ist empfehlenswert (1). XML stellt einen grundlegenden Baustein innerhalb Service-orientierter Architekturen dar. Viele Standards, Formate und Spezifikationen basieren auf XML und bilden die Basis für die nachrichtenbasierte Kommunikation zwischen Web Services. Des Weiteren ist diese Sprache vollständig vom Markt angenommen worden und wird auch in Zukunft ein de facto Standard sein. 51

52 4.2.2 SOAP Definition SOAP (SOAP war früher ein Akronym für Simple Object Access Protocol, das heute aber nicht mehr verwendet wird, da die Deutung nicht dem Sinn von SOAP entspricht) wurde von DevelopMentor, IBM, Lotus Development Corp., Microsoft und UserLand Software entwickelt und hat den Status einer W3C-Empfehlung. Diese Spezifikation definiert ein Nachrichtenformat zum standardisierten Austausch von strukturierten Informationen in einer dezentralen, verteilten Umgebung. Ziel beim Design von SOAP waren Einfachheit und Erweiterbarkeit. Um Interoperabilität in einer heterogenen Umgebung zu gewährleisten, nutzt die Spezifikation XML zur Repräsentation der auszutauschenden Informationen. Für den Transport der Nachrichten können verschiedene Transportprotokolle zum Einsatz kommen. Die Spezifikation beinhaltet dazu allgemeine Regeln (Profile), welche beispielsweise die Verwendung von SOAP über HTTP oder SMTP definieren Grundlagen SOAP wurde 1998 von Microsoft und UserLand Software für Remote-Procedure-CallAufrufe (RPC) über XML implementiert und 1999 in der Version 0.1 veröffentlicht. In den späteren Versionen 2007 wurde Version 1.2 veröffentlicht haben sich allerdings die Verwendungsmöglichkeiten signifikant erweitert, so dass SOAP nicht nur ein Format zum Aufruf von entfernten Funktionen darstellt, sondern ein allgemeines Format zum Austausch von strukturierten Informationen und zusammen mit anderen WS-Spezifikationen wie WSAddresssing ein umfassendes Messaging-Framework bietet. Eine SOAP Nachricht ist ein XML-Dokument, das aus drei Teilen besteht (siehe Abbildung 8): einem SOAP Envelope, optionalen SOAP Headern und einem SOAP Body. 52

53 S O A P E n v e lo p e < S O A P : E n v e l o p e x m l n s : S O A P = h t t p : //...> SO A P H eader < S O A P : H ead er> O p t io n a l: H e a d e r P a r ts < /S O A P : H e a d e r > SO A P B ody <SO A P:B ody> S O A P M e s s a g e P a y lo a d O p t io n a l: S O A P F a u lt < /S O A P : B o d y > Abbildung 8: Aufbau einer SOAP Nachricht SOAP Envelope Der SOAP Envelope ist ein Umschlag um den SOAP Header und SOAP Body. Er bildet die Wurzel des XML-Dokuments und definiert es als SOAP Nachricht. SOAP Header Eine SOAP Nachricht kann eine Reihe von SOAP Headern enthalten, die Metainformationen über die SOAP Nachricht speichern. Konkrete SOAP Header werden durch weitere Spezifikationen definiert, wie beispielsweise WS-Addressing, das einen Header mit Absender- und Empfängerinformationen definiert. Wenn ein Header in der SOAP Nachricht verwendet wird, dann muss er das erste direkte Kindelement (Element innerhalb eines übergeordneten Elements) des SOAP-Envelope-Elements sein. Die direkten Subelemente des SOAP Header-Elements werden als SOAP Header-Blöcke bezeichnet. Über das Headerattribut mustunderstand kann zudem spezifiziert werden, ob ein Empfänger fähig sein muss, einen Header zu verarbeiten. In vielen Anwendungen werden SOAP Nachrichten nicht vom Sender zum Empfänger, sondern über Zwischenstationen, so genannte SOAP Intermediäre (SOAP Intermediaries), übertragen. Diese Intermediate-Nodes können Informationen aus den Nachrichtenheadern verwenden, um die Nachrichten zu verarbeiten beispielsweise einen Header mit Adressinformationen, um die Nachricht korrekt weiterzuleiten. SOAP Body Der SOAP Body wird durch das XML-Element <Body> repräsentiert und muss immer in einer SOAP Nachricht enthalten sein. Er enthält die eigentlichen Nutzdaten, die vom Sender zum Empfänger übertragen werden und ein wohlgeformtes XML-Dokument darstellen müssen. Die Nutzdaten können beispielsweise Aufrufe oder Antworten eines entfernten Prozeduraufrufs sein oder im Falle eines Fehlers bei der Ausführung einer Prozedur einen SOAP Fault enthalten, das den Fehler beschreibt. Im Allgemeinen macht SOAP allerdings keine Vorgaben über den Aufbau des Inhaltes eines Body-Elementes, denn dieser kann durch die Web Service Description Language (siehe Kapitel 4.3.1) beschrieben werden. 53

54 Schemata Das vom W3C empfohlene Schema für SOAP ist unter oder zu finden Szenarien SOAP ist eine grundlegende Technologie zum Aufbau von verteilten Anwendungen. Typischerweise wird es verwendet, um lose gekoppelte Systeme zu realisieren. Dabei sind unterschiedliche Anwendungen möglich. SOAP erlaubt es, sowohl einfache entfernte Prozeduraufrufe (RPC) als auch hoch komplexe Nachrichtensysteme umzusetzen und kann mit verschiedenen Transportprotokollen (beispielsweise FTP, SMTP, HTTP, ) genutzt werden. In der Praxis wird aber in der Regel HTTP genutzt. Der klassische Einsatz von SOAP erfolgt beim Suchen eines Web Service in der Registry, bei der Kommunikation zwischen Consumer und Provider und beim Veröffentlichen eines Service durch den Provider. Die nachfolgende Abbildung verdeutlicht den Einsatz von SOAP im Umfeld von Web Services. R e g istry SO A P C o n su m e r P ro v id e r Abbildung 9: Klassische Verwendung von SOAP Empfehlung zur Anwendung Die Nutzung von SOAP ist empfehlenswert (1) im Umfeld von Web Services. Es ist ein Grundelement beim Aufbau einer SOA und wird auch in Zukunft ein wichtiger Standard für den Austausch von strukturierten Daten sein. 54

55 4.2.3 SOAP with Attachments (SwA) Definition SOAP with Attachments (SwA, SOAP mit Anhängen) bietet die Möglichkeit, SOAP Nachrichten mit unterschiedlichsten Anhängen zu versenden Grundlagen Die SwA Spezifikation definiert eine Möglichkeit, um Anhänge an eine SOAP Nachricht zu binden. Dazu werden MIME multipart/related Medientypen und Uniform Resource Identifiers für die Referenzierung von Teilen des MIME verwendet. MIME (Multipurpose Internet Mail Extensions) wird für die Deklaration von Inhalten in verschiedenen Internetprotokollen verwendet und ermöglicht die Übertragung von Daten in den verschiedensten Formaten. SwA ist ein Standard, der somit den Versand von beliebigen Daten unter Verwendung von SOAP ermöglicht. Das Konstrukt aus einer SOAP Nachricht im XML Format und einem Anhang (beispielsweise Binärdaten wie z.b. Bilder) wird auch SOAP message package genannt und als Multipart/Related MIME-Typ kodiert Schemata Für SwA existiert kein eigenständiges Schema. Stattdessen wird die SOAP Nachricht als Teil der durch MIME definierten Struktur übertragen. Ein Beispiel dazu findet sich im Anhang Szenarien SwA kommt zum Einsatz, wenn eine SOAP Nachricht mit einem beliebigen Anhang versendet werden soll. Diese Anhänge können textbasierte Dokumente wie XML Dateien sein oder binäre Daten wie beispielsweise Bilder oder Zeichnungen Empfehlung zur Anwendung Die Nutzung von SwA ist nicht empfehlenswert (4), da es nicht kompatibel zu WS-Security ist und damit ein Sicherheitsrisiko darstellt. Sobald man SOAP Nachrichten mit Anhängen verschicken möchte, sollten andere Methoden wie MTOM (siehe nächster Abschnitt) genutzt werden MTOM Definition MTOM (Message Transmission Optimization Mechanism) ist eine Methode, um das Übertragungsvolumen bei der SOAP Kommunikation zu optimieren, indem Teile der 55

56 Nachricht codiert werden. MTOM hat zur Zeit den Status einer W3C-Empfehlung und basiert auf XML Binary Optimized Packaging (XOP), das eine Methode spezifiziert, um XMLElemente mit beliebigem Inhalt in einem MIME-Anhang zu serialisieren Grundlagen Die Nutzdaten in SOAP Nachrichten sind wohlgeformte XML-Dokumente und damit zeichenkettenbasiert. Abhängig von der genutzten Zeichenkodierung stehen nur eine begrenzte Anzahl an Zeichen zur Verfügung. Binärdateien hingegen haben einen größeren Wertebereich als zeichenkodierte Formate und ermöglichen eine kompaktere Darstellung der Daten. Um Binärdateien mit SOAP Nachrichten zu übertragen, gibt es zwei unterschiedliche Konzepte: By value: Die Binärdaten werden in ein zeichenkettenbasiertes Format (z.b. Base64) umgewandelt und innerhalb eines Elementes der Nutzdaten versandt. Der Vorteil ist, dass die Binärdaten Teil der Nutzdaten sind und das XML-Dokument immer noch gültig ist. Nachteil ist der relativ hohe Speicherbedarf (bei Base64 sind beispielsweise für 4 Zeichen 3 Byte erforderlich, so dass eine rund 33% größere Datenmenge bei der Kodierung von Binärdaten verursacht wird). By reference: Die Binärdaten werden, ohne deren Umwandlung, als MIME-Attachment mit der Nachricht versandt. Zusätzlich wird eine Referenz auf den Anhang als Element oder Attribut in das XML-Dokument eingebettet. Der Vorteil dieser Vorgehensweise liegt in der kompakten Darstellung der Daten. Der Nachteil ist, dass die Nutzdaten nicht Teil des XMLDokumentes sind und bestimmte Protokolle sowie Verfahren, die auf XML-Dokumenten operieren möglicherweise nicht mehr anwendbar sind. MTOM versucht die beiden Konzepte zu verschmelzen. Dazu werden die binären Daten per MIME-Attachment übertragen ( by reference ). Zur Referenzierung wird das Element <include> der XML Binary Optimized Packaging (XOP) Spezifikation verwendet. Das Element verweist durch Globally Unique Identifier (GUID) auf das MIME-Attachment. Dies ermöglicht der Software, welche das Dokument verarbeitet, den Anhang logisch im XMLDokument als Base64-Wert ( by value ) erscheinen zu lassen. Beispielsweise kann eine Signatur der SOAP Nachricht somit einfach den Anhang mit einschließen. Durch den Versand von Binärdateien mit MTOM werden schon bei Datenmengen mit mehr als Tausend Bytes kleinere Nachrichten erzeugt Schemata Das Schemata für <include> findet sich unter Szenarien Der Einsatz von MTOM erfolgt immer dort, wo größere Binärdateien, wie z.b. AudioDateien, Videos oder Fotos, mit SOAP Nachrichten verschickt werden. Dies ist auch mit SOAP with Attachments (SwA) möglich, allerdings setzt SwA nur das Konzept by reference um, wodurch die oben beschriebenen Nachteile entstehen. Ein weiterer Vorteil von MTOM gegenüber SwA ist seine Rückwärtskompatibilität. Das bedeutet, dass MTOMEndpunkte sowohl MTOM als auch SwA, dagegen SwA-Endpunkte nicht mit MTOM optimierte Nachrichten verarbeiten können. 56

57 Empfehlung zur Anwendung Der Einsatz von MTOM ist empfehlenswert (1), da der Austausch von Binärdateien in der Zukunft weiter zunehmen wird. Zudem steigt, durch die verbesserte Technik im Bereich der digitalen Medien, die Größe von Binärdateien immer weiter an. Vor diesem Hintergrund ist die Entwicklung von MTOM und anderen Mechanismen zur Reduzierung der Nachrichtengröße weiter zu beachten. 4.3 Dienste beschreiben und auffinden Die nun folgenden Abschnitte beschäftigen sich mit den Themen WSDL, UDDI, WS-Inspection, WS-Discovery, WS-Policy, WS-PolicyAssertion, WS-PolicyAttachment und WS-MetadataExchange WSDL Definition Die Web Services Description Language (WSDL) ist eine auf XML-basierende Sprache zur plattform-, sprach- und protokollunabhängigen Beschreibung von Netzwerkdiensten (Web Services). Die Entwicklung von WSDL wurde von den Unternehmen IBM, Microsoft und Ariba initiiert. Im Juni 2007 wurde die aktuelle Version 2.0 zur W3C Empfehlung Grundlagen WSDL ermöglicht die XML-basierte Beschreibung eines Dienstes als einen Satz von Endpunkten mit einer Menge von Operationen, die ein Client unter einer durch die Dienstbeschreibung spezifizierten Adresse ausführen kann. Zu jeder Operation können die eingehenden und ausgehenden Daten (Nachrichten), Fehlernachrichten und ein MessageExchange-Pattern spezifiziert werden. WSDL-Dokumente sind hierarchisch aufgebaut, wobei das Wurzelelement eines WSDL-2.0-Dokuments das <description>-element ist, das alle notwendigen Namensräume definiert und die restlichen Elemente kapselt. Um eine Wiederverwendbarkeit von Teilen der WSDL-Beschreibung zu ermöglichen, ist das Dokument in einen abstrakten und konkreten Teil gegliedert. 57

58 Abstrakte WSDL- Definition: Der abstrakte Teil einer WSDL Beschreibung definiert unabhängig von dem Service ein abstraktes Interface mit einem Satz von Operationen. Für mögliche eingehende Nachrichten, ausgehende Nachrichten und Fehlernachrichten einer Operation legt der abstrakte Teil zudem die Datentypen fest. Die abstrakte Definition besteht aus folgenden Elementen: <interface>: Dieses Element repräsentiert ein abstraktes Interface, das aus einem Satz von Operationen besteht und durch die konkrete WSDL-Beschreibung als Web Service angeboten werden kann. <operation> : Eine Operation beschreibt eine Aktion, die vom Service unterstützt wird und besteht immer aus einer Kombination aus einer eingehenden (<input>) und einer ausgehenden (<output>) Nachricht. Zudem kann für jede Operation ein Message-Exchange-Pattern definiert werden. <types>: Definiert ein XML-Schema zur Beschreibung der Nachrichten, die über die Input- und Outputelemente an eine Operation gebunden sind. Konkrete WSDL-Definition: Im konkreten Teil werden für einen Dienst die Erreichbarkeit über das Netzwerk, das Protokoll, sowie die Art der Datenserialisierung und Codierung spezifiziert. Die konkrete WSDL-Definition besteht aus folgenden Elementen: <service>: Definition der Kommunikationsendpunkte (<endpoints>) für die Interfaces der abstrakten WSDL-Definition, d.h. die Beschreibung unter welcher URL auf die Funktionen des Web Service zugegriffen werden kann. <binding> : Dieses Element legt das zu verwendende Transportprotokoll und die Kodierung der Daten fest. Es bestimmt somit, wie auf den Service zugegriffen wird. Message-Exchange-Pattern: Für jede Operation eines Interfaces im abstrakten Teil der WSDL 2.0 Spezifikation kann ein Message Exchange Pattern (MEP) spezifiziert werden. Ein Message-Exchange-Pattern spezifiziert die Reihenfolge und die Kardinalität der Nachrichten einer Operation. Die vordefinierten MEPs sind der nachfolgenden Tabelle zu entnehmen. 58

59 MEP Beschreibung Fehlerbehandlung in-only Es werden nur Nachrichten empfangen. No Fault robust-in-only Es werden nur Nachrichten empfangen, außer im Fehlerfall. Message Triggers Fault in-out Einer eingehenden Nachricht folgt eine ausgehende Nachricht. Fault Replaces Message in-optional-out Einer eingehenden Nachricht folgt optional eine ausgehende Nachricht. Message Triggers Fault out-only Es werden nur Nachrichten gesendet. No Fault robust-out-only Es werden nur Nachrichten gesendet, außer im Fehlerfall. Message Triggers Fault out-in Einer ausgehenden Nachricht folgt eine eingehende Nachricht. Fault Replaces Message out-optional-in Einer ausgehenden Nachricht folgt optional eine eingehenden Nachricht. Message Triggers Fault Tabelle 1: Beschreibung der MEPs und ihre Fehlerbehandlung Neben der Reihenfolge und Kardinalität der Nachrichten definiert ein Message-ExchangePattern die Art des Nachrichtenaustauschs, wenn bei der Ausführung einer Operation ein Fehler auftritt. Hierfür sind drei Standardfälle definiert. No Fault: Es wird keine Fehlernachricht versendet. Fault Replaces Message: Hierbei kann jede Nachricht durch eine Fehlernachricht in gleicher Richtung ersetzt werden. Dabei ist Voraussetzung, dass im Normalfall eine Nachricht gesendet wird, die durch eine Fehlernachricht ersetzt werden kann. Message Triggers Fault: Definiert, dass jede Nachricht eine Fehlernachricht in entgegengesetzter Richtung auslösen kann. Dies bedeutet, dass im Normalfall keine Nachricht gesendet wird Schemata Das Schema für WSDL findet sich unter Szenarien Eine WSDL-Beschreibung ermöglicht einem Dienst, sich selbst zu beschreiben. Diese Beschreibung erlaubt zudem eine automatische Generierung und Konfiguration der Software auf Seite des Clients, um den Dienst aufzurufen. Nachfolgend wird ein klassisches Beispiel für den Einsatz von WSDL beschrieben, um ein Late-Service-Binding zu realisieren. Ein Consumer sucht in einem Service Repository nach einem geeignetem Service, z.b. für das Abrufen von Aktienkursen. Die Beschreibung des Web Service erhält der Consumer in Form eines WSDL-Dokuments. Durch dieses Dokument kennt er die Adresse, unter welcher der Dienst aufgerufen werden kann, sowie die dazu 59

60 erforderlichen Parameter, um den Dienst korrekt anzusprechen. Mit Hilfe von SOAP kann der Consumer die in dem WSDL-Dokument definierten Funktionen aufrufen Empfehlung zur Anwendung Der Einsatz von WSDL ist empfehlenswert (1), da die Sprache eine einfache und standardisierte Möglichkeit bietet, Web Services zu beschreiben. Daher wird WSDL auch in Zukunft eine wichtige Technologie im SOA-Umfeld darstellen UDDI Definition UDDI (Universal Description Discovery and Integration) ist eine von der OASIS standardisierte und definierte Methode zum Veröffentlichen und Auffinden von netzwerkbasierten Softwarekomponenten einer Service-orientierten Architektur (SOA). UDDI stellt einen Verzeichnisdienst dar, der öffentlich oder auch nur innerhalb von Organisationen bereitgestellt werden kann und einen standardisierten Mechanismus zum Klassifizieren, Katalogisieren und Verwalten von Web Services bietet. Diese im Verzeichnisdienst registrierten Web Services können demzufolge gefunden und von anderen Anwendungen genutzt werden [UDDI] Grundlagen UDDI stellt einen Verzeichnisdienst dar, in dem Unternehmen ihre angebotenen Dienste durch Dateien im XML-Format beschreiben können. Es handelt sich bei den Dateien konkret um WSDL-Dokumente, die insbesondere eine Definition der SOAP-Schnittstelle zu einem Web Service enthalten. Interessenten können so einen Service im Verzeichnis finden und mit Hilfe der WSDL-Beschreibung nutzen. Bei UDDI kann zwischen vier Arten von Informationen unterschieden werden. White Pages, Yellow Pages und Green Pages enthalten öffentliche Business-Informationen über den Dienstleister und die Services. Service Type Registrations hingegen geben die technischen Angaben zu einem Service preis. Kategorien von Informationen White Pages: Stellen Informationen über den Serviceanbieter bereit. Unter anderem beinhaltet ein Eintrag Kontaktinformationen, Organisationsinformationen und eine weltweit eindeutige Unternehmenskennzahl. Yellow Pages: Services werden nach Geschäftsfeldern auf Basis von Standardtaxonomien wie dem North American Industry Classification System kategorisiert. Es werden allgemeine Angaben über die angebotenen Dienste gemacht. Green Pages: Der Service und seine Prozesse werden beschrieben. Dies ermöglicht den Dienstnutzern das Suchen nach Services ohne Wissen der Branche oder über den Dienstleister. 60

61 Service Type Registrations: Enthalten technische Detailinformationen der angebotenen Dienste, die es dem Nutzer ermöglichen, eine Anwendung zur Verwendung des Web Service zu erstellen. Datenmodell von UDDI Das Datenmodell von UDDI beinhaltet fünf Kernelemente, die die Struktur eines Verzeichniseintrages definieren: BusinessEntity: Beschreibt den Web Service-Anbieter. BusinesService: Enthält eine Liste aller angebotenen Dienste eines Unternehmens. BindingTemplates: Beschreibt die technischen Details eines Web Service und die erforderlichen Informationen zum Aufruf des Dienstes. tmodels: Erlauben die Registrierung von Informationen zur technischen Schnittstelle/Spezifikation eines Service (bzw. stellen eine Referenz oder Art Fingerabdruck für eine technische Schnittstelle dar) und ermöglichen somit die einfache Identifizierung von kompatiblen Diensten. Unternehmen, die eine bestimmte Software einsetzen, können somit Dienste mit Schnittstellen identifizieren, die von Hause aus von der Software unterstützt werden. PublishersAssertion: Beschreibt Beziehungen zwischen Parteien. Technische Realisierung UDDI baut auf verschiedenen anerkannten Standards im Bereich der Webtechnologien auf, u.a. HTTP, XML, XML-Schema, SOAP und WSDL. Die konzeptionelle Beziehung zwischen UDDI und den einzelnen Standards bzw. Protokollen wird in der nachfolgenden Abbildung veranschaulicht: 61

62 Abbildung 10: Verhältnis von UDDI zu anderen Protokollen und Standards im Web Service-Umfeld [UDDI] Schemata Das Schema für UDDI ist unter zu finden Szenarien Nachfolgend wird ein typisches Anwendungsszenario für UDDI zusammen mit SOAP und WSDL beschrieben. Ein Service-Anbieter möchte einen von ihm umgesetzten Dienst, z.b. Abfrage von Wetterinformationen, anbieten. Dabei spielt es keine Rolle, auf welcher Plattform und mit welcher Programmiersprache der Dienst implementiert wurde. Der Anbieter erstellt eine WSDL-Beschreibung und veröffentlicht sie in einem UDDIVerzeichnis. Dabei muss es sich nicht zwangsläufig um ein öffentliches Verzeichnis handeln. Der Einsatz von UDDI kann auch innerhalb eines Unternehmens oder zwischen definierten Partnern erfolgen. Ein Consumer kann diesen Service im UDDI-Verzeichnis suchen und nutzen. Möchte bspw. ein Portalbetreiber Informationen über das aktuelle Wetter anbieten, kann er nach einem entsprechenden Dienst im UDDI-Verzeichnis suchen und den Service mittels der WSDLBeschreibung in sein Portal einbinden. Die WSDL-Beschreibung liefert in diesem Zusammenhang die notwendigen Informationen und Parameter zum ordnungsgemäßen Aufruf und Gebrauch des Dienstes. Wollen Besucher der Portalseite Informationen über das Wetter abfragen, dann werden die Anfragen per SOAP an den Service Provider weitergeleitet und der Portalbetreiber erhält die benötigten Informationen per SOAP-Response direkt vom Web Service. 62

63 Empfehlung zur Anwendung Das Veröffentlichen von WSDL-Beschreibungen in UDDI-Verzeichnissen wird empfohlen (1), da es eine einfache Möglichkeit ist, seinen Dienst für Dritte zugänglich zu machen WS-Inspection Definition WS-Inspection oder WS-Inspection Language (WSIL) ist wie UDDI eine Spezifikation zum Auffinden von Web Services und wurde von IBM und Microsoft entwickelt. Der Standard wurde 2001 erstmals veröffentlicht und im Januar 2007 aktualisiert. Während UDDI auf wenige dezentrale Verzeichnisse setzt, werden mittels WS-Inspection vornehmlich viele dezentrale kleine Verzeichnisse geschaffen, in denen wenige Anbieter (häufig auch nur ein einzelner Anbieter) ihre Dienste registrieren. Zur Realisierung relativ einfach aufzubauender Verzeichnisstrukturen definiert die WS-Inspection Spezifikation ein XML-Format und entsprechende Regeln. Das jeweilige WS-Inspection Dokument, das Referenzen auf bereits bestehende Dienstebeschreibungen aggregiert, wird vom Diensteanbieter über seinen Webserver bereitgestellt. WS-Inspection stellt des Weiteren einen Mechanismus bereit, mit dem existierende Verzeichnisse referenziert werden können, so dass ein Duplizieren von Informationen nicht nötig ist [WS-Inspection] Grundlagen Allgemein verfolgt WS-Inspection das Ziel möglichst einfach, aber dennoch erweiterbar zu sein. D.h. einerseits soll das Verfassen und Verwalten von WS-Inspection Dokumenten einfach sein und zum anderen sollen neue Referenzen auf ggf. neue Beschreibungsformate ohne Kompatibilitätsprobleme hinzugefügt werden können. Ein potentieller DiensteConsumer, der das WS-Inspection Dokument aufruft, soll in der Lage sein, zwischen den verfügbaren Beschreibungen die passende Dienstebeschreibung auszuwählen, die auch von ihm verstanden wird. Die wichtigsten Informationen eines WS-Inspection Dokuments befinden sich innerhalb des service -Elements bzw. in dessen Unterelement description. An dieser Stelle werden Referenzen auf jegliche Art von Dienstebeschreibungen angegeben. Typischerweise handelt es sich dabei um WSDL Dokumente, da WSDL als Beschreibungssprache für Web Services momentan am weitesten verbreitet ist. Es müssen jedoch nicht zwangsläufig WSDL-Dateien sein, auch andere Beschreibungen und zukünftig neue Formate können referenziert werden. Über das link -Element kann auf weitere Inspection Dokumente oder UDDI Repositories verwiesen werden. Durch diesen Mechanismus wird erreicht, dass Betreiber von UDDIVerzeichnissen keine WS-Inspection Dokumente separat erstellen bzw. Informationen dupliziert werden müssen. Nachfolgend wird die Syntax und Struktur eines WS-Inspection Dokuments veranschaulicht [WS-Inspection]: <wsil:inspection> <wsil:abstract xml:lang=""?... /> * <wsil:service> * 63

64 <wsil:abstract xml:lang=""?... /> * <wsil:name xml:lang=""?... /> * <wsil:description referencednamespace="uri" location="uri"?> * <wsil:abstract xml:lang=""?... /> * <-- extensibility element -->? </wsil:description> </wsil:service> <wsil:link referencednamespace="uri" location="uri"?/> * <wsil:abstract xml:lang=""?... /> * <-- extensibility element -->? </wsil:link> </wsil:inspection> Aus allgemeiner technischer Sicht greift ein potentieller Service Consumer mittels des HTTPProtokolls auf das WS-Inspection Dokument eines ihm bekannten Service-Providers zu und erhält somit eine Liste mit Web Services und Dienstebeschreibungen. Für das Auffinden von WS-Inspection Dokumenten sind zwei verschiedene Möglichkeiten üblich: Nutzung von inspection.wsil an den Haupteinstiegspunkten eines Web-Servers Verweis auf WS-Inspection-Dokumente innerhalb von HTML-Seiten Schemata Ein Standard-Schema ist unter zu finden Szenarien In dem Szenario zu WS-Inspection arbeiten ein Web Service Provider und ein Web Service Nutzer bereits zusammen und kennen sich. Der Provider hat das Ziel, Details zur Benutzung seiner Dienste zu veröffentlichen. Dazu legt er eine Datei inspection.wsil in das Root-Verzeichnis seines Webservers, so dass dieses Dokument unter aufgerufen werden kann. Diese Datei erhält nun die Verweise auf Beschreibungen aller Web Services, die der Provider anbietet. Der Web Service Nutzer kann nun die Beschreibungen der Web Services nachschlagen und aufrufen Empfehlung zur Anwendung WS-Inspection stellt eine einfache Möglichkeit zum Auffinden von Diensten bereit, insbesondere wenn die Nutzung eines Zentralen UDDI-Verzeichnisses keine Alternative darstellt. Daher wird die Nutzung dieser Spezifikation angeregt (2). 64

65 4.3.4 WS-Discovery Definition WS-Discovery ist eine Spezifikation, die ein Auffinden von Web Services ermöglicht. Es definiert ein Multicast Protokoll, das ein dynamisches Auffinden von Web Services in adhocund kontrollierten, lokalen Netzen ermöglicht. Ein zentraler Verzeichnisdienst ist somit bei Verwendung von WS-Discovery nicht notwendig. Die Kommunikation zwischen den Services und Clients erfolgt mit Hilfe von Web Service Standards, insbesondere durch den Einsatz von SOAP Nachrichten [WS-Discovery] Grundlagen Im Unterschied zu UDDI und WS-Inspection, die jeweils auf unterschiedliche Weise Verzeichnisstrukturen bereitstellen, verfolgt WS-Discovery einen anderen Ansatz zum Auffinden von Web Services. WS-Discovery stellt einen Mechanismus bereit, mit dem Clients Web Services innerhalb von Netzwerken dynamisch auffinden können. D.h. es sind keine Anfragen an Verzeichnisdienste nötig, in denen Web Services zuvor registriert sein müssen. WS-Discovery wurde von BEA Systems, Canon, Intel, Microsoft und WebMethods entwickelt. Der folgende Prozess verdeutlicht die Funktionsweise von WS-Discovery (vgl. [WSDiscovery]). Dabei ist das primäre Ziel, dass der Client den Web Service (Ziel-Service), der innerhalb des jeweiligen Netzes zur Verfügung steht, wirklich findet. Zum einen kann ein Client durch kurze Nachrichten innerhalb eines Netzwerkes nach einem bestimmten Dienst fragen und eine Antwort von einem passenden Dienst erhalten. Zum anderen informiert ein Dienst eine bestimmte Gruppe von potentiellen Clients, sobald er im Netzwerk bereitsteht. Durch diese Benachrichtigung seitens des Dienstes, kann der Netzwerkverkehr reduziert werden, da die Clients über die Verfügbarkeit des jeweiligen Dienstes informiert sind und keine Testanfragen mehr stellen müssen (Verhinderung des kontinuierlichen Pollings). 65

66 Abbildung 11: Nachrichtenkommunikation bei WS-Discovery [WS-Discovery] 1. Sobald ein Web Service (Ziel-Service) das Netzwerk betritt, wird ein MulticastHello gesendet. Multicast bedeutet, dass der Web Service eine Nachricht zu einer Vielzahl von Clients sendet, um jeden möglichen Nutzer des Web Service zu benachrichtigen. 2. Der Ziel-Service kann des Weiteren zu jeder Zeit ein Multicast-Probe erhalten. Unter Probe versteht man in diesem Zusammenhang eine bestimmte Art von Nachricht, die zum Auffinden von Diensten im Netzwerk gesendet wird (bzw. Testanfrage ob ein geeigneter Dienst vorhanden ist). 3. Befindet sich ein passender Ziel-Service im Netzwerk, so sendet dieser an den anfragenden Client eine Nachricht zurück, die ihm signalisiert, dass er einen passenden Dienst gefunden hat (Unicast Probe Match). Ggf. existieren mehrere zutreffende Dienste im Netz, so dass ein Client mehrere positive Antworten erhält. 4. Ein Ziel-Service kann außerdem jederzeit ein Multicast-Resolve empfangen. Ein Resolve ist ein Nachrichtentyp, mit dem ein bestimmter Dienst anhand eines Namens lokalisiert werden soll. 5. Der Ziel-Service schickt ein Unicast-Resolve Match (RM), eine Nachricht, die bestätigt, dass es sich um den richtigen Service handelt. 6. Sobald der Ziel-Service das Netzwerk verlässt, schickt er ein Multicast-Bye, damit die Clients wissen, dass dieser Service nicht weiter zur Verfügung steht. Um den Netzwerkverkehr bei vielen Endpunkten (Client und Server) zu minimieren, besteht die Möglichkeit, einen sog. Discovery Proxy zu verwenden. Falls dieser eine Testanfrage 66

67 (Probe) seitens eines Clients entdeckt, schickt der Proxy eine spezielle Nachricht, die den Clients das Vorhandensein des Proxys signalisiert. Die jeweiligen Clients stellen daraufhin auf ein Discovery Proxy spezifisches Protokoll um, so dass eine effizientere Nachrichtenkommunikation stattfinden kann. WS-Discovery trägt durch seine Funktion allgemein dazu bei, dass Web Services schnell gefunden werden, ist jedoch auf andere Standards und Spezifikationen angewiesen, um ein gewisses Sicherheitsniveau zu garantieren Schemata Ein Standard-Schema ist unter zu finden Szenarien WS-Discovery wird bereits in heutigen Systemen wie z.b. dem Betriebssystem Microsoft Windows Vista verwendet. Die Anwendung People Near Me nutzt WS-Discovery um befreundete Personen im selben Netzwerk zu finden und um mögliche gemeinsame Aktivitäten durchzuführen. Neben den bereits erwähnten Aufgaben kann WS-Discovery u.a. genutzt werden, um Services nach Typ und Anwendungsbereich auffindbar zu machen, erreichbare Services zu lokalisieren und somit tragbaren Geräten (Hand-Helds, Pocket PC, usw.) diesen Dienst auf einfache Weise zur Verfügung zu stellen und den Übergang zwischen Adhoc- und Managed-Networks zu vereinfachen Empfehlung zur Anwendung Obwohl sich WS-Discovery noch im Entwurfsstadium befindet, wird die Nutzung dieser Spezifikation angeregt (2). Durch die Verwendung von WS-Discovery können Web Services schnell lokalisiert werden. Es ist jedoch zu berücksichtigen, dass diese Spezifikation keine Anforderungen in Bezug auf die Sicherheit der Endpunkte (Dienste und Clients) stellt WS-Policy Definition Der W3C Standard WS-Policy definiert eine Syntax, um Anforderungen auszudrücken, die sich auf die nachrichtenbasierte Kommunikation zwischen Service Consumer und Web Services beziehen. Dazu definiert WS-Policy eine allgemeine XML-Struktur, um Anforderungsalternativen als eine Reihe von einfachen oder verschachtelten und/oderverknüpfungen zu definieren. Das konkrete Vokabular zur Definition der Alternativen ist Teil von domänenspezifischen Spezifikationen, wie WS-SecurityPolicy oder WSPolicyAssertion. 67

68 Grundlagen WS-Policy wurde in der Version 1.0 erstmals 2002 von BEA Systems, IBM, SAP, Microsoft und weiteren Firmen veröffentlicht. Nachdem 2004 die Version 1.2 veröffentlicht wurde, liegt der Standard seit 2007 in der Version 1.5 als W3C Empfehlung vor. Die Grundidee der Definition von Anforderungen mit WS-Policy ist die Formulierung von Alternativen für die Nutzung eines Web Service. Der Web Service-Client und der Web Service selbst stellen in ihrer WS-Policy mögliche Alternativen bereit, wie die Nachrichten, die gesendet und empfangen werden, strukturiert sein sollen. Möchte ein Client auf einen Dienst zugreifen, dann muss der Client zunächst die WS-Policy vom Service abrufen, die Anforderungsalternativen mit den Alternativen in seiner eigenen Policy abgleichen und eine Alternative für den Dienstaufruf verwenden, die vom Client und vom Dienst unterstützt wird. Um dies zu ermöglichen, spezifiziert WS-Policy die Formulierung der Anforderungsalternativen und einen Algorithmus, um zwei Policies abzugleichen. Definition der Anforderungsalternativen WS-Policy spezifiziert eine XML-Struktur, um Anforderungsalternativen auszudrücken, die aus einzelnen Alternativen (sog. Assertions) bestehen. Eine Assertion definiert einen Satz an Aussagen und repräsentiert eine individuelle Präferenz, eine bestimmte Anforderung, eine bestimmte Fähigkeit oder eine andere Eigenschaft des Verhaltens. Die Definition der Assertions selbst ist nicht Teil von WS-Policy und wird durch domänenspezifische Spezifikationen beschrieben. Beispielsweise definiert WS-SecurityPolicy Assertions, um Sicherheitsanforderungen auszudrücken. Das Wurzelelement einer Policy stellt das Tag <wsp:policy> dar, das folgende XMLElemente enthalten kann, die zur Gruppierung der Assertions genutzt werden: <wsp:all> : definiert, dass alle darin enthaltenen Assertions oder gruppierte Assertions erfüllt sein müssen. <wsp:exactlyone> : definiert, dass von den enthaltenen Assertions oder gruppierten Assertions genau eine erfüllt sein muss. <wsp:oneormore> : definiert, dass von den enthaltenen Assertions oder gruppierten Assertions mindestens eine erfüllt sein muss. Diese Elemente lassen sich beliebig verschachteln. Zudem können auch andere WS-Policies mittels des Tags <wsp:policyreference> referenziert und als Gruppierung von Assertions eingebunden werden. Abgleich der Policyalternativen Um einem Web Service-Client einen Abgleich seiner Policy mit einer Policy eines Dienstes zu ermöglichen, spezifiziert WS-Policy einen Algorithmus, um zwei Policies zu vergleichen und die Schnittmenge der gemeinsam unterstützten Assertions zu ermitteln. Der Abgleich ist möglich, ohne dass die Semantik der einzelnen Assertions bekannt sein muss. Verwendung von WS-Policy WS-Policy liefert also eine einheitliche Policy-Grammatik, um alle Anforderungsalternativen in einer konsistenten Art und Weise auszudrücken. Um WS-Policy allerdings in einem Web Service Szenario verwenden zu können, haben die folgenden Spezifikationen noch ergänzende Funktion: 68

69 WS-MetadataExchange: spezifiziert ein Protokoll zum Abruf von Metadaten über einen Web Service-Endpunkt. Dies ermöglicht dem Client, die WS-Policy von einem Service vor dem Aufruf des eigentlichen Dienstes abzurufen. WS-PolicyAttachment: ermöglicht eine Policy mit einem Web Service zu verknüpfen. Dabei kann sich eine Policy auf verschiedene Teile eines Dienstes beziehen (das sog. Policy Subject), wie beispielsweise eine Operation eines Dienstes, einen Endpunkt oder den Web Service selbst. Die folgende Darstellung verdeutlicht, wie mit Hilfe von WS-PolicyAttachment eine Policy, die mehrere Policy Assertions beinhalten kann, an ein Subject (in diesem Fall ein Web Service) gebunden wird. Abbildung 12: Darstellung der Zusammenhänge zwischen WS-Policy und WSPolicyAttachment[WSPO] Schemata Das Schema für WS-Policy in der Version 1.5 ist unter zu finden Szenarien In einem konkreten Szenario ermöglicht WS-Policy Web Service-Anbietern und Servicenutzern Anforderungen, die sich beispielsweise aus Sicherheitsrichtlinien oder einem bestimmten Anwendungsfall ergeben, an den Nachrichtenaustausch zu stellen. Während WSDL beschreibt, welches Interface ein Dienst bietet, beschreibt WS-Policy, welche Anforderungen der Dienst an die Kommunikation stellt. Der Nutzer eines Dienstes kann mittels WS-MetadataExchange eine Policy abrufen, die Schnittmenge der gemeinsam unterstützten Assertions ermitteln und dementsprechend die Nachrichtenkommunikation gestalten. Der Service wiederum kann eingehende Nachrichten auf Konformität mit seiner eigenen Policy prüfen. 69

70 Empfehlung zur Anwendung Die Verwendung von WS-Policy und den damit verknüpften Spezifikationen zur Formulierung einer Policy für einen Service ist empfehlenswert (1), da es sich als de-facto Standard durchgesetzt hat. Ebenso essentiell wie die Policy sind Mechanismen, welche sicherstellen, dass die Policy auch eingehalten wird. Hierbei ist darauf zu achten, dass die Policies bzw. mindestens eine Alternative durchgesetzt werden können, damit der Web Service Client und der Web Service-Nutzer miteinander kommunizieren können WS-PolicyAssertion Definition WS-PolicyAssertion definiert einen Satz an Policy-Assertions für die Verwendung in WSPolicy, die allgemeine Aussagen hinsichtlich Sprachoptionen, Kodierungsanforderungen, zu unterstützenden Protokollversionen und das Vorhandensein bestimmter Nachrichtenteile definieren. Diese Aussagen bilden das Vokabular, das in Verbindung mit WS-Policy die Policy eines Dienstes oder eines Service-Consumers beschreiben kann Grundlagen Die Spezifikation WS-PolicyAssertion wurde von BEA Systems, IBM, Microsoft, SAP und weiteren Mitgliedern des W3C entwickelt und veröffentlicht. Sie basiert auf dem Web Service Policy Framework (WS-Policy) und definiert einen Satz von Assertions für WS-Policy. Das WS-Policy Framework selbst stellt im wsp Namensraum vier grundlegende Assertions bereit: <wsp:textencoding> : Spezifiziert die Kodierung der genutzten Zeichen (z.b. utf-8) <wsp:language>: Spezifiziert die genutzte Sprache (z.b. en für Englisch oder en-gb für British English) <wsp:specversion> : Spezifiziert die Version einer bestimmten Spezifikation (z.b. die Nutzung von SOAP Version 1.1) <wsp:messagepredicate> : Spezifiziert eine Eigenschaft, die eine Nachricht haben kann und gegen die die Nachricht getestet werden kann (z.b. es muss exakt ein Security Header vorhanden sein) Schemata Ein Schema für WS-PolicyAssertion ist unter zu finden Szenarien Durch WS-PolicyAssertion kann beispielsweise bestimmt werden, dass 70

71 die natürliche Sprache Deutsch verwendet werden soll, die Texte in UTF-16 kodiert sind oder nur ein Satz von aktuellen Web Service-Spezifikationen zur Anwendung kommt Empfehlung zur Anwendung WS-PolicyAssertion stellt einen Standardsatz von Aussagen für Web Service Policies bereit, insbesondere für Sprachoptionen, Kodierungsanforderungen, Protokollversionen und das Vorhandensein bestimmter Nachrichtenteile. Die Verwendung von WS-PolicyAssertion ist dann empfohlen (1), wenn derartige Aussagen für einen Web Service getroffen werden sollen und es in Verbindung mit WS-Policy eingesetzt wird WS-PolicyAttachment Definition WS-PolicyAttachment ist eine Spezifikation, die definiert, in welcher Form Policies mit bestehenden Web Services verknüpft werden können. Sie ermöglicht die Bindung einer Policy an die Web Service Beschreibung (WSDL) oder die Ablage in einer Registry (UDDI), damit der Web Service Client diese auch abrufen und mit der Policy der Gegenseite vergleichen kann Grundlagen Die WS-PolicyAttachment Spezifikation wurde von BEA Systems, IBM, Microsoft, SAP und weiteren Mitgliedern des W3C entwickelt und veröffentlicht. W3C pflegt diese Spezifikation weiter und empfiehlt die Nutzung in Verbindung mit dem WS-Policy Framework in der jeweils passenden Version wurde die Spezifikation in der Version 1.5 herausgegeben. WS-PolicyAttachment ist ein Teil des Web Service Policy Frameworks (WS-Policy) und definiert eine XML-basierte Syntax, um Policies in WSDL-Dateien einzubetten oder durch UDDI abzufragen. Diese können dabei entweder direkt innerhalb eines Elements deklariert werden, auf das sie sich beziehen oder referenziert werden. WS-PolicyAttachment definiert, wie sich Policies auf Elemente innerhalb einer WSDL Definition beziehen sollen, wie Policies mit Web Service Endpunkten assoziiert werden können und wie Policies mit UDDI Entitäten assoziiert werden können. Die folgende Darstellung zeigt die Einbindung von Policies in ein WSDL-Dokument: 71

72 Abbildung 13: Einbindung von Policies in ein WSDL-Dokument [WSPAtt] Innerhalb einer WSDL gibt es eine abstrakte und eine konkrete Definition, in denen jeweils mehrere Ebenen definiert werden. Bei vier dieser Ebenen (Service Policy Subject, Endpoint Policy Subject, Operation Policy Subject und Message Policy Subject) ist es möglich, eine Policy, die die Anforderungen dieser Ebene beschreibt, anzuhängen. Diese Ebenen sind in Abbildung 13 dargestellt. Alternativ gibt es die Möglichkeit, Policies im UDDI Registry zu hinterlegen, so dass der Web Service auf eine extern gespeicherte Policy referenzieren kann oder Policies mit Hilfe von WS-MetadataExchange abzufragen Schemata Das Schema für WS-PolicyAttachment in der Version 1.5 ist unter zu finden Szenarien WS-PolicyAttachment wird dazu verwendet, die Service Policy mit der Beschreibung über einen Service zu verbinden. In diesem Szenario erhält der Web Service Client eine Policy, die mit Hilfe von WS-PolicyAttachment in WSDL eingebettet wurde. 72

73 Abbildung 14: Einbettung einer Policy mit verschiedenen Assertions in ein WSDLDokument Empfehlung zur Anwendung WS-PolicyAttachment wird empfohlen (1) als mögliche Alternative zur Verwendung eines separaten Metadata-Service, über den z.b. die Policy eines Dienstes abgerufen werden könnte. Im Gegensatz zu WS-MetadataExchange, welches nur eine recht einfache Möglichkeit bietet, Policies abzurufen, bietet WS-PolicyAttachment die Möglichkeit, Policies in einem zentralen UDDI-Verzeichnis an die UDDI Beschreibung zu binden, so dass sie von dort abgerufen werden können WS-MetadataExchange Definition WS-MetadataExchange spezifiziert ein sehr einfaches Protokoll zum Abrufen von Metadaten eines Web Service. Metadaten sind alle Daten, die ein Web Service Client zum Aufruf eines Web Service benötigt, wie WSDL Definitionen, Policy Dateien, XSD Schemata oder auch Service-Level-Agreements. WS-MetadataExchange baut dabei auf die Spezifikation WSTransfer auf Grundlagen WS-MetadataExchange ist eine von BEA Systems, IBM, Microsoft und SAP entwickelte Spezifikation, um Metadaten zu kapseln und standardisiert abzurufen. Der Abruf von Metadaten vor dem eigentlichen Serviceaufruf macht einen Service Consumer unabhängig von einem bestimmten Anbieter, da er alle Informationen zum Aufrufen des Service ad-hoc in einem standardisierten Format abfragen und darauf aufbauend die Clientsoftware automatisch konfigurieren kann. Zudem bewahrt es die Unabhängigkeit der Dienste und unterstützt die Eigenschaft von Diensten selbstbeschreibend zu sein. 73

74 Metadaten geben z.b. Aufschluss über den Inhalt bzw. die Struktur von Nachrichten, die ein Web Service erwartet (XML Schema) die zum Aufruf des Service nutzbaren Netzwerkprotokolle und die Endpunktadressen des Service (WSDL) die Anforderungen, die ein Web Service an den Aufruf und die ausgetauschten Nachrichten stellt (WS-Policy) Abbildung 15: Struktur eines GetMetaData Aufrufs mit WS-MetadataExchange WS-MetaDataExchange definiert ein einfaches Anfrageprotokoll, um diese Metadaten abzurufen. Dazu sendet der Anfragende einen GetMetaData Request an den Serviceendpunkt. Innerhalb dieses Request-Elementes kann durch die Angabe eines Dialect-Elementes die Art der angeforderten Metadaten spezifiziert werden. Die WSMetadataExchange Spezifikation definiert dazu die folgenden URI-Werte um verschiedene Datenformate zu kennzeichnen. Dialect URI Metadata-Format xs:schema [XML Schema] wsdl:definitions [WSDL] wsp:policy [WS-Policy] attachment wsp:policyattachment [WS-PolicyAttachment] mex:metadata [WS-MetadataExchange] Tabelle 2: Auflistung der Metadatenformate für WS-MetadataExchange Als Antwort auf den Request können die Metadaten auf unterschiedliche Art und Weise zurückgeliefert werden: 1. direkt eingefügt in die Antwortnachricht als Teil des mex:metadatasection Elementes, 2. als Referenz auf eine WS-Transfer Ressource, die durch eine WS-Addressing Endpunktreferenz angegeben ist und mit einem WS-Transfer GET Request abgefragt werden kann, 3. als Referenz auf eine Ressource, die durch eine URI gegeben ist und z.b. durch HTTP GET abgerufen werden kann. 74

75 Schemata Ein Standard-Schema ist unter zu finden Szenarien WS-MetadataExchange kann für Szenarien verwendet werden, in denen ein einfacher, direkter Austausch von Metadaten zwischen zwei Parteien gebraucht wird, z.b. wenn ein Client die Policy eines Service abrufen möchte, um diesen anschließend aufzurufen und kein Repository oder Verzeichnisdienst im Einsatz ist, von dem er diese Policy abrufen könnte Empfehlung zur Anwendung Die Nutzung von WS-MetadataExchange ist empfehlenswert (1). Es stellt eine von mehreren Alternativen dar, Metadaten für einen Web Service zu beziehen und setzt damit die Eigenschaft der Selbstbeschreibung von Diensten in einer SOA um. Es bleibt jedoch zu erwähnen, dass die in dieser Spezifikation definierten Interaktionen nur zur Beschaffung von Metadaten (z.b. Service-Beschreibung) gedacht sind, nicht etwa für die Beschaffung von Daten in Bezug auf Eigenschaften oder Attribut-Werte. 4.4 Grundlegende Sicherheitsstandards In diesem Kapitel werden die grundlegenden Sicherheitsstandards XML Encryption, XML Digital Signature, SAML, XACML, SPML und XKMS erläutert XML-Encryption Definition XML-Encryption beschreibt im Kern die Syntax und die Vorgehensweise zur Verschlüsselung von XML-Dokumenten. Es kann dazu verwendet werden, um Ende-zu-Ende Sicherheit für Anwendungen, die einen sicheren Austausch von strukturierten Daten benötigen, umzusetzen. XML-Encryption ist seit 2002 eine Empfehlung des W3C. 75

76 Grundlagen Die Verschlüsselung durch XML-Encryption erfolgt im XML-Dokument und kann sehr feingranular (Dokument, Element, Elementinhalt) erfolgen. Diese Eigenschaft von XMLEncryption erlaubt es, z.b. nur sensible Informationen zu schützen und Information für die Verarbeitung im Klartext zu erhalten. Ein weiteres wichtiges Merkmal ist, dass die Verschlüsselungsalgorithmen nicht vorgeschrieben sind und somit ein hoher Grad an Flexibilität realisiert werden kann. Bei der Verschlüsselung werden die zu verschlüsselnden Elemente durch chiffrierte Daten ersetzt. Granularität der Verschlüsselung Durch die Möglichkeit einzelne Teilbäume des XML-Dokuments zu verschlüsseln, können vertrauliche Informationen gezielt geschützt werden. Das W3C beschreibt fünf verschiedene Arten der Verschlüsselung. Verschlüsselung eines Elementes: Element und alle Kindelemente werden verschlüsselt. Verschlüsselung des Inhaltes eines Elementes: Das Element bleibt im Klartext erhalten, nur der Inhalt des Elements wird verschlüsselt. Verschlüsselung des Wertes eines Elementes: Nur Daten eines Elements werden verschlüsselt, nicht der komplette Inhalt des Elements. Verschlüsselung beliebiger Daten: Verschlüsseln beliebiger Daten im XML- Dokument. Super-Encryption: Verschlüsseln bereits verschlüsselter Elemente. Hauptelemente Die zu verschlüsselnden Daten in einem XML-Dokument werden immer durch das Wurzelelement <EncryptedData> ersetzt, das vom abstrakten Typ <EncryptedType> abgeleitet ist. <EncryptedData> beinhaltet die folgenden Elemente: <EncryptedKey> : Dient zur Übertragung des verschlüsselten symmetrischen Schlüssels. <EncryptionMethod> : Optionales Element, das den Verschlüsselungsalgorithmus angibt. <CipherData> : Erforderliches Element, das die chiffrierten Daten oder eine Referenz auf diese enthält. <KeyInfo> : Referenziert auf den Public Key, der zur Verschlüsselung des symmetrischen Schlüssels in <EncryptedKey> verwendet wurde. Verschlüsselung Zuerst müssen die zur Verschlüsselung notwendigen Parameter und kryptographischen Algorithmen ausgewählt werden. Danach sind die notwendigen Schlüssel zu beschaffen und das <KeyInfo>- Element wird erzeugt. Zum Abschluss werden die Daten verschlüsselt und das <EncryptedData> -Element erzeugt. Das Element tritt dann an die Stelle der zu sichernden Informationen im XML Dokument. 76

77 Entschlüsselung Zuerst wird das <EncryptedData> -Element ausgelesen, um die bei der Verschlüsselung gewählten Parameter, Algorithmen und Schlüsselinformation zu gewinnen. Anschließend werden der Schlüssel aus dem <KeyInfo> Element ermittelt und die verschlüsselten Daten aus dem <CipherData> Elements dechiffriert. Das dechiffrierte Element tritt dann an die Stelle der zuvor gesicherten Informationen im XML Dokument Schemata Das Schema für XML-Encryption ist unter zu finden Szenarien XML-Encryption kommt immer zum Einsatz, wenn sensible Informationen zu schützen sind. Dies ist insbesondere beim Transport von Daten über nicht-vertrauenswürdige Instanzen der Fall, weswegen XML-Encryption insbesondere bei Web Services im Kontext der WSSecurity Spezifikation Anwendung findet. Durch die Wahl der Granularität der Verschlüsselung ergeben sich unterschiedliche Möglichkeiten für XML-Encryption. Unter anderem können komplette XML-Dokumente vom Sender zum Empfänger vertraulich übertragen werden. Das Verfahren besitzt aber auch die Fähigkeit nur Teile zu verschlüsseln, so dass bestimmte Informationen von den entsprechenden Zwischenstationen bzw. Partnern gelesen und verarbeitet werden können Empfehlung zur Anwendung Die Verwendung von XML-Encryption ist empfehlenswert (1) und sollte in jedem Fall als Sicherheitsmaßnahme durchgeführt werden, wenn Informationen über mehrere Instanzen ausgetauscht werden bzw. die Informationen dauerhaft zu sichern sind. Der Einsatz sollte nicht nur auf geschäftskritische Nachrichten beschränkt sein, sondern auch im Zusammenhang mit dem Schutz der personenbezogenen Daten immer eine Rolle spielen. Grundvoraussetzung für die Wirksamkeit von XML-Encryption ist, dass immer sichere kryptographische Algorithmen (siehe [BNetzA]) mit den entsprechenden Parametern zum Einsatz kommen XML-Signature Definition XML-Signature ist eine Empfehlung vom W3C und definiert die XML-Syntax und Verarbeitungsregeln für die Erstellung und Darstellung von digitalen Signaturen. Mit XMLSignature können XML-Dokumente oder durch das XML-Dokument referenzierte Ressourcen, typischerweise XML-Dokumente, signiert werden. Das Signieren mit XMLSignature gewährleistet die Integrität, Authentizität und Verbindlichkeit von Daten. 77

78 Grundlagen Um XML-Signature einsetzen zu können, sind zusätzliche Schritte gegenüber den klassischen Vorgehen bei der Signaturerstellung (Berechnung des Hashwerts, der anschließend signiert wird) erforderlich. Das liegt an den unterschiedlichen Möglichkeiten Informationen in XMLDokumenten darzustellen, was zur Folge hat, dass Daten trotz semantisch gleichen Inhalts auf verschiedene Weise dargestellt werden können. Dadurch entstehen beim Signieren der Daten unterschiedliche Signaturen. Deshalb ist ein wichtiger Punkt bei der Erstellung von Signaturen die Kanonisierung und Transformation. Sie garantieren, das semantisch identische XML-Dokumente immer eine identische serialisierte Darstellung haben. Dies ist notwendig, da z.b. <Elem > und <Elem> zwar syntaktisch identisch sind, allerdings verursachen sie unterschiedliche Hashwerte aufgrund des Leerzeichens und damit unterschiedliche Signaturen. Der Schritt der Kanonisierung wird daher vor der Generierung der Signatur durchgeführt. Für das anschließende Signieren stehen drei Varianten zur Verfügung. Signaturvarianten Für das Signieren von XML-Dokumenten stehen drei unterschiedlichen Varianten zur Verfügung: Enveloped Signature: Einbettung der Signatur in das XML-Dokument. S ig n ie rte s X M L -D o k u m e n t X M L -S ig n a tu r Abbildung 16: Enveloped Signature Enveloping Signature: Signatur schließt signierte Daten ein. X M L -D o k u m e n t X M L -S ig n a tu r S ig n ie rte s X M L -D o k u m e n t Abbildung 17: Enveloping Signature Detached Signature: Signatur über Daten außerhalb des XML-Dokuments. 78

79 X M L -D o k u m e n t X M L -S ig n a tu r S ig n ie rte D a te n Abbildung 18: Detached Signature Hauptelemente Eine XML-Signature besteht aus dem Wurzelelement <signature>, dass die folgenden Elemente kapselt: <SignedInfo> : Beinhaltet oder referenziert auf die zu signierenden Daten und spezifiziert die verwendenden Algorithmen. <SignatureValue> : Enthält den Base64-codierten Signaturwert von <SignedInfo>. <KeyInfo> : Referenziert auf den Public Key zur Verifikation der Signatur Schemata Das Schema für XML-Signature ist unter zu finden Szenarien Neben der Sicherstellung der Vertraulichkeit von sensiblen Informationen, welche durch XML-Encryption verwirklicht wird, spielt die Authentizität, Integrität und die Verbindlichkeit, dass der Sender wirklich die Nachricht gesendet bzw. verfasst hat, eine wichtige Rolle. Überall, wo diese Anforderungen an XML-Dokumente gestellt werden, erfolgt der Einsatz von XML-Signature. Durch die verschiedenen Signaturvarianten von XML-Signature sind die Einsatzgebiete sehr vielfältig, unter anderem: Separation of Duty mit Teil- und Mehrfachsignaturen Archivpflege Kontrollsignaturen Multilaterale Verträge im Netz. Ein weiterer großer Vorteil von XML-Signature ist, dass es auf reines XML aufbaut. Somit ist es sehr leicht in SOAP integrierbar und erlaubt die Wahrung von Integrität und Authentizität von SOAP-Daten beim Versandt von SOAP Nachrichten. 79

80 Empfehlung zur Anwendung Die Verwendung von XML-Signature ist empfehlenswert (1). Allerdings muss auch hier, wie im Fall von XML-Encryption, immer auf die verwendeten kryptographischen Verfahren (siehe [BNetzA]) und die Wahl der Parameter geachtet werden. Die Parameter spielen auch eine entscheidenden Rolle bei der Archivierung von XML-Dokumenten SAML Definition SAML (Security Assertion Markup Language) ist ein von der OASIS Security Services Technical Committee standardisiertes XML-basiertes Framework für die Beschreibung und Abfrage von Authentifizierungs-, Autorisierungs- und Attributinformationen eines Nutzers über eine Reihe von Kommunikationsprotokollen wie HTTP oder SOAP Grundlagen Der Grundgedanke für die Entwicklung des SAML Standards war die Realisierung von Portabilität für Identitätsinformationen über Domänengrenzen hinweg, um so Benutzerinformationen in verschiedenen Administrationsdomänen miteinander zu verbinden. Diese Idee wurde zeitgleich von mehreren Initiativen verfolgt, welche sich teilweise beeinflussten, teilweise aber auch konkurrierten. Mit dem Ziel der Konvergenz dieser einzelnen Bestrebungen wurden in SAML 2.0 mehrere Spezifikationen vereint, insbesondere SAML 1.1 und das Liberty Identity Federation Framework (ID-FF) 1.2 (vgl. auch Kapitel ). Der SAML 2.0 Standard unterteilt sich in verschiedene Bausteine (siehe Abbildung 19). Den Kern bilden die Beschreibung von Identitätsinformationen durch eine festgelegte Struktur, so genannte SAML Assertions, und die Abfrage dieser Assertions durch ein Request-Response Protokoll. SAML Bindings beschreiben, wie diese Request-Response Protokoll-Nachrichten auf vorhandene Kommunikationsprotokolle wie HTTP oder SOAP abgebildet werden. Auf höchster Ebene beschreiben SAML Profile, wie die einzelnen Bausteine der Spezifikation genutzt werden, um komplexe Anwendungsszenarien umzusetzen, wie beispielsweise ein Web Browser Single-Sign-On. Neben diesen aufeinander aufbauenden Bausteinen gibt es noch zwei zusätzliche Konzepte: Metadaten und Authentifizierungskontexte. Metadaten erlauben die Konfiguration von Identitätsförderationen (siehe auch Kapitel 4.5.5), während mit Hilfe eines Authentifizierungskontextes detaillierte Informationen über den Authentifizierungsprozess gegeben werden können. 80

81 Abbildung 19: Bestandteile des SAML 2.0 Standards Assertions: SAML Assertions stellen Container für Identitätsinformationen dar, die von einer befugten Stelle ausgestellt werden, die die Identitätsinformationen verwaltet. Die enthaltene Information wird in so genannte Statements verpackt, für die der Aussteller Anspruch auf Richtigkeit der enthaltenen Information erhebt. Die Voraussetzung, um mit dem Inhalt der Assertion arbeiten zu können und z.b. Zugriffsentscheidungen abzuleiten, ist eine Vertrauensbeziehung zwischen dem Empfänger und dem Aussteller der Assertion (zumindest einseitig vom Empfänger zum Aussteller). Eine SAML Assertion umfasst verschiedene Informationen. Die wichtigsten sind: das Subjekt auf das sich alle Aussagen beziehen (Subject), die eigentlichen Aussagen über die Authentifizierung, Autorisierung oder Attribute des Subjektes der Assertion (AuthnStatement, AuthzDecisionStatement, AttributeStatement), eine eindeutige Kennung für den Aussteller der Assertion (Issuer), Bedingungen für die Nutzung der Assertion als Sicherheitstoken (Conditions). Für die Integrität, Vertraulichkeit und Verbindlichkeit der SAML Assertion kann zusätzlich die Signatur des Ausstellers auf Teile oder die gesamte Assertion angewendet werden. Protokolle: SAML Assertions werden über in der Spezifikation definierte Protokolle ausgetauscht, die einem Request/Response Muster folgen. Neben den klassischen Protokollen zur Abfrage der verschiedenen Typen von Assertions, stellt SAML weitere Protokolle wie z.b. für Single Logout oder Anfragen nach der Durchführung des Authentifizierungsprozesses bereit. Bindings: Bindings beschreiben, wie SAML Protokolle auf Kommunikations- und Nachrichtenprotokolle abgebildet werden. Profiles: SAML Profile beschreiben, wie Assertions, Protokolle und Bindings kombiniert werden, um einen bestimmten Anwendungsfall zu unterstützen, z.b: Web Browser SSO Profile (Multi-Domain-Single-Sign-On beim Zugriff auf verschiedene förderierte Web Seiten), Enhanced Client or Proxy Profile (SSO in Web Browsern mit beschränkten Kapazitäten), Identity Provider Discovery Profile (zur Bestimmung des Identitätsproviders des Benutzers), 81

82 Name Identifier Management Profile (Vergabe von eindeutigen Bezeichnern zum Linken mehrerer Accounts eines Benutzers). Weiterführende Informationen zu diesen Konzepten, die insbesondere beim Aufbau von Federationsinfrastrukturen gebraucht werden, finden sich in Kapitel Schemata Das Schemata für SAML ist unter zu finden Szenarien SAML findet in Szenarien Anwendung, in denen bestätigte Identitätsinformationen portabel von einer Administrationsdomäne in eine andere übertragen werden müssen. Ein Standardbeispiel ist der Kauf eines PCs durch den Mitarbeiter einer Firma bei einem externen Dienstleister. In den meisten Fällen wird der Mitarbeiter keinen eigenen Account bei dem externen Dienstleister haben. Stattdessen fordert der Dienstleister eine bestätigte Aussage des Unternehmens, dass der Mitarbeiter authentifiziert wurde und autorisiert ist, die Ware zu bestellen. Dazu formuliert er in seiner Sicherheitspolicy eine entsprechende Anforderung an ein SAML Token für die Bestätigung der Authentifizierung und Autorisierung. Eine Prüfung des SAML-Statements auf Service Provider-Seite stellt die Authentizität des berechtigten Zugriffs sicher. Derartige Szenarien gehen einher mit Identity Federation Konzepten, welche genauer in Kapitel 6.4 betrachtet werden Empfehlung zur Anwendung Die Verwendung von SAML ist empfehlenswert (1). SAML hat sich insbesondere als Tokenformat durchgesetzt, da es eine sehr flexible Möglichkeit bereitstellt Identitätsinformationen auszudrücken und als XML-basierte Struktur auszutauschen. Neben der Verwendung in den SAML Profilen, welche Föderationkonzepte beschreiben, wird das SAML Token Format auch in WS-Federation verwendet, welches einen parallelen Ansatz für Identity Federation beschreibt. Im Rahmen von WS-Federation werden SAML Token beispielsweise mit Hilfe von WS-Trust abgerufen und für die Umsetzung der WS-Federation Konzepte verwendet XACML Definition XACML steht als Akronym für extensible Access Control Markup Language. Es handelt sich dabei um eine vom OASIS Konsortium definierte XML-Policy Sprache, die die Zugriffskontrolle auf Ressourcen standardisiert. Mittels XACML wird beschrieben, wie Regeln bzw. Request-/Response-Nachrichten aufzustellen sind, um eine kontext- oder attributbasierte Autorisierung zu ermöglichen. Wesentliche Vorteile beim Einsatz von XACML sind die Übertragbarkeit von Zugriffsrechten sowie eine feingranulare 82

83 Zugriffssteuerung. Die aktuelle Version von XACML hat den Status 2.0 und wurde 2005 von der Standardisierungsorganisation OASIS spezifiziert. An einer neuen Version 3.0 wird gearbeitet, wobei diese die bisherigen Möglichkeiten von XACML um neue bzw. zusätzliche Aspekte (z.b. das Delegieren von Rechten) erweitern wird [XACML] Grundlagen Viele heutige IT-Systeme implementieren Zugriffs- bzw. Autorisationsmechanismen proprietär. Informationen über Entitäten bzw. deren Attribute werden in der Regel in bestimmten Repositories gespeichert, den so genannte Access Control Lists. Da diese jedoch von verschiedenen Systemen unterschiedlich umgesetzt werden, ist der Austausch bzw. die gemeinsame Nutzung von relevanten Autorisations-Informationen nur schwer realisierbar. XACML verfolgt daher insbesondere zwei Ziele. Zum einen soll eine standardisierte Beschreibung von Entitäten und deren Attribute für die Zugriffssteuerung erfolgen. Zum anderen soll ein Mechanismus angeboten werden, der eine feingranulare Zugriffssteuerung ermöglicht. Ziel ist es, über das Gewähren (permit) oder das Verwehren (deny) hinaus, weitere Möglichkeiten zu bieten, um vor oder nach der Autorisationsentscheidung bestimmte Aktionen durchführen zu können. XACML Architektur Abbildung 20 zeigt die Komponenten der XACML Architektur. Nachfolgend werden die Komponenten kurz beschrieben und deren Funktionsweise erläutert (vgl. [XACML]). In Kapitel 6.2 erfolgt im Kontext des Policy Managements zudem eine ausführliche Betrachtung der Komponenten. Eine Anfrage (beispielsweise eine SOAP Nachricht) kommt an dem Policy Enforcement Point (PEP) an. Der PEP erstellt eine XACML Anfrage (XACML-Request) und sendet diese an den Policy Decision Point (PDP), der die Anfrage auswertet und anschließend eine Antwort zurücksendet. Bei der Antwort kann es sich entweder um eine Zugriffserlaubnis (permit) oder -verweigerung (deny) mit entsprechenden Verpflichtungen (obligations) handeln. Bei der Entscheidungsfindung wertet der Policy Decision Point Policies und Rules aus. Es können mehrere Policies verfügbar sein, wobei jedoch nur diejenigen ausgewertet werden, die je nach Policy Target relevant sind. Ein Policy Target enthält Informationen über das Subjekt, die Aktion und andere umgebungsbedingte Eigenschaften (siehe Abschnitt XACML Policy). Um die Policies zu erhalten, benutzt der PDP den Policy Administration Point (PAP). Der PAP verwaltet Policies sowie Policy Sets und stellt sie dem PDP zur Verfügung. Der PDP kann auch den Policy Information Point (PIP) Dienst aufrufen, um die Attributwerte hinsichtlich Subjekt, Aktion und Umgebung zu erhalten. Hat der PDP aufgrund der Informationen eine Autorisationsentscheidung getroffen, wird diese an den PEP geschickt. Der PEP erlaubt oder verweigert auf Basis der Autorisationsentscheidung des PDP dementsprechend den Zugriff. Je nach Autorisationsentscheidung muss der Policy Enforcement Point zusätzlich so genannte Obligations (Verpflichtungen) erfüllen, d.h. bestimmte Aktionen durchführen. Eine typische Verpflichtung ist z.b. das Protokollieren des Zugriffs auf die jeweilige Ressource. 83

84 Abbildung 20: XACML Architektur (vgl. [XACML_IBM]) XACML Policy Eine Policy besteht aus einer Reihe von Regeln (rules), einer Kennung für Regelnkombinierende Algorithmen (rule-combining algorithms), einer Reihe von Verpflichtungen (obligations) und einem Ziel (target). Nachfolgend werden die oben genannten Komponenten einer Policy erläutert (vgl. [XACML]): Target: Jede Policy hat nur ein Target, das dazu dient zu entscheiden, ob eine Policy für die Anfrage relevant ist und dementsprechend ausgewertet wird. Dazu werden die drei Kategorien subject, resource und action mit ihren Werten in dem Target definiert. Es ist nicht verpflichtend, Werte für alle drei Kategorien anzugeben. Die Werte werden mit den jeweiligen Werten der Attribute in der Anfrage verglichen und nur bei einer Übereinstimmung wird die Policy als relevant erachtet und ausgewertet. Rules: Mehrere Rules können mit einer Policy verknüpft werden. Dabei besteht jede Rule aus einer Bedingung (condition), einem Effekt (effect) und einem Ziel (target). Eine Condition macht Aussagen, die über Attribute bei der Bewertung getroffen werden (entweder True, False oder Indeterminate). Effect kann hingegen die Ausprägung Permit oder Deny annehmen und somit die Konsequenzen einer Regel bei Erfüllung festlegen. Target bestimmt analog zur Target-Kategorie in der Policy, ob eine Regel für die Anfrage relevant ist. Rule-combining Algorithm: Da eine Policy aus mehreren Rules bestehen kann, ist die Gefahr gegeben, dass bestimmte Regeln sich widersprechen bzw. Konflikte hervorrufen. Rule-combining 84

85 Algorithms sind dafür verantwortlich, solche Konflikte zu beheben, so dass eine eindeutige Auswertung der Policy möglich wird. Obligations: Mittels sog. Obligations ist eine feingranulare Zugriffssteuerung durchführbar. In Abhängigkeit der Autorisationsentscheidung muss der Policy Enforcement Point bestimmte Aktionen ausführen, die innerhalb der Obligations festgelegt wurden. Zusammenhang zwischen XACML und SAML: Zwischen der XACML Architektur und der SAML Architektur gibt es einige Gemeinsamkeiten. Beide werden auf dem Gebiet der Authentisierung, Autorisation und Zugriffssteuerung eingesetzt und ergänzen sich. Während SAML für die Authentisierung sowie die Übertragung von Authentisierungs- und Autorisationsentscheidungen zwischen kooperierenden Entitäten verantwortlich ist, konzentriert sich XACML im Kern auf die Autorisationsentscheidungen. D.h. der XACML Standard befasst sich vielmehr damit wie Autorisationsanfragen intern verarbeitet werden. Des Weiteren definiert XACML die komplette Architektur mit Rules, Policies und Policy Sets, um eine Autorisationsentscheidung zu erzielen. Da SAML als auch XACML jeweils wichtige Teilaufgaben (Authentisierung und Autorisation) für einen sicheren Zugriff auf Ressourcen übernehmen und sich zudem sehr gut ergänzen, werden beide Standards in der Praxis oftmals zusammen verwendet. Dementsprechend existiert auch ein spezielles SAML 2.0 Profil, das die Übertragung von XACML-basierten Informationen innerhalb von SAML 2.0 Assertions ermöglicht Szenarien Eine Person möchte bestimmte medizinische Daten von einem Service Provider abrufen. Innerhalb des Diensteportals wählt der Nutzer dazu die gewünschte Datenquelle aus. Eine Autorisationsanfrage wird daraufhin an den Policy Enforcement Point gestellt. Dieser generiert eine XACML-Anfrage und leitet sie an den Policy Decision Point weiter. Über den Policy Administration Point erhält dieser wiederum die Regeln, die für eine Autorisationsentscheidung benötigt werden. In Abhängigkeit der definierten Regeln entscheidet der Policy Decision Point dann, ob der Nutzer zum Auslesen der angeforderten medizinischen Daten berechtigt ist und sendet seine Entscheidung an den Policy Enforcement Point. Der Policy Enforcement Point kann dann z.b. aufgrund der Autorisationsentscheidung dem Nutzer einen zeitlich beschränkten Lesezugriff auf die medizinischen Daten gewähren Empfehlung zur Anwendung Ein Einsatz von XACML wird empfohlen (1), wenn Ressourcen zwischen mehreren Organisationen gemeinsam genutzt werden sollen und eine einheitliche sowie feingranulare Zugriffssteuerung notwendig bzw. sinnvoll ist. XACML bietet die Möglichkeit, standardisiert Autorisations-Informationen festzulegen und Autorisationsentscheidungen zu treffen. 85

86 4.4.5 SPML Definition SPML steht als Akronym für Service Provisioning Markup Language und ist ein XMLbasiertes Framework für den Austausch von Benutzer-, Ressourcen- und ServiceProvisionierungs-Informationen zwischen kooperierenden Organisationen. Ziel ist allgemein die Automatisierung von Operationen, wie z.b. das Anlegen, Ändern oder Löschen von Benutzeraccounts und Systemberechtigungen. Die Spezifikation von SPML liegt zurzeit in Version 2 vor und wurde von der Standardisierungsorganisation OASIS veröffentlicht [SPML] Grundlagen Das SPML Domain Model besteht aus den vier Hauptelementen Requesting Authority, Provisioning Service Provider, Provisioning Service Target und Provisioning Service Object, die nachfolgend genauer beschrieben werden (vgl. [SPML]): Requesting Authority (RA): Eine Requesting Authority (kurz Requestor) ist eine Software-Komponente, die syntaktisch korrekte SPML Anfragen an einen Provisioning Service Provider stellt. Requesting Authorities können z.b. Portal- bzw. Benutzeranwendungen oder HRSysteme sein. In einem Ende-zu-Ende Provisioning-Szenario wird jede Komponente, die eine SPML Anfrage stellt, als Requestor betrachtet. Wichtig ist in diesem Zusammenhang die Vertrauensbeziehung zwischen Requestor (anfragende Komponente) und dem Provider (angefragte Komponente). Das Aufbauen und Gewährleisten dieser Vertrauensbeziehung sind nicht Gegenstand der SPMLSpezifikation. Provisioning Service Provider (PSP): Ein Provisioning Service Provider (kurz Provider) ist eine Software-Komponente, die syntaktisch korrekte SPML Anfragen von einem Requestor empfängt, verarbeitet und das Resultat der Anfrage zurücksendet. Ein Identity Management System könnte z.b. die Aufgabe eines Providers erfüllen. Provisioning Service Target (PST): Ein Provisioning Service Target (kurz Target) stellt einen Endpunkt dar, den ein Provider für Provisionierungs-Aktionen zur Verfügung stellt und verwaltet (z.b. Adapter für das Active Directory). Provisioning Service Object (PSO): Ein Provisioning Service Object ist vereinfacht ein Objekt, das eine Datenentität oder ein Informationsobjekt eines Targets darstellt. Z.B. ist als PSO jeder Nutzeraccount aufzufassen, der vom Provider verwaltet wird. Abbildung 21 zeigt die Hauptelemente des SPML Domain Models und deren Beziehungen untereinander. 86

87 Abbildung 21: SPML Domain Model Elements [SPML] SPML spezifiziert verschiedene Operationen für die Umsetzung eines Service-Provisionings. Folgende Operationen werden im Standard zu den sog. Core Operations gezählt [SPML]: listtargets (zum Auffinden von Targets des Providers) add (zum Hinzufügen eines neuen Objekts) lookup (zum Erhalt der XML, die das Objekt des Targets repräsentiert) modify (zum Modifizieren eines Objekts) delete (zum Löschen eines Objekts) Neben diesen Core Operations gibt es noch weitere Operationen, die im SPML Standard beschrieben werden (z.b. Password Capability, Batch Capability, Bulk Capability, Search Capability, Updates Capability, etc.) Szenarien Ein Unternehmen stellt einen neuen Mitarbeiter ein. In der Regel werden dann von einem Netzwerk-Administrator die notwendigen Berechtigungen für die jeweils benötigten Systeme und Dienste erstellt. Mittels SPML und der realisierbaren Service-Provisionierung könnten diese administrativen Prozesse bspw. nach der Erfassung im Personalsystem (HR-System) des Unternehmens über ein Service Provisioning System automatisiert ablaufen. Dieses könnte ferner gleichzeitig z.b. eine standardisierte Nachricht an das Provisioning System eines Geschäftspartners weiterleiten, so dass auch dort automatisiert die notwendigen Berechtigungen erstellt werden Empfehlung zur Anwendung Ein Einsatz von SPML wird angeregt (2), wenn eine Organisation sehr groß ist, bzw. einige Ressourcen mit anderen Organisationen gemeinsam genutzt werden. In diesen Fällen könnte 87

88 sich der Administrations- bzw. Provisionierungsaufwand durch eine Automatisierung ggf. erheblich minimieren. SPML kann dabei helfen, Provisionierungsprozesse zu vereinfachen und effizienter zu gestalten XML Key Management Specification (XKMS) Definition Die XML Key Management Specification (XKMS) beschreibt Möglichkeiten für den Austausch und die Überprüfung von Zertifikaten innerhalb einer PKI. Durch die Standardisierung wird zudem die Kompatibilität verschiedener PKI sichergestellt. Abstrahiert dargestellt bietet XKMS die Service-Fassade für eine PKI und kapselt deren komplexe Funktionalität Grundlagen Da im SOA-Umfeld die Kommunikation zwischen den einzelnen Services geschützt werden muss, stellt eine PKI eine wichtige Komponente für die Absicherung der Services dar. Mit Hilfe der PKI können die nötigen Schlüssel verteilt werden, um innerhalb des Systems die Sicherheitsanforderungen wie Vertraulichkeit, Authentizität, Integrität und Verbindlichkeit umsetzen zu können. Eine PKI sollte aufgrund dieser Tatsachen als zentrale Komponente innerhalb der SOASicherheitsinfrastruktur vorhanden sein. Allerdings besitzt eine PKI eine hohe Komplexität, die vor den Nutzern des Systems verborgen werden muss. Dies wird durch die Verwendung vom XKMS-Standard ermöglicht. XKMS gliedert sich in zwei Komponenten: XML Key Information Service Specification (X-KISS): Ermöglicht den Bezug und die Prüfung von Zertifikaten mittels Abfrage beim entsprechenden PKI-Dienstleister. Im Einzelnen: Bereitstellung eines Zertifikats, Lokalisierung eines Zertifikats, Validierung eines Zertifikats. XML Key Registration Service Specification (X-KRSS) sorgt für das Management der Zertifikate bzw. der privaten Schlüssel, d.h. die Ausstellung, Widerrufen und die Wiederherstellung von Zertifikatsschlüsseln. Im Einzelnen: Registrierung eines Zertifikats, Annullierung eines registrierten Zertifikats, Wiederherstellung eines Zertifikats, Authentisierung der Anfrage. Zu den Vorteilen von XKMS gehört die Möglichkeit der zentralen Bereitstellung von PKIs und deren Diensten. XKMS-Server können die Ressourcen-intensiven PKI-Operationen in Form eines Web Service für Geräte mit niedriger Performanz anbieten (z.b. mobile Geräte oder Embedded Devices). 88

89 Schemata Die XKMS-Schema Spezifikationen nutzen Elemente, die im XML-Signatur-Namensraum definiert sind. Der XML-Signatur-Namensraum wird durch den Prefix ds repräsentiert und ist unter zu finden Szenarien Die folgende Darstellung zeigt sehr abstrakt die Interaktion zwischen einem Client und einem XKMS-Service bzw. die Verbindung zwischen dem XKMS Service und dem PKI Server. Der Client fordert zur sicheren Nutzung eines Web Service ein Zertifikat beim XKMS-Service an (Locate Operation). Dieser ist mit dem PKI Server verbunden und beschafft die entsprechenden Parameter des öffentlichen Schlüssels, die dann als Resultat auf die Anfrage zurück an den Client geschickt werden. C lie n t X K M S S e rv ic e P K I S e rv er L o ca ter eq u est L o c a te R e s u lt Abbildung 22: Interaktion zwischen einem Client und einem XKMS-Service (Schlüsselaustausch) in Anlehnung an [XKMS] Empfehlung zur Anwendung Die Nutzung einer PKI und somit auch von XKMS ist empfehlenswert (1), um vor allem die Schutzziele Vertraulichkeit, Integrität und Authentizität zu erreichen. 4.5 Dienstkommunikation absichern Dieses Kapitel beschreibt eine Reihe von WS-*-Spezifikationen, die grundlegende Sicherheitsmechanismen definieren, um eine Service-orientierte Architektur abzusichern. Die folgende Tabelle gibt vorab einen Überblick, mit welchen Spezifikationen welche Sicherheitsanforderungen umgesetzt werden können. 89

90 Spezifikation WS-Security Sicherheitsanforderungen Vertraulichkeit (Nachrichtenebene) Integrität (Nachrichtenebene) Verbindlichkeit (Nachrichtenebene) WS-SecurityPolicy Definition von Sicherheitsanforderungen WS-Trust Ausstellen, Abrufen und Validieren von Sicherheitstoken WS-SecureConversation Vertraulichkeit (Session-Ebene) Integrität (Session-Ebene) Verbindlichkeit (Session-Ebene) WS-Federation Identity Federation über verschiedene Administrationsdomänen Tabelle 3: Sicherheitspezifikationen und deren Anwendung hinsichtlich der Umsetzung von Sicherheitsanforderungen WS-Security Definition WS-Security wurde mit dem Ziel entwickelt, den Austausch von SOAP Nachrichten abzusichern und somit den Schutzzielen Vertraulichkeit, Integrität, Verbindlichkeit und Authentizität gerecht zu werden. Die Hauptbestandteile von WS-Security sind Verschlüsselungs- und Signaturverfahren für SOAP Nachrichten, Mechanismen zum Austausch der dafür benötigten Schlüssel im Header der SOAP Nachricht, sowie Mechanismen zum Übertragen von Authentifizierungstoken im SOAP Header, um damit Benutzeridentitäten an SOAP Nachrichten zu binden. Im Gegensatz zu der reinen Sicherheit auf Transportebene kann damit eine Ende-zu-Ende-Sicherheit von Inhalten einer Nachricht gewährleistet werden Grundlagen Der Standard WS-Security wurde 2001 von IBM, Microsoft und VeriSign als Teil des Global XML Web Services Architecture (GXA) Framework entwickelt, um verschiedene Sicherheitstechnologien wie Signaturerstellung und Verschlüsselung zu kapseln. Um SOAP Nachrichten oder Teile dieser zu signieren und zu verschlüsseln, verwendet WS-Security die bestehenden XML-Basistechnologien XML-Encryption und XML-Signature und beschreibt die Integration dieser in SOAP. Ein wichtiges Element für die Verschlüsselungs- und Signaturverfahren von WS-Security stellen Security Token dar. Security Token transportieren zum einen die für die Signatur und Verschlüsselung benötigten Schlüssel und zum anderen Identitäts- und Authentisierungsinformationen über den Servicenutzer. Damit kann die Identität eines Benutzers mit der SOAP Nachricht verknüpft werden und es können personalisierte Dienste angeboten werden. 90

91 WS-Security spezifiziert eine XML-basierte Syntax, um die folgenden Sicherheitsinformationen in den SOAP Header von Nachrichten einzufügen: Security Token Signature-Elemente basierend auf XML-Signature (siehe Kapitel 4.4.2) Encryption-Elemente basierend auf XML-Encryption (siehe Kapitel 4.4.1) Security Token WS-Security unterstützt verschiedene Arten von Security Token. Teil der Spezifikation ist die Definition des UsernameTokens und des BinarySecurityTokens für Nicht-XML-basierte Formate wie X.509 Zertifikate oder Kerberos Tickets, die besonders kodiert sein müssen, um im SOAP Header versendet zu werden. Zur Unterstützung weiterer Tokenformate definiert WS-Security einen entsprechenden Erweiterungsmechanismus (Token Referenzen). Damit kann zum Beispiel SAML als Tokenformat mit WS-Security verwendet werden. Die meist genutzten Tokenformate werden im folgenden genauer erläutert: UsernameToken: Username-Token sind die einfachste und am weitesten verbreitete Art von Security Token. Es findet eine Authentifizierung mittels eines Benutzername/Passwort-Paares statt. Die Passwörter werden dabei normalerweise als Hash übermittelt. Der Hash wird dabei aus einem Nonce (Zufallswert) und einem Zeitstempel berechnet, um Replay-Attacken zu verhindern.x.509 Certificate Token: X.509 Certificate Token sind BinarySecurityToken, die die Bindung eines öffentlichen Schlüssels an ein Set von Attributen beschreiben, das mindestens den Namen des Subjects, den Namen des Ausstellers, die Seriennummer und ein Validierungsintervall enthält. Das X.509-Zertifikat kann zum Validieren eines öffentlichen Schlüssels und damit zur Feststellung der Authentizität einer SOAP Nachricht genutzt werden. SAML Token (SAML Assertions): SAML Token sind XML Token, welche eine Sammlung von Aussagen enthalten, die von einer Entität über eine andere Entität gemacht werden. Diese Aussagen können die Authentifizierung, Autorisierung oder bestimmte Attribute eines Subjects betreffen. Die Glaubwürdigkeit dieser Aussagen wird durch die Signatur des Tokens durch den Aussteller erreicht Schemata Ein Standard-Schema kann unter abgerufen werden Szenarien Die Möglichkeit, Sicherheitsmaßnahmen in den verschiedensten Formen zu definieren sowie die Flexibilität und Erweiterbarkeit des Standards WS-Security, erlauben dessen Einsatz in einer Vielzahl von Szenarien. Das folgende Beispiel zeigt den Aufbau einer SOAP Nachricht unter Berücksichtigung der Einbindung von Sicherheit zum Schutz der Nachricht. In diesem Fall wird die Nachricht von einem Web Service Client zum Web Service gesendet. Die Nachricht wurde vor dem Versand mit Sicherheitsmechanismen angereichert. Dies bedeutet, dass die Nachricht um die Komponente Sicherheit erweitert wurde, um Schutzziele wie z.b. Vertraulichkeit und Integrität zu erfüllen. Es ist zu sehen, dass die Nachricht z.b. signiert wurde und ein Security Token verwendet wird. 91

92 Abbildung 23: Einbindung von Sicherheitsmechanismen in den Header einer SOAP Nachricht durch WS-Security Empfehlung zur Anwendung WS-Security ist empfehlenswert (1), da es durch die Nutzung von XML-Encryption oder XML-Signature die Herstellung von Vertraulichkeit und Integrität auf Nachrichtenebene erlaubt. Damit können Nachrichten sicher über verschiedene nicht-vertrauenswürdige Zwischenstationen übertragen werden WS-SecurityPolicy Definition WS-SecurityPolicy spezifiziert eine Sammlung von Policy-Assertions (vgl. Kapitel 4.3.5) für die Nutzung in WS-Policy-Dokumenten, um sicherheitsbezogene Anforderungen und Fähigkeiten hinsichtlich der Verwendung von WS-Security, WS-Trust und WSSecureConversation auszudrücken Grundlagen WS-Policy definiert eine grundlegende Syntax, um Policies auszudrücken, die einen Satz von Anforderungen (sog. Assertions) umfassen. Allerdings spezifiziert WS-Policy nicht die Syntax und Semantik der Assertions selbst, denn dazu dienen weitere Spezifikationen. Eine dieser Spezifikationen stellt WS-SecurityPolicy dar, das einen Satz von Assertions definiert, um Sicherheitsanforderungen in Bezug auf WS-Security, WS-Trust und WSSecureConversation zu definieren. Policy-Assertions können mit einem Policy-Subject (vgl. Kapitel 4.3.7) assoziiert sein, das bestimmt, auf welchen Teil einer Dienstdefinition (Service, Endpoint, Operation oder Message) sich eine Assertion bezieht. Dies ermöglicht eine Klassifizierung der WSSecurityPolicy-Assertions basierend auf dem Policy-Subject, wobei WS-SecurityPolicy keine Assertions definiert, die einem Service zugeordnet sein können. Zudem werden auch Assertions spezifiziert, die keinem Policy-Subject zugewiesen werden können und nur innerhalb von anderen Policy-Assertions genutzt werden. 92

93 Assertions für Endpunkte Security Binding Assertions Ein Security-Binding liefert Informationen, um einen Austausch von Web Service Nachrichten abzusichern. Dazu können in Assertions dieses Typs weitere WS-SecurityPolicy-Assertions verschachtelt sein, die die zu verwendenden Security-Token (siehe Kapitel 4.5.1) definieren, das Vorhandensein sicherheitsrelevanter Nachrichtenteile vorschreiben (beispielsweise spezifische Teile des WS-Security-Headers) sowie Verfahren und Parameter für die zu verwendenden Algorithmen (beispielsweise für die Verschlüsselung) vorgeben. WS-SecurityPolicy definiert drei verschiedene Typen von Binding-Assertions, die unterschiedliche Sicherheitsmuster repräsentieren. Es kann entweder der Kanal abgesichert werden, über den Nachrichten ausgetauscht werden (TransportBinding) oder es können die Nachrichten selbst abgesichert werden, wobei entweder ein Security Token für beide Richtungen eines Nachrichtenaustausches (SymmetricBinding) oder unterschiedliche Security Token (AsymmetricBinding) verwendet werden können. WS-Security und WS-Trust Assertions: Diese Assertions fordern die Unterstützung und Einhaltung bestimmter Mechanismen und Eigenschaften hinsichtlich der Verwendung von WS-Security- oder WS-Trust. Die Verwendung dieser Assertions dient der Sicherstellung der Interoperabilität der kommunizierenden Parteien in Hinblick auf die Unterstützung von optionalen Protokollelementen sowie die Nutzung unterschiedlicher Versionen von WS-Security und WS-Trust. Supporting Token Assertions: Eine Assertion dieses Typs spezifiziert Sicherheitstoken, welche zusätzlich zu den durch die Binding-Assertion spezifizierten Token in einer SOAP Nachricht enthalten sein müssen. Beispielsweise kann spezifiziert sein, dass ein SAML-Token enthalten sein soll, welches die Authentifizierung des Benutzers bestätigt. Assertions zur Nutzung in einem Security Binding Einige Assertions werden durch WS-SecurityPolicy keinem Policy Subject zugeordnet, sondern finden innerhalb einer Security Binding Assertion Verwendung. Im Folgenden sind die beiden wichtigsten dieser Assertions dargestellt. Token Assertions: Assertions dieses Typs spezifizieren den Typ und die Eigenschaften von Security Token, die in einem Security Binding Verwendung finden. Algorithm Suite Assertion: Diese Assertion spezifiziert die von einem Binding zu verwendenden Algorithmen. Assertions für Operationen Supporting Token Assertions (s.o.) sind der einzige Typ von Assertions, die für das Policy Subjekt Operation spezifiziert werden können. Assertions für Nachrichten Protection Assertions: Assertions dieses Typs definieren die Nachrichtenteile, die mittels Signatur oder Verschlüsselung geschützt werden sollen. Required Element Assertions: Diese Assertion fordert das Vorhandensein spezifischer Nachrichtenteile, welche durch die Verwendung von XPath-Ausdrücken vorgegeben sind. 93

94 Schemata Ein Standard-Schema ist unter oder unter zu finden Szenarien WS-SecurityPolicy definiert sicherheitsbezogene Assertions für die Nutzung in WS-Policy und wird von Diensten verwendet, um bestimmte Sicherheitsanforderungen an Dienstbenutzer zu stellen. Die Clients der Dienstbenutzer können ebenfalls durch eine WSPolicy mit WS-SecurityPolicy-Assertions konfiguriert sein, die beschreibt, welche Sicherheitsmechanismen ein Client unterstützt. Um auf einen Dienst zuzugreifen, muss ein Client: 1. Die WS-Policy eines Dienstes mit dessen Sicherheitsanforderungen abrufen. 2. Gemäß WS-Policy die abgerufene Policy normalisieren (d.h. entsprechend den in WS-Policy definierten Algorithmen in eine eindeutige Syntax überführen) und die WS-SecurityPolicy-Assertions mit den eigenen WS-PolicyAssertions abgleichen. 3. Assertions aus der Schnittmenge wählen und die Nachrichten für den Dienstaufruf entsprechend absichern. Dieses Vorgehen ermöglicht ein Late-Binding zwischen den Diensten und ihren Nutzern (siehe Kapitel 6.2.4) und hilft, die wichtige Eigenschaft der losen Kopplung in einer SOA in Hinblick auf Sicherheit zu realisieren Empfehlung zur Anwendung Die Nutzung von WS-SecurityPolicy ist empfehlenswert (1), da mit Hilfe von WSSecurityPolicy-Assertions Sicherheitsanforderungen von Web Services beschrieben werden können WS-Trust Definition WS-Trust beschreibt ein Web Service-Interface für das Ausstellen, Erneuern, Bestätigen und Verwerfen von Security Token, welches von einem so genannten Security Token Service (STS) angeboten wird Grundlagen Wie im Kapitel zu WS-Security beschrieben, spezifiziert WS-Security eine Möglichkeit, Identitätsinformationen in Form von so genannten Security Token einer SOAP Nachricht hinzuzufügen. Diese Security Token können Schlüssel oder Zertifikate enthalten, zudem aber auch Aussagen (sog. Claims) über die Attribute oder die Authentifizierung einer Person machen beispielsweise in Form eines SAML-Token (vergleiche Kapitel 4.4.3). 94

95 Security Token und damit Aussagen über eine Person müssen nicht zwangsläufig von der Person selbst erzeugt werden, sondern können von einer dritten Instanz bereitgestellt werden, die den Account dieser Person verwaltet. Somit kann beispielsweise einer Person in einer Organisation ein Security Token bereitgestellt werden, das die Authentifizierung dieser Person bestätigt und die Rolle dieser Person in der Organisation beschreibt. Dieses Token kann im Anschluss für den Aufruf eines Dienstes genutzt werden, der basierend auf der Information im Token den Zugriff auf den Dienst autorisieren kann. WS-Trust beschreibt ein Web Service Interface sowie Mechanismen, die einer Instanz Security Token Service (STS) genannt das Ausstellen, Erneuern, Bestätigen und Verwerfen von Security Token ermöglichen. Token können bei Bedarf durch einen in WS-Trust spezifizierten request for security token (RST) angefragt und durch ein request for security token response (RSTR) zurückgeliefert werden. In der RST-Anfrage kann zudem spezifiziert werden, was für ein Tokentyp beispielsweise SAML 2.0 zurückgeliefert werden soll, welche Aussagen über eine Person (sog. Claims) in dem Token enthalten sein sollen und auf welche Weise ein auszustellendes Token zu verschlüsseln ist. Die Verschlüsselung und Signatur ist vom Typ des Tokens und der verwendeten Konfiguration abhängig (und wird durch WS-Trust gefordert). Damit ausgestellte Sicherheitstoken für den Aufruf eines Dienstes vertrauenswürdig verwendet werden können, sollte die Signatur des Tokens allerdings obligatorisch sein. Die Signatur eines Security Token Service dient auch der Bestätigung der Claims in einem Security Token Schemata Ein Standard-Schema ist unter zu finden. Des Weiteren wird eine Standard WSDL-Beschreibung unter angeboten Szenarien Die Verwendung von WS-Trust erlaubt die Bereitstellung von bestätigten Identitätsinformationen als Dienst (Security Token Service) und ermöglicht die Entkoppelung von Diensten und ihren Aufrufern. Ein Dienst muss nicht mehr jedem einzelnen Aufrufer hinsichtlich der Glaubwürdigkeit der übermittelten Identitätsinformationen direkt vertrauen, sondern er muss lediglich eine Vertrauensbeziehung zu einem oder mehreren Security Token Services etabliert haben. Dies ermöglicht eine Vereinfachung des Aufbaus einer vertrauenswürdigen Web ServiceInteraktion (siehe Abbildung 24). 95

96 Abbildung 24: WS-Trust Szenario Empfehlung zur Anwendung WS-Trust stellt eine wichtige Ergänzung zu WS-Security und SAML dar, da es einen Dienst spezifiziert, um Security Token (beispielsweise SAML) anzufordern, die dann in einer SOAP NSOAP Nachricht (mittels WS-Security) übertragen werden können. Im Gegensatz zu den Protokollen zum Abrufen von Token, welche in SAML spezifiziert sind, ist WS-Trust von dem Typ des Tokens unabhängig und stellt zudem die Grundlage von WS-Federation dar. Daher ist die Nutzung dieses Standards empfehlenswert (1) WS-SecureConversation Definition WS-SecureConversation ist eine Spezifikation der Standardisierungsorganisation OASIS, die auf WS-Security aufsetzt und derzeit in Version 1.3 als Standard vorliegt. Sie beschreibt Erweiterungen zum Erzeugen eines Sicherheitskontextes sowie zum Ableiten und Nutzen eines gemeinsamen Sitzungsschlüssels. Dadurch, dass nach einer einmaligen Authentisierung ein gemeinsamer Sitzungsschlüssel zum sicheren Austausch weiterer Nachrichten verwendet wird, bzw. die Kommunikation innerhalb des sog. Sicherheitskontextes abläuft, wird insbesondere bei vielen zu übertragenden Nachrichten eine hohe Performance und Sicherheit erreicht. WS-SecureConversation ist keine komplette Sicherheitslösung für Web Services. Die Spezifikation ist vielmehr ein Baustein, der in Verbindung mit anderen Standards und anwendungsspezifischen Protokollen für viele Sicherheitsszenarien eingesetzt wird [WSSecConv] Grundlagen Der WS-Security Standard konzentriert sich hauptsächlich auf Sicherheitsaspekte auf Nachrichtenebene und dient als Rahmen für das Anwenden von geeigneten Sicherungstechniken im Web Service Umfeld. Es werden z.b. grundlegende Aussagen getroffen, wie XML-Dokumente verschlüsselt oder signiert werden sollen. Für den sicheren Austausch einzelner Nachrichten ist der Einsatz dieser Schutzmechanismen empfehlenswert, 96

97 allerdings haben sie bei einer größeren Menge an auszutauschenden Nachrichten gewisse Schwächen. Für jede ausgetauschte Nachricht muss ein neuer symmetrischer Schlüssel neu generiert und gesichert mit der Nachricht übertragen werden, der dann für die Verschlüsselung der Nachricht verwendet werden kann. Dies erhöht die Nachrichtengröße und verlangsamt die Verarbeitung der Nachrichten. Vor diesem Hintergrund ist es sinnvoll, nach einer ersten sicheren gegenseitigen Authentisierung der Kommunikationspartner, einen so genannten Sicherheitskontext zu erstellen, in dem weitere Nachrichten auf effiziente Weise ausgetauscht werden. Genau diese Aufgabe und Funktionsweise spezifiziert WSSecureConversation und erweitert damit den WS-Security Standard um wichtige Aspekte. In der Regel wird zur Erstellung des Sicherheitskontextes ein gemeinsamer Sitzungsschlüssel erzeugt, mit dem beide Kommunikationspartner den Nachrichtenaustausch verschlüsseln. Mittels des Diffie-Hellman Schlüsselaustauschverfahrens kann z.b. gewährleistet werden, dass trotz Nutzung eines öffentlichen Kommunikationsmediums und damit der potentiellen Gefahr des Mithörens, ein sicherer Schlüsselaustausch stattfinden kann. Beide Kommunikationspartner verfügen somit über einen gemeinsamen symmetrischen Schlüssel, der eine sichere und effiziente Verschlüsselung ermöglicht. WS-SecureConversation definiert auf der SOAP-Schicht die Elemente, die zum Erzeugen eines Sicherheitskontextes benötigt werden. Zur Erzeugung und Verteilung von Sicherheitstoken werden dabei Teile von WS-Trust erweitert. Für den Sicherheitsheader (nach WS-Security) spezifiziert WS-SecureConversation einen so genannten SecurityContextToken, der mittels XML Encryption verschlüsselt übertragen wird. Für diesen initialen Austausch sieht WS-SecureConversation drei verschiedene Möglichkeiten vor, die in Abhängigkeit der Vertrauensbeziehung zum Kommunikationspartner zu bewerten und zu nutzen sind [Melzer2008]: Spezifiziertes Verfahren in WS-Trust: Ein externer Dienst, dem die Kommunikationspartner vertrauen, erzeugt das Token. Ein Kommunikationspartner erzeugt und verteilt das Token. Falls nicht alle anderen Beteiligten dieser Person bzw. dem Dienst vertrauen, scheitert das Verfahren. Das Token wird in einem Challenge/Response-Verfahren erzeugt. Im Kern basiert das Verfahren auf Diffie-Hellman. Listing: Das <SecurityContextToken> Element [Rosenberg] <wsse:securitycontexttoken wsu:id="..."> <wsu:identifier>...</wsu:identifier> <wsu:created>...</wsu:created> <wsu:expires>...</wsu:expires> <wsse:keys> <xenc:encryptedkey Id=" ">...</xenc:encryptedkey> <wsse:securitytokenreference>...</wsse:securitytokenreference >... </wsse:keys> </wsse:securitycontexttoken> Die Elemente und Attribute in dem <wsse:securitycontexttoken> Element werden nachfolgend beschrieben (vgl. [Rosenberg]): 97

98 <wsu:identifier> Das notwendige <wsu:identifier> Element identifiziert den Sicherheitkontext mittels URI. Dieser Sicherheitskontext URI muss eindeutig für Sender als auch Empfänger sein. <wsu:created> Das optionale Element <wsu:created> kennzeichnet den Erstellungszeitpunkt des Sicherheitskontextes. Es wird in der Regel nur bei der erstmaligen Verwendung des Tokens angegeben. <wsu:expires> Das optionale <wsu:expires> Element gibt das Ablaufdatum des Sicherheitskontextes gemäß der Zeitmessung des Anfragestellers an. Es wird in der Regel nur bei der erstmaligen Verwendung des Tokens angegeben. <Keys> Das optionale <Keys> Element enthält das gemeinsame Sicherheitsgeheimnis des Sicherheitskontextes. Es wird üblicherweise nur bei der erstmaligen Verwendung des Tokens spezifiziert. Falls kein <Keys> Element angegeben ist, wird davon ausgegangen, dass bereits das gemeinsame Geheimnis bekannt und mit dem Sicherheitskontext assoziiert ist. Dieser kann dann über die URI im <wsu:identifier> Element identifiziert werden. <xenc:encryptedkey> Das optionale <xenc:encryptedkey> Element beinhaltet das gemeinsame Geheimnis des Sicherheitskontextes. Das optionale Attribut spezifiziert eine "ID" für den Schlüssel. <SecurityTokenReference> Das optionale <SecurityTokenReference> Element referenziert das gemeinsame Geheimnis des Sicherheitskontextes Empfehlung zur Anwendung WS-SecureConversation hat sich als Sicherheitsstandard für Web Services etabliert und wird daher empfohlen (1). Werden viele Nachrichten zwischen Web Services ausgetauscht, kann mittels WS-SecureConversation eine sichere und dennoch performante Kommunikation erreicht werden WS-Federation Definition WS-Federation ist eine von IBM und Microsoft entworfene Spezifikation um Identity Federation in webbasierten Umgebungen umzusetzen. Identity Federation beschreibt dabei die gemeinsame Nutzung von Identitätsinformationen, welche von administrativ eigenständigen Instanzen verwaltet werden. WS-Federation definiert die Mechanismen, um unterschiedliche Sicherheitsdomänen zu einem Verbund (Federation) zusammenzuschließen, Identitäten im Verbund zu verbinden (Account Linking) und Identitätsinformationen zwischen diesen Domänen unter Beachtung der Privatsphäre des Benutzers abzurufen und auszutauschen. 98

99 Grundlagen Das einer Federation zugrundeliegende Konzept ist ein Circle Of Trust basierend auf Vereinbarungen und Verträgen zwischen den teilnehmenden Parteien. Dadurch können Benutzer ihre digitalen Identitäten zwischen verschiedenen Domänen verbinden (Account Linking) und Identitätsinformationen, die in einer Domäne verwaltet werden, in einer anderen Domäne verwenden. Dazu muss die Verwaltung, das Auffinden und der Zugriff auf die Informationen zwischen den Teilnehmern auf Basis von einheitlichen Prozessmodellen und Protokollen erfolgen. Um dieses Ziel zu verwirklichen, baut WS-Federation auf den Konzepten von WS-Trust, WS-Policy und WS-Security auf. Konzeptionell beschreibt die Spezifikation Anwendungsszenarien für Förderationen sowie Förderationsprotokolle. WS-Federation unterscheidet dabei klar zwischen Umgebungen mit aktiven Clients, die via SOAP kommunizieren können und passiven Clients wie Web Browsern, die lediglich HTTP verstehen. Für die Etablierung einer Förderation definiert WS-Federation ein Metadatendokument, das Informationen über die Teilnehmer der Förderation umfasst (wie beispielsweise die Adresse eines Identity Providers) und zwischen den Teilnehmern beim Aufbau der Förderation ausgetauscht wird. Zusätzlich gibt es weitere Services, wie Attribute Services: WS-Federation definiert Zugriff und Verwendung eines Attribute Service basierend auf dem Security Token Service Konzept von WS-Trust, um zusätzliche Benutzerinformationen zu verwalten und verfügbar zu machen. Pseudonym Services: Pseudonyme stellen ein wichtiges Mittel dar, um die Privatsphäre eines Benutzers zu schützen. WS-Federation beschreibt wie ein Pseudonym Service, der mit einem Security Token Service kombiniert ist, Pseudonyme statt des Benutzernamens in den ausgestellten Token verwenden kann. Federated Sign-Out: WS-Federation definiert einen Mechanismus, um allen Parteien im Verbund mitzuteilen, dass ein Teilnehmer seine Sitzung beendet hat. Diese Elemente machen eine förderierte Authentifizierung, einen Attributaustausch und ein Pseudonym- bzw. Namensmanagement in webbasierten Umgebungen möglich Schemata Für die WS-Federation Spezifikation gibt es folgende Schemata: Szenarien WS-Federation wird immer dort eingesetzt, wo Identitäts-, Autorisierungs- und Authentifizierungsinformationen in unterschiedlichen Domänen verwaltet werden. Typische Szenarien sind z.b.: Eine Organisation will ihren Partnerorganisationen Zugang zu ihren Anwendungen geben, ohne die Identitäten auf ihren System zu verwalten. 99

100 Organisationen haben sich zu einem Verbund zusammengeschlossen und wollen nicht, dass der Kunde sich bei jedem Portal immer wieder neu anmelden muss (multi-domain SSO) Empfehlung zur Anwendung WS-Federation ist grundsätzlich zu empfehlen (1). Jedoch gibt es mit den SAML Spezifikationen einen parallelen Ansatz, um Identity Federation umzusetzen, der nicht mit WS-Federation interoperabel ist. Während die Protokolle und Mechanismen für web-basiertes SSO in beiden Ansätzen sehr ähnlich sind, unterstützt im Moment nur WS-Federation SOAPbasiertes SSO. Das heißt, dass nur WS-Federation ein klar definiertes SOAP-basiertes Authentifizierungsprotokoll beinhaltet. Zudem ist WS-Federation flexibler bzgl. der Verwendung von Sicherheitstoken. Da es auf WS-Trust basiert, kann WS-Federation mit jedem Tokenformat umgehen, für das es ein entsprechendes Token Profile gibt. 4.6 Messaging-Nachrichten zustellen Die in diesem Kapitel beschriebenen Spezifikationen lassen sich in zwei Gruppen einteilen: Spezifikationen für die Adressierung von Web Services und solche für die Übertragung von Nachrichten. Dabei ist zu beachten, dass sich die hier vorgestellten Spezifikationen nicht ergänzen, sondern in ihrer jeweiligen Gruppe in Konkurrenz zueinander stehen. Die vorgestellten Spezifikationen für die Nachrichtenübertragung zwischen Web Services sind WS-Eventing und WS-Notification. Die WS-Notification Spezifikation setzt sich aus den drei Subspezifikationen WS-BaseNotification 1.3, WS-Topics 1.3 und WSBrokeredNotification 1.3 zusammen. Alle drei Spezifikationen werden durch die Organisation OASIS verwaltet und sind dort bis auf WS-Topics 1.3 als Approved Standard geführt. Die Spezifikation WS-Eventing hingegen wird durch das W3C verwaltet und liegt dort im Status Public Draft vor. Aktuell wird das Ziel verfolgt, eine einheitliche Spezifikation zu schaffen mit der Bezeichnung WS-EventNotification. Im Gegensatz dazu unterscheiden sich die hier vorgestellten Spezifikationen für die Adressierung von Web Services, WS-Addressing und WS-Routing, bezüglich ihrer Standardisierung deutlich. Seitens des W3C wurde WS-Addressing in die Spezifikationen Web Services Addressing 1.0 Core, Web Services Addressing Metadata und Web Services Addressing SOAP Binding unterteilt. Diese Spezifikationen werden vom W3C mit dem Status Empfohlen geführt. Im Gegensatz dazu handelt es sich beim WS-Routing um eine proprietäre Spezifikation der Firma Microsoft, die bislang keiner Standardisierung unterworfen wurde WS-Addressing Definition WS-Addressing ermöglicht die Identifizierung und Referenzierung von Web ServiceEndpunkten und spezifiziert einen Nachrichten-Header, um Informationen über den Nachrichtenaustausch in einer Nachricht einzufügen. 100

101 Grundlagen WS-Addressing bestehend aus den Substandards Web Services Addressing - Core Web Services Addressing Metadata Web Services Addressing - SOAP Binding Web Services Addressing - Core Der WS-Adressing Core Standard stellt einen transportneutralen Mechanismus zur Adressierung von Web Services und Nachrichten bereit. Diese Adressierungsmöglichkeit von Web Services wird als Endpunkt-Referenz (EPR) bezeichnet und basiert auf einer XMLStruktur, die die Adresse des Services als URI sowie die optionalen Elemente Parameter und Metadaten umfasst. Durch WS-Addressing Core im Release 1.0 wurde zudem der Message-Information-Header eingeführt, der zusätzliche Metainformationen wie die Zieladresse einer Nachricht, die Adresse für die Antwort auf eine Nachricht und die Adresse für die Antwort im Fehlerfall enthält. Zusätzlich kann ein Message Information Header eine eindeutige ID enthalten, um einen Kommunikationskontext unabhängig von dem Transportprotokoll zu gewährleisten. Dies kann beispielsweise einem Dienst und seinen Nutzern eine asynchrone Kommunikation ermöglichen, da die Service Consumer eingehende Antwortnachrichten mittels der ID den zuvor gestellten Dienstanfragen zuordnen können. Die Endpunkt-Referenz sowie der Message-Information-Header sind erweiterbar, wiederverwendbar und protokollunabhängig. Diese Eigenschaft ermöglicht es, dass andere Spezifikationen auf der WS-Addressing-Core-Spezifikation aufbauen können. Beispielsweise definiert WS-Addressing-SOAP-Binding die Verwendung des Message-Information-Headers in SOAP. Web Services Addressing - Metadata Die WS-Addressing-Metadata-Spezifikation beschreibt den Zusammenhang und die Verwendung der WS-Addressing-Eigenschaften (beschrieben in WS-Addressing-Core) mit WSDL und WS-Policy. Dazu wird definiert, wie eine Endpunkt-Referenz ebenfalls eine Referenz auf die WSDL-Definition eines Dienstes enthalten kann und wie EndpunktReferenzen in WSDL verwendet werden können. In Hinblick auf WS-Policy definiert die Spezifikation Assertions (vgl. WS-Policy) für die Verwendung in WS-Policy, damit beispielsweise ein Dienst Anforderungen an die Verwendung von WS-Addressing stellen kann. Web Services Addressing - SOAP Binding Web Services Addressing SOAP Binding definiert die Verwendung der abstrakten Eigenschaften von WS-Addressing (spezifiziert durch WS-Addressing Core) in einer SOAP Nachricht. So beschreibt das SOAP Binding die Verwendung des Message-InformationHeaders als SOAP Header Schemata Ein Schema ist unter zu finden. 101

102 Szenarien Werden Nachrichten z.b. zwischen Unternehmen oder Organisationen ausgetauscht, so muss ein Transport einer Nachricht über Proxies, Firewalls und Gateways hinweg möglich sein. Die Nachricht durchläuft dabei ggf. mehrere Netze mit unterschiedlichen Transportprotokollen. Um eine Nachricht korrekt ausliefern zu können, muss sie daher alle notwendigen Informationen über ihren Endpunkt, d.h. ihre Lieferadresse enthalten. Nur so kann sie korrekt weitergeleitet werden. Mit WS-Addressing lassen sich diese Informationen in den Header einer Nachricht integrieren Empfehlung zur Anwendung Alle drei Standards zu WS-Addressing (Web Services Addressing 1.0 Core, Web Services Addressing 1.0 Metadata und Web Services Addressing 1.0 SOAP Binding) werden vom W3C als Recommendation geführt und werden daher für die Adressierung von Web Services empfohlen (1) WS-Routing Definition WS-Routing beschreibt den Weg, den eine Nachricht vom initialen Sender zum endgültigen Empfänger über eine Gruppe von optionalen Intermediären nehmen kann. Dies kann innerhalb des SOAP Headers über das Web Service Routing Protokoll ausgedrückt werden. Die Spezifikation ermöglicht Nachrichtenaustausch-Muster wie z.b. request/response, Nachrichtenbestätigungen und Peer-to-Peer Konversationen. WS-Routing ist eine SOAP Erweiterung zur Spezifizierung von Routen oder Pfaden (Paths) Grundlagen WS-Routing kommt meist mit weiteren SOAP basierten Protokollen zum Einsatz, um sichere und vertrauensvolle Services zu gewährleisten. Folgende Darstellung zeigt ein Beispiel in dem A der initiale Sender ist, der über die Intermediäre B und C eine SOAP Nachricht an den Empfänger D sendet. SenderA In te rm e d iä r B In te rm e d iä r C E m p fä n g e r D Abbildung 25: Beispiel für WS-Routing. Die WS-Routing Spezifikation definiert hier ein so genanntes Pfad-Element, welches dem Header eine SOAP Nachricht hinzugefügt wird. Anschließend wird die SOAP Nachricht über die Intermediäre B und C geroutet. Das folgende Beispiel veranschaulicht, wie der Pfad in der oben gezeigten Abbildung in einer Nachricht durch einen SOAP Sender A abgebildet wird. 102

103 (01)<SOAP-ENV:Envelope (02) xmlns:soap-env=" (03) <SOAP-ENV:Header> (04) <wsrp:path xmlns:wsrp=" (05) <wsrp:action> (06) <wsrp:to>soap://d.com/some/endpoint</wsrp:to> (07) <wsrp:fwd> (08) <wsrp:via>soap://b.com</wsrp:via> (09) <wsrp:via>soap://c.com</wsrp:via> (10) </wsrp:fwd> (11) <wsrp:from>soap://a.com/some/endpoint</wsrp:from> (11) <wsrp:id>uuid:84b9f5d0-33fb-4a81-b02b -5b760641c1d6</wsrp:id> (12) </wsrp:path> (13) </SOAP-ENV:Header> (14) <SOAP-ENV:Body> (15)... (16) </SOAP-ENV:Body> (17)</SOAP-ENV:Envelope> Elementbeschreibung: from intialer Sender A, to Empfänger D, fwd Intermediäre B und C, rev Nachrichtenpfad für Rückrichtung. Das Element rev dient dem Zwei-Wege Nachrichtenaustausch Szenarien WS-Routing verfolgt ein vergleichbares Ziel wie WS-Addressing. Daher wird auf das WSAddressing Kapitel verwiesen Empfehlung zur Anwendung Bei WS-Routing handelt es sich um eine Spezifikation der Firma Microsoft. Bisher wurden von Microsoft keine Anstrengungen für eine Standardisierung unternommen. Da Microsoft selbst eine Migration von WS-Routing zu WS-Addressing empfiehlt (siehe kann davon ausgegangen werden, dass WS-Routing in Zukunft keine Bedeutung haben wird. Die Spezifikation wird daher nicht empfohlen (4). 103

104 4.6.3 WS-Eventing Definition Möchte eine Anwendung darüber informiert werden, wenn in anderen Anwendungen besondere Ereignisse (Events) auftreten, so benötigt sie einen Mechanismus, um dieses Interesse den anderen Anwendungen mitzuteilen. WS-Eventing beschreibt ein Protokoll zum Registrieren an einer Eventquelle, zum Beenden einer Subscription und zum Senden von Mitteilungen über Events Grundlagen Eine Eventquelle stellt einen Web Service zum Senden von Mitteilungen und Akzeptieren von Subskriptionen dar. Im Gegensatz dazu ist die Eventsenke ein Web Service, der es ermöglicht Mitteilungen zu empfangen, d.h. er ist einer Anwendung zugeordnet, die über Events informiert werden möchte. Der Subscription Manager in der WS-Eventing Spezifikation verwaltet die Subskriptionen einer Eventquelle. Diese Aufgabe kann von der Eventquelle selbst übernommen werden oder an einen dafür vorgesehenen Web Service delegiert werden. Standardmäßig definiert WS-Eventing nur das Push Verfahren als Möglichkeit zur Nachrichtenübermittlung. WS-Eventing ist jedoch so ausgelegt, dass weitere Delivery Verfahren wie z.b. Poll möglich sind, d.h. es ist jederzeit möglich, weitere Verfahren zur Nachrichtenübermittlung zu definieren. Ziel ist es, dass es keine Einschränkungen in Bezug auf die Nachrichtenübermittlung durch die Spezifikation gibt. Mit Hilfe von WS-Eventing ist es möglich, Subskriptionen zu erstellen und zu löschen, den Ablauf für Subskriptionen zu definieren und diese gegebenenfalls zu erneuern. WS-Eventing unterstützt verschiedene Enkodierungsformate wie z.b. SOAP 1.1 und SOAP 1.2. Filterausdrücke werden zwar unterstützt, allerdings können die Nachrichten nicht mit Hilfe von Topics kategorisiert werden Schemata Ein Schema ist unter zu finden Szenarien WS-Eventing bietet sich für ähnliche Szenarien an wie auch WS-Notification. Daher wird auf das WS-Notification Kapitel verwiesen Empfehlung zur Anwendung Da der Standard aktuell nur als Public Draft vorliegt und sich in Konkurrenz zu WSNotification befindet, kann der Einsatz nicht uneingeschränkt befürwortet werden. Daher ist der Standard zu beobachten (3). 104

105 4.6.4 WS-Notification Definition Die Spezifikation WS-Notification (WSN) besteht aus drei Substandards WS-BaseNotification, WS-Topics und WS-BrokeredNotification. Sie spezifiziert den zum Publish-Subscribe Prozess gehörenden Datentransfer für Web Services. Als Verfahren zur Übertragung von Notifications sind in der Spezifikation Push und Pull Verfahren beschrieben. Das Pull Verfahren kommt z.b. bei einer Trennung von NotificationProducer und NotificationConsumer durch eine Firewall zum Einsatz Grundlagen WS-Notification setzt das so genannte Notification Pattern um. Kernelement des Pattern ist das so genannte Event. Ein Event ist ein beliebiges Ereignis, über welches die so genannten NotificationConsumer informiert werden möchten. WS-BaseNotification WS-BaseNotification stellt die Basis Spezifikation der WS-Notification Familie dar, auf der alle weiteren Spezifikationen der WSN-Familie aufbauen. Es wird zwischen den Rollen NotificationProducer und NotificationConsumer unterschieden. Der NotificationProducer erzeugt die so genannten Notifications und versendet diese an den NotificationConsumer. Dazu muss sich der NotficationConsumer vorher durch Versand eines Registrierungs-Request (Subscription Request) angemeldet haben und einen geeigneten Service für den Empfang der Notifications bereithalten. S u b sc rib e R e q u e st N o tific a tio n P ro d u c e r N o tific a tio n C o n su m er N o tific a tio n Abbildung 26: Notification Pattern Der Subscribe Request enthält eine Referenz des NotificationConsumers. Ist der Subscribe Request vom NotificationProducer bestätigt, kann der NotificationConsumer Notifications empfangen. Es besteht die Möglichkeit Notifications zu filtern. Die drei in der WS-BaseNotification Spezifikation definierten Filterarten sind der Nachrichtenfilter, der Topic Filter und der Producer Statusfilter. 105

106 Um die Sicherheit während des Austauschs zwischen NotificationProducer und NotificationConsumer zu gewährleisten wird empfohlen, dass der in WS-Security beschriebene Mechanismus eingesetzt wird. Außerdem wird empfohlen Security Policies einzuführen, so dass nur autorisierte NotificationConsumer Registrierungen durchführen, ändern oder löschen können. WS-Topics Die WS-Topics Spezifikation bietet einen Mechanismus zur Kategorisierung und Organisation von Nachrichten nach Topics. Um den in WS-Topics spezifizierten Mechanismus einzusetzen wird auf den Notification Mechanismus in WS-BaseNotification zurückgegriffen. Topics sind vergleichbar mit Filtern aus der WS-BaseNotification. Topics werden bei der Registrierung von Subscribern sowie bei der Erstellung von Nachrichten eines Publisher angewandt. Topics sind nicht Bestandteil der Notificationnachricht. Jedes einzelne Topic wird einem XML Namespace mit einem eindeutigen URI zugeordnet. Damit soll vermieden werden, dass unterschiedliche Anwendungen den gleichen Topic Namen verwenden. Durch Metadaten wird die Beziehung von Topic zu XML Namespace beschrieben. Für den NotificationProducer ist daraus sofort ersichtlich wie eine Event Nachricht aufgebaut ist. In WS-Topics sind Regeln zur Vermeidung von Inkonsistenzen definiert wie z.b., dass ein Topic keine zwei gleich benannten Entitäten besitzen kann. Die Sicherheitaspekte von WS-Topics werden in den Spezifikationen WS-BaseNotification und WS-BokeredNotification beschrieben. Hier wird empfohlen, die Authorisierungsregeln an die Granularität der Topics anzupassen. WS-BrokeredNotification Der Substandard WS-BrokeredNotification spezifiziert einen Zwischenhändler (Intermediär) zwischen dem NotificationProducer und dem NotificationConsumer. Der NotificationBroker steht zentral zwischen diesen beiden und agiert gleichzeitig selbst als NotificationProducer und NotificationConsumer. S u b sc rib e R e q u e st P u b lish e r N o tific a tio n C o n su m e r N o tific a tio n B ro k e r P u b lish N o tific a tio n N o tific a tio n Abbildung 27: Brokered Notification Pattern Der Publisher entspricht in diesem Fall einem NotificationProducer, mit dem Unterschied, dass er keine Möglichkeiten für einen Subscribe Request anbieten muss, da diese Funktionalität vom NotificationBroker übernommen werden kann. Durch einen NotificationBroker ist z.b. ein Load-Balancing möglich. Der NotificationBroker baut wie auch schon die WS-Topic Spezifikation auf der Basis Spezifikation WSBaseNotification auf. Durch den WS-NotificationBroker ist es möglich, die direkte Kommunikation zwischen Publisher und Consumer gewollt zu vermeiden. 106

107 In der WS-BrokeredNotification Spezifikation ist es möglich, Bedarfs-basiert zu publizieren. Der Producer muss somit lediglich eine Subscription selbständig verwalten. Dazu registrieren sich die Producer am NotificationBroker, welcher anschließend die Nachrichten filtert. Diese Vorgehensweise kann den Nachrichtenverkehr erheblich senken Szenarien Bei einem klassischen Web Service kann eine Anwendung bei Bedarf Daten an den Service senden oder Daten von dem Service abrufen. Häufig ist es jedoch notwendig, dass eine Anwendung über besondere Ereignisse benachrichtigt wird. Will sich ein Nutzer z.b. über die Wettervorhersage informieren, so kann er die Daten von einem entsprechenden Web Service abfragen. Geht es jedoch darum, eine Unwetterwarnung zu verschicken, so muss eine entsprechende Warnung an eine Vielzahl von Nutzern verschickt werden. WS-Notification bietet die notwendigen Mechanismen, um solche Szenarien mittels Web Services zu realisieren Empfehlung zur Anwendung Die Standards werden durch OASIS verwaltet und sind dort bis auf WS-Topics 1.3 als Approved Standard geführt. WS-Notification befindet sich in Konkurrenz zu WS-Eventing. Es gibt Bestrebungen beide Standards in einem WS-EventNotification Standard zusammenzuführen. Konkrete Ergebnisse dieser Bemühungen müssen abgewartet werden. Daher ist der Standard genau wie WS-Eventing zu beobachten (3). 4.7 Reliable-Messaging Nachfolgend beschrieben werden die Spezifikationen: WS-Reliability und WS-ReliableMessaging WS-Reliability Definition WS-Reliability ist eine Spezifikation, die ähnlich wie WS-ReliableMessaging (siehe nächster Abschnitt) zur Sicherstellung einer Nachrichtenübertragung erstellt wurde. Es soll speziell kritische Web Service Applikationen, z.b. einen Service zum Durchführen von Banktransaktionen, dabei unterstützen, eine zuverlässige Übertragung von Nachrichten zu verfolgen und zu kontrollieren Grundlagen Die WS-Reliability Spezifikation wurde vor WS-ReliableMessaging von OASIS mit der Unterstützung eines Konsortiums aus mehren Firmen Fujitsu, Hitachi, NEC, Oracle 107

108 Corporation, Progress Software und Sun Microsystems aus der ebxml Message Service Spezifikation heraus entwickelt. Obwohl dieser Standard in die WS-* Sammlung einzuordnen ist, ist WS-Reliability nicht an die übrigen WS-* Spezifikationen angepasst bzw. nicht mit ihnen abgestimmt. Dies ist unter anderem darauf zurückzuführen, dass WS-Reliability nicht wie WS-ReliableMessaging (siehe nächsten Abschnitt) von Firmen wie Microsoft und IBM, die an der Entwicklung vieler WS-* Spezifikationen beteiligt sind, entwickelt wurde. Die Spezifikation wurde hingegen zur Nutzung bzw. Kombination mit anderen, komplementären Protokollen wie z.b. ebxml, SOAP Message Security 1.0 oder WS-I Basic Profile 1.1 geschaffen. SOAP über HTTP alleine ist nicht geeignet, sobald ein Kommunikationsprotokoll auf Applikationsebene ein gewisses Maß an Zuverlässigkeit und Sicherheit garantieren muss. WS-Reliability ist ein auf SOAP basierendes Protokoll für den zuverlässigen Austausch von SOAP Nachrichten mit garantierter Zustellung und kann in HTTP eingebettet werden. WS-Reliability garantiert nicht nur den Versand, sondern belässt die Nachrichten beim Absender, solange die Verantwortung für eine Nachricht an den Empfänger übertragen wurde, eliminiert Duplikate von Nachrichten, ordnet und gruppiert die Nachrichten und gibt eine Reihenfolge vor, in der die Nachrichten verschickt werden sollen und informiert über den erfragten Status. Die Funktionen zur Erreichung einer verlässlichen Nachrichtenübertragung durch WSReliability basieren auf Erweiterungen von SOAP und nicht nur auf den darunter liegenden Transportprotokollen. Dadurch erlaubt die Spezifikation einer großen Anzahl verschiedenster Systeme zuverlässig interoperabel in einer plattform- und herstellerunabhängigen Landschaft zu interagieren.[wsr] Schemata Ein Standard-Schema kann unter abgerufen und verwendet werden Szenarien WS-Reliability definiert Zuverlässigkeit im Kontext von aktuellen Web Service Standards. Da dies grob den Aufgaben von WS-ReliableMessaging entspricht, unterscheiden sich die Szenarien an dieser Stelle nicht. Daher ist das Szenario im nächsten Abschnitt zu WSReliableMessaging beschrieben Empfehlung zur Anwendung Es ist der Trend zu erkennen, dass WS-Reliability mehr und mehr von WSReliableMessaging verdrängt wird. Die meisten Anbieter, die WS-Reliability entwickelt haben, unterstützen heute auch WS-ReliableMessaging. Daher sollte die Entwicklung dieser Spezifikation nur beobachtet werden (3). 108

109 4.7.2 WS-ReliableMessaging Definition WS-ReliableMessaging (WS-RM) ist ein Nachrichtenprotokoll zur Identifikation, Verfolgung und Durchführung einer zuverlässigen Übertragung von Nachrichten, die zwischen zwei Partnern, einer Quelle und einem Ziel, verschickt werden. WS-RM definiert eine Einbindung in SOAP, die für die Interoperabilität notwendig ist und zusätzliche Sicherheitsanforderungen wie z.b. Integrität ermöglicht Grundlagen WS-ReliableMessaging (WS-RM) wurde von BEA, IBM, Microsoft und TIBCO Software entwickelt mit der Absicht, einen erfolgreichen Versand einer Nachricht zu garantieren. Es wird in die Nachrichtenversendung (Binding Block) integriert und komplettiert WS-Security, WS-Policy und andere Web Service Spezifikationen. WS-RM stellt des Weiteren die folgenden Funktionen bereit, sobald eine Nachricht zwischen zwei Endpunkten (RMSource und RMDestination ) verschickt wird: Bestimmung des Nachrichtenstatus, Lieferung von Nachrichten in angefordertem Zustand, Eliminierung von Duplikaten. Das Reliable Messaging Model sieht vor, dass eine zuverlässige Quelle und ein zuverlässiges Ziel dazu genutzt werden, einer Web Service Quelle bzw. einem Ziel den zuverlässigen Versand einer Nachricht zu garantieren. Diese Garantie wird auch Zusicherung eines Versands (delivery assurance) genannt. Das Protokoll WS-RM unterstützt die jeweiligen Endpunkte dabei, eine delivery assurance bereitzustellen. Es gibt vier Grundzusicherungen (assurances), die die Endpunkte eines Web Service bereitstellen können: AtMostOnce : Nachrichten werden ggf. nicht geliefert; eine Mehrfachlieferung ist ausgeschlossen. AtLeastOnce : Nachrichten werden mindestens einmal (oder auch öfter) geliefert; eine Fehlermeldung wird erzeugt, falls keine der Nachrichten zugestellt werden konnte. ExactlyOnce : Jede Nachricht wird exakt einmal geschickt; eine Fehlermeldung wird erzeugt, falls die Nachricht nicht zugestellt werden können. InOrder: Nachrichten werden auf Hin- und Rückweg in derselben Reihenfolge verschickt; diese assurance kann mit den bereits genannten kombiniert werden. Die folgende Darstellung veranschaulicht, wie dieser Prozess abläuft. 109

110 V ersen d er E m p fä n g e r A p p lik a tio n sq u e lle A p p lik a tio n sz ie l a u s lie fe rn sen d en R M Q u e lle ü b e rm itte ln R M Z ie l b e stä tig e n e rh a lte n Abbildung 28: Darstellung der Funktionsweise von WSReliableMessaging [WSRM] Es sind jedoch einige Voraussetzungen zu erfüllen, damit ein einwandfreier Ablauf so möglich ist. Dabei wird die Integration anderer Web Service Spezifikationen erkennbar: Die RM-Quelle muss eine Endpunkt-Referenz eines RM-Ziels kennen (WS- Addressing) Die RM-Quelle muss die Policy des RM-Ziels kennen (WSRM-Policy) Die RM-Quelle und das RM-Ziel müssen im Security-Kontext stehen, sobald ein Nachrichtenaustausch erforderlich ist (WS-Security) Im Falle von Protokoll-Invarianten muss die RM-Quelle eine sequenzielle Nummer vergeben muss das RM-Ziel ein Acknowledgement in die Nachrichten integrieren Die folgende Darstellung zeigt den Ablauf in detaillierterer Form. Hierbei ist zu sehen, dass die zweite Nachricht (MessageNumber = 2) aufgrund einer Störung beim ersten Versuch nicht beim Web Service B ankommt. Erst nach nochmaligem Versuch wird die Nachricht erfolgreich zugestellt. 110

111 W e b se rv ic e A R e lia b le M e ssa g in g P ro to k o ll W e b se rv ic e B E t a b lie r u n g v o n P r o to k o ll-b e d in g u n g e n S e q u e n c e w ir d e r s t e llt (C r e a t e S e q u e n c e ()) S e q u e n c e -A n t w o rt w ir d e r s te llt (C r e a t e S e q u e n c e R e s p o n s e (Id e n t ifie r = h t t p :// )) N a c h r ic h t s e n d e n (S e q u e n c e (Id e n t ifie r = h t t p ://, M e s s a g e N u m b e r = 1 )) N a c h r ic h t s e n d e n (S e q u e n c e (Id e n t ifie r = h t t p ://, M e s s a g e N u m b e r = 2 )) N a c h r ic h t s e n d e n (S e q u e n c e (Id e n t ifie r = h t t p ://, M e s s a g e N u m b e r = 3, L a s t M e s s a g e ) B e s t ä t ig u n g e r h a lte n (S e q u e n c e A c k n o w le d g e m e n t (Id e n t ifie r = h t t p ://, A c k n o w le d g e m e n tr a n g e = 1,3 ) B e s t ä t ig u n g a n fo rd e rn (S e q u e n c e (Id e n t ifie r = h t t p ://, M e s s a g e N u m b e r = 2, A c k R e q u e s te d ) B e s t ä t ig u n g e r h a lte n (S e q u e n c e A c k n o w le d g e m e n t (Id e n t ifie r = h t t p ://, A c k n o w le d g e m e n tr a n g e = ) S e q u e n c e t e r m in ie r e n (T e r m in a te S e q u e n c e (Id e n t ifie r = h t t p :// )) Abbildung 29: Detaillierte Darstellung des Ablaufs von WS-ReliableMessaging [WSRM] Schemata Ein Standard-Schema ist unter zu finden. Zudem kann ein Schema für die auf WS-ReliableMessaging zugeschnittenen Policy Assertions unter abgerufen werden Szenarien Das WS-ReliableMessaging Protokoll wird z.b. von Firmen, B2B Applikationen und kritischen Infrastruktursystemen verwendet, die Garantien für den Empfang von Nachrichten geben müssen. Ohne entsprechende Mechanismen können durch Fehler in der Nachrichtenzustellung Übertragungen abgebrochen werden, Nachrichten verloren gehen, Nachrichten fälschlicherweise dupliziert oder neu angefragt werden oder ganze Arbeitsstände verloren gehen. WS-RM hilft dabei, dies zu verhindern Empfehlung zur Anwendung Die Nutzung von WS-ReliableMessaging ist grundsätzlich empfehlenswert (1), wenn für einen Web Service die Zusicherung gebraucht wird, dass Nachrichten korrekt verschickt und somit auch korrekt verarbeitet worden sind. 4.8 Transaction Specifications Zuverlässiges Transaktionsmanagement ist für die meisten Geschäftsanwendungen eine notwendige Voraussetzung für den Betrieb. In den folgenden Kapiteln werden die 111

112 Spezifikationen der Protokolle zur Transaktionssteuerung beschrieben. Alle im Folgenden erläuterten Spezifikationen basieren auf SOAP und WSDL und bilden eine Erweiterung dieser WS-Coordination Definition Web Services verbinden zunehmend komplexe und umfangreiche verteilte Anwendungen. Ein Geschäftsvorgang (Aktivität) besteht meistens aus mehreren Teilaufgaben, die durch Web Services ausgeführt werden. Um die konsistente Ausführung des Geschäftsvorgangs zu gewährleisten und die Ergebnisse der einzelnen Teilaufgaben zusammenzuführen wurde das WS-Coordination Framework erstellt. WS-Coordination beschreibt ein Modell für ein Transaktionsmanagementsystem, um Transaktionen im Umfeld von Web Services zu realisieren. Eine Transaktion wird in der Regel als eine Zusammenfassung logisch zusammenhängender Einzeloperationen definiert, die sich durch die Einhaltung der ACID Eigenschaften (Atomicity, Consistency, Isolation, Durability) auszeichnet Grundlagen Das Framework erleichtert die Implementierung verteilter Anwendungen, indem es eine Basis für die Erstellung eines so genannten Koordinators bildet. Der Koordinator ist für die Abstimmung der Arbeit zwischen den einzelnen Aktivitäten verantwortlich. Dazu registrieren sich die beteiligten Web Services beim Koordinator. Je nach Art der umzusetzenden Transaktionen (z.b. kurz- oder langlaufende Transaktionen) kommen unterschiedliche Koordinatorprotokolle zum Einsatz. Aus diesem Grund werden diese nicht in WS-Coordination definiert. WS-AtomicTransaction und WS-BusinessActivity sind Beispiele für zwei Standards, die entsprechende Koordinatorprotokolle definieren. Das WS-Coordination Framework besteht aus den folgenden Komponenten: Activation Service bietet den Einstiegspunkt für eine Applikation (Initiator) um eine Aktivität zu starten. Der Activation Service initiiert die Erstellung des Koordinationskontextes (CoordinationContext). Der CoordinationContext ist ein Objekt, dass an die Teilnehmer einer Aktivität gesendet wird und in dem der Zustand und Informationen zu einer Aktivität gespeichert sind. Ein Beispiel für ein enthaltenes Datum wäre die Verfallszeit für das Kontextobjekt. Registration Service dient als Registrierungsinstanz für Web Services, die an einer Aktivität teilnehmen wollen. Sobald der teilnehmende Web Service den CoordinationContext vom Activation Service erfolgreich erhalten hat, kann er sich für die Teilnahme an einer Aktivität anmelden. Protokolle für die Beschreibung von Koordinationsmodellen Die enthaltenen Protokolle bilden eine Basis für die Implementierung von eigenen Koordinationsmodellen. Es sind bislang zwei konkrete Implementierungen vorhanden WS-AtomicTransaction und WS-Business Activity. Diese werden in den nächsten Kapiteln erläutert. 112

113 Jeder Teilnehmer bzw. Web Service kann einen eigenen Koordinator implementieren, der basierend auf dem CoordinationContext Objekt der anderen Teilnehmer die ihm zugeordnete Aktivität steuert und die Ergebnisse an die Teilnehmer sendet. Die eigentliche Kommunikation erfolgt dabei über das Koordinationsprotokoll wie z.b. WSAtomicTransaction Szenarien Im folgenden Bild wird das Zusammenspiel der einzelnen Komponenten dargestellt: Web Service Web Service Kontext erstellen Beteiligung registrieren Koordinator Activation Service Registration Service Koordinationsmodell Protokoll Service Koordinationsprotokoll Web Service Abbildung 30: Zusammenspiel der einzelnen Komponenten bei WSCoordination Ein wichtiges Thema in der WS-Coordination Spezifikation ist die Sicherheit der Anwendung. Bei der Umsetzung von Transaktionen spielen Sicherheitsüberlegungen immer eine große Rolle. Daher definiert WS-Coordination eine Reihe von Sicherheitszielen: Nur autorisierte Teilnehmer können einen CoordinationContext erstellen Nur autorisierte Teilnehmer können sich für eine Aktivität registrieren Nur legitimierte CoordinationContext Objekte dürfen für die Registrierung an einer Aktivität verwendet werden Vorhandene Sicherheitsinfrastrukturen können genutzt werden (z.b. WS-Security) Die Autorisierung kann sowohl auf der Ebene einer Einzelidentität als auch einer Gruppe erfolgen Diese Ziele haben ihren Ursprung in den allgemeinen Anforderungen Integrität, Vertraulichkeit und Authentifizierung. Das in WS-Coordination beschriebene Sicherheitsmodell erläutert, wie mit Hilfe der Web Service Spezifikationen WS-Security, 113

114 WS-Trust, WS-Policy und WS-SecureConversation diese Sicherheitsziele erreicht werden können Empfehlung zur Anwendung WS-Coordination ist ein Baustein des Web Service Coordination Frameworks und benötigt für die Umsetzung eines Transaktionsmanagements für Web Services weitere Standards wie WS-AtomicTransaction und WS-BusinessActivity. Im Zusammenspiel mit den anderen Spezifikationen des Web Service Coordination Frameworks wird der Standard empfohlen (1) WS-AtomicTransaction Definition WS-AtomicTransaction definiert auf Basis von WS-Coordination ein Koordinatorprotokoll. Ziel von WS-Atomic Transaction ist es, kurzlaufende Transaktionen zu unterstützen. Es kann genutzt werden um kurze ACID-konforme Transaktionen (atomar, konsistent, isoliert, dauerhaft) in dezentralen Umgebungen auf Basis von Web Services auszuführen Grundlagen Eine atomare Transaktion kann als Ergebnis nur zwei Zustände liefern. Entweder die Transaktion ist erfolgreich ausgeführt worden oder sie ist fehlerhaft. Ein teilweiser Erfolg ist also nicht möglich. Eine atomare Transaktion erfordert einen hohen Grad an Zuverlässigkeit der Teilnehmer und ist meistens nur von kurzer Dauer, da die Ressourcen während einer Transaktion gesperrt werden sollten. WS-AtomicTransaction baut auf WS-Coordination auf und besteht aus zwei Protokollspezifikationen: Two-Phase Commit (2PC) Koordiniert die Teilnehmer, um die Entscheidung zu treffen, ob eine Transaktion erfolgreich oder nicht erfolgreich verlaufen ist und stellt sicher, dass die Teilnehmer darüber informiert werden. Das 2PC Protokoll besteht aus zwei Varianten: Volatile Two-Phase Commit (Volatile 2PC) Für Teilnehmer, die flüchtige Ressourcen managen wie z.b. Cache Ressourcen. Durable Two-Phase Commit (Durable 2PC) Für Teilnehmer, die nicht flüchtige Ressourcen managen wie z.b. Datenbank Management Systeme Completion Initiiert die Commit Verarbeitung. Abhängig von den für das jeweilige Protokoll registrierten Teilnehmern beginnt der Koordinator mit Volatile 2PC und geht über zu Durable 2PC. Das Endergebnis wird an den Initiator zurückgegeben. Die Protokolle beschreiben die Kommunikation zwischen den einzelnen Teilnehmern als Zustandsautomaten mit ihren definierten Zuständen, Transitionen zwischen den Zuständen und Nachrichten, die ausgetauscht werden. Zusätzlich sind folgende Bestandteile, die für die komplette Beschreibung einer atomaren Transaktion notwendig sind, enthalten: 114

115 Atomic Transaction Context Baut auf der CoordinationContext Spezifikation auf und stellt eine Erweiterung dieser im Hinblick auf atomare Transaktionen dar. Policy Assertion Die WS-Policy Definition kann bei der Beschreibung von atomaren Transaktionen verwendet werden, um Policies zu definieren. Transaction Faults Beschreibt Fehlernachrichten, die im Rahmen von atomaren Transaktionen ausgetauscht werden können. Security Model Das Sicherheitsmodell der AtomicTransaction basiert auf dem WS-Coordination Security Model und kann um spezielle Aspekte für atomare Transaktionen erweitert werden Szenarien Ein mögliches Szenario für eine atomare Transaktion wäre eine Geldüberweisung von einer Bank zur anderen. Diese besteht aus zwei Aktionen die atomar, also untrennbar, ausgeführt werden müssen. Zum einen muss das Geld auf dem Zielkonto gebucht werden und zum anderen muss es von dem Ursprungskonto abgebucht werden. Wenn eine der Aktionen nicht erfolgreich ist, muss sichergestellt werden, dass alle Aktionen zurückgenommen werden. Eine atomare Transaktion wird von einem Initiator angestoßen, von einem Koordinator gesteuert und von mehreren Teilnehmern ausgeführt. Ergebnis Anforderung Initiator Koordinator Teilnehmer 1 Teilnehmer 2 Teilnehmer n Abbildung 31: Szenario WS-AtomicTransaction Jeder Teilnehmer einer Transaktion hat eine bestimmte Aufgabe zu erfüllen. Zunächst werden alle Aufgaben von den Teilnehmern probehalber ausgeführt. Jeder Teilnehmer meldet an den Koordinator, ob seine Aufgabe mit Erfolg ausgeführt werden konnte. Erhält der Koordinator von einem oder mehreren Teilnehmer die Rückmeldung, dass eine Aufgabe nicht erfolgreich durchgeführt werden konnte, so gibt er an alle Teilnehmer die Anweisung, dass alle Aufgaben derart abgebrochen werden, als wenn sie niemals stattgefunden hätten. 115

116 Nur wenn alle Teilnehmer einen Erfolg vermelden, wird die Transaktion als Erfolg gewertet. Nur dann meldet der Koordinator den Erfolg an alle Teilnehmer, die dann ihre Aufgaben final durchführen, d.h. z.b. das Ergebnis persistent speichern Empfehlung zur Anwendung Der Einsatz wird zusammen mit WS-Coordination empfohlen (1) WS-BusinessActivity Definition WS-BusinessActivity definiert auf Basis von WS-Coordination ein Koordinatorprotokoll. Im Gegensatz zu WS-AtomicTransaction stehen dabei jedoch langlaufende Transaktionen im Vordergrund Grundlagen Im Gegensatz zu kurzlaufenden Transaktionen werden bei langlaufenden Transaktionen einzelne Aufgaben permanent ausgeführt, bevor die gesamte Transaktion abgeschlossen wird. Daher sind zusätzliche Mechanismen notwendig, um diese Änderungen wieder rückgängig zu machen, wenn die Transaktion scheitert (Compensation). WS-BusinessActivity stellt entsprechende Protokolle zur Verfügung, die es ermöglichen, dass existierende Geschäftsprozess- und Workflow-Systeme ihre proprietären Mechanismen kapseln und über Vertrauensgrenzen und unterschiedliche Herstellerimplementierungen hinweg interagieren. Die Merkmale einer Geschäftsaktivität sind gemäß WS-BusinessActivity wie folgt charakterisiert: Eine Geschäftsaktivität kann viele Ressourcen über einen langen Zeitraum verwenden. Sie kann aus einer großen Anzahl von atomaren Transaktionen bestehen. Einzelne Aufgaben können vor dem Ende einer Geschäftsaktivität bereits ausgeführt werden und externe Systeme beeinflussen. Die Antwortzeit für eine Anfrage kann unter Umständen sehr lange dauern (z.b. im Rahmen der Benutzerinteraktion oder während eines Herstellungsprozesses). Falls bei einem Fehler eine oder mehrere Aktionen zurückgenommen werden müssen, ist eine effektive Fehlerbehandlung erforderlich. Teilnehmer einer Geschäftsaktivität könnten unterschiedliche Authentifizierungsverfahren verwenden und müssen individuell authentifiziert werden. Um insbesondere mit der Anforderung der Langläufigkeit umzugehen, werden die Transaktionseigenschaften der Atomarität und Isolation aufgeweicht. Beispielsweise wird nicht gefordert, dass alle Änderungen erst nach Erfolg der gesamten Transaktion final 116

117 durchgeführt werden, sondern Aktivitäten können schon vor Ende der Transaktion abgeschlossen werden. Für den Fehlerfall ist ein Kompensationskonzept vorgesehen, welches es erlaubt, bereits durchgeführte Aktivitäten wieder rückgängig zu machen. Die Spezifikation umfasst folgende Protokolltypen für die Kommunikation: BusinessAgreementWithParticipantCompletion Der Teilnehmer registriert sich mit Hilfe des eigenen Koordinators, so dass er von diesem gesteuert werden kann. Der Teilnehmer ist in der Lage, selbst die Fertigstellung seiner Aufträge zu erkennen. BusinessAgreementWithCoordinatorCompletion - Der Teilnehmer registriert sich mit Hilfe des eigenen Koordinators, so dass er von diesem gesteuert werden kann. Der Teilnehmer erhält vom Koordinator die Nachricht, dass alle Aufträge abgearbeitet wurden. Zusätzlich werden folgende Bestandteile verwendet: BusinessActivityContext Das Objekt speichert den aktuellen Zustand einer BusinessActivity. Die Definition basiert auf dem CoordinationContext aus der WSCoordination Spezifikation und erweitert diesen. Policy Assertion Die WS-Policy Definition kann bei der Beschreibung von atomaren Transaktionen verwendet werden. Security Model Das Sicherheitsmodell der WS-BusinessActivity basiert auf dem WS-Coordination Security Model und kann um spezielle Aspekte für die Abbildung von Geschäftsprozessen erweitert werden. Addressing Headers Aufgrund der Tatsache, dass das BusinessActivity Protokoll Nachrichten nach dem OneWay-Model, also ohne eine erwartete Antwort austauscht, muss eine explizite Adressierung der Nachrichten erfolgen. Die Adressierung findet dabei zwischen dem Koordinator und Teilnehmern einer Kommunikation statt. Die Spezifikationen für die Adressierung basieren auf der WS-Addressing Definition Szenarien Das Architekturmodell der Spezifikation kann verwendet werden, um komplexe Geschäftsprozesse flexibel abzubilden und eine zuverlässige Implementierung zu erleichtern. Dazu können folgende Ansätze verwendet werden: Eine Geschäftsanwendung kann in Bereiche (Business Activity Scopes) aufgeteilt werden. Ein Bereich kann aus mehreren Einzelprozessen bestehen, die mit Hilfe von Web Services abgebildet werden und ein gemeinsames Ergebnis zurückgeben. Mehrere Bereiche können hierarchisch untereinander organisiert werden. Teilnehmer einer Business Activity können diese jederzeit verlassen, ohne das Ergebnis der Gesamtberechnung abzuwarten. Somit ist die Anzahl der Teilnehmer dynamisch und kann im laufenden Prozess angepasst werden. Ein Teilnehmer kann ohne eine Aufforderung das Ergebnis seiner Logik abliefern, um Verzögerungen im Rahmen des gesamten Prozesses zu minimieren Empfehlung zur Anwendung Der Einsatz wird in Zusammenhang mit WS-Coordination empfohlen (1). 117

118 4.9 Dienste orchestrieren und choreographieren Im folgenden Kapitel werden die Standards WSFL, BPEL, WS-CDL und ebxml für die Orchestrierung und Choreographie von Web Services beschrieben WSFL Definition WSFL steht für Web Services Flow Language (WSFL) und ist eine XML-basierte, graphenorientierte Sprache zur Beschreibung von Workflows und Geschäftsprozessen auf Basis von Web Services. Sie gibt also Aufschluss darüber, wie sich Web Services zusammensetzen bzw. wie diese interagieren. Dadurch können nicht nur Workflows bzw. Geschäftsprozesse definiert werden, sondern auch die allgemeine Interaktion zwischen den Geschäftspartnern Grundlagen WSFL wurde von IBM entwickelt mit dem Ziel, eine nahtlose Integration von Applikationen, unabhängig von Programmiersprache oder Betriebssystem, zu schaffen und darüber hinaus eine nahtlose Integration in Geschäftsprozesse und Transaktions-Lebenszyklen, die Web Services nutzen, zu gewährleisten. Des Weiteren definiert WSFL eine öffentliche Schnittstelle, die es Geschäftsprozessen erlaubt, sich als Web Services zu präsentieren bzw. anzubieten. Der Standard WSFL baut auf WSDL auf und kann in den Kontext der WS-*-Spezifikationen eingeordnet werden. WSFL ist abhängig von Spezifikationen wie SOAP oder UDDI. WSFL berücksichtigt zwei Typen: Spezifizierung von ausführbaren Geschäftsprozessen, des so genannten Flow Model : Das Flow Model ist eine Spezifikation zur internen Ablaufsteuerung von Aktivitäten (<activity>) und deren Eigenschaften, sowie der durch Kontroll- und Datenflüsse verbundenen Aktivitäten, welche in einem Workflow abgebildet werden können. Dadurch wird beschrieben, wie ein bestimmtes Geschäftsziel erreicht werden kann was im Ergebnis zu der Beschreibung eines Geschäftsprozesses führt. Spezifizierung der Interaktion zwischen Geschäftspartnern, des so genannten Global Model : Das Global Model beschreibt alle Interaktionen zwischen Service Providern und entscheidet, welche Web Services wie miteinander interagieren und wie diese Interaktion auf die Schnittstellen der entsprechenden Web Services abgebildet werden soll. Mit Hilfe des Tags <pluglink> wird die Verknüpfung von WSDL Operationen mit den beteiligten Service Provider Typen sichergestellt. 118

119 Durch die Bereitstellung der beiden genannten Modelle hat ein Service Provider die Möglichkeit, vollständige Geschäftsprozesse ( Ende-zu-Ende ) zu beschreiben und abzubilden. [WSFL] Schemata Ein Schema zur Beschreibung der Struktur von WSFL ist in dem von IBM entwickelten WSFL-Guide unter veröffentlicht worden Szenarien Das folgende Beispiel veranschaulicht einen in WSFL beschriebenen Work Flow/Prozess einer Ticketbestellung. Die Pfeile stellen die Verknüpfung der Web Services bzw. der Interaktionspartner dar. Dieser Gesamtprozess wird durch das Global Model beschrieben. Jede einzelne Aktivität hingegen wird durch das Flow Model beschrieben. Durch die grafische Darstellung werden die Schnittstellen einzelner Web Services aufgezeigt Empfehlung zur Anwendung WSFL ist neben Flow Definition Markup Language (FDML) und Business Process Execution Language For Web Services (BPEL4WS) eine der gängigen Web Service WorkflowSprachen. WSFL wurde jedoch mit der Zeit von BPEL verdrängt, nachdem die Ideen von WSFL in die Entwicklung von BPEL einflossen. Aus diesem Grund wird empfohlen, diese Spezifikation zunächst zu beobachten (3) und mit anderen Workflow-Sprachen zu vergleichen. Abbildung 32: Darstellung eines in WSFL beschriebenen Work Flow/ Prozesses einer Ticketbestellung [WSFL] 119

120 4.9.2 BPEL Definition Die Business Process Execution Language (BPEL) ist eine von der OASIS standardisierte XML-basierte Sprache zum Orchestrieren von Web Services. Somit ermöglicht es BPEL, Services innerhalb und außerhalb einer Organisation in eine durch den Geschäftsprozess definierte Ablaufreihenfolge zu bringen. Die Vorläufer von BPEL sind die WorkflowDefinitions-Sprachen WSFL (Web Services Flow Language), XLANG (XML Language) und BPEL4WS Grundlagen WS-BPEL ist eine Sprache zur Beschreibung von Geschäftsprozessen, die durch Web Services realisiert werden. Die durch Web Services modellierten Geschäftsprozesse können wieder selbst ein Web Service sein. Dafür baut BPEL auf dem Servicemodell von WSDL auf. Die Sprache stellte spezielle Elemente bereit. Unter anderem können Aktivitäten eines Geschäftsprozesses in Scopes zusammengefasst werden. Ein Scope beinhaltet: Sequenzen von Prozessaktivitäten, vor allem Web Service Interaktionen, Korrelation von Nachrichten und Prozessinstanzen, Verhalten für die Wiederherstellung im Falle von Fehlern, Beziehungen zwischen Prozessrollen. Das Grundkonzept von BPEL kann auf zwei verschiedene Arten realisiert werden. Auf der einen Seite gibt es ausführbare BPEL-Prozesse. Sie definieren das komplette Verhalten des Geschäftsprozesses sowohl für den externen sichtbaren Teil als auch für die interne Verarbeitung. Wohingegen ein abstrakter BPEL-Prozess nur das Verhalten beschreibt und konkrete, operationale Details verbirgt, um die internen Entscheidungsgrundlagen und Vorgänge vor Geschäftspartnern geheim zu halten. Ein BPEL-Dokument enthält folgende Hauptbestandteile: Partner Link Types, Partner Links und Endpoint References: WS-BPEL kann die Beziehungen zu den Partnerprozessen, mit denen der Geschäftsprozess im Laufe der Bearbeitung interagiert, modellieren. Die Beschreibung der Funktionalität der Partnerprozesse erfolgt durch deren WSDL-Beschreibung. Die Interaktion zwischen Geschäftsprozessen und Partnern ist typischerweise Peer-to-Peer. Der Partner nimmt einerseits einen Service in Anspruch (Consumer), der vom Geschäftsprozess bereitgestellt wird, andererseits ist der Partner auch ein Provider für den Geschäftsprozess. Dieses Interaktionsmodell von BPEL erlaubt es, Nachrichten bidirektional in Peer-to-Peer Konversation auszutauschen, die über Tage, Wochen oder Monate andauern. Mit Partner Links können diese direkten Peer-to-Peer-Beziehungen modelliert werden. Correlation Sets: Mittels Correlation Sets können unterschiedliche Instanzen eines BPELProzesses unterschieden werden, um eingehende Nachrichten den richtigen Prozessinstanzen zuzuordnen. 120

121 Variables: Variables enthält eine beliebige XML-Struktur, die durch ein Schema definiert ist. Die Variablen können einerseits die Ein- und Ausgabeparameter der Activities beinhalten, andererseits aber auch zur Steuerung des Verhaltens eines Prozesses verwendet werden. Handlers: Handlers reagieren auf Änderungen im <scope> (Local variables, Local partner links, Local correlation sets, Menge von Activities (basic oder structured)). Es existieren die folgenden Handler: Event handler: Reaktion auf Ereignisse im Zusammenhang mit Nachrichten oder Zeit (Zeitüberschreitung oder Zeitdauer). Fault handler: Behandlung von unterschiedlichen außergewöhnlichen Situationen, vor allem interne Fehler. Compensation handler: Wiederherstellung in den Zustand vor der Durchführung der Aktivitäten. Termination handler: Behandlung von erzwungenen Abbrüchen von Prozessaktivitäten, vor allem externe Fehler. Activities: In BPEL werden zwei verschiedene Aktivitäten unterschieden, Basic und Structured Activities. Basic Activities beschreiben elementare Schritte des Prozessverhaltens. Structured Activities legen den Ablauf des Geschäftsprozesses fest und ermöglichen die Schachtelung von anderen Activities. So können Structured Activities rekursiv weitere Basic und/oder Structured Activities beinhalten Schemata Unter den folgenden Links sind die Schemata für alle notwendigen Elemente zur Beschreibung eines Geschäftsprozesses mittels BPEL aufgeführt. Abstract BPEL Common Base: Executable Processes: Partner Link Type : Service Reference : Variable Properties: Szenarien BPEL modelliert Geschäftsprozesse durch Orchestrieren und Automatisieren von Web Services. Dabei besteht auch die Möglichkeit, mehrstufige Geschäftsprozesse zu erstellen. Ein einfaches Einsatzszenario ist ein mit BPEL gestalteter Reiseprozess. Ein Kunde gibt seine Daten an und bucht zuerst über den Web Service Hotelreservierung ein Hotel. Der Service 121

122 liefert die erforderlichen Daten und Kosten für das Hotel zurück. Anschließend ermöglicht der Web Service Flugreservierung die Buchung eines Fluges zu dem entsprechenden Reisedatum. Auch dieser Service liefert die notwendigen Informationen und Kosten zurück. Aus den empfangen Informationen und Kosten erstellt der Reiseprozess eine Buchungsbestätigung mit den anfallenden Kosten für den Kunden Empfehlung zur Anwendung Die Verwendung von BPEL ist empfehlenswert (1), da BPEL sowohl durch die syntaktischen Konstrukte als auch durch die Orientierung der Ablaufbeschreibung an herkömmlichen Programmiersprachen die Entwicklung von Anwendungen im SOA-Umfeld vereinfacht. Weiterhin ist BPEL bereits vom Markt angenommen. So führen große Hersteller BPELEngines und BPEL-Prozess Manager für die graphische Modellierung und Ausführung von Geschäftsprozessen im Sortiment. Es sei allerdings darauf hingewiesen, dass bedingt durch eine große Menge an Freiheitsgraden in der Spezifikation die Implementierungen dieses Standards sehr stark variieren können und häufig nicht vollständig kompatibel sind WS-CDL Definition WS-CDL steht als Akronym für Web Services Choreography Description Language und beschreibt als XML-basierte Sprache peer-to-peer Kollaborationen zwischen Akteuren. Aus Beobachterperspektive wird das gemeinsame und sich ergänzende Verhalten der Akteure definiert, wobei der geregelte Nachrichtenaustausch dem Erreichen eines gemeinsamen Geschäftsziels dient. Die Web Services Choreography Spezifikation zielt darauf ab, interoperable, peer-to-peer Kollaborationen zwischen jeglichen Akteuren und unabhängig von der Systemumgebung (Plattform, Programmiersprache) herzustellen. WS-CDL wurde durch das W3C im November 2005 spezifiziert und liegt derzeit als Candidate Recommendation in Version 1.0 vor [WS-CDL] Grundlagen Um eine funktionierende Kollaboration zwischen mehreren Teilnehmern zu erreichen, ist es sinnvoll, die Regeln und Verantwortlichkeiten für die Interaktionen aus einer globalen Sicht zu definieren. Mittels WS-CDL können diese Regeln, Bedingungen und Verantwortlichkeiten definiert werden, so dass später jeder Teilnehmer auf Basis der vorliegenden globalen Definition eine eigene Lösung entwickeln und auf Konformität testen kann. In der Praxis hat eine Choreographiebeschreibung einen weiteren wichtigen Vorteil. In manchen Fällen möchten Unternehmen nicht die Kontrolle über ihre Prozesse an ihre Partner delegieren. Mittels Choreographie können die Verantwortlichkeiten klar getrennt werden und die Parteien können sich gemeinsam auf die Leistungserbringung bestimmter Teile verständigen. 122

123 WS-CDL ist somit eine Sprache zur Modellierung von abstrakten Prozessen (Choreographie). Sie wurde als komplementäre Modellierungssprache zu anderen Sprachen entworfen, die zur Orchestrierung von ausführbaren Prozessen verwendet werden (vgl. [Melzer2008]). Abbildung 33: WS-CDL Funktionsweise (vgl. [WS-CDL]) Abbildung 33 zeigt Unternehmen A und Unternehmen B, die ihre Web Service basierten Anwendungen integrieren möchten. Die jeweiligen Verantwortlichen beider Unternehmen haben sich auf die Art der Zusammenarbeit der Dienste, Regeln und Bedingungen verständigt. Eine WS-CDL basierte Repräsentation wird erstellt, welche die Interoperabilität zwischen den Business Entitäten sicherstellt und dabei von der technischen Implementierung abstrahiert. Unternehmen A setzt auf eine BPEL Lösung, um den Teil der Choreographie zu realisieren, während Unternehmen B eine J2EE Lösung verwendet (vgl. [WS-CDL]). Neben den bereits beschriebenen Zielen, werden weitere Ziele von WS-CDL im W3C Standard erläutert (vgl. [WS-CDL]): Reusability: Die Choreographie-Definition kann von verschiedenen Teilnehmern aus unterschiedlichen Bereichen und auch mit unterschiedlicher Software genutzt werden. Cooperation: Die Reihenfolge des Nachrichtenaustauschs zwischen mehreren Teilnehmern ist definiert, und somit ist beschrieben wie eine Kooperation stattfinden sollte. Multi-Party Collaboration: Die Anzahl an Teilnehmern und Prozessen ist nicht beschränkt. 123

124 Semantics: Choreographien können Informationen enthalten, die leicht lesbar und verständlich für Menschen sind. Composability: Existierende Choreographien können zu neuen Choreographien zusammengesetzt werden. Modularity: Choreographien können aus Teilen anderer Choreographien erstellt werden. Information Driven Collaboration: Choreographien beschreiben, wie Teilnehmer innerhalb der Kollaboration fortzufahren haben (z.b. wenn neue Informationen eintreffen oder Bedingungen erfüllt sind). Information Alignment: Das Kommunizieren und Synchronisieren von Informationen wird den Teilnehmern erlaubt. Exception Handling: Choreographien können Aktionen definieren, die bei Auftreten von bestimmten Fehlern durchgeführt werden. Transactionality: Teilnehmer oder Prozesse können lang anhaltende Kollaborationen wie eine Art "Transaktion" ansehen und koordinieren (Zurücksetzen von Zuständen oder Wiederholen von Aktionen ist möglich). Specification Composability: Die WS-CDL Spezifikation ist dafür vorgesehen, mit anderen Spezifikationen bzw. ergänzend zu existierenden Spezifikationen verwendet zu werden (z.b. WS-Reliability, WS-CAF, WS-Security, BPEL...). Abgrenzung zu Business Process Languages: WS-CDL ist keine ausführbare Geschäftsprozess-Beschreibungssprache oder Implementierungssprache. Diese Aufgaben übernehmen andere Sprachen bzw. Spezifikationen wie bspw. XLANG, WSFL, BPEL, BPML oder XPDL. WS-CDL ist des Weiteren nicht auf eine bestimmte GeschäftsprozessImplementierungssprache angewiesen. Aus diesem Grund ist es möglich, vollkommen interoperable Kollaborationen zwischen verschiedenen Teilnehmern, unabhängig von deren unterstützter Systemplattform und Programmiersprache, zu definieren (vgl. [WS-CDL]) Empfehlung zur Anwendung Die Nutzung von WS-CDL sollte insbesondere dann angeregt (2) werden, wenn mehrere Parteien kollaborieren wollen und eine klare Abgrenzung der unterschiedlichen Verantwortlichkeiten hinsichtlich der Leistungserbringung sinnvoll bzw. notwendig ist. Auf Grundlage der globalen Modellierung mittels WS-CDL können die Teilnehmer ihre Lösungen im Gesamtsystem konform implementieren, so dass die Interoperabilität gewährleistet wird ebxml Definition ebxml steht für Electronic Business using XML, basiert auf XML und stellt eine Familie verschiedenster Standards bereit, um die Technologien für elektronische 124

125 Geschäftsbeziehungen und Geschäftsprozesse zu vereinen. ebxml macht es möglich, dass jeder die Web Services eines anderen auffinden kann und mit jedem über das Internet durch die Nutzung standardisierter Methoden und Protokolle Geschäftsbeziehungen führen, Nachrichten austauschen und elektronische Geschäftsprozesse definieren und registrieren kann Grundlagen ebxml wurde im Jahre 1999 von UN/CEFACT (United Nations Center For Trade Facilitation And Electronic Business) und OASIS (Organization for the Advancement of Structured Information Standards) als gemeinsame Initiative ins Leben gerufen. Die Standardfamilie verfolgt das Ziel, ein technisches Framework zur Nutzung von XML für elektronische Geschäftsbeziehungen und Geschäftsprozesse zu schaffen. ebxml bietet u.a. folgende Möglichkeiten: Es können komplexe Geschäftsprozesse abgebildet werden. Es kann die Struktur und der Inhalt von Geschäftsdokumenten festgelegt werden. Es können Prozesse definiert werden. Es kann den durchgängigen Transport, Routing und Packaging bereitstellen um den verlässlichen Versand und Erhalt von Nachrichten über das Internet sicherzustellen. ebxml nutzt zur detaillierten Beschreibung eines Web Services bzw. von Beziehungen zwischen Web Services nicht nur WSDL. Zum Aufbau einer Geschäftsbeziehung wird zusätzlich CPP (Collaboration Protocol Profile) und CAP (Collaboration Agreement Protocol) verwendet. Diese Protokolle liefern z.b. Informationen zu den angebotenen Services, über Restriktionen, Error-Handling oder Fehlerszenarien sowie eine Beschreibung, wie die elektronische Geschäftsbeziehung aufgebaut werden soll. ebxml wurde bereits als Standard-Familie von der International Standard Organisation (ISO) anerkannt. Die folgenden Standards existieren: ISO : ebxml Collaborative Partner Profile Agreement ISO : ebxml Messaging Service Specification ISO : ebxml Registry Information Model ISO : ebxml Registry Services Specification ISO : ebxml Core Components Technical Specification Des Weiteren gibt es technische Spezifikationen, die sich auf bestimmte Unterthemen beziehen. Die folgende Liste zeigt einen Auszug: ebxml Technical Architecture Specification (v1.04): Beschreibung der grundlegenden technischen ebxml-architektur oder Business Process Specification Schemata (v1.01): Beschreibung eines XML-Schema für Geschäftsprozesse. ebxml ermöglicht den automatischen Aufbau von Geschäftsbeziehungen und bietet Geschäftspartner dadurch die Möglichkeit, Zeit und vor allem Kosten einzusparen. [ebxml] 125

126 Schemata Ein XML-Schema für Geschäftsprozesse wurde von dem Konsortium entwickelt und veröffentlicht. Dieses ist unter der folgenden Adresse zu finden: ebbpss.xsd Eine DTD wird ebenfalls angeboten: Szenarien Die folgende Darstellung zeigt den Aufbau einer elektronischen Geschäftsbeziehung und der damit verbundenen Etablierung eines Geschäftsprozesses. In diesem Szenario möchte Unternehmen A eine elektronische Geschäftsbeziehung mit Unternehmen B aufbauen: Abbildung 34: Aufbau einer elektronischen Geschäftsbeziehung mit ebxml in Anlehnung an [ebxml2] 1. Um Informationen über Unternehmen B zu erhalten, fragt Unternehmen A bei der ebxml-registry, einem öffentlichen Verzeichnis für das Collaboration Protocol Profile (CPP) des Unternehmens, an, ob Informationen zu dem jeweiligen Unternehmen zur Verfügung stehen. Die CPP gibt z.b. Informationen über zu nutzende XML-Schemata oder Sicherheitsmechanismen (z.b. SSL oder XMLEncryption), die bereitgestellt werden müssen sowie die Adresse des Servers. Voraussetzung ist, dass sich Unternehmen B zuvor dort angemeldet hat. Die Registry erlaubt z.b. gegenüber UDDI eine weitergehende und detailliertere Darstellung der angebotenen Web Services. 2. Im zweiten Schritt wird ein Business Agreement geschlossen. In diesem Prozess wird ein Collaboration Agreement Protocol (CAP) erstellt, sobald eine Kooperation aufgrund einer erfolgreichen Suche eines Anwenders in der Registry etabliert werden soll. Damit wird sichergestellt, dass sich die beteiligten Geschäftspartner über die für die Kooperation relevanten Aspekte, wie z.b. welche Verschlüsselungsverfahren zum Einsatz kommen sollen, geeinigt haben. Unternehmen A schickt dann das CAP zu Unternehmen B. Akzeptiert dieses das CAP, kann die Geschäftsbeziehung hergestellt werden. 3. Wurde das Business Agreement geschlossen, können entsprechend die zuvor definierten Business Szenarios genutzt und Geschäfte abgewickelt werden. Der gestrichelte Pfeil zwischen Unternehmen B und der Registry symbolisiert eine Aktualisierung des CPP, z.b. durch eine Änderung der Anforderungen oder anderer 126

127 Informationen. Diese Aktualisierung kann dann von Unternehmen A abgefragt werden, um die Anforderungen zur Aufrechterhaltung der Geschäftsbeziehung zu garantieren Empfehlung zur Anwendung Die Nutzung von ebxml kann nicht grundsätzlich empfohlen oder nicht empfohlen werden, da dies von einer Vielzahl von Rahmenbedingungen abhängt. Es müssen z.b. die Unternehmen, mit denen eine elektronische Geschäftsbeziehung aufgebaut werden soll, die Standards, Spezifikationen und Sicherheitsmechanismen des Partners unterstützen. Es ist jedoch offensichtlich, dass ebxml eine für die Geschäftswelt interessante Standardfamilie bereitstellt. Aus diesem Grund könnte ebxml in Zukunft noch stärker in den Fokus rücken, daher sollte diese Standardfamilie beobachtet werden (3) Weitere Standards WS-ResourceFramework Definition WS-ResourceFramework (WSRF) wurde zur Spezifizierung bzw. Standardisierung von Interaktionen mit statusbehafteten Web Services ( stateful services ) zwischen Applikationen entwickelt. Diese werden z.b. von der Open Grid Services Architecture (OGSA), einer Service-orientierten Architektur für Grid Computing, benötigt. Damit trägt der Standard maßgeblich dazu bei, Grid Computing, System Management und Web Services anzugleichen bzw. zusammenzuschließen Grundlagen WS-ResourceFramework wurde von GlobusAlliance, IBM und HP entwickelt und 2006 von OASIS standardisiert. Vor WSRF gab es keinen formalen bzw. standardisierten Mechanismus, um Verbindungen zwischen Web Services und deren Status darzustellen, was zur Folge hatte, dass jeder Client oder jede Applikation statusbehaftete Ressourcen (z.b. physische Entitäten oder logische Daten) unterschiedlich behandelte. WSRF wurde daher mit der Absicht entwickelt, Interaktionen mit statusbehafteten Web Services zu standardisieren und dadurch eine höhere Kompatibilität zu erreichen. WSRF arbeitet mit Ressourcen (WS-Resource), die jeweils eine separate Entität darstellen. Sie werden über eindeutige Schlüssel identifiziert und besitzen die Funktionalität, einen aktuellen Status eines Web Service, z.b. eine Zwischenspeicherung (Daten, Datenbankinhalte, etc.), zu halten. Eine Ressource hat eine unverwechselbare Identität und einen definierten Lebenszyklus. Sie kann durch einen oder mehrere Web Services genutzt werden. Das Resource Properties Dokument stellt dabei eine Sicht auf die Ressourcen bereit, mit denen ein Client oder ein Web Service interagiert. WSRF wurde vor allem dazu entwickelt, den Anforderungen des Grid Computings, mit statusbehaftete Ressourcen zu arbeiten, gerecht zu werden. Die Open Grid Services Architecture (OGSA) ist eine offene Softwarearchitektur für Rechnerstrukturen (Grids), die 127

128 Web Services und Schnittstellen definiert. Diese offene Architektur wurde entwickelt, um die Probleme der Nutzung von OGSI (Open Grid Services Infrastructure), einem Vorläufer von OGSA, zu lösen. Durch OGSA und der damit verbundenen Nutzung des WSResourceFrameworks als Infrastruktur, die auf OGSA basiert, wurde ein Weg geschaffen, der durch die Nutzung der gleichen Web Service Standards ermöglicht, dass die Grid- und die Web Communities auf gleicher Basis arbeiten können. [WSRF] Umfang Die WSRF-Spezifikation besteht aus fünf technischen Spezifikationen, die das Zusammenwirken von Ressourcen und spezifischen Web Services beschreiben. Sie lassen sich zudem einzeln nutzen. Die folgende Tabelle stellt diese Spezifikationen dar. Name der Spezifikation Beschreibung WS-ResourceLifetime Beschreibt Mechanismen zur Zerstörung von Ressourcen (WS-Resources), z.b. sofortige Zerstörung oder Zerstörung nach einem bestimmten Zeitplan. WS-ResourceProperties Definiert eine WS-Resource und Mechanismen zur Einstellung, Änderung oder Löschung von Eigenschaften einer WS-Resource. WS-RenewableReferences Bietet einen Mechanismus zur Bestückung einer WSAddressing-Referenz eines Endpunktes mit PolicyInformationen, die zur Einstellung einer aktualisierten Version einer Endpunkt-Referenz benötigt wird, sobald sie Gültigkeit erlangt. WS-ServiceGroup Bietet eine Schnittstelle zu einer bezugnehmenden Sammlung von heterogenen Web Services. WS-BaseFaults Beschreibt einen XML-Typ zur Nutzung im Falle von Fehlern innerhalb einer Nachrichtenübermittlung zwischen Web Services Tabelle 4: Übersicht über die Spezifikationen des WS-Resource Frameworks Szenarien WS-ResourceFramework findet vor allem im Grid Computing Bereich Anwendung. Grid Computing bezeichnet einen mächtigen, selbstkontrollierenden virtuellen Computer, der sich aus einer großen Menge an heterogenen Systemen zusammensetzt, die mit den verschiedensten Variationen von Ressourcen arbeiten und somit eine Form des verteilten Rechnens ermöglichen. OGSA ist eine offene Architektur, die zugehörige Komponenten der Grid-Umgebung als Services darstellt. Innerhalb dieser Architektur definiert WSRF die Informationen über den Status der Ressourcen, die von Web Services zur Realisierung von Grid-Diensten verwendet werden können. 128

129 Empfehlung zur Anwendung Die Nutzung dieses Standards ist empfehlenswert (1), sobald Grid-Dienste mit Web Services interagieren müssen. WSRF bringt notwendige Mechanismen mit, um mit statusbehafteten Ressourcen zu arbeiten. Dadurch können Sicherheitsmechanismen bei der Kommunikation mit Web Services bzw. zwischen Service-Grids genutzt werden Standards für Komponentenmodelle: Service Component Architecture Definition Die Service Component Architecture (SCA) stellt einen Ansatz dar, um Software kompontentenbasiert zu entwerfen und umzusetzen. Das Kernstück der SCA Spezifikationen bildet die Spezifikation SCA Assembly Model V1.00, die ein abstraktes Komponentenmodell definiert, um die Modellierung und technologieunabhängige Beschreibung von Softwarekomponenten und deren Abhängigkeiten zu ermöglichen Grundlagen Übersicht SCA Der SCA Standard umfasst eine Reihe von Spezifikationen, welche im Kern folgendes beschreiben: eine SCA-Komponente und ihre Eigenschaften die Abhängigkeiten zwischen Komponenten die Zusammenfassung von Komponenten zu zusammengesetzten Komponenten (Composites). Die Beschreibung einer Komponente erfolgt deklarativ in XML Syntax und umfasst auch eine Referenz auf die konkrete Implementierung einer Komponente, die die Geschäftsfunktionen realisiert. Die Komponentenimplementierung kann mittels verschiedener Sprachen erfolgen, beispielsweise durch eine einfache Java-Klasse oder eine BPEL-ProzessBeschreibung (vgl. Kapitel 4.9.2). Die Komponentenbeschreibung zusammen mit der Referenz auf die Implementierung ermöglicht der SCA-Laufzeitumgebung die Instantiierung und Konfiguration einer konkreten, ausführbaren Instanz einer Komponente. Ein wesentlicher Teil der SCA Spezifikationen beschreibt die Abbildung des Komponentenmodells auf eine konkrete Technologie: SCA Java Component Implementation V1.00 SCA Spring Component Implementation V1.00 SCA BPEL Client and Implementation V1.00 SCA C++ Client and Implementation V1.00 SCA COBOL Client and Implementation V1.00 SCA C Client and Implementation V

130 Zur Laufzeit verwaltet die SCA-Umgebung die Instanzen der Komponentenimplementierung und gewährleistet zudem die Kommunikation zwischen den Komponenten gemäß der modellierten Beziehungen in der Komponentenbeschreibung. Beispielsweise könnten die Komponenten durch einfache Java-Klassen realisiert sein und in einem Prozess ausgeführt werden, so dass die Abhängigkeiten zwischen den Komponenten durch die SCALaufzeitumgebung auf einfache Funktionsaufrufe von Java-Klassen abgebildet werden können. Sollen die Komponentenimplementierungen über verschiedene Systeme verteilt sein, so besteht die Möglichkeit, dass die Laufzeitumgebung die Funktionalität Service-basiert zur Verfügung stellt und nutzt. Zudem kann in der Beschreibung einer Komponente über ein so genanntes Binding explizit spezifiziert werden, wie Komponenten Funktionalität anbieten oder konsumieren. Vier SCA Spezifikationen widmen sich diesem Aspekt im Kontext einer konkreten Technologie: SCA Web Services Binding V1.00 SCA JMS Binding V1.00 SCA EJB Session Bean Binding V1.00 SCA JCA Binding V1.00 Neben einem Protokoll in Form eines Bindings lassen sich für eine Komponente und die angebotene Funktionalität auch spezifische Anforderungen an die Sicherheit und Transaktionalität stellen, beschrieben durch die folgenden Spezifikationen: SCA Policy Framework V1.00 SCA Transaction Policy V1.00 Eine genauere Betrachtung des SCA-Policy-Frameworks erfolgt im Kapitel Die Spezifikationen für die Service Component Architecture wurden ursprünglich als Zusammenschluss verschiedener Hersteller wie BEA, IBM und Oracle entwickelt mit dem Ziel, ein technologie-neutrales Komponentenmodell zu schaffen. Seit 2007 werden die Spezifikationen von OASIS (vgl. Kapitel ) gepflegt. Komponenten SCA-Komponenten bilden das zentrale Element einer SCA. Sie beschreiben die elementaren Bausteine und können zu größeren Einheiten (sog. Composites) zusammengefügt werden, welche alleine oder im Verbund die Anwendung bilden. Komponenten werden durch eine XML-Datei (mit der Endung.composite) beschrieben, welche als Format die Service Component Definition Language (SCDL) verwendet. SCDL beschreibt die Eigenschaften und die Beziehungen von Komponenten durch die abstrakten Konstrukte Services, Referenzen, Eigenschaften und Bindings. Abbildung 35 zeigt den schematischen Aufbau einer SCA Komponente. 130

131 Abbildung 35: Schematischer Aufbau einer SCA Komponente Services Jede abstrakte Definition einer Komponente wird durch die Laufzeitumgebung auf eine konkrete Komponentenimplementierung abgebildet, die eine bestimmte Geschäftslogik realisiert. SCA-Services identifizieren den Teil der Geschäftslogik, der von dieser Komponente als Satz von Operationen angeboten werden soll, um von einer anderen Komponente oder Client-Anwendung verwendet werden zu können. Referenzen Neben dem Anbieten von Funktionalität als SCA-Dienst, kann eine Komponente auch die Dienste anderer Komponenten nutzen, um ihre Geschäftslogik umzusetzen. Dazu beschreiben Referenzen die Abhängigkeit einer Komponente von den SCA-Diensten anderer Komponenten, aber auch zu extern bereitgestellten Diensten (beispielsweise Web Services). Eigenschaften Neben Diensten und Referenzen können für eine Komponente auch bestimmte Eigenschaften definiert werden. Eigenschaften bestehen aus einem Typ, Namen und dem zugehörigen Wert, wobei sowohl einfache als auch komplexe Datentypen möglich sind. Eigenschaften bieten der Laufzeitumgebung die Möglichkeit, eine Komponentenimplementierung bei der Instanziierung basierend auf den Werten der Eigenschaften der jeweiligen Komponente zu konfigurieren. Bindings Bindings spezifizieren die Art mittels der eine Komponente mit einer anderen Entität kommunizieren kann und können Referenzen und Services zugeordnet sein. Während Services und Referenzen beschreiben, welche Funktionen konsumiert und angeboten werden, beschreibt ein Binding das Protokoll, auf dessen Basis diese Kommunikation erfolgen soll. Ein einzelner Dienst oder eine einzelne Referenz kann mehrere Protokolle unterstützen, über die der Zugriff möglich ist. Innerhalb einer SCA-Domäne kann dieses Protokoll implizit durch die SCALaufzeitumgebung bestimmt werden. Nur wenn eine Komponente mit Systemen außerhalb der eigenen SCA-Domäne kommunizieren soll, muss ein Binding explizit angegeben werden. 131

132 Composites Composites bieten einen Gruppierungsmechanismus für Komponenten und bestehen aus einer Reihe von Komponenten, Services, Referenzen, anderen Composites sowie ihren Verbindungen untereinander. Im Unterschied zu Komponenten sind Composites nicht direkt mit einer Implementierung verknüpft, sondern fassen verschiedene Komponenten zu einer Ausführungseinheit zusammen. SCA Domäne Eine SCA Domäne repräsentiert die Ausführungsumgebung einer Menge von Composites innerhalb einer geschlossen Administrationsdomäne. Die SCA Spezifikationen geben nicht vor, welche Instanzen einer Komponente auf welche Art ob verteilt oder über einen Funktionsaufruf aufgerufen werden. Dies entscheidet und regelt die Laufzeitumgebung selbstständig. Der Kommunikationskanal ist somit nicht mehr implementierungsspezifisch festgelegt, sondern kann deklarativ den Anforderungen angepasst werden. Die Konfiguration der eingesetzten Laufzeitumgebung entscheidet letztendlich, ob eine konkrete Komponentenbeschreibung mittels lose gekoppelter Dienste oder eng gekoppelter, implementierungsspezifischer Objekte ausgeführt wird. Durch die Verwendung des SCAWeb Service-Bindings können Dienste konsumiert und Composites als Dienste interoperabel bereitgestellt werden, ohne dass die Verwendung des Komponentenmodells für den Web Service-Nutzer ersichtlich sein muss. Das SCA-Konzept ermöglicht zudem die Abbildung des Komponentenmodells auf ein verteiltes System, das dem Paradigma einer Serviceorientierten Architektur folgt, wie es in der OASIS Referenz Architektur für Serviceorientierte Architekturen beschrieben ist. In welchem Umfang Konzepte beispielsweise hinsichtlich Sicherheit unterstützt werden, ist jedoch von den Möglichkeiten der SCAAusführungsumgebung abhängig Schemata Das SCA Assembly Model definiert mit der Service Component Definition Language ein XML Format zur Beschreibung der oben beschriebenen Konzepte. Jede Komponente wird durch ein component -Element beschrieben und unterhalb eines composite Elementknotens in die XML Struktur eingefügt. Innerhalb der component -Struktur wird die Komponente mit ihren Eigenschaften (Tag: property), Implementierungen (Tag: implementation ), Referenzen (Tag: reference ) und Services (Tag: service ) beschrieben. Im Anhang findet sich ein Beispiel für die Definition einer Komponente mit SCDL Szenarien Das SCA-Konzept stellt einen modellgetriebenen Ansatz dar, der eine einfache Wiederverwendbarkeit von Geschäftsfunktionen in Form von Komponenten ermöglicht. Diese Komponenten können in verschiedenen Kontexten benutzt werden und können darüber hinaus dieselbe Komponentenimplementierung mit unterschiedlicher Konfiguration einbinden. SCA zielt auf eine vereinfachte Entwicklung und Wartung von Anwendungen ab, da der Entwickler nur Abhängigkeiten zwischen Komponenten definieren und im Programmcode ein 132

133 abstraktes Interface aufrufen muss. Der Einsatz von SCA bietet sich immer dann an, wenn wiederverwendbare Funktionalitäten als Komponenten gekapselt in verschiedenen Anwendungen zum Einsatz kommen soll. Beispielsweise werden Auftragsbearbeitungsfunktionen wie Bestellung, Bezahlung und Lieferung in vielen Anwendungen benötigt, welche mit Hilfe von SCA schnell in unterschiedliche SOA Szenarien eingebunden werden könnten Empfehlung zur Anwendung Die Verwendung der SCA Spezifikationen im produktiven Einsatz ist zu beobachten (3), da es noch nicht abzusehen ist, ob sich eine breite Verwendung dieser Spezifikation durchsetzen wird. Die SCA-Spezifikationen wurden im Jahre 2007 in der Version 1.0 von der OASIS standardisiert. Der Erfolg dieses Konzeptes wird von der Unterstützung durch Projekte und Plattformen abhängig sein. Verschiedene OpenSource-Implementierungen für SCA Laufzeitumgebungen existieren bereits in einer ersten Version (beispielsweise Apache Tuscany [Tuscany] und Fabric3 [Fabric3]), während verschiedene Hersteller ihre eigene Implementierungen planen. Jedoch sind die existierenden OpenSource Implementierungen noch auf keinem Stand, der einen produktiven Einsatz erlaubt. Ebenso ist die Werkzeugunterstützung noch in einer anfänglichen Entwicklung. Das SOA Tools Platform Project zielt beispielsweise auf die Entwicklung von Entwicklertools für die Entwicklungsumgebung Eclipse. Für die Realisierung einer Service-orientierten Architektur ist der Umfang der Unterstützung der Web Service-Standards entscheidend. Apache Tuscany setzt beispielsweise auf Apache Axis2 auf. Die SCA-Spezifikationen genießen auch keine Unterstützung von Microsoft, da Microsoft im Rahmen seiner dotnet-plattform mit der Windows Communication Foundation ein Framework zur Erstellung von verteilten Anwendungen bietet, welches ebenfalls eine deklarative Dienstkomposition ermöglicht und darüber hinaus die Web ServiceSpezifikationen komplett unterstützt Interoperabilität Das Kapitel Interoperabilität beschreibt die Standardisierungsorganisationen OASIS, IEEE, W3C und WS-I mit ihren Strukturen, Aufgaben und Zielen. Es wird dargestellt, welche relevanten Standards sie unterstützen und fördern OASIS OASIS (Organization for the Advancement of Structured Information Standards) verfolgt das Ziel, die Entwicklung, Konvergenz, Einsatz und Einführung von offenen Standards für die globale Informationsgesellschaft voran zu treiben. OASIS ist eine internationale, nicht gewinnorientierte Organisation zur Entwicklung, Konvergenz und Einführung von E-Business und Web Service Standards. Dieses Ziel wird in weitere strategische Ziele unterteilt: Ziel ist zum einen eine effektive, effiziente, offene und transparente Umgebung für die Entwicklung, Koordination und Instandhaltung von Standards in hoher Qualität 133

134 bereitzustellen. Transparenz und Offenheit sollen die grundlegenden Prinzipien von OASIS darstellen. Zum anderen soll eine internationale Repräsentanz und Vielfältigkeit der OASIS Mitgliedschaft erreicht werden. Die Teilnahme der Endbenutzer soll erhöht werden und Regierung, Akademie und Forschungsinstitutionen, sowie Open Source Communities sollen mit einbezogen werden. Dies soll den Wert und die Benutzerfreundlichkeit der Arbeit von OASIS am Markt steigern. Ein weiteres Ziel ist es, alle Phasen des Standard Lebenszyklus mit einzubeziehen wie Anforderungsdefinitionen, Spezifikation, Entwicklung, Best Pratices und Einführungsdienstleistungen. OASIS wurde 1993 unter dem Namen SGML Open als eine Organisation aus Anbietern und Benutzern gegründet. Ziel war die Entwicklung von Richtlinien zur Interoperabilität von Produkten, die die Standard Gerneralized Markup Language (SGML) unterstützen. Mit dem Wandel der High Tech Industrie in 1998 wechselte SGML Open seinen Namen in OASIS open, um den erweiterten Scope und die Extensible Markup Language XML sowie weitere Standards einzubeziehen. Darüber hinaus stieg OASIS 1998 in die Entwicklung von technischen Spezifikationen ein. Die OASIS Organisation betreibt die zwei am weitesten anerkannten Informationsportale Cover Pages und XML.org. Die Mitgliedersektion unterteilt sich in CGM Open, COSL, egov, Emergency, IDtrust, LegalXML, Open CSA und Telekom. OASIS repräsentiert mehr als 4000 Mitglieder in über 600 Organisationen und in 100 Ländern. Die Mitglieder der Organisation bestimmen selbst die technische Agenda in einem offenen, demokratischen Prozess. Zusammenarbeit und Beziehungen pflegt OASIS u.a. mit W3C, ISO, ISO/IEC JTC1, ITU, UN/ECE und RosettaNet. Diese Gruppen arbeiten zusammen, um die Koordination über verschiedene internationale Programme für die effizientere Entwicklung und schnellere Etablierung der Standards am globalen Markt zu gewährleisten. Die Foundational Sponsoren von OASIS unterstützen die organisatorische Infrastruktur, die technische Arbeit und weitere Programme der Organisation. Zu den Standards des OASIS Konsortiums zählen: Application Vulnerability Description Language (AVDL), Business Centric Methodology (BCM), Common Alerting Protocol (CAP), Content Assembly Mechanism (CAM), Darwin Information Typing Architecture (DITA), Digital Signature Services (DSS), Directory Services Markup Language (DSML), DocBook, ebxml Business Process Specification Schema Technical Specification, ebxml Collaborative Partner Profile Agreement (CPPA), ebxml Messaging Services: Part 1, Core Features, ebxml Message Service Specification, 134

135 ebxml Registry Information Model (RIM), ebxml Registry Services Specification (RS), Election Markup Language (EML), Emergency Data Exchange Language (EDXL) Distribution Element, Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE), Emergency Data Exchange Language Resource Messaging (EDXL-RM), extensible Access Control Markup Language (XACML), OpenDocument Format for Office Applications (OpenDocument), Reference Model for Service Oriented Architecture, Security Assertion Markup Language (SAML), Service Provisioning Markup Language (SPML) v2.0, Solution Deployment Descriptor Specification 1.0, Universal Business Language (UBL) v2.0, Universal Business Language Naming & Design Rules (UBL NDR), Universal Description, Discovery and Integration (UDDI), UOML (Unstructured Operation Markup Language) Part 1 Version, WebCGM, Web Services Business Process Execution Language, Web Services Context (WS-Context), Web Services Distributed Management (WSDM), WSDM Management Using Web Services (WSDM-MUWS), Web Services Notification (WSN), WS-Reliability (WS-R), WS-ReliableMessaging, Web Services for Remote Portlets (WSRP), Web Services Resource Framework (WSRF), WS-SecureConversation, WS-SecurityPolicy, Web Services Security, Web Services Security SAML Token Profile, REL Token Profile, Web Services Transaction, WS-Trust, XML Catalogs, XML Common Biometric Format (XCBF), XML Localisation Interchange File Format (XLIFF). 135

136 IEEE IEEE (Institute of Electrical and Electronics Engineers, Inc.) verfolgt das Ziel der Förderung von technologischen Innovationen und sieht sich als eine globale Gesellschaft mit technischen Spezialisten. IEEE ist ein weltweiter Berufsverband von Ingenieuren aus den Bereichen der Computerwissenschaft und Elektrotechnik. IEEE ist mit mehr als Mitgliedern die größte professionelle technische, nicht gewinnorientierte Organisation weltweit. Nahezu ein Drittel der technischen Literatur auf der Welt in den Bereichen Informatik und Elektrotechnik werden vom IEEE publiziert. Das IEEE ist als Antreiber für technologische Innovationen bekannt und gilt als anerkannter Veranstalter von Fachtagungen. Darüber hinaus ist das IEEE an der Bildung von Gremien für die Normung von Techniken, Hardware und Software beteiligt. Organisiert ist das IEEE in einer sich gegenseitig ergänzenden regionalen und technischen Struktur. IEEE Mitglieder sind Ingenieure, Wissenschaftler, Spezialisten der Elektrotechnik, Computerwissenschaften und Ingenieurwesen. Sie gelten als führend in der Entwicklung von industriellen Standards in Branchen wie z.b. Elektronik, Power und Energie, biomedizinische Technologie, Gesundheit, Informationstechnologie, Informationssicherheit, Telekommunikation, Transport, Luftfahrt und Nano Technologie. Das IEEE entstand im Jahr 1963 aus einem Zusammenschluss des Instituts of Radio Engineers (IRE, gegründet in 1912) und des American Institute of Electrical Engineers (AIEE, gegründet 1884). Das IEEE verfolgt eine strategische Zusammenarbeit mit den internationalen Normierungsgremien IEC (International Electrotechnical Committee), ISO (International Organization for Standardization) und ITU (International Telecommunication Union). Mit einem aktiven Portfolio von nahezu 1300 Standards und Projekten in der Entwicklung ist das IEEE eine zentrale Stelle für die Standardisierung von aufkommenden Technologien. Die IEEE/IET Bibliothek umfasst mehr als 1,7 Millionen Dokumente in elektronischer Form. Zu den Standards des IEEE zählen: IEEE 488 Bussystem für Peripheriegeräte, IEEE 610 Standard Glossary of Software Engineering Terminology, IEEE 730 Standard for Software Quality Assurance Plans, IEEE Guide for Software Quality Assurance Planning, IEEE 754 Gleitkomma-Arithmetik-Spezifikationen, IEEE 802 LAN/MAN, IEEE Wireless LAN, IEEE BWA Broadband Wireless Access/WiMAX, IEEE 828 Standard for Software Configuration Management Plans, IEEE 829 Standard for Software Test Documentation, IEEE Software Requirements Specification, IEEE Standard Dictionary of Measures of the Software Aspects of Dependability, IEEE 1003 POSIX, 136

137 IEEE 1008 Standard for Software Unit Testing, IEEE 1012 Standard for Software Verification and Validation, IEEE 1016 Software Design Description, IEEE 1028 Standard for Software Reviews, IEEE 1042 Guide to Software Configuration Management, IEEE 1044 Standard Classification for Software Anomalies, IEEE Guide to Classification for Software Anomalies, IEEE 1058 Software Project Management Plan, IEEE 1059 Guide for Software Verification and Validation Plans, IEEE 1061 Standard for a software quality metrics methodology, IEEE 1062 Recommended Practice for Software Acquisition, IEEE 1063 Standard for Software User Documentation, IEEE 1076 Very High Speed Integrated Circuit Hardware Description Language, IEEE JTAG, IEEE 1209 Recommended practice for the Evaluation and Selection of Computer- Aided Software Engineering (CASE) tools, IEEE 1228 Standard for Software Safety Plans, IEEE 1233 Guide for Developing System Requirements Specifications, IEEE 1275 OpenFirmware, IEEE 1284 Parallele Schnittstelle, IEEE 1348 Recommended Practice for the Adaption of Computer-Aided Software Engineering (CASE) Tools, IEEE 1394 FireWire/i.Link Bussysteme, IEEE 1451 Intelligente Sensorik im Netzwerk, IEEE IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Systems and software engineering System life cycle processes W3C Das W3C (World Wide Web Consortium) ist eine internationale Organisation zur Erschließung des World Wide Webs. Es entstand aufgrund von inkompatiblen HTML Versionen unterschiedlicher Anbieter. Dies erhöhte die Wahrscheinlichkeit von Inkonsistenzen zwischen verschiedenen Webseiten. Ziel war es, alle Anbieter auf einen Standard zu bringen und diesen zu etablieren. Das W3C verfolgt die fünf strategische Ziele: Das World Wide Web soll für jeden verfügbar sein, unabhängig von Software, Netzwerk Infrastruktur, Land oder Kultur. 137

138 Das World Wide Web soll auf jeder Plattform verfügbar sein, unabhängig von der Hardware. Das World Wide Web soll als Wissensgrundlage zur Verfügung stehen. Das World Wide Web soll von überall erreichbar sein, unabhängig von der Bandbreite. Das World Wide Web soll Vertrauen schaffen und als eine vertrauensvolle Umgebung angesehen werden. Um die Ziele des World Wide Webs voranzutreiben und Interoperabilität zu gewährleisten, werden einheitliche Spezifikationen, Richtlinien, Software und Tools entwickelt. W3C wurde 1994 von Tim Berners-Lee, dem Erfinder des World Wide Webs, gegründet und ist heute mit drei Hauptsitzen in den USA, Japan und Frankreich sowie 16 weiteren Büros weltweit präsent. Die Organisation umfasst 419 Mitgliederorganisationen, aufgestellt in vier Domänen, 32 Arbeitsgruppen und 13 Interessensgruppen aus über 40 Ländern. Die Liste der Mitglieder steht öffentlich zur Verfügung. Mitglieder sind nicht gewinnbringende Organisationen, Universitäten und Regierungseinheiten. Da die W3C Organisation nicht zwischenstaatlich anerkannt ist und somit keine Standards zertifizieren kann, werden Standards synonym als W3C Recommendations (Empfehlungen) bezeichnet. Die von W3C verwendeten Entwicklungstechnologien sind in der Regel frei von Patentgebühren. W3C hat seinen eigenen Entwicklungsprozess festgelegt, der in die folgenden fünf Stufen untergliedert ist: Working Draft, Last Call Working Draft, Candidate Recommendation, Proposed Recommendation, W3C Recommendation. Ziel dieses Prozesses ist es, einen Konsens über eine Web Technologie sowohl innerhalb des W3C als auch über die gesamte Web Community zu erreichen. Zu den W3C Recommendations gehören: Hypertext Markup Language (HTML), Extensible Hypertext Markup Language (XHTML), Extensible Markup Language (XML), Extensible MultiModal Annotation markup language (EMMA), XML Schema (XML Schema), Extensible Stylesheet Language (XSL), XSL Transformation (XSLT), Cascading Style Sheets (CSS), Portable Network Graphics (PNG) ist in der Version 1.2 auch ein ISO-Standard, 138

139 Scalable Vector Graphics (SVG), Synchronized Multimedia Integration Language (SMIL), Mathematical Markup Language (MathML), Resource Description Framework (RDF), Really Simple Syndication (RSS), SOAP (SOAP), Web Services Description Language (WSDL), Web Services Addressing (WS-Addressing), Web Services Policy (WS-Policy), Document Object Model (DOM), Web Content Accessibility Guidelines (WCAG), Web Ontology Language (OWL), XML Path Language (XPath), XML Powered Web Forms (XForms), XML Link Language (XLink), XML Pointer Language (XPointer), XML Query Language (XQuery), Voice XML (VoiceXML) WS-I Die Web Services Interoperability Organization (WS-I) wurde gegründet, um die Interoperabilität von Web Services zu verbessern. Dazu werden Best Practice Ansätze für die Nutzung von Web Service Standards erarbeitet. WS-I verfolgt zwei Ziele: Förderung der Web Service Interoperabilität über Plattformen, Betriebssysteme und Programmiersprachen hinweg, Bereitstellung praktischer Implementierungshilfen. WS-I ist eine weltweite Organisation, mit Mitgliederunternehmen aus über 14 Ländern (Nordamerika, Südamerika, Europa und Asien). Die WS-I besteht aus Communities von Web Service Marktführern und Standards Development Organizations (SDOs). WS-I entwickelt und unterstützt Profile und Test Tools basierend auf Best Practices von Web Service Standards. Die WS-I Organisation ist nicht als eine zertifizierende Organisation zu sehen. WS-I arbeitet mit weiteren Web Service Standards Organisationen zusammen und integriert Gruppen aus ausgewählten Web Service Standards, die von OASIS, W3C oder anderen SDOs kommen können. Falls WS-I einen Fehler in einem Standard feststellt, werden die SDOs informiert, so dass der Fehler behoben werden kann. Die Korrektur wird anschließend in dem WS-I relevanten Profil angewandt. Mitglieder erhalten unter anderem Zugriff auf fertiggestellte WS-I Profile noch vor deren Veröffentlichung. Durch Communities erhalten Mitglieder die Möglichkeit, sich gegenseitig 139

140 neue Industrieentwicklungen näher zu bringen und sich innerhalb von WS-I zu vernetzen, um neue Geschäftsmöglichkeiten zu erschließen. Außerdem helfen die WS-I Communities Kunden bei der Entwicklung interoperabler Web Services. Ferner werden Geschäftsorganisationsszenarios und Anforderungen bereitgestellt, um die Profilentwicklung in der Zukunft besser beeinflussen zu können. WS-I Profile decken verschiedene Technologien ab. So verwendet z.b. Profile Basic 2.0 die Attachements Profile Version 1.0, Namespaces in XML 1.0 (Second Editon), RFC2246: The TLS Protocol Version 1.0, usw.. Folgende Profile sind derzeit veröffentlicht: Basic Profile, Simple Soap Binding Profile, Basic Security Profile, Reliable Secure Profile, Kerberos Token Profile, REL Token Profile, SAML Token Profile. 140

141 5 Security Management Das folgende Kapitel beschreibt Modelle, Verfahren und Lösungen zur effizienten Umsetzung von sicheren Service-orientierten Architekturen sowie deren Management. Nachdem das vorangegangene Kapitel die theoretischen Grundlagen dargestellt hat, vermittelt dieses Kapitel das notwendige Wissen für relevante Sicherheitsmaßnahmen in anwendungsnahen und organisatorischen Bereichen. Das Sicherheitsmanagement, das für die Planung, Umsetzung, Steuerung und Kontrolle der Sicherheit innerhalb einer Organisation verantwortlich ist, verbindet die Disziplinen Governance, Risk & Compliance (GRC), SOA Migration und SOA Lifecycle Management, damit sie fließend ineinander übergehen bzw. ineinander greifen. 5.1 Governance, Risk- & Compliance-Management Einordnung SOA Governance Allgemein befasst sich Governance mit übergeordneten Organisationsstrukturen und notwendigen Mechanismen zur Steuerung und Regelung der Organisation. Somit sind die Verantwortlichen im Rahmen der Governance zuständig für das Lenken von internen Entscheidungen sowie der Sicherstellung der Einhaltung der Gesetze, Richtlinien, Normen und Verfahren, damit alle Beteiligten und Aktivitäten zur Erreichung der Organisationsziele beitragen. Hierfür ermöglicht Governance die Organisation transparent zu steuern und die Zuordnung der Rechte, Entscheidungen zu treffen und zu bestimmen, welche Maßnahmen zu verwenden sind und welche Politik zu verfolgen ist. Zum besseren Verständnis der SOA Governance werden zunächst die einzelnen Steuerungsund Regelungsstrukturen in einer Organisation beschrieben und anschließend die Einordnung der SOA Governance in diese Strukturen vorgenommen Corporate Governance Die Corporate Governance legt, auf Basis der organisatorischen Strategie, von Marktposition und den Grundsätzen der Geschäftstätigkeit, die Regeln und Leitlinien fest, wie das Geschäft der Organisation zu leiten ist. Dafür definiert sie Rollen und Verantwortlichkeiten für interne und externe Aufgaben sowie deren Interaktionen und die dazugehörigen Steuerungs- und Kontrollmechanismen IT-Governance IT-Governance bringt IT-Aktivitäten mit den Zielen der Organisation zusammen. Dieser Teil der Governance umfasst sowohl die Entscheidungsbefugnisse im Zusammenhang mit ITInvestitionen, als auch die Politiken, Praktiken und Verfahren zur Messung und Kontrolle der IT-Entscheidungen sowie deren Priorisierung. Die Verantwortung liegt beim IT-Management der Organisation. 141

142 Information Security Governance Die Information Security Governance liegt wie die Corporate Governance in der Verantwortung der Führung einer Organisation. Sie muss ein integraler und transparenter Teil der Corporate Governance sein und im Einklang mit der IT-Governance stehen. Der Fokus der Information Security Governance liegt auf der Steuerung und Regelung der Informationssicherheit SOA Governance SOA-Governance ist eine Erweiterung der Corporate- und IT-Governance mit dem speziellen Fokus auf den Lebenszyklus von Geschäftsprozessen, Services und Anwendungen sowie deren Steuerung und der Regelung der Vorgaben in einer SOA. SOA Governance hat das Ziel, durch Steuerungs- und Kontrollmaßnahmen die Services an der Organisationsstrategie auszurichten und dadurch einen Wertbeitrag von SOA zum Erfolg der Organisation zu leisten. Somit ersetzt die SOA Governance nicht die IT-Governance, sondern baut sie um SOA-spezifische Ansätze aus. Im Rahmen der Umsetzung von Service-orientierten Architekturen werden die Governance Prozesse um Konzepte für Wiederverwendbarkeit von Services, Verwalten der Lebenszyklen von Services und Regelung von Abhängigkeiten innerhalb des Gesamtsystems erweitert SOA Security Governance SOA Security Governance ist eine Untermenge der gesamten SOA-Governance und steuert die Sicherheitsanforderungen einer SOA SOA Compliance SOA Compliance umfasst die Einhaltung der Richtlinien, Organisationsziele, Regeln und Leitlinien denen die Geschäftsprozesse, Services und Anwendungen unterworfen sind. C o r p o r a te G o v e r n a n c e I n f o r m a tio n S e c u r ity G overnance IT G overnan ce SO A G overnance S O A C o m p lia n ce G overnance S O A S e c u r ity G overnance Abbildung 36: Einordnung SOA Governance 142

143 5.1.2 Governance, Risk & Compliance in SOA Governance, Risk & Compliance (GRC) bedeutet für SOA, dass durch die Nutzung der Beziehung zwischen Governance, Risikomanagement und Compliance eine effektivere, besser zusammenarbeitende und sicherere Architektur geschaffen werden kann. Dabei gelten die folgenden Grundsätze: Compliance setzt den Rahmen Das Compliance-Management ist für die Messung von Übereinstimmungen mit einer definierten Menge von Anforderungen verantwortlich. Diese Anforderungen ergeben sich in der Regel aus internen Policies und Vorgaben, externen Gesetzen und Regularien sowie vertraglichen Verpflichtungen, die sich zum Teil konkret auf die SOA beziehen können. Kontrollen ergeben sich wiederum aus diesen Anforderungen und es liegt in der Verantwortung des Compliance-Managements sicherzustellen, dass diese Kontrollen durchgesetzt werden, wirksam sind und vollständig dokumentiert werden. Das Risikomanagement bildet das Fundament zur Umsetzung Das Risikomanagement koordiniert zusammen mit dem Compliance-Management die Bestimmung des wirtschaftlichen Kontexts von möglichen Kontrollen sowie der Kontrolle zur Bestimmung von Ausfällen und Mängeln innerhalb der SOA. Das Risikomanagement wertet zudem Möglichkeiten zur Minimierung von Risiken durch die Analyse der Kosten, des Nutzens und des Restrisikos für die SOA aus. Governance führt alles zusammen und steuert es transparent Governance-Verantwortliche koordinieren auf Basis der Risikoanalysen zusammen mit dem Risikomanagement weitere Entscheidungen, um die festgelegten Ziele der SOA und somit der Organisation zu erreichen. Dies beinhaltet die Auswahl von Optionen, die von Experten des Risikomanagements empfohlen wurden, um Risiken zu eliminieren, minimieren, transferieren oder zu akzeptieren. Die ausgewählten Optionen werden für die Priorisierung zurück zum Risikomanagement und im Anschluss zur Implementierung und Kontrolle an das Compliance-Management gegeben. Dadurch schließt sich der GRC-Kreislauf für die SOA. GRC erhöht die Möglichkeiten für Organisationen strategische Entscheidungen auf Basis einer Risikoorientierung zu treffen, Vorschriften jeglicher Art einzuhalten und Aktivitäten zur Verbesserung der SOA selber zu steuern. Auf diese Weise erreichen Organisationen durch ein geeignetes Risiko-und ComplianceManagement (zusammen mit den Elementen der strategischen Ausrichtung, dem Value Delivery, der Performance-Messung und dem Resource Management) letztlich eine gute Governance, die in der SOA etabliert werden kann SOA Governance Framework Im Kern des SOA Governance Frameworks werden aufbauend auf der Strategie der Organisation Elemente zusammengefasst, die es erlauben, Services zu steuern, zu kontrollieren und transparent zu gestalten. Hierfür werden im Rahmen des Governance Prozesses Richtlinien, Regeln und Standards 143

144 definiert, verwaltet, durchgesetzt und gemessen. Das SOA Governance Framework besteht aus den Komponenten: Strategische Ausrichtung, Risikomanagement, Ressourcenmanagement, Value Delivery, Performancemessungen. Die SOA Security Governance nutzt diese Komponenten und gestaltet sie gemäß den Sicherheitsanforderungen aus. Nachfolgend werden die Komponenten des SOA Governance Frameworks mit Bezug auf die Sicherheit dargestellt Strategische Ausrichtung Dieser Bereich konzentriert sich auf die Sicherstellung, dass die Organisationsvisionen, die Sicherheitsziele sowie die SOA-Strategie durch Services erreicht bzw. erfüllt werden. Die strategische Ausrichtung stellt die Bedeutung der SOA für eine Organisation dar und zeigt vor allem den Nutzen auf. Es muss klar werden, dass die Visionen und Strategien der Organisation durch die SOA umgesetzt bzw. unterstützt werden können. Im ersten Schritt werden nicht nur Sicherheitsziele definiert, sondern auch Bereiche innerhalb der Organisation (z.b. Geschäftsbereiche oder IT-Abteilungen) identifiziert, in denen die Governance angewandt oder verbessert werden muss. Anschließend sind in diesen Bereichen die Governance-Mechanismen und -Anordnungen zu definieren und anzupassen. Dies kann z.b. die Festlegung neuer Konzepte für die Anfertigung von Richtlinien sein. Als dritten Schritt sollten unter anderem die folgenden Regeln, Richtlinien und Standards erstellt bzw. angepasst werden: Richtlinien für die SOA-Zielarchitektur, um die Architektur, die Ziele der Organisation und die SOA-Strategie zu unterstützen, Richtlinien für neue Services, für die Wiederverwendbarkeit von Services in verschiedenen Geschäftsbereichen, für die Änderung von Services sowie deren Ablösung, Festschreibung einer SOA-Strategie, die sich an der Organisations- und IT-Strategie ausrichtet, Richtlinien für den Service Lebenszyklus bzw. Service Governance Lebenszyklus. Die Richtlinien sollen sicherstellen, dass die Service Portfolios mit der SOAStrategie im Einklang stehen. Des Weiteren sollten die Sicherheitsziele Vertraulichkeit, Integrität, Verfügbarkeit, Authentisierung, Autorisierung und Verbindlichkeit in dem Grad ihrer Umsetzung für die jeweiligen Services einer SOA individuell definiert werden. Die genannten Ziele sind in Kapitel 3.1 näher beschrieben. 144

145 Bezogen auf die SOA Security Governance müssen z.b. die Vergabe von Rollen und Verantwortlichkeiten geplant und Richtlinien aus Sicherheitssicht (z.b. Planung des VierAugen-Prinzips bzw. Funktionstrennung) erstellt werden. Die Funktionstrennung wird durch festzulegende Parameter bestimmt. Diese beruhen auf den Aufgaben, die ein Mitarbeiter zur Bearbeitung eines Geschäftsprozesses durchführen muss. Die Berechtigungen dafür werden zu Aufgabengruppen zusammengefasst und in Rollen hinterlegt. Die Funktionstrennung kann als Matrix von Funktionen und Rollen dargestellt werden Risikomanagement Risikomanagement ist die systematische Erfassung und Bewertung von Risiken sowie die Steuerung von Reaktionen und das Umsetzen von Maßnahmen gegen festgestellte Risiken. Risikomanagement erfordert eine Risiko-Sensibilisierung bei der Organisationsleitung, die Steuerung der analysierten Risiken, ein Verständnis für Compliance-Anforderungen und die Integration der Verantwortlichkeit für das Risikomanagement in der Organisation. Die Ergebnisse (ermittelte Risiken, Schutzmaßnahmen,...) des Risikomanagements werden den anderen Komponenten zur Verfügung gestellt. (siehe auch Abschnitt 5.1.5). Die SOA Security Governance prüft z.b. für die Vergabe von Rollen und Verantwortlichkeiten, welche Risiken entstehen und bewertet diese. Risiken können unter anderem durch mangelhafte Funktionstrennung hervorgerufen werden und ggf. gegen die Compliance Anforderungen verstoßen Ressourcenmanagement Das Ressourcenmanagement beschäftigt sich mit der Planung, Bereitstellung und Optimierung des Einsatzes der Ressourcen (Personal) und der Definition von Rollen und Verantwortlichkeiten. Ein weiterer wesentlicher Bestandteil ist der effiziente und effektive Einsatz von SOA-spezifischem Expertenwissen und Wissen über die Infrastruktur. Unter anderem sind die folgenden Aufgaben umzusetzen: Verteilung von finanziellen Ressourcen Verteilung von Mitarbeitern und Fachkräften Vergabe von Rollen, Verantwortlichkeiten und Kompetenzen Im Ressourcenmanagement übernimmt SOA Security Governance z.b. die: Etablierung eines Kapazitätsmanagements, Erarbeitung eines Awareness-Programms zur Steigerung des Sicherheitsbewusstseins, Erarbeitung eines Trainingsplans zur Steigerung der Expertise im Bereich Sicherheit. Bezogen auf die Vergabe von Rollen und Verantwortlichkeiten ist eine Aktivität der SOA Security Governance im Ressourcenmanagement, Rollen wie beispielsweise Chief Information Security Officer (CISO), Compliance Manager, IT-Sicherheitsbeauftragter, usw. mit geeigneten Personen zu besetzen. 145

146 Value Delivery Diese Komponente setzt die definierten Richtlinien, Regeln und Standards durch. Ziel ist es, die von der Organisationsleitung ausgehende SOA-Strategie zu leben. Dafür werden die Lösungen für die Governanceanforderungen in die Praxis umgesetzt. Unter anderem sind die folgenden Aktivitäten auszuführen: Überwachung und Steuerung der Service-Lebenszyklen und betroffenen Prozesse Kommunikation von Richtlinien, Strategie und Standards Aktivierung der Richtlinieninfrastruktur Schulung von Mitarbeitern Etablieren von Technologie zur Verwaltung von Ressourcen, Implementierung von Services und IT-Werkzeugen. Die SOA Security Governance würde in diesem Bereich beispielsweise die folgenden Aktivitäten ausführen: Kommunikation von Sicherheitsstrategie, -Politik und -Framework, Durchsetzen der Sicherheitsrichtlinien, -Standards und -Prozeduren, Etablierung eines Risikomanagements, Kontrolle der Einhaltung von Gesetzen sowie externen und internen Regularien und Vorgaben, Aufbau eines Sicherheits-Controllings und -Reportings. Zudem müssen die in strategischer Ausrichtung geplanten und im Ressourcenmanagement besetzen Rollen umgesetzt und gelebt werden Performancemessungen Die Performancemessung erfolgt im Rahmen des Performance Managements. Die definierten Regeln, Richtlinien und Standards werden überwacht und überprüft, um mögliche Abweichungen frühzeitig zu erkennen. Ziel ist die Strategische Ausrichtung, Umsetzung von SOA Projekten, Verwendung von Ressourcen, Prozessperformance und Leistungserbringung zu kontrollieren und Schwachstellen zu identifizieren. Dazu werden die definierten Key Performance Indikatoren (KPIs), Indikatoren zur Kontrolle bestimmter Attribute oder Quoten bestimmt und ein Reporting etabliert. Beispielhaft sind die folgenden Kontrollen und Überprüfungen durchzuführen: Überprüfung der Einhaltung der definierten Richtlinien und Governanceanordnungen, Erhebung und Analyse von Messdaten für die IT-Effektivität. 146

147 Die SOA Security Governance würde die Einhaltung der Verantwortlichkeiten und die korrekte Ausübung der vergebenen sicherheitsrelevanten Rollen überprüfen Aufbau eines SOA Governance Frameworks Das SOA Governance Framework muss sich kontinuierlich den neuen Umständen und Herausforderungen anpassen. Daher liegt für Aufbau, Wartung und Erweiterung des SOAGovernance-Frameworks ein kontinuierlicher, interativer Prozess zu Grunde, der sich im Idealfall an dem Plan-Do-Check-Act (PDCA)-Kreislauf (siehe [PDCA]) orientiert. Die einzelnen Komponenten (Strategische Ausrichtung, Risikomanagement, Ressourcenmanagement, Value Delivery und Performancemessung) werden phasenweise umgesetzt (siehe Abbildung 37). Dabei muss in jeder Phase jede Komponente betrachtet werden, um deren kontinuierliche Verbesserung zu gewährleisten. S tra te g is c h e A u s ric h tu n g R is k o m a n a g e m en t R e ss o u rc en m a n ag e m e n t V a lu e D e liv e ry P e rfo rm a n c e m es su n g SO A G overnance Fram ew ork S tr a te g is c h e A u s ric h tu n g R isk o m a n a g e m en t R e sso u rcen m a n ag e m e n t V a lu e D e liv e ry P e rfo rm a n c e m es su n g S t r a te g is c h e A u s r ic h tu n g R is k o m a n a g e m en t R e s s o u rc en m a n ag e m e n t V a lu e D e liv e ry P e rfo rm a n c e m essu n g S tra te g is c h e A u s ric h tu n g R is k o m a n a g e m en t R e ss o u rc en m a n ag e m e n t V a lu e D e liv e ry P e rfo rm a n c e m es su n g Abbildung 37: PDCA-Cycle mit Komponenten Plan Der erste Schritt zu einem SOA Governance Framework ist die Definition von organisatorischen SOA-Zielen und SOA-Strategien. Diese müssen an den Zielen und Strategien der Organisation ausgerichtet sein, damit die Bestrebungen in Richtung SOA den größtmöglichen Erfolg haben. Daneben sind auch geltende Einschränkungen wie z.b. Ressourcen oder Budget aufzunehmen. Zur Verbesserung der SOA Governance sind bereits in der Plan-Phase Metriken zu definieren, um später in der Check-Phase eine aussagekräftige Bewertung durchführen zu können. Dafür werden Standards, Richtlinien, Portfolios, Projekte und Aktionen definiert bzw. modifiziert, die dem aktuellen SOA-Reifegrad der Organisation entsprechen und helfen, die nächste Ebene zu erreichen. 147

148 Do Die geplanten Governance Mechanismen werden in die Praxis umgesetzt. Dazu gehören Mechanismen zum: Aufnehmen und Beurteilen von Metriken und Durchsetzen von Richtlinien und Prozeduren. Es sollte darauf geachtet werden, dass die meisten Governance-Prozesse und die Aufnahme der Metriken größtenteils automatisiert erfolgen Check Die Check-Phase beinhaltet die Auswertung der Metriken und die Erstellung eines aussagekräftigen Berichts, der es ermöglicht, notwendige Handlungsfelder zu identifizieren. Ein Beispiel könnte wie folgt aussehen: Anzahl der Systeme, bei denen die Sicherheitsanforderungen nicht erfüllt sind, oder Anzahl und Art der vermuteten und tatsächlichen Zugriffsverletzungen Act Genau wie die SOA immer reifer hinsichtlich ihrer qualitativen Ausrichtung wird, muss sich auch das Governance Framework weiterentwickeln. Daher ist die SOA Strategie anzupassen und zu verbessern und in der Folge auch die Richtlinien und Metriken. Mit diesem Vorgehen wird sichergestellt, dass die SOA Governance mit der SOA reift Risikomanagement Das Risikomanagement befasst sich mit dem Prozess der Analyse und Bewertung von Bedrohungen und Schwachstellen im SOA-Umfeld sowie der Entwicklung von Strategien für das Management der sich daraus ergebenden Risiken. Ein Risiko ist definiert als die Gefahr von Verlusten infolge einer Unangemessenheit oder des Versagens von internen Verfahren, Menschen und Systemen. Des Weiteren können externe Ereignisse oder Gegebenheiten maßgebliche Risiken verursachen. Abbildung 38: Einordnung SOA-Risiken 148

149 Der Risikomanagement-Prozess gibt vor, auf welcher Grundlage von Faktoren das Risikomanagement vorgeht bzw. welche Faktoren mit in die Bewertung der Risiken einbezogen werden. Faktoren können dabei die Eintrittswahrscheinlichkeit oder die Schadenshöhe sein, die z.b. im Zusammenspiel einen Indikator als Basis der Bewertung bilden können. Diese Faktoren nehmen Einfluss auf die Frage, welche Risikobehandlungsstrategie angewandt werden soll. Für die Durchführung von Risikoanalysen bzw. -Bewertungen können die folgenden national und international anerkannten Standards und Good Practices genutzt werden: BSI-Standard 100-3: Risikoanalyse auf der Basis des IT-Grundschutzes, ISO 27005:2008: Information Security Risk Management Standard, ISO 27001:2005: Internationale Norm zum Management von Informationssicherheit, ISO 27002:2005: Formelles Zertifizierungsverfahren für die Einhaltung von Standards, NIST : Risk Management Richtlinie für IT Systeme, Relevante COBIT-Kontrollen. Das Risikomanagement beinhaltet je nach Standard bzw. Vorgehensmodell verschiedene Phasen. Gängige Phasen sind z.b. Risikoanalyse, Risikobewertung und Risikobehandlung die nachfolgend dargestellt sind: Abbildung 39: Darstellung des Risikomanagement-Prozesses Die folgenden Abschnitte beschreiben die dargestellten Phasen des RisikomanagementProzesses. Dabei werden die Unterpunkte näher erläutert und der Zusammenhang der einzelnen Unterpunkte bzw. Phasen wird beschrieben. 149

150 Bevor der in Abbildung 39 dargestellte Risikomanagement Prozess startet, werden die Informationen erfasst und klassifiziert (z.b. offen, intern, vertraulich, streng vertraulich). Danach wird eine Schutzbedarfsfeststellung durchgeführt. Ziel einer Schutzbedarfsfeststellung ist zu ermitteln, welcher Schutz für die Information und die eingesetzte Informationstechnik ausreichend und angemessen ist. Dabei wird der Schutzbedarf bezüglich der Sicherheitsziele Vertraulichkeit, Integrität und Verfügbarkeit bestimmt. Anhand der Ergebnisse der Schutzbedarfsfeststellung lassen sich die potentiellen Schadenshöhen ermitteln, die Grundlage für die Risikobewertung sind Risikoanalyse Die Risikoanalyse beinhaltet je nach Vorgehensweise eine Risikoidentifizierung als ersten Schritt des Risikomanagements. Bei der Risikoidentifizierung werden zunächst potenzielle Gefahren und identifizierte Schwachstellen aller betroffenen Komponenten und Prozesse analysiert. Zur Auflistung von potenziellen Bedrohungen können die in Kapitel 3.3 aufgeführten SOA-spezifischen Gefahren sowie die Gefahrenkataloge des Bundesamtes für Sicherheit in der Informationstechnik herangezogen werden. Es gibt in den Gefahrenkatalogen des BSI fünf verschiedene Kategorien für Gefahren (siehe auch Kapitel 3.2): Höhere Gewalt, Organisatorische Mängel, Menschliche Fehlhandlungen, Technisches Versagen, Vorsätzliche Handlungen. Diesen Kategorien können SOA-spezifischen Gefahren, die im Kapitel 3.3 erläutert werden, zugeordnet werden. Beispiele für SOA-spezifische Gefahren wären: Versäumte Anpassung der Organisationsstrukturen, die durch die Einführung einer SOA und damit grenzüberschreitender Aktivitäten nötig wird, Nicht korrekt am Business ausgerichtete IT. Dadurch werden Services nicht spezifisch genug geplant und entwickelt. Aus der Liste der Gefahren und der gefundenen Schwachstellen lassen sich direkt die Risiken ableiten. Die analysierten Risiken können sowohl auf die gesamte Architektur als auch auf einzelne IT-Komponenten oder Prozessschritte der SOA angewandt werden Risikobewertung Im zweiten Schritt werden die analysierten Risiken bewertet. Diese Bewertung beinhaltet die Ermittlung von Eintrittswahrscheinlichkeiten, von potenziellen Schadenshöhen (abhängig von der Bewertung der Assets) und von Risikoindikatoren zur Ermittlung einer geeigneten Risikostrategie zur Risikobehandlung. Ein Risikoindikator kann z.b. ermittelt werden, indem die Eintrittswahrscheinlichkeit und die potenzielle Schadenshöhe in einer Matrix verbunden werden. Je höher die Eintrittswahrscheinlichkeit in Kombination mit der Schadenshöhe ist, desto höher ist auch der Risikofaktor und desto kritischer ist das Risiko für die betrachtete SOA bzw. die gesamte IT der Organisation. 150

151 Zur Ermittlung der Schadenshöhe sind potenzielle Schäden aufzuzeigen, die sich in die folgenden Gruppen einstufen lassen [Ho 2009]: Direkter monetärer Schaden z. B. durch Vertragsstrafen oder Systemausfälle verursacht. Dies gilt insbesondere für Systeme, die zur direkten Generierung von Umsätzen beitragen. Der monetäre Schaden kann meist direkt beziffert werden. Indirekter monetärer Schaden, z. B. durch einen Imageschaden verursacht, der die Abwanderung von Kunden zufolge hat. Die Rufschädigung kann z.b. durch öffentlich ausgefochtene Schadensersatzklagen, falsche PR-Maßnahmen oder einen erfolgreichen Hackerangriff verursacht werden. Missachtung von Compliance-Anforderungen, z.b. durch den Verstoß gegen gesetzliche und regulative Auflagen oder der Verletzung von Fristen mit der Folge der strafrechtlichen Verfolgung oder dem Ausschluss aus Märkten. Schäden an Personen, z. B. durch fehlerhafte Produkte oder Arbeitsabläufe. Schäden, die sich speziell für Behörden durch die Nichtverfügbarkeit von Systemen ergeben, z.b. wenn Firmen Informationspflichten nicht erfüllen oder Bürger nicht mehr auf Services zugreifen können. Schäden, die sich direkt auf die SOA auswirken, z.b. Services können nicht genutzt werden, da Abhängigkeiten zu anderen Services nicht berücksichtigt wurden. Dadurch kommt es zu Zeitverzögerungen und zusätzlichen Kosten. Die genannten potenziellen Schäden lassen sich je nach Kritikalität für den jeweiligen Teil der Service-orientierten Architektur beziffern. Dadurch entsteht innerhalb der Risikomatrix eine neue Reihe von Risikofaktoren, die in Verbindung mit der Eintrittswahrscheinlichkeit den Risikoindikator ergeben. Dieser Risikoindikator gibt dann, je nach Strategie, einen Risikobehandlungsansatz vor. Mögliche Strategien zur Behandlung von Risiken sind im nächsten Abschnitt beschrieben Risikobehandlung Sind die Risiken identifiziert und nachfolgend bewertet worden, gilt es einen nachhaltigen Maßnahmenkatalog zu erstellen, der die verschiedenen Vorgehensweisen der Risikobehandlung kostenoptimal abwägt und das Gesamtrisiko mindert. Dazu gibt es verschiedene Risikobehandlungsstrategien, die wie folgt beschrieben werden können. Risikovermeidung Risikovermeidung ist die restriktivste Art des Risikoumgangs. Hierbei wird ein Risikopotenzial als zu hoch eingeschätzt. Mittels Reduzierung der Eintrittswahrscheinlichkeit auf nahezu Null wird das Risiko umgangen. Beispielhaft hierbei könnte ein operatives Risiko bei der Standortplanung der für die SOA relevanten Server sein. In diesem Beispiel würde man vermeiden, ein Rechenzentrum oder einen Technikraum direkt in ein überflutungsgefährdetes Gebiet zu bauen. Risikoverminderung Die Risikoverminderung stellt eine weniger drastische Vorgehensweise dar und reduziert die Eintrittswahrscheinlichkeit oder Auswirkungen eines Risikos auf ein akzeptables Niveau. Beispielhaft könnte hier die Einführung einer Firewall genannt werden, die das Einschleusen von unerwünschtem Code verhindert. Risikodiversifikation Risikodiversifikation überträgt bzw. verteilt ein Gesamtrisiko auf viele Einzelrisiken. 151

152 Diese sollten möglichst nicht positiv korreliert sein. So ist zum Beispiel zu erwägen, ob es sinnvoll ist, zur Bewältigung von Ausfallrisiken redundante Systeme einzuführen. Damit würde das gleiche Risiko auf mehrere Instanzen verteilt. So könnte z.b. ein Service redundant auf verschiedenen Systemen laufen, um im Falle des Ausfalls des einen, den Betrieb mit dem anderen weiterzuführen. Risikotransfer Ein klassisches Beispiel stellen Versicherungen dar. Die wirtschaftlichen Auswirkungen eines eingetretenen Risikos werden auf einen externen Risikoträger übertragen. Risikovorsorge Wird die Wirkung des Risikos nicht transferiert, sondern selbst getragen, muss die Organisation selbsttätig vorsorgen. Rückstellungen sind ein klassisches Beispiel hierfür. Risikoakzeptanz Das Risiko, in den meisten Fällen das verbleibende Restrisiko, wird akzeptiert. Es gibt zudem Risiken, die nicht eliminiert und nur mit hohem Aufwand minimiert werden können. Zu diesen Risiken, die oft von Organisationen akzeptiert werden, gehören unter anderem Naturkatastrophen. Je nach der Kosten/Nutzen-Abwägung und der Gewissheit, wie hoch die Kosten für die Bekämpfung von Risiken sein können, werden sich die Verantwortlichen für eine Risikobehandlungsstrategie entscheiden. Es wird jedoch klar, dass die genannten Strategien eingesetzt werden sollten, um das Schadenspotenzial, dem die Organisation gegenüber steht, zu minimieren bzw. auf ein akzeptables Level zu bringen Schutzmaßnahmen Die bisherige Darstellung des Risikomanagement-Prozesses hat gezeigt, dass das Management von Risiken innerhalb einer SOA von hoher Wichtigkeit ist, um potenzielle Schäden gering zu halten. Im Kapitel 3.3 sind Schutzmaßnahmen gemäß BSI Standard benannt. Nachfolgend sind beispielhaft einige dieser Maßnahmen aufgelistet. Sie sind entsprechend der sechs Maßnahmenkataloge des IT-Grundschutzes kategorisiert: Infrastruktur: Diverse Maßnahmen zum Brandschutz (Brandmeldeanlage, Rauchschutz, etc.) Physische Absicherung von Hardware, die die technische Grundlage für die SOA bilden. Dazu zählt die Einrichtung einer Zugangskontrolle Organisation: Sicheres Löschen von Daten eines Web Service, die nicht mehr benötigt werden Vergabe von Zugriffsberechtigungen auf sensible Informationen Personal: Bestimmung von Verantwortlichkeiten der einzelnen Bereichen der SOA, besonders aber im Bereich Governance und Compliance, Sicherheit und Risikomanagement 152

153 Verpflichtung zu Verschwiegenheit externer Mitarbeiter, die aktiv in den SOA Lebenszyklus (siehe Kapitel 5.3) eingebunden sind, besonders aus Sicherheitssicht Hardware und Software: Anwendung von Verschlüsselungstechniken zum Schutz kritischer Daten innerhalb der SOA Einsatz von Security Agents zum Durchsetzen von Sicherheitsrichtlinien Absicherung der Serversysteme auf denen die SOA aufbaut bzw. die Services gehostet werden. Dies beinhaltet das Härten der Serversysteme Kommunikation: Absicherung der Kommunikationswege in verteilten Systemen bzw. zwischen verschiedenen Services der SOA Restriktive Rechtevergabe für den Zugriff auf Services Notfallvorsorge: Erstellung von Datensicherungen zur schnellen Wiederherstellung (Restore) nach einem Stör- bzw. Notfall Erstellen eines Wiederanlaufplans für die Architektur Auch hier gilt es zu berücksichtigen, dass sich die angegebenen Maßnahmen in Form von Standards und Tools weiterentwickeln und in regelmäßigen Abständen aktualisiert werden müssen. Der folgende Abschnitt gibt dazu ein Vorgehen vor Kontinuierliche Verbesserung Die kontinuierliche Verbesserung stellt die letzte Phase des Risikomanagement-Prozesses dar und zielt auf die Aufrechterhaltung und Verbesserung des Risikomanagements für die SOA ab, um beständig die Risiken einer SOA zu analysieren und zu behandeln. Ein Anstoß für die kontinuierliche Verbesserung im Risikomanagement kann z.b. die Änderung der Gefahrenlage, Änderung der Geschäftsanforderungen oder Änderung der Services sein. Falls Maßnahmen nicht vollständig umgesetzt oder behandelt wurden, kann dies auch ein Grund für den Anlauf der kontinuierlichen Verbesserung sein. Wenn diese Phase erreicht ist, wurden bereits die ersten Erfahrungen gemacht, die ersten Risiken analysiert und behandelt. Es ist beabsichtigt, dass die Sicherheit des Prozesses in dieser Phase verbessert wird. Dies bedeutet: Analyse und Bewertung von weiteren SOA-Risiken: Im Laufe der Zeit bzw. mit der Einführung von Änderungen (Change Management) kann es sein, dass sich die SOA zusätzlichen Risiken stellen muss bzw. dass Änderungen in der SOA Umgebung auftreten. Daher sind die Schritte der Analyse und der Bewertung im Rahmen der kontinuierlichen Verbesserung nochmals durchzuführen. 153

154 Änderung der Risikobehandlungsstrategie: Es kann sein, dass aufgrund von Änderungen von Gegebenheiten oder von strategischen Entscheidungen die Risikobehandlungsstrategie geändert wird. Diese Änderung sollte im Rahmen der kontinuierlichen Verbesserung auf Machbarkeit, Sicherheit und Wirtschaftlichkeit geprüft werden. Identifizierung von Maßnahmen zur Verbesserung der Prozesse, die durch die SOA unterstützt werden: Es ist erforderlich, dass die Sicherheitsverantwortlichen der Organisation bzw. speziell der SOA Maßnahmen zur kontinuierlichen Verbesserung des Risikomanagements entwickeln und bereitstellen. Es besteht das Ziel, dass die Wirksamkeit des Risikomanagements durch die Nutzung von Sicherheitspolitiken, Prüfungsergebnissen, Analysen, korrigierenden und präventiven Maßnahmen erhöht wird. Implementierung von Maßnahmen zur Verbesserung der SOA: Im zweiten Schritt der kontinuierlichen Verbesserung sind die identifizierten Verbesserungsmaßnahmen zu implementieren. Der Status der Umsetzung der Verbesserungen kann zu einem späteren Zeitpunkt durch die interne Revision oder durch externe Prüfer getestet werden. Aktualisierung von SOA-spezifischen Sicherheitskonzepten, Richtlinien und Prozeduren: Die Aktualisierung von z.b. Risikoplänen zur Gefahrenabwehr könnte unter anderem eine Folge der Umsetzung von Verbesserungen sein. Teil der Gefahrenabwehr kann zum Beispiel eine Störfallplanung oder ein Business Continuity Plan sein. Einführung zusätzlicher Maßnahmen zur Vorbeugung von SOA-Risiken: Das Sicherheitsmanagement sollte präventive Maßnahmen wählen, die zur Vorbeugung von Risiken dienen. Die folgenden Schritte tragen dazu bei: Identifizierung neuer, potentieller Gefahren bzw. Risiken und deren Ursachen Bewertung der Notwendigkeit von Maßnahmen zur Verhinderung des Auftretens Festlegung und Einführung von vorbeugenden Maßnahmen Aufnahme und Bewertung der Ergebnisse der Maßnahme Kontrolle der Wirkung der vorbeugenden Maßnahmen Steigerung der Sensibilisierung des Managements bzw. der Verantwortlichen der SOA: Im Rahmen der kontinuierlichen Verbesserung sollte das Management weiter sensibilisiert werden. Dies trägt auch dazu bei, dass die nötigen Mittel bereitgestellt werden. Kontrolle der Maßnahmen zur Verbesserung des Prozesses: Der Status der Umsetzung von Maßnahmen zur Verbesserung kann mit Hilfe von definierten Key Performance Indikatoren (KPI) kontrolliert und berichtet werden. Auf Grundlage der Ergebnisse der KPI Messung kann das Management wiederum mit geeigneten Maßnahmen gegensteuern. Durch die kontinuierliche Verbesserung des Risikomanagement-Prozesses können potenzielle Risiken für die SOA zusätzlich analysiert und bewertet, Maßnahmen zur Eliminierung bzw. Minimierung identifiziert und implementiert sowie Mechanismen zur Kontrolle eingeführt werden. Durch die kontinuierliche Verbesserung wird die SOA nachhaltig verbessert und optimiert, was sich aus Sicht des Risikomanagements durch die Eliminierung bzw. Minimierung von Risiken zeigt. 154

155 5.1.6 Compliance-Management Unter dem Begriff der Compliance versteht man die Einhaltung externer und interner Vorgaben. Ziel einer jeden Organisation ist die Einhaltung der Compliance-Anforderungen zur Vermeidung von eventuellen Schäden wie z.b. Schädigung des Images durch negative Presse nach einem erfolgreichen Hackerangriff oder dem Ausschluss von Haftungsfällen bzw. Schadensersatzklagen. Gesetze und externe sowie interne Regularien und Vorgaben National und international gibt es immer mehr gesetzliche Regularien, die es einzuhalten gilt. In diesem Zusammenhang gilt es für jede Organisation, allgemeine und/oder spezifische Compliance-Anforderungen zu erfüllen. Um Maßnahmen auf eine geeignete Weise durchsetzen zu können, benötigt man neben Checklisten und Vorgehensmodellen auch entsprechende Werkzeuge wie z.b. spezielle Compliance-Tools. Externe Gesetze und Regularien können z.b. wie folgt benannt werden: Telemediengesetz (TMG) Regelt Informationspflichten eines Anbieters von Services wie z.b. Impressum oder die Allgemeinen Geschäftsbedingungen. Vorratsdatenspeicherung Besagt, dass Kommunikationsvorgänge, die elektronisch durchgeführt werden, für eine bestimmte Frist gespeichert werden müssen. Bundesdatenschutzgesetz (BDSG) Regelt zusammen mit Landesdatenschutzgesetzen den Umgang mit personenbezogenen Daten in IT-Systemen und die Rechte Betroffener. Es werden z.b. Aussagen zu Auskunfts- und Berichtigungspflicht, Beschwerderecht und Möglichkeiten zur Löschung und Sperrung getroffen. Gesetze zur Schaffung eines internen Kontrollsystems bzw. Risikomanagements: KonTraG Besagt, dass der Vorstand einer Organisation geeignete Maßnahmen (Einrichtung eines Überwachungssystems) zu treffen hat, um den Fortbestand der Gesellschaft zu sichern und gefährdende Entwicklungen früh zu erkennen. Sarbanes Oxley Act of 2002 (SOX) Verpflichtet Organisationen, die an der Amerikanische Börse gelistet sind, adäquate Kontrollstrukturen und Prozeduren für finanztechnisch relevante Systeme zu etablieren. 8. EU-Richtlinie (Euro SOX) Besagt z.b., dass ein Risikomanagementsystem zu etablieren ist. Interne Gesetze und Richtlinien könnten z.b. wie folgt benannt werden: Interne Vorgaben durch Sicherheitskonzepte, -Richtlinien und -Prozeduren Behörden-spezifische Vorgaben wie die Beachtung spezieller Vorgaben bei dem Umgang mit VS-eingestuften Daten Interne Datenschutzvorgaben durch einen Sicherheitsbeauftragten 155

156 Interne Berichtspflichten 5.2 Sichere SOA Migration Definition Eine SOA Migration ist ein langfristiger Prozess, der gewachsene Anwendungslandschaften und IT-Infrastrukturen in eine Service-orientierte Struktur überführt und auf eine Architektur abbildet Grundlagen Beschreibung SOA Migration Organisationen stehen heutzutage vor der Herausforderung, sich den schnell ändernden Marktsituationen und Kundenansprüchen anpassen zu müssen. Dafür müssen die IT-Systeme schnell und flexibel an die sich ändernden Geschäftsprozesse angepasst werden. Dieser Aufgabe können allerdings viele der gewachsenen Anwendungslandschaften nicht nachkommen. Das liegt unter anderem an ihren eng verbundenen und komplexen Altsystemen mit vielen Punkt-zu-Punkt-Schnittstellen und Abhängigkeiten. Eine Antwort kann der Umbau der etablierten Anwendungslandschaft zu einer Service-orientierten Architektur sein. Durch ihre lose gekoppelten Services und deren Wiederverwendbarkeit besitzen Service-orientierte Architekturen das Potenzial, die Herausforderungen zu meistern und viel flexibler zu sein als monolithische Systeme. Eine Migration kann insbesondere dann sinnvoll sein, wenn eine heterogene Anwendungslandschaft in der Organisation vorliegt, die Organisation sehr stark mit Partnern und Kunden vernetzt ist, eine schnelle und flexible Anpassung der IT aufgrund der Marktbedingungen erforderlich ist. Alle drei Punkte sind Aspekte, die dafür sprechen eine SOA einzuführen. Dabei sollte beachtet werden, dass die Migration auf eine SOA immer im Kontext von neuen Anforderungen steht, d.h. es werden neue Services erstellt und Altanwendungen Servicefähig gemacht, damit die Services die neuen Geschäftsanforderungen schnell umsetzen können. Eine Herausforderung bei der Migration ist die Integration der Altsysteme bzw. der bestehenden IT-Landschaft in eine SOA, denn die Altsysteme können nicht einfach durch neu entwickelte Services ersetzt werden. Zum einen würde die Organisation ihre über Jahre getätigten Investitionen verlieren, zum anderen sind die Leistungen der Altsysteme optimiert und sie verkörpern viele Wettbewerbsvorteile, die Organisationen benötigen, um erfolgreich zu sein. Aus diesem Grund ist es wichtig, diese Anwendungen als Services verfügbar zu machen, damit sie in neue Geschäftsprozesse der Organisation eingebaut werden können. 156

157 Somit ist eine schnelle Ablösung der gewachsenen Anwendungslandschaft in vielen Organisation nicht möglich. D.h. die SOA Migration stellt ein langfristiges, strategisches Programm dar, dass von der Leitung der Organisation getragen und gesteuert werden muss. Mit der SOA Migration, also mit der Ausrichtung von Software und Architektur nach dem SOA-Paradigma, stoßen Organisationen einen Prozess an, der sich in Abhängigkeit von deren Größe über mehrere Jahre erstrecken kann. Um eine SOA Migration erfolgreich zu gestalten, sollten die folgenden vier Bereiche beachtet werden: Strategische Ausrichtung: Die SOA Strategie muss an den Geschäftszielen ausgerichtet sein, dafür sind alle Geschäftsprozesse, die die Ziele unterstützen, zu identifizieren. SOA Governance: Die Verfahren, Richtlinien, Rollen und Verantwortlichkeiten zur kontinuierlichen Ausrichtung der Services und Geschäftsprozesse an den Geschäftszielen durch Steuerungs- und Kontrollmaßnahmen sind zu definieren (siehe Kapitel 5.1). Beurteilung der Technologie: Es sollte realistisch eingeschätzt werden, was die verschiedenen Technologien in Abhängigkeit vom zu lösenden Problem leisten können und was nicht. Veränderung der Denkweise: Ein Verständnis für das Konzept SOA muss bei den Mitarbeitern geschaffen werden Vorgehensmodelle Ziel einer SOA Migration ist der Übergang von einer gewachsenen Anwendungslandschaft zu einer Service-orientierten Architektur. Dafür ist es erforderlich die Geschäftsprozesse auf die IT abzubilden. Hierfür gibt es zwei unterschiedliche Vorgehensmodelle: Top-down: Beim Top-down-Ansatz ist der Ausgangspunkt das Geschäftsmodell der Organisation. Aus diesem Modell werden die Services aus den fachlichen Anforderungen abgeleitet und immer weiter verfeinert. Bei diesem Ansatz muss die SOA parallel neben den Altsystemen aufgebaut und zunächst zwei parallele Architekturen betrieben werden. Nach der erfolgreichen Erprobung erfolgt eine vollständige und unmittelbare Umstellung aller Applikationen und Systeme eines Unternehmens auf eine SOA. Dieses Vorgehen lässt sich allerdings nur bei sehr kleinen Organisationen anwenden. Bei größeren Organisationen ist eine vollständige SOA Migration ein Prozess, der sich über mehrere Jahre erstreckt. 157

158 Vorteile Nachteile Gesamte IT-Architektur ist nach den Bedürfnissen der Geschäftsprozesse ausgerichtet. Durch parallele Systeme entstehen hohe Kosten. Services sind aus den fachlichen Anforderungen abgeleitet. ROI wird später erreicht. Wiederverwendbarkeit wird verbessert. Durch die plötzliche Umstellung entsteht ein höheres Risiko (keine Lernphase, überforderte Mitarbeiter, Effizienzeinbußen, ). Tabelle 5: Vor- und Nachteil der Top-down Vorgehensweise Bottom-up: Beim Bottom-up-Ansatz werden die bereits bestehenden Möglichkeiten der ITInfrastruktur genutzt, um punktuell und iterativ bestehende Anwendungskomponenten in neue Services zu überführen. Dafür werden neue Services aus den Fachabteilungen heraus entwickelt und auf die bestehende Infrastruktur aufgesetzt. Darüber hinaus werden existierende Funktionalitäten der Anwendungslandschaft z.b. durch Web Service Schnittstellen erweitert und als neue Dienste zur Verfügung gestellt. Vorteile Nachteile Schnelle Ergebnisse werden geliefert. Standardisierung wird reduziert. Vorhandenen Infrastruktur wird berücksichtigt. Flexibilität wird reduziert. Es gibt eine Lernphase für alle Beteiligten. Anfangs hohe Investitionen notwendig, aber die Systeme werden nur sukzessive angebunden. Tabelle 6: Vor- und Nachteile der Bottom-up Vorgehensweise Kombiniertes Vorgehen Meet-in-the-middle In der Praxis wird selten eines der beiden skizzierten Vorgehensmodelle in Reinform angewandt. Vielmehr wird versucht die Vorteile der beiden Herangehensweisen zu kombinieren. Das so entstehende Verfahren wird als Meet-in-the-middle bezeichnet. Dabei werden bestehende Geschäfts- und IT-Modelle schrittweise, sowohl aus den Fachabteilungen als auch aus den fachlichen Geschäftsanforderungen heraus, aufeinander abgestimmt. Die Migration auf eine SOA sollte iterativ erfolgen und mit einer geschäftlichen Priorisierung in jeder Iteration einhergehen. Der Grund für das iterative Vorgehen ist, dass eine vollständige SOA Migration hoch komplex ist, sehr lange dauert und hohe Kosten verursacht. Somit ist die Migration nicht in einem Projekt realisierbar. Jede Iteration wird so geplant, dass sie eine Umstellung und Integration eines Teilbereiches adressiert, aus dem direkt ein Mehrwert sichtbar wird und der für weitere Iterationen motiviert. Außerdem erlaubt ein iteratives Vorgehen eine bessere Kontrolle und Steuerung. Die nachfolgende Abbildung zeigt eine typische Entwicklung einer SOA. 158

159 B e ste h e n d e A n w e n d u n g sla n d sc h a ft se r v ic e -o r ie n tie r te A r c h ite k tu r F le x ib ilitä t, W ie d e r v e r w e n d b a r k e it, lo se K o p p lu n g, n e h m e n z u Abbildung 40: Schrittweise SOA Migration (vgl. [Gi 2008]) Ablauf SOA Migration Die SOA Migration besteht aus vier Phasen, wobei die phasenübergreifende SOA Governance (siehe Kapitel 5.1) für die Steuerung und Kontrolle des Ablaufs und für die kontinuierliche Verbesserung der Services verantwortlich ist. Die vier Phasen sind: Strategie: Definiert die Ziele für die Migration und erstellt die Strategie und die Roadmap zur Zielerreichung. Planung: Leitet die Services aus Geschäftszielen und -anforderungen ab und beschreibt die Umsetzung der Services. Migration: Umsetzung der Services und der zur Bereitstellung notwendigen physischen Umgebung. Betrieb: Stellt den laufenden Betrieb der SOA sicher. Da die SOA Migration schrittweise erfolgt, lässt sich die Gesamtaufgabe der Realisierung einer SOA nicht in vier Phasen unterteilen. Es handelt sich vielmehr um einen iterativen Prozess mit dem Ziel, die SOA in einzelnen Stufen immer weiter auszubauen. Die Umsetzung einer einzigen Stufe einer SOA bedeutet in der Regel eine Vielzahl von Projekten, z.b. kann es sein, dass erst ein einzelner Service umgesetzt wird (1. Projekt). Anschließend wird der Service in einem neuen Prozess genutzt (2. Projekt). Danach werden an den Prozess Fachanwendungen angeschlossen (3., 4., Projekt). Alle diese Projekte hängen zusammen. Jedes Projekte muss aber separat geplant und umgesetzt werden. Das bedeutet, dass für jede Auswahl an Services, die neu hinzukommen, der Migrationsprozess durchlaufen wird. SO A G overnance Abbildung 41: Vorgehen SOA Migration 159

160 Nachfolgend werden die Phasen der SOA Migration beschrieben. Strategie Zu Beginn einer SOA Migration müssen der aktuelle Stand der Organisation hinsichtlich der SOA-Reife und die Geschäftsanforderungen ermittelt werden. Die Feststellung der SOAReife kann unter anderem mit dem in Kapitel vorgestellten SOA Maturity Model erfolgen. Darüber hinaus müssen die Geschäfts- und IT-Ziele und die zukünftige Entwicklung der Organisation verstanden und aufgenommen werden. Ausgehend vom Bedarf der Organisation sollte ein Soll-Zustand auf der konzeptionellen Ebene definiert werden, durch den die Organisation in die Lage versetzt wird, ihre Ziele zu erreichen und die notwendigen Maßnahmen zur Zielerreichung zu identifizieren. Aus dem gewünschten Soll-Zustand ist ein Plan zu erstellen, der die notwendigen Projekte und Aktivitäten zur Umsetzung der SOA identifiziert und priorisiert. Planung 1. Bestehende Systeme analysieren Zu Beginn einer SOA Migration müssen die technischen und geschäftlichen Rahmenbedingungen für die Migration aufgenommen und die zur Verfügung stehenden Informationen für die Umstellung auf eine SOA gesammelt werden. Dazu gehört auch die Identifizierung der Stakeholder. Hierbei sollte z.b. erfasst werden, wer die SOA Migration vorantreibt und finanziert, das Wissen über die Altsysteme und die zukünftige SOAUmgebung hat und die Nachfrage für potentielle Services schafft. Besonderer Wert bei der Analyse sollte auf der Begutachtung von Sicherheitsanforderungen der Geschäftsanforderungen, Geschäftsprozesse, Altsysteme und Komponenten liegen. Vor allem sind die Gründe und Maßnahmen selbst zu beachten und zu erfassen. Dadurch lassen sich wichtige Informationen für die Sicherheit der Systeme in der späteren Zielumgebung und für die Anpassung des Sicherheitskonzepts sammeln. 2. Auswahl von Services Zunächst sind die Servicekandidaten für die Migration bzw. neue Services zu identifizieren. Die Identifikation der Services erfolgt anhand des Vorgehensmodells (siehe Kapitel ). In der Regel wird die Lokalisierung der Services sowohl nach dem Top-down als auch nach dem Bottom-Up Verfahren erfolgen. Nachdem im ersten Schritt die umzusetzenden Services identifiziert wurden, ist jetzt eine kleine Anzahl an Services auszuwählen, die implementiert werden soll. Der Grund hierfür ist, dass die Migration auf eine SOA nicht in einem Schritt erfolgt, sondern in mehreren kleineren. Ziel bei der Konzeption des ersten Schrittes sollte es sein, dass Einsparungen erzielt werden, die den nächsten Schritt finanzieren oder erleichtern. Gute Kandidaten zur Umsetzung sind Services, die: konkrete Funktionen ausführen, klar definierte Ein- und Ausgaben haben, nicht organisationskritisch sind, sich in stabilen Umgebungen befinden und wiederverwendet werden können. 160

161 3. Definieren der Zielumgebung In diesem Schritt werden Informationen über die SOA-Zielumgebung für die ausgewählten Dienste gesammelt. Unter anderem sollte ermittelt werden: Hauptkomponenten der SOA-Umgebung (Registries, Key Management Komponenten, UDDI,...), Zusammenspiel der verwendeten Technologien und Standards in der Zielumgebung, Leitlinien für die Umsetzung von Services, Interaktion zwischen den Services und der Umgebung, Erwartete Quality of Service (QoS) für die Services. 4. Unterschiede analysieren (GAP-Analyse) Die Lücke zwischen dem Soll- und Ist-Zustand wird ermittelt, um die Handlungsfelder bei der Umwandlung von Altanwendungen oder der Etablierung neuer Services zu identifizieren. Die Analyse der Lücke kann auf unterschiedliche Weise und Tiefe erfolgen. Z.B. kann unter Umständen eine Analyse der Code-Qualität mit Hilfe von speziellen Analyse Tools erfolgen oder eine einfache Befragung der Entwickler durchgeführt werden. In diesem Schritt sollte außerdem eine Schätzung des Aufwands und der Kosten durchgeführt werden, die durch die Migration entstehen. 5. Risikoanalyse Die Risikoanalyse soll die relevanten Gefährdungen für die SOA und die neuen Services identifizieren und die daraus möglicherweise resultierenden Risiken abschätzen. (Siehe Kapitel 5.1.5) 6. Migrationskonzept Das Migrationskonzept beschreibt im Detail, welche Teile des Altsystems betroffen sind, welche Änderungen zur Migration durchzuführen sind und an welcher Stelle die migrierten Systemteile in das Neusystem zu integrieren sind. Abhängig von Aspekten der Sicherheit des Altsystems wird für die Geschäftsprozesse eine Migrations- und Rollbackstrategie gewählt und eine detaillierte Migrationsplanung festgelegt. (Siehe Kapitel 5.2.4) Alle Informationen, die in den vorangegangenen Aktivitäten gesammelt wurden, fließen in das Migrationskonzept ein. Zusätzlich spielen die Informationen eine entscheidende Rolle bei der Abschätzung der Wirtschaftlichkeit des Migrationsvorhabens. Ein Migrationskonzept sollte unter anderem die folgenden Punkte adressieren: Betrachtung und Einschätzung der Risiken, Durchführbarkeit und Aufwände, SOA-Migrationsplan, Darstellung des Ist-Zustands und der Zielumgebung, Konzept für die Gestaltung des Wissenstransfers, Erstellen eines Sicherheitskonzeptes. 161

162 Migration In der Migrationsphase werden sowohl die neu konstruierten, als auch die aus den Altanwendungen entstandenen Services und Komponenten in die Produktivumgebung migriert. Außerdem müssen die erforderlichen Infrastrukturkomponenten aufgebaut werden. Beim Aufbau der Komponenten und Services in unterschiedlichen Domänen ist auf die korrekte Durchführung der Funktionstrennung zu achten. Auch die erstellten Sicherheitskonzepte und die gesetzlichen Vorschriften sind entsprechend umzusetzen. Im Rahmen der Umsetzung ist neben der Realisierung der Services auch die Schulung der fachlichen Mitarbeiter und der Nutzer entscheidend. Außerdem sollte frühzeitig mit dem Wissenstransfer aus dem Projekt in die Abteilungen begonnen werden bzw. das Know-How der Mitarbeiter entsprechend der Anpassungen der Services erweitert werden. Ziel der Maßnahmen ist unter anderem, dass Fachabteilungen übergreifend prozessorientiert denken (Geschäftsprozesse), d.h. Sie müssen die SOA Prinzipien in Bezug auf Geschäftsprozesse und Serviceorientierung verstehen. Nutzer in den neuen Anwendungen bzw. Funktionalitäten (z.b. Portal) geschult werden. IT-Abteilungen (sofern sie selbst entwickeln) die entsprechenden Architekturen und Technologien erlernen. IT-Abteilungen ggf. Besonderheiten im Betrieb kennen lernen (z.b. wie überwache ich ein verteiltes System?). Betrieb Im Kern des Betriebs steht das SOA Management und allen voran die SOA Governance, die von der Organisation gelebt werden muss. Ohne eine von der Organisationsführung ausgehende Steuerung und Kontrolle kann die Realisierung einer SOA nicht verwirklicht werden. Der Aufbau einer SOA ist ein strategischer Prozess, der über mehrere Jahre kontinuierlich vorangetrieben werden muss Methoden und Hilfsmittel zur Unterstützung der Migration Zur Unterstützung der SOA Migration gibt es unterschiedliche Methoden, die vor allem bei der Strategie- und Planungsphase helfen. Nachfolgend werden zwei von ihnen vorgestellt. Das SOA Maturity Model gibt der Organisation während der Strategiephase einen ersten Überblick über die SOA-Reife der Organisation und kann erste Aktivitäten für die Entwicklung einer SOA-Roadmap aufzeigen. Das Application Portfolio Management kann einerseits der Organisation bei der Strategiephase helfen, notwendige Projekte zum strukturierten Aufbau einer SOA zu identifizieren und andererseits bei der Planungsphase unterstützen, die geeigneten Services für die Umsetzung zu ermitteln Application Portfolio Management Ein Anwendungsportfolio ist die Menge aller in einer Organisation vorhandenen Software Assets (Anwendungen bzw. Services). Dieses Portfolio muss verwaltet werden, so dass der 162

163 Nutzen für die Organisation unter Berücksichtigung eines akzeptierten Risikoniveaus maximiert wird. Als erster Schritt wird das bestehende Anwendungsportfolio erfasst und untersucht. Diese Phase wird als Assessment bezeichnet. Dabei wird das Portfolio einerseits hinsichtlich strategischer Aspekte der Organisation (Ziele, Marketing, operationelle Prioritäten) und andererseits auf die Portfolioeigenschaften (Qualität der Anwendungen, technische Ziele, finanzielle Aspekte) eingeschätzt. Anschließend folgt die Phase Transformation Management, in der zuerst die Ziele des Portfolios definiert werden müssen. Darauf aufbauend werden Projekte geplant und durchgeführt, um das Portfolio an den gesetzten Zielen auszurichten. Zur Anpassung der Services des Portfolios stehen die Maßnahmen Ersetzen, Einstellen, Restrukturierung, Neu bewerten oder Verlagerung zur Verfügung. Um das Portfolio lebendig zu halten, müssen regelmäßig dessen strategische Ausrichtung und die enthaltenen Anwendungen untersucht werden. Dies soll sicherstellen, dass das Portfolio die Organisationsziele effektiv und effizient unterstützt SOA Maturity Model Ausgangspunkt für viele SOA-Initiativen ist eine erste Einschätzung der Ausgangslage der Organisation. Hier kann das SOA Maturity Model helfen, das die Fragen beantwortet: Wo sind wir gerade? Wo wollen wir hin? Wie erreichen wir das Ziel? Die Abschätzung der aktuellen Situation erfolgt anhand unterschiedlicher Kriterien im Bereich der Organisation. Z.B. kann bewertet werden: Wie stark sind die SOA-Kompetenzen in der Organisation ausgeprägt? Erfährt die SOA Initiative eine breite Unterstützung durch die Organisationsleitung? Welche Komponenten einer SOA-Infrastruktur sind umgesetzt? Ist eine SOA Governance etabliert? Gibt es eine SOA-Roadmap und welche Schritte sieht sie vor? Welche aktuellen SOA Initiativen werden durchgeführt? Gibt es bereits Erfahrungen und erfolgreiche Projekte im Umfeld von SOA? Wurde eine Kosten-Nutzenanalyse auf Basis von SOA durchgeführt? 163

164 Die Informationen werden durch ein organisationsweites Assessment aufgenommen und die Daten anschließend ausgewertet. Zum Schluss erfolgt die Einordnung der Organisation in das sechsstufige SOA Maturity Model, dessen einzelne Stufen (Level) nachfolgend erläutert werden. Level 0: In der Organisation ist das Thema SOA nicht präsent und es gibt auch keine Erfahrungen. Level 1: In oder in Teilen der Organisation gibt es erste Bestrebungen eine SOA aufzubauen. Es wurden erste Erfahrungen gesammelt. Allerdings beschränken sich die bisherigen Aktivitäten auf Erfahrungen, die durch die Implementierung von einzelnen Web Services gesammelt wurden, bei denen die Technologie im Mittelpunkt stand. Level 2: In der gesamten Organisation gibt es ein klares Bekenntnis, ausgehend von der Organisationsleitung, zum Aufbau einer SOA. Dafür werden die notwendigen organisatorischen Strukturen aufgebaut. Erste initiale SOA-Projekte mit dem Ziel, Geschäftsprozesse abzubilden, werden gestartet bzw. laufen. Level 3: Es existiert eine organisationsweite SOA-Strategie. Zur Einführung der SOA wurde ein Service-Katalog definiert und ein Service Modell für die gesamte Organisation erstellt. Die ersten Projekte befinden sich in der finalen Phase. Dabei wurden wiederverwendbare Services implementiert und orchestriert. Die Organisation hat die SOA Governance Prozesse umgesetzt, die sicherstellen, dass alle neuen Projekte im Einklang mit der SOA Strategie stehen. Level 4: Erfahrungen aus abgeschlossenen SOA-Projekten liegen vor und können für weitere Projekte und den Betrieb genutzt werden. Alle alten und neuen Geschäftsprozesse werden auf der Grundlage der SOA aufgebaut bzw. migriert. Die Organisation verfügt zu dem über ein gemanagtes Service Portfolio und einen Service Lifecycle. Metriken für den Betrieb wurden erstellt und werden berichtet. Level 5: Die komplette Organisation operiert auf einer dynamischen SOA, die sowohl mit der IT als auch dem Geschäft synchronisiert ist. Dies garantiert der Organisation die optimale Balance zwischen Flexibilität, Kosten, Risiko und Leistung. Das SOA Maturity Model erfüllt somit die folgenden Aufgaben: Darstellung der Ausgangslage, Identifizierung von Lücken, Erleichterung der Kommunikation der SOA-Vision, Priorisierung von Maßnahmen und Darstellung von deren Wirkung, Schaffung von Grundlagen für die Messung des Erfolgs, Vorgaben für eine Roadmap. 164

165 Die nachfolgende Abbildung 42 zeigt das sechsstufige SOA-Maturity Model [BE 2005]. Zusammen mit den vorangegangenen Kriterien zur Abschätzung der aktuellen Situation kann die Organisation in einen Level eingeordnet werden. Das Modell enthält auf jeder Ebene einige Aktivitäten, die umgesetzt werden müssen, um diese Stufe zu erreichen. Auf der rechten Seite der Abbildung ist eine Auswahl von Standards aufgelistet, die in dieser Stufe verwendet werden könnten. P ro z e s s O p tim ie ru n g B u s in e s s P e rfo rm a n c e M a n a g e m e n t / B A M R u n tim e -G o v e rn a n c e u n d R ic h tlin ie n O p tim ie r te S O A P ro ze sse au sfü h ren P e rfo rm a n c e M e trik e n m e s s e n S O A L ife -C y c le M a n a g e m e n t P ro zessa u sfü h ru n g P ro z e s s e m o d e llie re n S e rv ic e s id e n tifiz ie re n, d e fin ie re n u n d o rc h e strie re n R e c h te, R o lle n, R ic h tlin ie n, S L A s d e fin ie re n D e fin ie re n v o n T e c h n o lo g ie s ta n d a rd s fü r d ie S O A R e g is try /R e p o s ito ry e in fü h re n P ro z e s s e id e n tifiz ie re n D e fin ie re n v o n S e rv ic e s In itie re n v o n S O A P ro je k te n P la n u n g d e r M ig ra tio n v o n A lts y s te m e n K e in S O A P r o z e s s m o d e llie r u n g e b X M L, W S -T ru s t, B P E L, BPM N A r c h ite k tu r S e r v ic e s U D D I, W S -R e lia b le M e s s a g in g, W S -P o lic y, W S -A d d re s s in g, W S -S e c u rity, S A M L I n itia le S e r v ic e s X M L, W SD L, SO A P A n w e n d u n g ssilo s Abbildung 42: SOA Maturity Model SOA Migration aus Sicherheitssicht Bei vielen großen Organisationen, die unterschiedliche Anwendungen für die Ausübung ihrer Geschäftstätigkeit benötigen, ist die IT sehr stark in den Abteilungen verankert. Ein Grund dafür kann sein, dass die einzelnen Abteilungen selbst dafür Sorge zu tragen haben, ihre IT zu verwalten. Sie sind also selbst dafür verantwortlich, ihre IT entsprechend ihres Bedarfs auszubauen und weiterzuentwickeln. Ein solches dezentrales Modell führt im Laufe der Zeit zu einer Zunahme des Funktionsumfangs der Anwendungen. Gleichzeitig wächst aber auch die Anzahl redundant vorhandener Anwendungen und die Menge der oft proprietären Schnittstellen und Abhängigkeiten. Neben diesem Anwendungswildwuchs führt die dezentrale Verwaltung der IT auch zu unterschiedlichen Sicherheitsmechanismen, z.b. Nutzerverwaltung, Verschlüsselung oder Rollenkonzepte. Durch diese Entwicklung ist eine Wiederverwendbarkeit der Anwendungen in anderen Abteilungen oder deren Austausch nur schwer möglich. Abbildung 43 zeigt eine typische gewachsene Anwendungslandschaft mit ihren Abhängigkeiten und engen Kopplungen der Anwendungen. A b te ilu n g 1 A b te ilu n g 2 A b te ilu n g 3 A nw endung B A nw end ung A A n w en dun g A A nw endung E A nw end ung B A n w en dun g D A nw end ung C A nw endung D Abbildung 43: Typische gewachsene Anwendungslandschaft einer Organisation und deren Interaktion 165

166 Die Eigenschaften dieser Anwendungslandschaften stehen im Gegensatz zu denen einer SOA. Tabelle 7 verdeutlicht einige der Gegensätze. Trotzdem kann es sinnvoll sein diese Anwendungen mit ihren Sicherheitsmechanismen in die SOA zu integrieren, da sie unter Umständen ein Alleinstellungsmerkmal der Organisation sind. Monolithisches System Service-orientierte Architektur Oftmals eng gekoppelt Basiert auf dem Prinzip der losen Kopplung Eingeschränkte Wiederverwendbarkeit der Anwendungen Services können orchestriert werden und sind wiederverwendbar Anwendungen stehen einem bekannten Nutzerkreis zur Verfügung Auffindbarkeit der Services wird sichergestellt, Services können von unterschiedlich vielen Instanzen genutzt werden Nutzung der Anwendungen nur in einer Domäne Nutzung der Services in unterschiedlichen Domänen Nutzung von proprietären Komponenten und Schnittstellen SOA setzt auf offene Standards auf Tabelle 7: Gegenüberstellung einiger Eigenschaften von monolithischen Systemen und SOA Bei der SOA Migration kann unterschieden werden zwischen Services, die neu entwickelt werden und Services, die durch die Kapselung von Altanwendungen entstehen. Der übliche Fall ist, dass Services aus Altanwendungen extrahiert werden. Daher wird dies im nachfolgenden Kapitel beleuchtet Services aus Altanwendungen Die Migration der Altanwendungen in eine SOA ist ein Weg, die Anwendungen in die modernen Arbeitsabläufe der Organisation einzubinden. Typischerweise erfolgt die Integration mit so genannten Wrapper-Services, die vor die Altanwendung gesetzt werden, um diese Service-fähig zu machen. Es gibt unterschiedliche Wege, die Wrapper Services umzusetzen [Ka 2008]: Wenn es sich um eine alleinstehende Anwendung handelt, kann deren Bibliothek um eine Funktion erweitert werden, die es erlaubt, ein- und ausgehende Serviceaufrufe zu verstehen und zu verarbeiten. Besitzt eine Anwendung bereits eine Schnittstelle, um Dateien und Dokumente zu empfangen und zu senden, so wird diese Fähigkeit der Anwendung als Service veröffentlicht. Nimmt z.b. eine Anwendung Anfragen in Form von Nachrichten in eine Warteschlange an und produziert Antworten in Form von Nachrichten in eine Warteschlange, dann kann diese Fähigkeit als Web Service veröffentlicht werden. Verfügt eine Anwendung bereits über eine Schnittstelle, so kann diese genutzt werden, um daraus eine Service-Schnittstelle zu implementieren. Wenn z.b. eine Anwendung schon über eine CORBA-Schnittstelle verfügt, dann kann diese angepasst werden, um aus dieser Schnittelle einen Web Service zu machen. Wenn eine Anwendung nicht die richtigen Schnittstellen hat, um einen Service zu implementieren, dann wird versucht, die Interaktion des Nutzers zu imitieren. Zum 166

167 Beispiel haben manche Mainframes nur eine Cursor-basierte Schnittstelle. Um die Schnittstelle anzusprechen, werden die Tastatureingaben des Nutzers imitiert. Um Daten aus der Anwendung zu erhalten, werden diese über Screen Scraping Verfahren ausgelesen, d.h. die Daten werden direkt aus der Bildschirmausgabe der Anwendung übernommen. Diese Daten werden dann über einen Web Service nutzbar gemacht. Die Wrapper Services abstrahieren Details der Anwendung und setzen eine ServiceSchnittstelle auf die Altanwendung auf. Abbildung 44 verdeutlicht die Arbeitsweise. Der Wrapper Service kann in der Praxis z.b. ein Web Service sein. Aber auch der Enterprise Service Bus (ESB) verfügt typischerweise über Mechanismen, um Funktionalitäten zu kapseln und sie als Services bereit zu stellen. Unter anderem kann der ESB einen Adapter nutzen, um die proprietären Schnittstellen des Altsystems direkt anzusprechen. Abbildung 44: Arbeitsweise eines Wrapper Service Nachdem klar ist, wie die Altanwendungen gekapselt werden, damit sie als Services verfügbar sind, stellt sich die Frage, wie die Sicherheitsmechanismen der Services mit denen der Altanwendungen abgestimmt werden. Da die Altanwendung typischerweise nur für die Fachabteilung zugänglich war, wurden auch nur für diesen Sicherheitskontext die Sicherheitsmechanismen entwickelt. Diese stehen unter Umständen nicht mit den von der Organisation genehmigten Sicherheitsmechanismen im Einklang. Daher sind die Mechanismen aufeinander abzustimmen. Dafür gibt es drei Möglichkeiten [Ka 2008]: 1. Die Sicherheit wird komplett im Wrapper Service verwaltet, 2. Die Nutzer des Wrapper Services werden auf Nutzer der Anwendung abgebildet, 3. Die Sicherheit wird komplett von der Altanwendung übernommen. Sicherheit wird komplett im Wrapper Service verwaltet Dieses Vorgehen wird typischerweise gewählt, wenn die Altanwendungen nicht über adäquate Sicherheitsmechanismen verfügen. Die Sicherheit kann dann komplett vom Wrapper Service übernommen werden. Oft wurde bei solchen Altanwendungen die Sicherheit an die darunter liegende Infrastrukturebene delegiert. Ein Beispiel für die Delegation ist File Permission bei Unix-Anwendungen, zur Vergabe von Zugriffsrechten auf Dateien. Nutzer des Wrapper Services werden auf Nutzer der Anwendung abgebildet Bei diesem Vorgehen tritt der Wrapper Service als eine Art Vermittler auf. Er bildet die Nutzer in der Organisation auf die Nutzer der Altanwendung ab. Für dieses Vorgehen gibt es unterschiedliche Möglichkeiten. Unter anderem können die Sicherheitsmechanismen des Wrapper Services auf die Altanwendung abgebildet werden. Z.B. sind in einer Organisation zumeist die Rollen viel feingranularer definiert als bei einer zu integrierenden Altanwendung. Angenommen die Altanwendung kennt nur drei Rollen. Der Wrapper Service bildet in diesem Fall jeden authentifizierten und autorisierten Nutzer auf eine der drei Rollen ab. 167

168 Abbildung 45: Abbilden der Sicherheitsmechanismen des Wrapper Service auf die Altanwendung Auch ist es möglich, dass sowohl der Wrapper Service, als auch die Altanwendung den gleichen Sicherheitsservice nutzen. Somit wird ein Sicherheitskontext außerhalb der Altanwendung geschaffen, z.b. sind beide mit einem Sicherheitsservice für die Authentifizierung verbunden. Die Nutzer werden in diesem Szenario von der Altanwendung verwaltet und der Wrapper Service kann die Nutzer und Rollen für die Autorisierung nutzen. Abbildung 46: Nutzung eines gemeinsamen Security Service von Wrapper Service und Anwendung Sicherheit wird komplett von der Altanwendung übernommen Diese Maßnahme wird typischerweise angewandt, wenn es sich um sehr große Anwendungen, z.b. ERP Anwendungen, handelt. Diese verfügen in der Regel über umfassende Sicherheitsmechanismen, die jede Art von Anwendung (Web-, DesktopAnwendung,...) unterstützen. Da solche großen Systeme über eine Vielzahl von Sicherheitsmechanismen und Schnittstellen verfügen, ist es schwer und oftmals wenig sinnvoll diese zu ersetzen. Somit werden die bestehenden Sicherheitsmechanismen von der Altanwendung genutzt. Nachdem erklärt wurde, wie die Altanwendungen integriert werden können, stehen Organisationen vor der Herausforderung, die richtige Architektur für ihre SOA Sicherheitslösung zu wählen. 168

169 Architektur In den vorangegangen Abschnitten wurde ausgeblendet, wo Services im Netzwerk gehostet werden, um die Komplexität möglichst gering zu halten. Allerdings hat die Lage der Services eine große Bedeutung für das Design der SOA Sicherheitslösung der Organisation. Nachfolgend werden einige Auswirkungen, die sich durch die Lage der Services ergeben, anhand von drei Anwendungsfällen gezeigt [Ka 2008]: 1. Absichern von Services im Intranet, 2. Absichern von Services, die für die Öffentlichkeit zugänglich sind, 3. Absichern von Services von und zu Partnern. Absichern von Services im Intranet Das Absichern der Services im Intranet kann eine leichte Aufgabe sein, wenn sich alle Entitäten in einem großen Netzwerk befinden. In diesem Fall können z.b. die Identitäten zentral verwaltet werden und es gibt eine klare Organisationsgrenze. Dies wird aber in den wenigsten Organisationen der Fall sein. Typischerweise sind die Organisationen zersplittert mit einer teilweise hoch komplexen Netzwerktopologie. Administrative und rechtliche Einschränkungen, die Vielzahl von Rechenzentren und der Mangel an IT-Personal in kleinen Niederlassungen können einen erheblichen Einfluss auf die Architektur für eine SOA Sicherheitslösung haben. Beim Absichern von Services im Intranet findet die Sicherheit vor allem an den Organisationsgrenzen Anwendung. Innerhalb der Domäne gelten alle Entitäten als vertrauenswürdig oder Vertrauensbeziehungen können relativ leicht etabliert werden, da sie unter der gleichen administrativen Kontrolle stehen. Wenn z.b. unterschiedliche autonome Organisationseinheiten (z.b. Profit Center) verschiedene Services in der Organisation nutzen, dann ist zwischen den Einheiten eine Vertrauensbeziehung aufzubauen, um eine sichere Nutzung der Services zu gewährleisten. Es erfordert einen Management-Prozess, um eine Vertrauensbeziehung zu etablieren und zu verwalten. Zur Verwaltung gehören z.b. die Konfiguration von Komponenten oder die Verwaltung von Credentials und Securtiy Policies in der gesamten Organisation. Aus diesem Beispiel wird ersichtlich, dass die Absicherung von Services im Intranet hoch komplex werden kann und sehr individuell auf die Bedürfnisse der Organisation zugeschnitten werden muss. Absichern von Services, die für die Öffentlichkeit zugänglich sind Wenn Services für die Öffentlichkeit zugänglich gemacht werden, dann sollte beim Design der SOA Sicherheitslösung insbesondere berücksichtigt werden, dass unautorisierte Nutzer die Services angreifen oder sogar Kontrolle über sie erlangen können. Daher beeinflusst das Bereitstellen von Services für die Öffentlichkeit die Architektur. Es gibt unterschiedliche Möglichkeiten den Service zu sichern. Unter anderem kann die Architektur durch Firewalls und eine Demilitarized Zone (DMZ) erweitert werden. Dabei stehen sowohl Web Services als auch ein Security Service in der DMZ. Der Security Service befindet sich vor dem Web Service und schützt diesen durch die Überprüfung der Anfragen, z.b. durch XML-Filterung (siehe Kapitel 7.2). Außerdem kann er die Aufgabe der Authentifizierung und Autorisierung der Anfragen übernehmen. Dazu würde er z.b. auf einen Directory Server zugreifen, der sich im internen Netzwerk befindet, um Anfragen zu authentifizieren und zu autorisieren. Durch die Platzierung des Servers in das innere 169

170 Netzwerk ist er vor direkten Angriffen geschützt. Validierte Anfragen leitet der Security Service an den Web Service weiter. Dieser greift dann auf den Anwendungsserver zu, der sich auch im inneren Netzwerk befindet. Dabei erlaubt der Service nur vorab festgelegte Funktionsaufrufe auf dem Anwendungsserver. Somit ist auch dieser vor direkten Angriffen geschützt. Die Abbildung 47 zeigt den Aufbau der beschriebenen DMZ. Abbildung 47: Aufbau DMZ (vgl. [Ka 2008]) Absichern von Services von und zu Partnern Partnerorganisationen unterscheiden sich von internen oder öffentlichen Entitäten, weil die Partner und ihre Sicherheitsarchitektur teilweise der Organisation bekannt sind. Bei der Zusammenarbeit mit Partnern sollte vertraglich geregelt werden, dass die Partner die Sicherheitsrichtlinien der Organisation einhalten. Der Aufbau von Vertrauensbeziehungen geht einher mit komplexen Verträgen, um das Risiko für beide Seiten auszubalancieren bzw. gering zu halten. Die Herausforderung bei der Umsetzung der Sicherheitsrichtlinien liegt typischerweise in den unterschiedlichen Sicherheitstechnologien der Partnerorganisationen. Somit kann das Anbieten und das Nutzen von Services von Partnern Auswirkungen auf die Architektur haben. Um den sicheren Zugriff auf die jeweiligen Partnersysteme zu gewährleisten, kann z.b. eine Architektur für Identity Federation (siehe Kapitel ) aufgebaut werden. Diese ermöglicht den Austausch von digitalen Identitäten und weiteren Informationen zwischen den Organisationen. Außerdem können Security Agents bei Partnern platziert werden, die unter anderem das Verschlüsseln der Nachrichten und Durchsetzen der Policies durchführen. Da in der Regel den Security Agents vertraut wird, kann der Partner direkt auf die Web Services in der DMZ zugreifen Allgemeine Auswirkung der SOA-Migration auf die Sicherheitsanforderungen Standardisierte Service-Schnittstellen Nach der Migration besitzt das Altsystem eine standardisierte Schnittstelle nach außen über die die Anwendung erreichbar ist. Diese selbstbeschreibende Schnittstelle macht den Service nach außen verfügbar. Genauso wie der Service beschrieben wird, sollte auch die Sicherheit 170

171 dargestellt werden. Der Service muss kommunizieren, welche Anforderungen er an den Aufrufer des Service stellt. Sicherheitsimplikationen: Die Dienstbeschreibung sollte auch die Beschreibung der Sicherheitsanforderungen enthalten, z.b. mittels WS-SecurityPolicy in Kombination mit WS-Policy. Lose Kopplung Lose Kopplung bedeutet für die Komponenten u.a., dass sie nicht binär-kompatibel sein müssen, da sie lose über einen Nachrichtenaustausch gekoppelt sind. Diese Unabhängigkeit ist eine Eigenschaft, die den SOA-Ansatz von der bisherigen Entwicklung klassischer verteilter oder komponentenbasierter Applikationen unterscheidet. Während frühere Systeme in der Regel eng gekoppelt waren, d.h. viele Anwendungen direkt miteinander kommunizierten, werden diese Kommunikationsmuster bei einer SOA Migration aufgebrochen. Zwischen den Services besteht dann ein Minimum an Abhängigkeiten, um eine größtmögliche Wiederverwendbarkeit zu erreichen. Ein Prozess wird aus lose gekoppelten Services zusammengefügt. Dadurch kommunizieren beim Prozessablauf eine Vielzahl von Instanzen miteinander, die sich teilweise nicht kennen. Früher hingegen waren die Kommunikationspartner durch die enge Kopplung vorab bekannt. Typischerweise bestanden Altsysteme nur aus einem Front- und Back-end. Die Daten wurden nicht zwischen unterschiedlichen Systemen ausgetauscht, sondern wurden nur im System verarbeitet und gespeichert. Dieses geschlossene System wird bei der Migration von Anwendungen aufgebrochen und Services tauschen mit anderen Services und verteilten Systemen Daten aus. Nach der SOA Migration sind die für die Altsysteme typischen Punkt-zu-PunktVerbindungen aufgebrochen und die Nachrichten werden teilweise über Zwischenknoten ausgetauscht. Dabei kann es erforderlich sein, dass die Zwischenknoten den Inhalt der Nachricht nicht lesen dürfen oder dass sie Teile der Nachricht verarbeiten bzw. modifizieren müssen. Dies erfordert unterschiedliche Verschlüsselung von Nachrichtenteilen für verschiedene Empfänger oder die Signatur von Teilen einer Nachricht. Sicherheitsimplikationen: Absicherung des Nachrichtenverkehrs Nachrichtenauthentizität muss gewährleistet sein, Bindung der Identität des Senders an die Nachricht (Von wem kommt die Nachricht?) Vertrauensbeziehungen müssen vorab geklärt und im System abgebildet sein Wiederverwendbarkeit und Orchestrierung Altanwendungen, die nur für eine Aufgabe vorgesehen waren, sollten nach der Migration dem Anspruch der Wiederverwendbarkeit gerecht werden, d. h. die Altanwendungen, die nach der Migration service-fähig sind, können wie neu konzipierte Services in verschiedenen Prozessen eingesetzt werden. Dadurch ändert sich aber in Abhängigkeit vom Prozess auch der Sicherheitskontext, was beim Design der Altanwendung nicht vorgesehen war. Um dieses Problem zu lösen, müssen die Services verschiedene Sicherheitsmodelle unterstützen, damit sie in verschiedenen Sicherheitskontexten nutzbar sind, z.b. sollten sie unterschiedliche Tokenformate unterstützen. Deshalb ist es erforderlich, dass die Sicherheit nicht isoliert und Service-spezifisch umgesetzt ist, sondern die eingesetzten Protokolle zum Informationsabruf und zur Beschreibung der benötigten Informationen standardisiert und auf verschiedene 171

172 Formate abbildbar sind. Darüber hinaus sind die Services in einer SOA zustandslos, d.h. alle Informationen, die der Service benötigt, insbesondere Identitätsinformationen, müssen mit dem Dienstaufruf übergeben werden. Somit darf die Sicherheit nicht proprietär im Dienst verankert sein. Sicherheitsimplikationen: Identitätsmanagement muss von den Services entkoppelt sein (siehe nächstes Kapitel) Standardisierte Sicherheitsprotokolle (WS-* Standards) müssen verwendet werden, die verschiedene Sicherheitsmodelle unterstützen Auffindbarkeit der Services/Nutzung der Services in unterschiedlichen Domänen Services stehen z.b. über Repositories zur Verfügung und können von vielen unterschiedlichen Instanzen genutzt werden. Sicherheitsimplikationen: Es muss vorab geklärt werden, welchem Benutzerkreis der Service verfügbar gemacht wird. Wird der Service nur innerhalb einer Domäne oder auch domänenübergreifend genutzt? Wie wird die Vertrauensbeziehung zwischen Provider und Consumer etabliert? Die Sicherheitsanforderungen des Service müssen öffentlich gemacht werden, z.b. mit Hilfe von WS-PolicyAttachment und WS-MetadataExchange. 5.3 SOA Lifecycle Management Möchte eine Organisation eine Service-orientierte Architektur einführen oder einen neuen Service einrichten, ist der Aufbau über den Betrieb bis hin zur Ablösung dieser SOA bzw. des Service innerhalb eines Lebenszyklus zu betrachten. Dies liefert den Verantwortlichen eine Darstellungsform, die beschreibt, was in welcher Reihenfolge geschieht bzw. geschehen sollte bzw. in welchem Reifegrad sich die SOA befindet Hintergrund Der Begriff Lebenszyklus wird in der Wirtschaft meist mit dem eines Produktes in Verbindung gebracht. Dieses Konzept beschreibt die Lebensdauer eines Produktes oder einer Dienstleistung, von der Entwicklung und Markteinführung bis hin zur Sättigung bzw. der Einstellung des Vertriebes aus z.b. strategischen Gründen. Es stellt also mehr ein vom Markt getriebenes Vorgehen dar. Der SOA Lebenszyklus ist ein Modell, welches die Service-orientierte Architektur in ihrer Entwicklung von der Konzeption bis zum Betrieb bzw. dem produktiven Einsatz aufbaut und die stetige Weiterentwicklung beschreibt. Themen, die im SOA Lebenszyklus betrachtet werden können, sind dabei z.b. eine Abfolge von Aktivitäten wie die Planung des Entwicklungsprojektes, die nötig sind um eine Service-orientierte Architektur zu etablieren. Dabei können diese Aktivitäten an die jeweils spezifische SOA angepasst werden. Der SOA 172

173 Lebenszyklus kann stark mit dem einer Anwendung verglichen werden. Die Phase des Lebenszyklus einer Anwendung beschreibt die Planung, Realisierung, Inbetriebnahme, Weiterentwicklung, Migration und Abschaltung. Diese Phasen finden sich auch im SOA Lebenszyklus wieder. Die notwendigen Schritte zur Bestimmung der Sicherheitsanforderungen und -Maßnahmen werden in der Planungs- und Designphase (siehe Kapitel ) beschrieben. Services sind Bestandteile einer SOA, durchlaufen jedoch in ihrem Leben einen eigenen Zyklus, losgelöst von dem der SOA. Ein SOA Lebenszyklus startet mit einem bestimmten Set an Services, die parallel mit der SOA Infrastruktur aufgebaut und entwickelt werden. Befindet sich der SOA Lebenszyklus in der Phase des Betriebs, kommt es im Allgemeinen vor, dass weitere Services oder auch neue Versionen der Services entwickelt und eingespielt werden. Da eine SOA häufig in mehreren Iterationen umgesetzt wird, folgt daher auf eine Betriebsphase eine weitere Planungs- und Designphase, d.h. der SOA Lebenszyklus beginnt wieder von vorn für diese Services. Auf diese Weise können in jeder Iteration neue Services entwickelt, bestehende weiterentwickelt und nicht mehr benötigte Services abgelöst werden. Jeder dieser Services durchläuft dabei einen eigenen Lebenszyklus von seiner Planung bis zu seiner Ablösung. Während der Entwicklung eines Services müssen Sicherheitsanforderungen, die im Rahmen der Planung des Service definiert wurden, berücksichtigt werden. Der vollständige Service Lebenszyklus sowie die notwendigen Schritte zur Bestimmung der Sicherheitsanforderungen und -maßnahmen werden in Kapitel beschrieben Der SOA Lebenszyklus Um einen erfolgreichen SOA-Ansatz zu realisieren, wird von der Planung bis hin zur Ablösung immer öfter die Betrachtungsweise eines Lebenszyklus gewählt. Durch diese Herangehensweise ist es möglich, eine SOA von Anfang bis Ende bzw. zum Einstellen des Betriebs darzustellen und so eine ganzheitliche Sicht auf die einzelnen Phasen zu bekommen. Viele Organisationen haben bereits eigene Lebenszyklen definiert und veröffentlicht. Bei näherer Betrachtung der verschiedenen Ansätze ist jedoch ein ähnliches Muster zu erkennen. Dieses Muster spiegelt sich in den einzelnen Schritten des Lebenszyklus wider und kann wie folgt skizziert werden: SO A L e b e n sz y k lu s P la n u n g u n d D e s ig n A u fb a u u n d E n tw ic k lu n g D e p lo y m e n t B e tr ie b u n d M a n a g em ent A b lö s u n g Z e it Abbildung 48: SOA Lebenszyklus Die Abbildung zeigt einen möglichen SOA Lebenszyklus mit fünf Schritten, die im Laufe der Zeit durchlaufen werden. Anders als bei einem Produktlebenszyklus, in dem die einzelnen Phasen konkret mit z.b. Umsatzzahlen beziffert werden können, stellt sich der SOALebenszyklus eher als Vorgehensmodell dar. Die Phase der Ablösung der SOA wird an dieser Stelle nur grob erläutert. Diese Phase gilt für eine SOA auch nur dann, wenn die komplette 173

174 Architektur geändert werden soll. Dies kann z.b. der Fall sein, wenn eine Organisation in Zukunft auf ein neues, heute noch nicht bekanntes Architekturmodell migriert Planung und Design In der Planungs- und Design-Phase werden zunächst relevante Konzepte, wie das Architekturkonzept oder SOA-relevante Sicherheitskonzepte erstellt bzw. definiert. Unabhängig davon, ob eine Service-orientierte Architektur neu aufgesetzt oder ein neuer Service (siehe Kapitel ) entwickelt werden soll, sind Maßnahmen für die Einführung zu planen. Im Bereich der Sicherheit werden neue Maßnahmen geplant und konzipiert bzw. bestehende Maßnahmen angepasst, um die in Kapitel 3.1 beschriebenen Sicherheitsziele zu erreichen. Des Weiteren sind zur Definition von Sicherheitsanforderungen und der entsprechenden Sicherheitsmaßnahmen vorab die folgenden Schritte des im Kapitel beschriebenen Risikomanagements zu durchlaufen: Bestimmung der Assets und deren Klassifizierung, Schutzbedarfsfeststellung, Risikoanalyse, Risikobewertung, Risikobehandlung. Nachdem das Risikomanagement Vorgaben für den Umgang mit den Risiken definiert hat, müssen notwendige Maßnahmen zur Umsetzung der Vorgaben geplant werden. In der Planungs- und Design-Phase einer neuen Service-orientierten Architektur werden die Geschäfts- und Sicherheitsanforderungen sowie Ziele der Organisation aufgenommen und festgehalten. Damit diese Anforderungen und Ziele auf die zukünftige SOA angewendet werden können, werden diese in technische Spezifikationen übersetzt. Die gesamten Informationen, die in dieser Phase zusammengetragen werden, sind vollständig zu dokumentieren und so zu verwalten, dass eine Aktualität über den gesamten Lebenszyklus gewährleistet ist. Gerade im Bereich der Sicherheit sind z.b. die folgenden Aspekte bei der Planung einer neuen Service-orientierten Architektur zu beachten: Absicherung der Kommunikations- und Transportwege, Zugriffskontrolle und Rollenmanagement, Aufbau eines einheitlichen Benutzermanagements, Ausarbeitung von Sicherheitsprozessen, Bereitstellung von zusätzlichen Systemen, die im Notfall eingesetzt werden können, Berücksichtigung von internen und externen Compliance-Anforderungen (siehe Kapitel 5.1.6). Wird hingegen nur ein zusätzlicher Service aufgenommen, sind verstärkt andere, konkretere Faktoren zu beachten (siehe auch Kapitel ). Die Modellierung des Service erfordert die Berücksichtigung von Endpunkten und Verbindungen zu anderen Services sowie Aspekte wie die Granularität des Service, die zukünftige Nutzung oder andere funktionale und nichtfunktional Aspekte wie z.b. die Sicherheit oder die Handhabung von Änderungen und Ausnahmen. 174

175 In beiden Fällen sind die folgenden Aufgaben zu erfüllen: Definition und Anwendung von spezifischen Sicherheitsanforderungen, Identifizierung und Priorisierung von Risiken (siehe Kapitel 5.1.5), Die Identifizierung von relevanten externen Regularien und Gesetzen sowie interner Vorgaben, besonders aus dem Bereich der Sicherheit (siehe Kapitel 5.1.6), Berücksichtigung von Performance-Aspekten und somit der Beantwortung der Frage, wie diese Sicherheitsmaßnahmen die Performance der Systeme beeinflussen können (siehe auch Kapitel 5.2), Prüfung und Dokumentation von Abhängigkeiten der Ressourcen und der Applikationen, der Kapazitätsanforderungen sowie der Zugangsbarrieren (Sicherheit), Einrichtung von Workflows (z.b. wer hat welche Rechte bzw. muss sein Einverständnis oder eine Freigabe geben?), die als Leitfaden für die Umsetzung dienen, Definition von Key Performace Indikatoren (KPI) zum Controlling und Reporting der SOA, Definition von Service Level Agreements (SLAs) im Falle von Beteiligungen externer oder interner Dienstleister (siehe Kapitel ), Erstellung einer Versionshistorie für ein effektives Applikationsmanagement. Zur Absicherung der Architektur und der Services ist es wichtig, dass die jeweils folgenden Personen eigenverantwortlich dazu beitragen, das Sicherheitsniveau zu erhöhen: Der IT-Sicherheitsbeauftragter bzw. der Corporate Information Security Officer (CISO) entwickelt und verteilt Sicherheits-Policies und ggf. weitere Standards und Methoden. Risikomanager führen eine Risikoanalyse und -bewertung (siehe Kapitel 5.1.5) durch, um so zur Definition von adäquaten Sicherheitsmaßnahmen beizutragen. Die Verantwortlichen der Fachseiten führen eine Schutzbedarfsfeststellung durch und klassifizieren dementsprechend ihre Daten. Andere Architekturen berücksichtigen Bei der Konzeption und Entwicklung einer SOA ist die Berücksichtigung anderer Architekturen innerhalb der Organisation von großer Bedeutung. Diese Architekturen können das Vorhaben maßgeblich beeinflussen. Es kann z.b. vorkommen, dass die von den Fachseiten spezifizierten Vorgaben wie z.b. Design-Patterns, Architektur-Patterns oder die Nutzung von Standards nicht mit der Planung bzw. Konzeption der SOA vereinbar sind. Die folgenden Architekturen müssen in der jeweiligen Organisation berücksichtigt werden: Business Architektur Beinhaltet z.b. die Business Strategie, Governance Aspekte, Organisationsstrukturen und die Kern-Geschäftsprozesse der Organisation bzw. des Unternehmens Datenarchitektur Beinhaltet z.b. logische und physikalische Datenstrukturen, Datenschutz- und Sicherheitsaspekte sowie das Management der Datenressourcen. 175

176 Sicherheitsarchitektur Beinhaltet den Aufbau der Architektur aus Sicherheitssicht, z.b. die Berücksichtigung von verschiedenen Sicherheitszonen (z.b. DMZ) Applikationsarchitektur Beinhaltet z.b. Pläne für Anwendungssysteme sowie Schnittstellen zu den KernGeschäftsprozessen der Organisation bzw. des Unternehmens. Technologie-Architektur Beinhaltet z.b. die logischen Soft- und Hardware-Ressourcen, die IT-Infrastruktur, Middleware, technische Standards und IT-Prozesse. Nach der Bewertung und Berücksichtigung der verschiedenen Architekturen kann die Entwicklung und anschließende Transformation beginnen. Erst durch die Berücksichtigung der verschiedenen Vorgaben ist die Herleitung einer organisations-spezifischen Serviceorientierten Architektur auf Basis der individuellen Geschäftsanforderungen möglich Aufbau und Entwicklung Mit Hilfe der in der Planungs- und Design-Phase durchgeführten Aktivitäten konnten Konzepte und technische Spezifikationen bzw. Übersetzungen in technische Konzepte erstellt werden, die nun eine Kommunikation der Geschäftsziele in Richtung der IT-Organisation ermöglichen. Die IT-Organisation hat in der zweiten Phase die Aufgabe, die Konzepte mit samt der Anforderungen der Fachseite in Bezug auf Funktionalität und Nutzerfreundlichkeit und weitere Anforderungen wie z.b. der des Sicherheitsmanagements im Rahmen der Sicherheitskonzeption bei der Entwicklung zu berücksichtigen. Bei der Umsetzung der Konzepte und Anforderungen ist besonders zu berücksichtigen, dass eine enge Zusammenarbeit des organisatorischen und technischen Personals zur Abstimmung der Fach- mit der technischen Seite erfolgt. Ziel der Zusammenarbeit ist es, das Design des Business in einzelnen Prozessdefinitionen so zu übersetzen, dass die Vorgaben und die Ergebnisse bestmöglich mit der IT vereinbar sind. Um ein adäquates Sicherheitsniveau zu schaffen, tragen z.b. die folgenden Personen wie folgt zum Aufbau bzw. der Entwicklung bei: Der IT-Sicherheitsbeauftragter ist vor allem dafür verantwortlich, dass die Sicherheitsanforderungen richtig umgesetzt werden, Entwickler und Administratoren müssen die Sicherheitsanforderungen gemäß der Vorgaben umsetzen, Spezielle Prüfer sollten unter anderem zur Qualitätssicherung eine Quellcodeanalyse und funktionale Tests durchführen, um ein lückenloses Ergebnis bereitzustellen. Ist die Entwicklung abgeschlossen, werden die Anwendungen implementiert und getestet. Der Test muss in einer gesicherten Testumgebung ablaufen. Die Sicherheit besonders kritischer Anwendungen sollte ggf. durch eine Schwachstellenanalyse (z.b. Penetration Tests) nochmal geprüft und somit sichergestellt werden. Kapitel beschreibt Testmethoden und Tools, die in dieser Phase zum Einsatz kommen sollten. 176

177 Deployment Wurden die Konzepte und Anforderungen des Business bzw. der Fachseiten richtig von der IT umgesetzt, kann die Architektur zum produktiven Einsatz übergehen. Die jeweiligen Anwendungen bzw. Services wurden also erfolgreich implementiert und getestet, so dass das Ergebnis auf das Zielsystem verteilt und dort konfiguriert werden kann. Dies beinhaltet die Etablierung einer Hosting-Umgebung für die Applikationen und Services. Bei der Einrichtung der Hosting-Umgebung und der Entwicklung der jeweiligen Aufgaben ist zu berücksichtigen, inwieweit die bestehende Infrastruktur ergänzt werden muss. Aus Sicherheitssicht ist das Ziel dieser Phase, das Ergebnis der Planung und Entwicklung in eine sichere Umgebung zu verteilen (Deployment). Um die Sicherheit der Umgebung zu gewährleisten, sind die durch die Verantwortlichen vorgegebenen Kontrollen technisch umzusetzen. In dieser Phase ist besonders darauf zu achten, dass die relevanten Infrastrukturund Architekturkomponenten (z.b. Server, Netzwerk, Betriebssysteme) den in der Planungsphase definierten und in der Aufbauphase entwickelten Sicherheitsanforderungen entsprechen. Die Einbeziehung von Richtlinien für die sichere Administration und Konfiguration der Applikationen und der spezifischen Sicherheitspolitiken ist hier zu berücksichtigen. Die folgenden Personen tragen während des Betriebs zur Sicherheit innerhalb der SOA bei: IT-Administratoren verantworten die Verteilung der Services und die Einhaltung der Sicherheitsrichtlinien in den relevanten Anwendungen und Infrastrukturen, Test Manager prüfen, ob die Services richtig verteilt und sicher konfiguriert wurden. Wurde die Verteilung und Konfiguration erfolgreich abgeschlossen, kann die SOA bzw. können die Services der SOA in den Betrieb übergehen Betrieb, Monitoring und Management inkl. Governance In dieser Phase beginnt der allgemeine Betrieb der Services einer SOA bzw. die Nutzung der zur Verfügung stehenden Services durch interne oder externe Service-Nutzer. Dies ist die längste Phase des SOA Lebenszyklus und gleichsam die wichtigste. Nach der erfolgreichen Verteilung und Konfiguration beginnt der Betrieb und das Management der Architektur und der Services. Die Phase umfasst für die Verantwortlichen die Kontrolle und Verwaltung der einzelnen Bestandteile einer SOA. Dies beinhaltet z.b. die Verwaltung von organisatorischen Aufgaben, Sicherheitsmechanismen, Technologien und Software sowie die Überwachung der Performance und der Mechanismen, die eingesetzt werden, um den sicheren Betrieb zu gewährleisten. Monitoring ist dabei ein wichtiger Bestandteil, um zu prüfen, ob die zugrunde liegenden IT-Systeme und Services die Anforderungen erfüllen bzw. SLAs (falls vereinbart) eingehalten werden können. Es liefert für die Kontrolle der Anforderungen bzw. der SLAs (siehe Kapitel ) die nötigen Informationen, die durch das Controlling so aufbereitet werden können, dass sie in Verbindung mit einem Sicherheits-Reporting Entscheidungsgrundlagen liefern. Dazu zählt z.b. die Bewertung von Service-Anfragen (Request) sowie die Schnelligkeit der RequestAntworten. 177

178 Der Betrieb einer SOA stellt sicherlich die längste Phase des Lebenszyklus dar. Während des Betriebs der SOA sind sowohl technische als auch organisatorische Aspekte zu berücksichtigen. Technische Aspekte sind z.b.: Durchführung von Routine-Wartungen, Sicherung von Anwendungsdaten (Backup), Pflege von Ressourcen und Benutzern, Vorhersage über zukünftige Kapazitätsanforderungen, Prüfung, ob sämtliche internen und rechtlichen Anforderungen stets erfüllt sind. Zu den organisatorischen Aspekten zählen unter anderem: Verwaltung des Geschäftsmodells, Erfüllungsgrad der gesteckten Ziele, Bewertung des betrieblichen Umfelds, Messung des Erfolgs oder Misserfolgs des Vorhabens und Definition von Rollen und Verantwortlichkeiten. Die folgenden Personen tragen während des Betriebs zur Sicherheit innerhalb der SOA bei: IT-Administratoren verantworten die Verwaltung von Sicherheitsrichtlinien in den relevanten Anwendungen und Infrastrukturen und überwachen den reibungslosen und sicheren Betrieb. Während des Betriebs überwacht der Incident Manager in Zusammenarbeit mit dem IT-Administrator das Systemverhalten, um Störfälle oder sonstige negative Vorkommnisse rechtzeitig zu erkennen. Dies verhindert das Eintreten von potenziellen Bedrohungen und führt somit zu einer Minimierung der Risiken. Während des Betriebs ist die Sicherheit durch einen geeigneten Prüfer zu bewerten. Die Prüfung des Systems beinhaltet die Einhaltung der rechtlichen Vorgaben sowie der Sicherheits- und Unternehmenspolitiken Ablösung Die Phase der Ablösung gilt für eine SOA nur dann, wenn die vollständige Architektur geändert werden soll. Hierfür gibt es unterschiedliche Gründe, z.b.: Neue Architekturparadigmen, die für die Organisation interessant sind, Strategiewechsel der Organisation oder Änderung der Architektur zur Steigerung der Effizienz. Die Ablösung von Services kann hingegen jederzeit erforderlich werden. Es kann z.b. bereits heute vorkommen, dass eine grundlegende Technologiemigration das Aussterben einiger Services bedingt. Ein Beispiel ist die Einführung eines Enterprise Service Bus (ESB), der über grundlegende Funktionen und Services verfügt. Dies kann z.b. dazu führen, dass 178

179 bestehende Sicherheitsservices aufgrund der geänderten Architektur nicht mehr benötigt werden oder durch neue zu ersetzen sind. Auch die letzte Phase des Lebenszyklus einer SOA oder eines Service ist nicht zu unterschätzen. Wichtig ist, dass z.b. der Übergang von einem alten zu einem neuen Service richtig geplant und Schritt für Schritt durchgeführt wird (siehe auch Kapitel ) Rahmenbedingungen für den SOA Lebenszyklus Dieser Abschnitt beschreibt organisatorische und technische Rahmenbedingungen, die Einfluss auf eine SOA nehmen können Artefakte einführen und verwalten Im SOA Lebenszyklus werden viele Ergebnisse benötigt, die nicht direkt mit dem Aufbau der SOA zusammenhängen. Diese Ergebnisse werden innerhalb des Lebenszyklus in Form zusätzlicher Konzepte, Prozesse, Policies, Dokumentationen, Berichte, Protokolle oder Umfragen erarbeitet und genutzt. Im Bereich der Sicherheit handelt es sich um Sicherheitskonzepte, relevante Sicherheitsprozesse, Sicherheitspolitiken, Dokumentation zur sicheren Implementierung, Migration und Absicherung (Hardening), Sicherheitsberichte oder Umfragen zu sicherheitsrelevanten Themengebieten. Diese Themen werden als zusätzliche Artefakte bezeichnet. Innerhalb des Lebenszyklus werden Änderungen dieser Artefakte über die einzelnen Phasen hinweg durchgeführt, kontrolliert und verwaltet. Die Anforderungen, gerade auch im Bereich Sicherheit, die sich teilweise aus der Einbeziehung dieser Artefakte ergeben, werden von dem SOA-Lebenszyklus berücksichtigt und bei Bedarf eingeführt Andere Lebenszyklen und Vorgehensmodelle berücksichtigen Zur effektiven und ganzheitlichen Verwaltung des SOA Lebenszyklus und somit der gesamten SOA innerhalb der Organisation ist es unerlässlich, dass andere Lebenszyklen dokumentiert und kontrolliert werden, von der Konzeption bis hin zur Ablösung. Wie beschrieben stellt der übergreifende SOA Lebenszyklus Verbindungen und Beziehungen zu anderen Lebenszyklen dar. Dazu gehören beispielsweise die im Folgenden dargestellten Lebenszyklen. Lebenszyklen der betroffenen IT-Systeme Die IT-Systeme, die zur Realisierung bzw. für den Betrieb der SOA verwendet werden, haben eine gewisse Lebenserwartung. Aus diesem Grund müssen die Lebenszyklen der ITSysteme, sei es Software oder Hardware, mit in die Kontrolle des SOA Lebenszyklus aufgenommen werden. Somit entsteht eine Schnittstelle zu diesen Lebenszyklen. Der IT-Lebenszyklus kann z.b. wie folgt abgebildet werden: IT -S y stem L e b e n sz y k lu s D e f in itio n E n tw ic k lu n g D e p lo y m e n t B e tr ie b u n d W a rtu n g E n tso r g u n g Z e it Abbildung 49: IT-System Lebenszyklus 179

180 Lebenszyklen und Vorgehensmodelle der Software-Entwicklung Sobald es um die Entwicklung eines Web Service geht, entsteht eine Schnittstelle zu Vorgehensmodellen aus Sicht der Softwareentwicklung. Aus dem Bereich der Softwareentwicklung sind schon viele verschiedene Modelle hervorgegangen, z.b. das V-Model XT [VM 2008], Rational Unified Process (RUP) (ein von IBM entwickeltes Vorgehensmodell, welches sich als Standard etabliert hat und meist nur in leicht abgewandelter Form genutzt wird.) oder Extreme Programming (eine Methode aus dem Bereich agile Softwareentwicklung). Damit der SOA Lebenszyklus reibungslos abläuft und es nicht zu Zeitverzögerungen bei der Entwicklung und späteren Verteilung kommt, ist es essentiell, dass derartige Modelle genutzt werden. Die Berücksichtigung dieser Vorgehensmodelle spielt vor allem in der Phase 2 Aufbau und Entwicklung (siehe Kapitel ) eine wichtige Rolle. Diese Phase berücksichtigt zudem die relevanten Sicherheitsaspekte. Abbildung 50: Darstellung des V-Modells XT[VModellXT] Lebenszyklus der Nutzung eines Web Service Im Leben einer SOA werden eine Vielzahl von Web Services entwickelt, veröffentlicht und von Nutzern verwendet. Bei der Betrachtung des Service Lebenszyklus steht in diesem Kontext der Web Service im Fokus. Wird z.b. ein neuer Web Service entwickelt, startet auch für diesen Service ein eigener Lebenszyklus, von der Planung bis hin zur Ablösung. Während die Planung, Entwicklung und Inbetriebnahme eines Service durch Lebenszyklen und Vorgehensmodelle der Softwareentwicklung abgedeckt werden, kann die Beschreibung der Phase des Betriebs bzw. der Nutzung des Service durch einen eigenen, generischen Lebenszyklus beschrieben werden, der sich wie folgt darstellt: 1. Veröffentlichen/Registrieren: Ein Service Provider publiziert einen Dienst und registriert ihn in einem öffentlich zugänglichen Verzeichnis (Service-Repository). 2. Finden: Ein Nutzer greift mit einer Suchanfrage auf das Service-Repository zu, um einen geeigneten Dienst aufzufinden. 3. Binden: Der Nutzer erhält vom Verzeichnisdienst die Adresse, unter welcher der Dienst aufgerufen werden kann, sowie die dazu erforderlichen Parameter, um den Dienst korrekt anzusprechen. 4. Ausführen: Der Nutzer führt den Serviceaufruf unter der zuvor erhaltenen Adresse und unter entsprechender Wahl der Eingangsparameter aus. Als Ergebnis liefert der Dienst die Ergebnisparameter. 180

181 Der Lebenszyklus der Nutzung eines Web Service kann wie folgt abgebildet werden: Da die Services einer gewissen Dynamik unterliegen, sie also an mehreren Stellen registriert, S e r v ic e N u tz u n g sz y k lu s V e r ö f f e n tlic h e n R e g is tr ie r e n F in d e n B in d e n A u sfü h ren Z e it Abbildung 51: Nutzungszyklus eines Web Service veröffentlicht oder mehrmals gefunden und gebunden werden können, beinhaltet dieser die folgenden drei Unterlebenszyklen : Mehrfache Veröffentlichung und Registrierung: Ein Web Service kann an mehreren Stellen registriert und veröffentlicht werden. Ist dies der Fall, wird der komplette Nutzungszyklus mehrfach durchlaufen. Viele Nutzer Finden und Binden: Ist ein Service registriert und veröffentlicht, kann dieser von vielen Service-Nutzern gefunden, gebunden und ausgeführt werden. Services werden neu gebunden und ausgeführt: Ein gefundener Service kann immer wieder neu gebunden und ausgeführt werden. Für den Nutzungszyklus eines Service müssen die notwendigen Sicherheitsanforderungen bekannt sein. Diese müssen bereits in der Planungsphase des SOA Lebenszyklus definiert werden. Bei der Entwicklung und Implementierung neuer Web Services sind die bereits in der Planungsphase genannten Sicherheitsanforderungen zu berücksichtigen bzw. zu hinterfragen. Zudem ist der Schutzbedarf bzw. die Klassifizierung der Daten, die von dem Service verschickt oder verarbeitet werden zu ermitteln, um somit geeignete Standards und Spezifikationen anzuwenden. Der Nutzungszyklus eines Services ist aus Sicherheitssicht vor allem für die folgenden Personen von großer Bedeutung: Sicherheitsverantwortliche (Thema störungsfreier Betrieb, Notfallmanagement, Restore bei Datenverlust, usw.) IT-Administratoren verantworten die Verwaltung von Sicherheitsrichtlinien und kontrollieren das Monitoring der Services Service Level Manager prüfen, ob die vereinbarten Service Level eingehalten wurden Sicherheits-Auditoren prüfen in regelmäßigen Abständen den Status der Sicherheit eines speziellen bzw. kritischen Web Service Besonders große Bedeutung nimmt das Thema Versionierung bei der Betrachtung des Service Lebenszyklus ein. Werden neue Services geplant, entwickelt und eingeführt ist es besonders wichtig, dass organisatorische Aspekte wie z.b. Einhaltung von Sicherheitsanforderungen sowie technische Aspekte wie z.b. Zieladressierung oder Schnittstellen berücksichtigt werden. Wird z.b. ein alter Service abgeschaltet und der neue Service ist noch nicht einsatzbereit, kann dies dazu führen, dass unternehmenskritische Prozesse nicht mehr 181

182 durchgeführt werden können. Daher ist die strategische Planung der Einführung, aber auch der Abschaltung von Services von großer Bedeutung. Zusammenhang der Lebenszyklen Durch die Zusammenführung der verschiedenen Lebenszyklen und Vorgehensmodelle lässt sich eine Übersicht der verschiedenen Schnittstellen darstellen. Dadurch erhalten die Verantwortlichen Anhaltspunkte von möglichen Einflussfaktoren der entstehenden SOA. Die Übersicht bzw. Zusammenführung lässt sich wie folgt beispielhaft skizzieren: IT -S y stem L e b e n s z y k lu s D e f in itio n E n tw ic k lu n g D e p lo y m e n t B e tr ie b u n d W a rtu n g E n tso r g u n g SO A L e b e n s z y k lu s P la n u n g u n d D e s ig n A u fb a u u n d E n tw ic k lu n g D e p lo y m e n t B e tr ie b u n d M a n a g em ent A b lö s u n g V o r g e h e n s m o d e ll S o ftw a ree n tw ic k lu n g Service Service NutzungsS e r v ic e Nutzungszyklus N u zyklus tzu n g sz y k lu s V e r ö f f e n tlic h e n RV ee grviösetf rrf öie enf rf teel ninc thl iec nh e n R e g is tr ie r e n R e g is tr ie r e n F in d e n F in d e n F in d e n B in d e n B in d e n B in d e n A u sfü h ren A u sfü h ren A u sfü h ren Z e it Abbildung 52: Übersicht der Lebenszyklen Die Übersicht der Lebenszyklen gibt einen guten Überblick über die Zusammenhänge der einzelnen Lebenszyklen. Im Mittelpunkt steht dabei der Lebenszyklus der SOA, er überdauert alle anderen Lebenszyklen. SOA- und IT-System Lebenszyklus Im Laufe des Lebens der SOA ist es besonders wichtig, dass die genutzten ITSysteme kontinuierlich die Anforderungen an Performance und Verfügbarkeit erfüllen können. Ist die letzte Phase des IT-System Lebenszyklus, die Entsorgung, erreicht, ist ein adäquates Ersatzsystem zu beschaffen, um die SOA reibungslos weiterlaufen zu lassen. Es besteht also eine gewisse Abhängigkeit von dem ganzheitlichen Management des Lebenszyklus von IT-Systemen. Wird ein ITSystem durch mangelndes Management des Lebenszyklus nicht rechtzeitig ausgetauscht, kann das den Produktivbetrieb der gesamten SOA beeinträchtigen. SOA- und Software Entwicklungs-Lebenszyklus In der Entwicklungsphase des ersten Set an Services, mit dem die SOA startet, ist besonders der Software Entwicklungs-Lebenszyklus bzw. das jeweils genutzte Vorgehen zu beachten. Sowohl die Softwarekomponenten der SOA Infrastruktur als auch die Services einer SOA werden gemäß der Vorgehensmodelle der Softwareentwicklung umgesetzt. Die Entwicklung einer SOA kann daher auch als komplexes Softwareentwicklungsprojekt verstanden werden, welches sich aus einer Vielzahl einzelner Entwicklungsteilprojekte zusammensetzt. 182

183 SOA Lebens- und Service Nutzungszyklus Ein wesentliches Merkmal einer SOA ist es, dass immer wieder neue Services hinzukommen und alte Services abgelöst werden. Ein neuer Service muss in eine sichere Umgebung verteilt (deployed) werden und im Anschluss unter Berücksichtigung der spezifischen Sicherheitsanforderungen betrieben und kontrolliert werden. Die Bindung des neuen Service wird dabei innerhalb der Phase des Betriebs und des Managements durchgeführt. Soll ein Service weiterentwickelt oder abgeschaltet werden, ist es wichtig, genaue Informationen über die Nutzung des Service zu besitzen. Daher ist die Beachtung des Nutzungszyklus jedes einzelnen Services ein wichtiger Bestandteil der Weiterentwicklung einer SOA Service Level Agreements definieren Ein Service-Level-Agreement (SLA) beschreibt Rahmenbedingungen, die in Verbindung mit der Erbringung verschiedener Services (in diesem Fall Dienstleistungen, die von externen oder internen Lieferanten geliefert werden), meist innerhalb eines Sourcing-Verhältnisses, eingehalten werden müssen. Diese Leistungen werden vertraglich festgehalten und im Nachhinein unter anderem vom Compliance-Management geprüft (siehe auch Kapitel 5.1.2) Ziel eines SLA-Vertrages ist es, aktuelle und marktgerechte Services, welche die Anforderungen der Servicenehmer widerspiegeln, zu definieren und festzuhalten, transparente Services zwischen Servicegeber und -nehmer aufzubauen, die sich durch Verständlichkeit und Interpretationsfreiheit auszeichnen, klar voneinander abgegrenzte und wohldefinierte Services zu definieren, realistische Servicelevels mit spezifischen, messbaren, erreichbaren und realistischen Key Performance Indikatoren zu vereinbaren, definierte Messmethoden abzustimmen und anforderungsgerechte Reporting- Konzepte zu erstellen. SLAs werden vereinbart, um zu erbringende Dienstleistungen vertraglich festzuhalten und zusätzliche Vorgaben zu definieren, die während der Service-Erbringung kontrolliert werden können. Die Einhaltung der Vorgaben kann somit bestimmt und eine Vertragsverletzung ermittelt werden. SLAs werden vor allem für nicht-funktionale Eigenschaften, die der Beschreibung weiterer teilweise ebenfalls geschäftsrelevanter Aspekte dienen, vereinbart. Diese nicht-funktionalen Eigenschaften sind z.b. Sicherheit, Verfügbarkeit und Performance. Ein Beispiel für ein SLA aus dem Bereich Sicherheit könnte die Bereitstellung von einer gewissen Anzahl von Schlüsselpaaren als Servicegegenstand sein. Dazu würden z.b. die Verfügbarkeits- und Abrufzeiten definiert, die den Service anschließend messbar machen Ergebnis Das Ergebnis ist ein SOA-Lebenszyklus, der die einzelnen Schritte der Service-orientierten Architektur abbildet. Die Dokumentation eines Lebenszyklus ist empfehlenswert, um ein effektives Management zu gewährleisten. Innerhalb der Phasen des SOA Lebenszyklus können besonders die Sicherheitsanforderungen definiert, Risiken analysiert und Sicherheitsmaßnahmen vorgegeben, implementiert und kontrolliert werden. Dies eröffnet 183

184 allen Beteiligten die Möglichkeit, die SOA an sich bzw. die Anwendungen und Services so abzusichern, dass Risiken bestmöglich minimiert und Angriffe effektiv abgewehrt werden und darüber hinaus ein adäquates Sicherheitsniveau geschaffen wird. 184

185 5.4 Darstellung des Zusammenhangs Sicherheitsmanagement, GRC, SOA Migration und SOA Lifecycle Management Dieses Kapitel hat bisher einzelne Teildisziplinen des Sicherheitsmanagements dargestellt. Wie diese Teile zusammenhängen, wird im folgenden Abschnitt beschrieben. Der Begriff Sicherheitsmanagement setzt sich aus den Einzelbegriffen Sicherheit und Management zusammen. Durch diese Zusammenführung wird im übertragenem Sinne die Planung, Steuerung und Kontrolle der Sicherheit innerhalb einer Organisation garantiert. Um dies zu gewährleisten, muss das Sicherheitsmanagement eng mit GovernanceVerantwortlichen, Risiko-Managern, Compliance-Managern sowie mit den organisatorischen und technischen Mitarbeitern der Organisation zusammenarbeiten. Im Vordergrund steht dabei der Lebenszyklus der SOA. Die folgende Darstellung zeigt, wie die beschrieben Teildisziplinen zusammenarbeiten müssen, damit die ganzheitliche Sicherheit nachhaltig gewährleistet werden kann: G o v e rn a n c e SO A G overn an ce S ic h e rh e itsm a n a g e m e n t R is ik o m a n a g e m e n t SO A L e b e n sz y k lu s P la n u n g u n d D e s ig n A u fb a u u n d E n tw ic k lu n g C o m p lia n c e M a n a g e m e n t D e p lo y m e n t B e tr ie b u n d M a n a g em ent A b lö s u n g S O A M ig r a tio n Abbildung 53: Darstellung der Zusammenhänge In den vorherigen Abschnitten wurden Modelle, Verfahren und Lösungen zur effizienten Umsetzung von sicheren Service-orientierten Architekturen sowie deren Management beschreiben. Dabei wurden z.b. Sicherheitsstandards und Good Practices wie BSI-Standard bis 100-3: Auf Basis des IT-Grundschutzes ISO 27001:2005: Internationale Norm zum Management von Informationssicherheit ISO 27002:2005: Formelles Zertifizierungsverfahren für die Einhaltung von Standards genutzt. Damit diese Modelle, Verfahren und Lösungen effizient und effektiv angewandt werden können, müssen die Teilbereiche Governance, Risk und Compliance (GRC), SOA Migration und SOA Lifecycle Management fließend ineinander übergehen bzw. ineinander greifen. Das Sicherheitsmanagement ist dabei das Bindeglied der Teilbereiche. Ein Verfahren zur sicheren SOA Migration muss z.b. mit den innerhalb der Planungs- und Designphase des Managements des Lebenszyklus geplanten Lösungen vereinbar sein. Das 185

186 Sicherheitsmanagement definiert die internen Vorgaben, kontrolliert die externen Regularien (Compliance) und stellt somit die Verbindung zwischen der Planung- und Designphase mit der SOA Migration her. In der SOA-Welt stellt sich besonders die Frage, wie sich die einzelnen Komponenten sicher verwalten lassen. Aus Sicherheitssicht ist das Sicherheitsmanagement für die effektive Verwaltung der Methoden und Vorgaben sowie für die Kontrolle des sicheren Betriebs der einzelnen Komponenten verantwortlich. In Zeiten vor SOA, in denen die Anwendungen zumeist noch auf monolithischen Systemen liefen, konnte die Sicherheit mit den Unterbereichen Risiko- und Compliance-Management vergleichsweise einfach kontrolliert und verwaltet werden. Risiken konnten z.b. für jedes einzelne System analysiert, bewertet und behandelt werden. In einer SOA ist jedoch der Prozessgedanke innerhalb des Risikomanagements in den Vordergrund zu stellen. Die reine Analyse der Risiken für ITSysteme, IT-Infrastruktur und IT-Organisation deckt nur noch eine Teilmenge ab. Nur durch den Blick für das Ganze, also der ganzheitlichen Betrachtung inklusive der relevanten Geschäftsprozesse, können Risiken effektiv in der SOA-Welt analysiert und entsprechend behandeln werden. Dies gilt dann für jede Phase des Lebenszyklus der SOA sowie für die Aufgabe der Migration von Legacy-Systemen. Das Sicherheitsmanagement verwaltet und steuert in Zusammenarbeit mit der Governance sämtliche Bestandteile einer SOA-Landschaft, wie beispielsweise Sicherheits-Prozesse, die Umsetzung interner Vorgaben, Service Level Agreements, Verfügbarkeiten und Zugriffsrechte und schafft damit eine standardisierte Sicherheitslage, die es ermöglicht, dass das Sicherheitsniveau der Service-orientierten Architektur und der gesamten Organisation gesteigert werden kann. 186

187 6 Konzepte für Sicherheit in Service-orientierten Architekturen Nachdem mit dem vorhergehenden Kapitel Aufgaben des Security Managements und der SOA Governance betrachtet wurden, widmet sich dieses Kapitel nun konkreten technischen Konzepten, welche die von der Governance-Ebene vorgegebenen Sicherheitsrichtlinien in einem ganzheitlichen Sicherheitskonzept umsetzen. Eine Möglichkeit der technischen Umsetzung ist ein SOA Security Framework, das ein umfangreiches Rahmenwerk zur Absicherung von Service-orientierten Architekturen bietet und in Kapitel 6.1 beschrieben wird. Weiterhin werden in diesem Kapitel die Konzepte des Policy Managements, Trust Managements für die sichere Verwaltung von digitalen Identitäten sowie für die sichere Komposition von Diensten zur Abbildung von Geschäftsprozessen beschrieben. Darüber hinaus wird auf Konzepte zur Sicherstellung der Interoperabilität einer SOA mit anderen Implementierungen basierend auf den WS-I Standards eingegangen. 6.1 SOA Security Framework Ein SOA Security Framework bietet mit den nötigen Konzepten die technische Grundlage, mit dessen Hilfe bestehende Sicherheitsanforderungen umgesetzt werden können. Es umfasst eine Reihe von Sicherheitsmechanismen, die genutzt werden können, um die Dienste in einer SOA abzusichern. Für die Implementierung der Sicherheitsfunktionalität sind verschiedene Architekturansätze denkbar, die in Kapitel beschrieben werden. Das SOA Security Framework ist die technische Basis innerhalb der SOA Governance, die sich wiederum in die Unternehmens-Governance, wie in Kapitel beschrieben, eingliedert. Die SOA Compliance Governance prüft dabei, ob sämtliche Gesetze und Vorgaben eingehalten werden. Das SOA Security Framework hat die Aufgabe, die Anforderungen und Vorgaben der SOA Security Governance umzusetzen. Abbildung 54 zeigt die Zusammenhänge innerhalb der SOA Governance. Abbildung 54: Darstellung der Zusammenhänge SOA Governance und Security Framework Im Gegensatz zum SOA Governance Framework, welches aufbauend auf der Strategie der Organisation Elemente zusammenfasst, die es erlauben, Services zu steuern, zu kontrollieren 187

188 und transparent zu gestalten, dient das SOA Security Framework durch die Anwendung verschiedener Architekturansätze dazu, die Anforderungen technisch umzusetzen. 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 Umsetzer (Policy-Enforcement-Points, siehe Kapitel 6.2) verteilt wird, damit diese die Einhaltung der Richtlinie forcieren Architekturansätze Die Eignung von SOA-Security-Ansätzen im Rahmen des SOA Security Frameworks ist stark von den unterstützten Architekturansätzen abhängig, wobei insbesondere die Frage nach der Implementierung der eigentlichen Security-Funktionalität ausschlaggebend ist. Die Umsetzung der Sicherheitsrichtlinie für Services und Applikationen kann prinzipiell auf drei Arten erfolgen: Nutzung einer Proxyschicht vor den Services (Security als Infrastruktur), Verwendung von Security-Services (Security as a Service), als Teil der Anwendungslogik. Die folgende Abbildung zeigt diese Architekturansätze: Abbildung 55: Architekturansätze Die beiden erst genannten Ansätze sind i.d.r. durch ein Agentenkonzept zu realisieren. Agenten oder Connectoren sind lokale Laufzeitkomponenten, die (Security-) Funktionalität umsetzen. Diese Funktionalitäten werden durch die Nutzung verschiedener Standards bereitgestellt. Durch die Nutzung eines Agentenkonzeptes kann beispielsweise geprüft werden, ob eine Funktionalität wie die Authentisierung mittels Smart Cards, die 188

189 Verschlüsselung oder Signatur einer SOAP Nachricht auch wirklich umgesetzt wird. Agenten können daher im Sinne eines Proxy-Konzepts (siehe Kapitel ) vor den Systemen implementiert sein oder als (Security-) Service Provider (siehe Kapitel ) innerhalb einer Domäne oder Zone stehen und Funktionalität bereitstellen Security als Infrastruktur Abbildung 56: Sicherheit als integraler Bestandteil der Infrastruktur einer SOA Security als Infrastruktur wird genutzt, wenn Sicherheitsmechanismen von der Anwendungslogik getrennt werden sollen. Es wird angestrebt, Systeme und Aufrufe durch eine Infrastrukturkomponente (Appliance oder Proxy) 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 gewisse 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 können. Durch die Verwendung dieses Konzeptes wird eine klare Trennung zwischen Anwendungs- und Sicherheitslogik erreicht. Die Sicherheitsmechanismen können dann die benötigten Transformationen in der Nachricht durchführen, bevor diese anschließend für ihren eigentlichen Bestimmungszweck verwendet wird. Folgende Services sind sinnvollerweise über einen Infrastrukturansatz umzusetzen: Authorization-Services entscheiden über den Zugriff eines Consumers auf eine Ressource. Grundlage hierfür sind Sicherheitsregeln (Security Rules). Ein Standard hierfür ist z.b. XACML. Message-Protection-Services schützen die eigentlichen Nachrichten ganz oder bis auf Statement-Ebene. Standards hierfür sind u.a. WS-Security und SAML. Interoperation-Service allgemeine standardisierte Web Service-Schnittstellen zu Systemen. Führt benötigte Nachrichtentransformationen zur Anbindung von Systemen und Altanwendungen (Legacy Applications) durch (siehe Kapitel 5.2). 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 Authentifizierung bietet SAML 2.0 standardisierte Methoden, die eine Interoperabilität von Authentifizierungsinformationen ermöglichen. Ein entsprechendes Entity- und CredentialMapping vorausgesetzt, sind somit auch Federation-Ansätze umzusetzen. Für die Autorisierung der Service Aufrufe ermöglicht die zentrale Komponente die Verwaltung von 189

190 Rollen und Rechten für den Zugriff. Am Policy-Enforcement-Point (vor oder auf den Services/Backendsystemen) kann auf deren Basis die Entscheidung 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 Web Service das System im erwarteten Format anspricht Security as a Service Abbildung 57: Sicherheit als eigenständiger Service In einer SOA-Infrastruktur liegt es nahe, Sicherheit als wiederverwendbare Services bereitzustellen. Security-Services stellen dabei Sicherheitsmechanismen als Dienste bereit, die von allen Anwendungen/Komponenten über standardisierte Schnittstellen genutzt werden können. Über ein solches Konzept lassen sich viele Sicherheitsanforderungen realisieren. Dieses Konzept trägt insbesondere der Wiederverwendbarkeit Rechnung, da viele Sicherheitsmechanismen von verschiedenen Anwendungen gleichartig genutzt werden können. Beispiele hierfür sind Content-Filtering, Anti-Virus, Signatur oder Public-KeyInfrastruktur (PKI) via XKMS. Je nach Last- und Nutzverhalten sowie unter Berücksichtigung der Struktur einer Domäne ist es sinnvoll, zentralisierte Services bereitzustellen Applikationssicherheit Abbildung 58: Sicherheit als integraler Bestandteil der mit einem WS-Interface versehenden Anwendung Eine Implementierung von Sicherheitsmechanismen innerhalb der Applikationen scheidet zumeist schon aufgrund der Inflexibilität und fehlenden Administrationsmöglichkeiten aus, da das Prinzip der Wiederverwendbarkeit nicht eingehalten werden kann. Zudem ist bei diesem Ansatz die Forderung nach einer strikten Trennung von Applikationslogik und Sicherheitslogik nicht zu erfüllen. Auch der Aufwand der Implementierung in jeder Applikation und jedem Service verhindert einen Einsatz in komplexen Prozessen. Zusätzlich wirkt sich die monolithische Struktur auf Aspekte der Ausfallsicherheit, Lastverteilung und 190

191 Skalierbarkeit aus. Existieren viele solcher Anwendungen mit integrierter Sicherheitslogik, so gibt es deutliche Nachteile und Grenzen mit Blick auf Beherrschbarkeit und Administrierbarkeit, da eine zentrale Verwaltung nicht möglich ist. Nichtsdestotrotz kommt es immer wieder vor, dass solche Anwendungen Bestandteil einer SOA sind. Dies ist beispielsweise der Fall, wenn ein Sicherheitsmechanismus nicht aus der (Alt-)Anwendung heraus gelöst werden kann. Im Rahmen der Integration einer solchen (Alt-)Anwendung in eine SOA sind häufig individuelle Anpassungsarbeiten erforderlich Ergebnis In einem Nicht-SOA-Umfeld wird die Sicherheit durch Sicherheitsmaßnahmen des Betriebssystems, einer Sicherheitslogik in den Anwendungen und/oder in der Infrastruktur (Netz) abgebildet. Dies ist in einem SOA-Umfeld jedoch nicht ausreichend. Eine Anforderung an eine Service-orientierte Architektur ist die Wiederverwendbarkeit von Services und die Zentralisierung derselben. Aus diesem Grund müssen die Berechtigungsverwaltung und die Security-Administration außerhalb der Service-Logik erfolgen und möglichst als Security as a Service oder Security als Infrastruktur umgesetzt werden Konzepte im Rahmen der Umsetzung eines SOA Security Frameworks Grundsätzlich gelten für die Absicherung von Service-orientierten Architekturen bzw. -Infrastrukturen zunächst ähnliche Anforderungen wie bei der Absicherung herkömmlicher Systeme teilweise in SOA-typischen 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 sicherer Methoden signiert (Sicherstellung von Integrität) oder verschlüsselt (Erreichen 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 z.b. die interoperable Beschreibung von Identitäten, der Einsatz von Industriestandards und die Gewährleistung der Wiederverwendbarkeit von Diensten. Die folgenden Konzepte werden in den nächsten Kapiteln näher beschrieben: Policy Management, Trust Management, Identitätsmanagement, Sichere Dienstkomposition zur Abbildung von Geschäftsprozessen, Web Service Interoperabilität. 191

192 6.2 Policy Management Einleitung Die Anforderung der Wiederverwendbarkeit von Diensten in einer Service-orientierten Architektur ist ein wichtiger Aspekt, der die Umsetzung von Sicherheit von traditionellen Ansätzen unterscheidet. Um einen Dienst in verschiedenen Kontexten, die mit unterschiedlichen Sicherheitsanforderungen einhergehen, wiederverwenden zu können, stellt das feste Einprogrammieren von Sicherheitsmechanismen in einen Dienst keine Option dar. Anforderungsänderungen würden in diesem Fall zu aufwändigen und kostenintensiven Implementierungsanpassungen führen. Des Weiteren wäre eine schnelle Anpassung der ITInfrastruktur zur optimalen Unterstützung der Geschäftsprozesse nicht realisierbar. Vor diesem Hintergrund sollte vielmehr ein deklarativer Ansatz verfolgt werden, um die Belange der Sicherheits- und Fachseite voneinander zu trennen und damit im Ergebnis einen höheren Grad an Wiederverwendbarkeit und Flexibilität zu erzielen. Das Policy Management verfolgt einen solchen deklarativen Ansatz. Neben der formalen Definition von Sicherheitsrichtlinien (so genannte Policies), zählen auch das Verteilen, Aushandeln, Durchsetzen und Überwachen von Policies zu den Aufgaben des Policy Managements. In Policies werden die notwendigen Sicherheitsrichtlinien formal beschrieben, die von den Diensten in einer Service-orientierten Architektur genutzt werden, um kontextabhängig die entsprechenden Sicherheitsmechanismen anzuwenden. Eine Definition von Richtlinien kann dabei auf verschiedenen Abstraktionsstufen erfolgen. In der Regel werden ausgehend von geschäftlichen oder rechtlichen Anforderungen im Unternehmen zunächst allgemeine Richtlinien festgelegt. Z.B. wird beschrieben, dass ein Zugriff auf Kundendaten nur durch Mitarbeiter der Vertriebsabteilung erfolgen darf oder dass die Kommunikation mit einem Lieferanten zwingend vertraulich erfolgen muss. Aus diesen allgemeinen Anforderungen werden konkretere Richtlinien formuliert, die beispielsweise entsprechende Nutzerrechte für Gruppen, Mitarbeiter oder Rollen enthalten. Letztlich müssen diese Richtlinien dann von den IT-Systemen bzw. Diensten umgesetzt werden können. D.h. es muss eine standardisierte Beschreibung in maschinenlesbarer Form erstellt werden, damit die Richtlinien z.b. durch einen Dienst korrekt interpretiert werden können und die gewünschten Sicherheitsmechanismen zum Tragen kommen. In einer Service-orientierten Architektur werden an vielen Stellen Vorgaben benötigt, um die Sicherheit innerhalb des Gesamtsystems zu gewährleisten. Demzufolge müssen unterschiedliche Policies erstellt, verteilt und umgesetzt werden. Zusätzlich ist es wichtig, die korrekte Umsetzung von Sicherheitsrichtlinien regelmäßig zu überprüfen, um zu gewährleisten, dass mit den Policies auch die Ziele erreicht werden, für die sie definiert wurden. In diesem Kapitel werden die grundlegenden Phasen des Policy Managements beschrieben. Unterschieden werden folgende Phasen: 1. Policy Definiton 2. Verteilung von Policies (Policy Deployment) 3. Aushandeln von Sicherheitspolicies Sicheres Late Service Binding 4. Durchsetzung von Policies (Policy Enforcement) 5. Policy Monitoring 192

193 Innerhalb der o.g. unterschiedlichen Phasen kommen verschiedene Basiskomponenten zum Einsatz, die jeweils gewisse Aufgaben übernehmen und im Zusammenspiel für die Umsetzung der Policies verantwortlich sind. Abbildung 59 zeigt die relevanten Basiskomponenten und deren Abhängigkeiten untereinander. Abbildung 59: Basiskomponenten für das Policy Management Da die Basiskomponenten bereits im Rahmen der Standards beschrieben wurden (siehe Kapitel 4.4.4), werden nachfolgend lediglich deren grundlegende Aufgaben kurz erläutert. Im Policy Adminstration Point (PAP) (u.a. auch als Policy Management Point bekannt) werden Policies erstellt, so dass abstrakte Beschreibungen von geschäftlichen oder rechtlichen Anforderungen vorliegen. Dabei ist der Entscheidungskontext zu spezifizieren (z.b. Subjekt, Ressource, Aktion und Environment) sowie der Typ der Policy festzulegen (z.b. Policy zum Schutz der Integrität, Vertraulichkeit oder Authentifizierung). Des Weiteren ist eine Verknüpfung (Bindung) zu realen Entitäten vorzunehmen, beispielsweise zu Attributen des Subjekts in einem LDAP-Verzeichnis. Innerhalb der Gesamtarchitektur besteht eine weitere wesentliche Aufgabe des Policy Administration Points darin, die Policies so zu verteilen, dass bei Bedarf ein Zugriff und eine nachfolgende Auswertung sowie Umsetzung erfolgen kann. Bezogen auf die Gesamtarchitektur nimmt der Policy Administration Point somit Aufgaben in den beiden Phasen Definition von Policies und Verteilung von Policies wahr. Der Policy Decision Point (PDP) besitzt die Aufgabe, auf Grundlage von Policies, Entscheidungen zu treffen. Die Policies erhält der PDP vom Policy Adminstration Point, der für die Verteilung der Policies verantwortlich ist. Bei einer Entscheidungsanfrage des Policy Enforcement Points, z.b. wenn ein Nutzer auf eine bestimmte Ressource zugreifen möchte, ermittelt der PDP zunächst aus den übermittelten Daten der Anfrage die relevanten Policies. In einem nächsten Schritt überprüft der PDP, ob in dem genannten Beispiel ein Zugriff gemäß der Policies möglich ist oder dieser verweigert werden muss. Ggf. werden zur Bewertung weitere Attribute benötigt, die der Policy Decision Point nach kurzen Request/Reponse Nachrichten von dem Policy Information Point erhält. Das Ergebnis der Bewertung teilt der PDP schließlich dem Policy Enforcement Point in einer Antwortnachricht mit, so dass dieser entsprechende Maßnahmen ergreifen kann (Zugriff erlauben oder Zugriff 193

194 verweigern). Je nach Architektur ist es durchaus möglich, dass der Policy Decision Point und der Policy Enforcement Point eine Einheit bilden. In diesem Fall werden dennoch weiterhin zwei logisch voneinander getrennte Aufgaben erfüllt. Innerhalb des Policy Managements ist die PDP-Komponente am ehesten der Phase Durchsetzung von Policies zuzuordnen. Werden zu einem Zeitpunkt für eine Entscheidung bestimmte Informationen benötigt, wird der Policy Information Point (PIP) (z.b. LDAP-Verzeichnis) von dem Policy Decison Point kontaktiert. Je nach Anforderung der entsprechenden Policy werden in einer Antwortnachricht z.b. die Attribute zu einem Subjekt, einer Ressource oder Environment (Entscheidungskontext) dem PDP mitgeteilt. Dieser kann dann die Informationen mittels der Policy evaluieren und anschließend eine Entscheidung treffen. Der PIP kann innerhalb des Policy Managements zwei Phasen zugeordnet werden. Zum einen ist er in der Definitionsphase von Bedeutung, weil eine Verbindung zwischen Policies und realen Entitäten (z.b. Benutzerrollen in einem LDAP-Verzeichnis) hergestellt wird. Zum anderen kann der Policy Information Point auch der Phase Durchsetzung von Policies zugeordnet werden, da er bei Handlungsbedarf als Informationsquelle die Grundlage für Entscheidungen und damit die Durchsetzung von Policies bildet. Im Zusammenhang mit der Bereitstellung von Attributen, insbesondere im Kontext von föderierten Systemen, ist häufig der Begriff Attribute Authority zu lesen. Eine Attribute Authority hat als vertrauenswürdige Stelle/Komponente Zugriff auf Datenbanken mit Identitätsattributen von Nutzern und kann diese basierend auf Regeln unter bestimmten Bedingungen herausgeben bzw. bereitstellen. Darüber hinaus bietet eine Attribute Authority die wesentliche Funktionalität, Attribute einer Person oder Entität zu einem bestimmten Zeitpunkt sicher zu bestätigen. Das Validieren der Authentizität von Attributen oder den sicheren Austausch von Attributen kann ebenfalls von einer Attribute Authority geleistet werden. In Bezug auf das Bereitstellen von Attributen nimmt eine Attribute Authority die gleiche Funktion wie der Policy Information Point wahr, kann allerdings wie beschrieben weitere wichtige Aufgaben im Rahmen einer sicheren Autorisierung übernehmen. Der Policy Enforcement Point (PEP) ist für die Durchsetzung von Policies verantwortlich. D.h. der PEP stellt technisch z.b. sicher, dass, je nach Entscheidung des Policy Decision Points, ein Zugriff auf eine Unternehmensressource (Web Service, Datenbank, Anwendung...) erfolgen kann oder der Zugriff verweigert wird. Des Weiteren kann eine Policy beispielsweise vorschreiben, dass der Zugriff auf die Ressource verschlüsselt erfolgen muss. Der Policy Enforcement Point besitzt dann die Aufgabe sicherzustellen, dass entsprechende Verschlüsselungsmechanismen angewendet werden, um Policy-konform das geforderte Sicherheitslevel zu erzielen Policy Definition Innerhalb eines Unternehmens oder einer Behörde existieren jeweils bestimmte Richtlinien (so genannte Corporate Policies), die einzuhalten sind. Viele dieser geschäftlichen oder rechtlichen Richtlinien haben dabei oftmals direkte Auswirkungen auf die vorhandene oder zu realisierende IT-Infrastruktur. Z.B. kann es aus Gründen des Datenschutzes erforderlich sein, dass bestimmte personenbezogene Daten stets vertraulich behandelt werden. Diese Anforderung hat zur Konsequenz, dass eine zugriffsgeschützte Speicherung sowie 194

195 verschlüsselte Übertragung durch die involvierten IT-Komponenten umzusetzen ist. Wie genau diese Anforderungen zu realisieren sind, wird jeweils in Policies beschrieben. Damit die entsprechenden IT-Komponenten die Policies verstehen und durchsetzen können, muss die Definition der Policies in einer standardisierten sowie maschinenlesbaren Form (vorwiegend XML) vorgenommen werden. Um von den allgemeinen Corporate Policies zu den konkreten IT-spezifischen Policies zu gelangen, wird in der Regel ein mehrstufiger Prozess durchlaufen (siehe Abbildung 60), in dem der Detaillierungsgrad stetig zunimmt. Ausgehend von den Unternehmens-/ Behördenpolicies, werden in einem nächsten Schritt Prozess-spezifische Richtlinien definiert, d.h. eine Präzisierung der allgemeinen Anforderung vorgenommen. Im Anschluss daran ist es sinnvoll, die Richtlinien nach den grundlegenden Sicherheitszielen zu kategorisieren. Manche Richtlinien betreffen beispielsweise den Schutz von Nachrichten (Integrität), andere hingegen die Authentifizierung von Benutzern oder Diensten (Authentication) und wiederum andere Richtlinien den Zugriffsschutz auf bestimmte Ressourcen (Authorization). Zur Erreichung der Sicherheitsziele gibt es eine Ebene tiefer, d.h. auf IT-Ebene, entsprechende Sicherheitsprotokolle bzw. Standards, die von den IT-Komponenten oder Diensten innerhalb der Service-orientierten Architektur zu nutzen sind. Während WS-Security z.b. ein möglicher Standard zum Schutz von Nachrichten ist, wird SAML für die Authentifizierung und XACML für den Zugriffsschutz genutzt. Durch eine Kategorisierung der Policies nach den Sicherheitszielen, wird somit indirekt zugleich eine Vorauswahl möglicher Technologien und Standards vorgenommen und dadurch bereits eine gute Vorarbeit zur Definition konkreter Service-spezifischer Policies geleistet. Diese Service-spezifischen Policies sind letztlich von IT-Experten zu erstellen, die über entsprechendes Know-How hinsichtlich des Standards sowie der relevanten IT-Systeme und deren Zusammenwirken innerhalb der Gesamtarchitektur verfügen (vgl. [PMgmt]). Der beschriebene mehrstufige Policy-Definitionsprozess muss nicht zwangsläufig komplett manuell erfolgen, bei bestimmten Voraussetzungen kann der Prozess durch automatisierte Transformationen unterstützt werden. Werden standardisierte Beschreibungs- bzw. Modellierungssprachen (UML, BPMN, usw.) bereits auf höheren Ebenen - z.b. auf Prozessebene - eingesetzt, können benötigte Sicherheits- und Service-spezifische Policies durch entsprechende Anwendungsprogramme automatisch generiert werden (vgl. [PMgmt]). Bei der Administration, Erstellung und Anpassung von Policies ist darauf zu achten, dass diese Aufgaben nur von autorisierten Personen durchgeführt werden, da geänderte Policies unmittelbar das Sicherheitsniveau im Unternehmen beeinflussen. Ein Zugriffsschutz auf die Policies ist daher durch entsprechende Authentifizierungs- und Autorisierungsmechanismen zu gewährleisten. Abbildung 60: Abstraktionsebenen von Policies (vgl. [PMgmt]) 195

196 Ähnlich der Diskussion zur Vorgehensweise bei der Implementierung von Web Services, stellt sich auch bei der Definition von Richtlinien die Frage, ob allgemein immer ein TopDown oder ein Bottom-Up Ansatz verfolgt werden soll. Prinzipiell stellt ein Top-Down Ansatz, wie er zuvor beschrieben wurde, eine optimale Vorgehensweise dar, um bestmöglich die geschäftlichen Anforderungen umzusetzen. In der Praxis ist eine solche Vorgehensweise jedoch nicht immer durchführbar, da die Leistungsfähigkeit bestehender IT-Systeme berücksichtigt werden muss und diese oftmals die Möglichkeiten einer Realisierung limitieren. Bestimmte Systeme sind ggf. nicht in der Lage, gewünschte Sicherheitsmechanismen zu unterstützen, so dass eine Wiederverwendbarkeit innerhalb der Gesamtarchitektur nur bedingt gewährleistet ist. Vor diesem Hintergrund ist eine Bottom-Up Betrachtung sinnvoll, um genau diese Restriktionen identifizieren und geeignete Lösungen entwickeln zu können. Allgemein ist es daher ratsam, bei der Definition von Policies eine Kombination aus beiden Ansätzen durchzuführen (vgl. [PMgmt]. Relevante Standards Zur Definition von Policies kommen in der Praxis vorwiegend folgende Standards zum Einsatz: XACML (siehe Kapitel 4.4.4): XACML (extensible Access Control Markup Language) ist eine XML-Policy Sprache, die die Zugriffskontrolle auf Ressourcen standardisiert. Mit XACML wird beschrieben, wie Regeln bzw. Anfragen und Antworten zu formulieren sind, so dass eine kontextbasierte (attributbasierte) Autorisierung durchführbar ist. WS-Policy (siehe Kapitel 4.3.5): WS-Policy definiert eine Syntax, um Anforderungen auszudrücken, die sich auf die nachrichtenbasierte Kommunikation zwischen Service Consumer und Web Services beziehen. Dazu spezifiziert WS-Policy eine allgemeine XML-Struktur, um Anforderungsalternativen als eine Reihe von einfachen oder verschachtelten und/oder-verknüpfungen zu definieren. WS-Security-Policy (siehe Kapitel 4.5.2): WS-Security-Policy spezifiziert eine Sammlung von Policy-Assertions in WS-Policy Dokumenten, um sicherheitsbezogene Anforderungen und Fähigkeiten hinsichtlich der Verwendung von WS-Security, WS-Trust und WS-SecureConversation auszudrücken Policy Definition - SCA Policy Framework Nachfolgend wird erläutert, wie für die Service Component Architecture (SCA) Policies definiert werden können. Es handelt sich in diesem Abschnitt somit um keine neue Phase innerhalb des Policy Managements, sondern vielmehr um einen Exkurs bzw. eine erweiterte Beschreibung der Policy Definition-Phase (siehe Abschnitt 6.2.2). In Kapitel wurde allgemein die Service Component Architecture (SCA) beschrieben, die einen Ansatz darstellt, um Software komponentenbasiert zu entwerfen und umzusetzen. Der nachfolgende Abschnitt beschäftigt sich speziell mit dem Policy Framework (vgl. 196

197 [SCAPolicy]), das für SCA definiert wurde. Mit dem Framework wird das Ziel verfolgt, das Spezifizieren von Anforderungen (Bedingungen, Fähigkeiten, Qualitätserwartungen) bereits von Beginn an, d.h. bereits innerhalb des allgemeinen Komponentendesigns, bis hin zur konkreten Realisierung zu unterstützen. Somit ist es beispielsweise möglich, dass der SCA Designer zunächst grundlegende Anforderungen bzw. Absichten (so genannte Intents) an eine Komponente definiert, die dann zu einem späteren Zeitpunkt in Form von konkreten Policies durch einen IT- bzw. Policy-Experten verfeinert und umgesetzt werden. Abstrakte Spezifikationen durch Intents Bei Intents handelt es sich um abstrakte Anforderungsspezifikationen, die bewusst keine Aussage zur Verwendung einer bestimmten Technologie oder eines Protokolls treffen. Der SCA Designer beschreibt mit Intents lediglich auf eine allgemeine Weise, was er innerhalb der Architektur benötigt. Zum Beispiel kann die Anforderung definiert werden, dass Mechanismen zur Sicherstellung der Vertraulichkeit benötigt werden. Welche Mechanismen genau zum Einsatz kommen sollen, so dass das Ziel erreicht werden kann, wird in Intents nicht beschrieben (vgl. [SCAPolicy]). Mittels so genannter qualified Intents kann die allgemeine Anforderung verfeinert werden. Z.B. ist dann eine Aussage möglich, ob sich die Vertraulichkeit auf die Nachricht (confidentiality.message) oder auf die Übertragung bezieht (confidentiality.transport). <intent name= sca:confidentiality constrains= sca:binding <description> Protect messages from unauthorized reading. </description> </intent> <intent name= sca:confidentiality.transport /> Profile Intents sind als eine Art Makro aufzufassen, d.h. eine Bezeichnung für eine Sammlung von Intents. Im Prinzip handelt es sich um eine Anforderung, die nur dann erfüllt wird, wenn alle untergeordneten Intents (spezifiziert über requires Attribut) erfüllt werden. Im Rahmen der Spezifikation wurden bereits qualifizierende Intents für Sicherheit (security), Zuverlässigkeit (reliability) und Transaktionalität (transactionality) vordefiniert. Für den Bereich Sicherheit sind die Intents Vertraulichkeit (confidentiality), Authentifizierung (authentication) und Integrität (integrity) verfügbar. Zur Verfeinerung können die beiden Qualifier message und transport verwendet werden (z.b. confidentiality.transport, integrity.message, ). Unabhängig davon können durch SCA Implementierungen weitere Intents für bestimmte Funktionalitäten definiert werden, die ggf. in einem bestimmten Kontext von Bedeutung sind. Zuordnung von konkreten Policies durch PolicySets und IntentMaps Eine grobe Spezifikation von Richtlinien durch (qualifizierende) Intents reicht nicht aus, damit Sicherheitsmechanismen geeignet von den Komponenten umgesetzt werden können. Für die Umsetzung ist es notwendig, konkrete Policies den zuvor definierten Intents zuzuordnen (vgl. [SCAPolicy]). Mittels PolicySets können mehrere konkrete Policies definiert bzw. zusammengefasst werden. Dabei werden weiterhin die Policies bestimmten Intents zugeordnet, die von dem jeweiligen PolicySet unterstützt werden (z.b. confidentiality). 197

198 IntentMaps weisen den qualified Intents (s. <qualifier/> Element im Codebeispiel) konkrete Policies zu. Alle Policies innerhalb einer IntentMap beziehen sich auf eine Policy Domäne. PolicySets wiederum aggregieren IntentMaps, um Zuordnungen von Intents und Policies für mehrere Domänen zu erstellen. Zuordnung von Policies zu SCA Komponenten Intents und/oder PolicySets können beliebigen SCA Komponenten zugeordnet werden. Über das optionale requires Attribut werden Intents spezifiziert, über das optionale policysets hingegen ein oder mehrere PolicySets (vgl. [SCAPolicy]). <intentmap provides= sca:confidentiality default= transport > <qualifier name= transport > <wsp:policyattachment> <!-- policy expression and policy subject for transport alternatve --> </wsp:policyattachment> <wsp:policyattachment> </wsp:policyattachment> </qualifier> <qualifier name= message > <wsp:policyattachment> <!-- policy expression and policy subject for message alternatve --> </wsp:policyattachment> </qualifier> </intentmap> Rollen und Verantwortlichkeiten für das SCA Policy Framework Die SCA Policy Framework Spezifikation unterscheidet grundsätzlich vier verschiedene Rollen, die jeweils bestimmte Aufgaben übernehmen (vgl. [SCAPolicy]): Policy Administrator: Seine Aufgabe besteht darin, sowohl Intents als auch konkrete PolicySets zu definieren. Entwickler (Developer): Der Entwickler ist hauptsächlich für die Implementierung der Komponenten und Komponententypen verantwortlich. Falls es möglich ist, eine Komponente zu entwickeln, ohne bereits ein bestimmtes Binding vorzuschreiben, kann er über Intents allgemeine Anforderungen festlegen. Anderenfalls kann er bei der Entwicklung Bindings und PolicySets spezifizieren. Assembler: Der Assembler erstellt Composites. Da Composites Implementierungen sind, besitzt er eine ähnliche Rolle wie der Entwickler. Der einzige Unterschied besteht darin, dass er Composites aus bestehenden Komponenten entwickelt, die miteinander verbunden werden. Er erstellt daher auch Intents und definiert Bindings sowie PolicySets. Deployer: Er ist für die Umsetzung verantwortlich, d.h. er führt die Implementierungen (in der Regel Composites) in der SCA Domäne ein. Er trifft die letzten Entscheidungen über alle Konfigurationen und stellt sicher, dass alle geforderten Ziele/Intents erreicht werden. 198

199 6.2.3 Verteilung von Policies Für die Durchsetzung (Enforcement) von Policies ist es erforderlich, dass der jeweilige Dienst (PEP) Zugriff auf die notwendigen Policies hat. Die verschiedenen Varianten der Administration und Verteilung werden nachfolgend beschrieben (vgl. [PMgmt]). 1. Lokale Speicherung von Policies und separate Administration In dieser Variante werden die Policies lokal, d.h. auf demselben IT-System bzw. Container wie der Dienst (PEP) vorgehalten. Die Administration der Policies erfolgt lokal und wird für jeden Dienst einzeln vorgenommen. Demzufolge ergibt sich ein großer zu betreibender Verwaltungsaufwand, wenn mehrere Dienste innerhalb eines Geschäftsprozesses involviert sind. Abbildung 61: Lokale Speicherung von Policies und separate Administration (vgl. [PMgmt]) 2. Lokale Speicherung von Policies mit zentralisierter Administration Die Administration der Policies wird in dieser Variante zentral vorgenommen. Die Policies werden jedoch wie in Variante 1 lokal vorgehalten, so dass weiterhin ein Zugriff durch die Dienste immer auf das jeweilige lokale Policy-Repository erfolgt. Aufgrund dieser Konstellation ist zwingend durch den Policy Administration Point zu gewährleisten, dass bei diensteübergreifenden Policies immer eine Synchronisation aller Repositories erfolgt. Abbildung 62: Lokale Speicherung von Policies mit zentralisierter Administration (vgl. [PMgmt]) 199

200 3. Zentrale Speicherung und Administration der Policies Alle Policies werden in einem zentralen Repository gespeichert und verwaltet. Der Administrationsaufwand, der sich bei dienstübergreifenden Policies ergibt, ist demzufolge, verglichen mit den vorherigen Varianten, relativ gering. Allerdings muss bei dieser Variante jedes Mal, wenn eine Policy geprüft werden soll (z.b. Zugang auf eine Ressource erlauben oder verhindern), ein Zugriff über das Netzwerk auf das zentrale Repository erfolgen. Dieser Umstand kann ggf. zu Verfügbarkeits- und Performanceproblemen führen, wenn beispielsweise Engpässe im Netzwerk auftreten (z.b. Ausfall einer Netzwerkkomponente oder zu hoher Netzwerkverkehr). Abbildung 63: Zentrale Speicherung und Administration der Policies (vgl. [PMgmt]) 4. Zentrale Administration sowie zentrale und dezentrale Speicherung der Policies Bei dieser Variante wird ähnlich wie zuvor ein zentrales Repository für die Policies verwendet und auch zentral die Administration auf Basis dieses Repositories vorgenommen. Allerdings greifen die Dienste (PEPs) immer nur auf lokale Kopien der Policies zu, die zusätzlich zu dem zentralen Repository existieren. Ein zwingend erforderlicher Netzwerkzugriff auf das zentrale Repository im Rahmen eines Enforcement-Vorgangs entfällt demnach. Die Synchronisierung der lokalen Kopien kann entweder nach dem Push-Prinzip (PAP verteilt Policies auf lokale Repositories) oder nach dem Pull-Prinzip (PEPs aktualisieren selbst ihre lokalen Kopien) erfolgen. Bei der Verwendung von lokalen Kopien ist darauf zu achten, dass diese durch zusätzliche Sicherungsmaßnahmen vor Manipulationen geschützt werden. 200

201 Abbildung 64: Zentrale Administration sowie zentrale und dezentrale Speicherung der Policies (vgl. [PMgmt]) Aushandeln von Sicherheitspolicies Sicheres Late Service Binding In Service-orientierten Architekturen stellt die Kompatibilität von Sicherheitsmechanismen eine besondere Herausforderung dar, da Dienste in verschiedenen Kontexten genutzt und verschiedene Modelle und Technologien zur Absicherung herangezogen werden können. Insbesondere wenn Dienste dynamisch über einen Verzeichnisdienst gefunden und genutzt werden, ist die dynamische Bestimmung und Konfiguration der vom Service Consumer zu verwendenden Sicherheitsmechanismen zur Laufzeit unabdingbar. Das Grundprinzip ist der Austausch der Sicherheitspolicies zwischen einem Client und dem Dienst, um zu ermitteln, mit welchen Sicherheitsmechanismen der Client den Dienst ansprechen kann. Im Folgenden wird die grundlegende Problematik der Kompatibilität im Hinblick auf die Web ServiceTechnologien beschrieben. Zudem wird die Lösung dieses Problems über den Austausch von Sicherheitsanforderungen basierend auf WS-Policy und die Verwendung dieses Konzeptes im Rahmen des Late Service Bindings von Diensten erläutert Sicherstellung der Kompatibilität der Sicherheitsanforderungen Service-orientierte Architekturen können mit unterschiedlichen Technologien realisiert sein, die verschiedene Sicherheitsmechanismen unterstützen. Im Umfeld der Web ServiceTechnologien kann die Vertraulichkeit, die Integrität und die Authentizität von ausgetauschten Nachrichten beispielsweise durch die Spezifikationen WS-Security, WS-Trust und WS-SecureConversation sichergestellt werden (vgl. Kapitel 4.5). Diese Spezifikationen erlauben die Nutzung von unterschiedlichen Sicherheitskonzepten und Verfahren, um eine Integration der Web Service-Technologien in verschiedenen Umgebungen zu ermöglichen, die auf unterschiedlichen Sicherheitstechnologien beruhen. So können beispielsweise auch die in Kapitel 6.4 beschriebenen verschiedenen Verfahren für das Identitätsmanagement Anwendung finden. Diese Flexibilität führt allerdings zu dem Problem, dass die Kompatibilität nicht alleine durch die Unterstützung der Web Service-Spezifikationen gewährleistet werden kann. Die Hauptursache für Inkompatibilitäten ist zum einen, dass die Web Service Sicherheitsspezifikationen optionale Elemente definieren und zum anderen, dass eine 201

202 Auswahl an Möglichkeiten geboten wird. Implementierungen, die unterschiedliche Optionen voraussetzen oder aus der Auswahl an Möglichkeiten gegensätzliche gewählt haben, sind nicht kompatibel. Tabelle 8 listet einige Beispiele für Inkompatibilitäten aufgrund unterschiedlicher Sicherheitsanforderungen auf. Inkompatible Sicherheitsanforderungen Beschreibung Sicherstellung der Vertraulichkeit durch Absicherung des Transportkanals oder durch Absicherung der Nachricht. Die Vertraulichkeit kann auf Kanalebene sichergestellt werden oder mittels WSSecurity durch die ausgetauschten Nachrichten. Die Web Service-Clients müssen die Absicherung gemäß den Anforderungen des Dienstes umsetzen. Verwendung verschiedener Algorithmen, Schlüsselstärken und Kodierungen. WS-Security erlaubt die Absicherung verschiedener Nachrichtenteile mit unterschiedlichen Algorithmen und Schlüsselstärken. Unterschiedliche Implementierungen können unterschiedliche Verfahren unterstützen. Nutzung verschiedener Formate von Sicherheitstoken und unterschiedliche zugrunde liegende Vertrauensbeziehungen. In WS-Security können verschiedene Arten von Sicherheitstoken verwendet werden, um Identitätsinformationen an eine Web Service-Nachricht zu binden. Zudem kann wie im Kapitel 6.4 Identitätsmanagement beschrieben eine Vertrauensbeziehung zu bestimmten Identitätsprovidern bestehen, durch die Identitätsinformationen beglaubigt sein müssen. Ein Web ServiceAufruf kann nur erfolgreich sein, wenn die richtigen Sicherheitstoken von den richtigen Identitätsprovidern abgerufen und in die Nachricht eingefügt wurden. Unterschiedliche Verwendung der Spezifikationen mit unterschiedlichen Optionen. Beispiele hierfür sind eine unterschiedliche Reihenfolge der Nutzung von Verschlüsselung und Signatur in einer Nachricht und eine unterschiedliche Reihenfolge von Sicherheitsheadern in einer SOAP Nachricht. Sicherheitstechnisch macht es einen großen Unterschied, in welcher Reihenfolge bestimmte Mechanismen und Spezifikationen hinsichtlich Verschlüsselung und Integrität angewendet wurden. Daher müssen Client und Dienst die Absicherung der Nachrichten identisch vornehmen, um sicher kommunizieren zu können. Tabelle 8: Beispiele für Inkompatibilitäten hinsichtlich der Umsetzung von Sicherheit in einer SOA Eine nahe liegende Lösung ist die Reduktion der möglichen Optionen auf eine Grundmenge, die von allen Implementierungen unterstützt werden müssen. Dieser Ansatz wird vom WS-I Profile verfolgt, das in Kapitel 6.6 näher beschrieben ist. Allerdings löst dies nicht die Problematik, dass verschiedene Dienste immer noch verschiedene Sicherheitsmodelle 202

203 unterstützen können und die Sicherheitsanforderungen von Diensten gerade wenn die Dienste dynamisch gefunden und genutzt werden sollen zum Zeitpunkt der Entwicklung häufig nicht bekannt sind. Policy-basierter Ansatz zur Sicherstellung der WS Kompatibilität Eine Grundeigenschaft von Diensten in einer Service-orientierten Architektur ist deren Selbstbeschreibung. Dazu ermöglicht WSDL eine einheitliche Beschreibung der Schnittstelle eines Dienstes, die veröffentlicht und von anderen Diensten und Clients genutzt werden kann. Allerdings impliziert die Anforderung der Selbstbeschreibung eines Dienstes auch, dass der Dienst beschreibt, wie Clients die Nachrichten für den Aufruf des Dienstes zu strukturieren haben und welche Informationen enthalten sein müssen beispielsweise Identitätsinformationen. Diese Anforderungen können im Kontext von Web Services durch WS-Policy beschrieben werden. Ein Client kann die Policy des Dienstes nutzen, um seine Nachrichten konform zu dieser Policy aufzubauen und den Dienst interoperabel aufzurufen. Dieser Ansatz ermöglicht die Sicherstellung der Interoperabilität zur Laufzeit und garantiert die SOA-Eigenschaften wie Selbstbeschreibung, Interoperabilität und Wiederverwendbarkeit. Abbildung 65: Dynamische Nutzung eines Dienstes unter Berücksichtigung von Sicherheitsanforderungen Der Ablauf beim Aufruf eines Dienstes erfolgt in vier Schritten und ist in Abbildung 65 dargestellt: 1. Sicherheitspolicy des Dienstes abrufen Der Client muss im ersten Schritt die Policy des Dienstes mit den Sicherheitsanforderungen abrufen. Im Rahmen der Web Service-Technologien ist 203

204 diese Policy durch WS-Policy beschrieben unter Verwendung von WSSecurityPolicy zur Beschreibung der Sicherheitsanforderungen (vgl. Kapitel und Kapitel 4.5.2). Grundsätzlich gibt es zwei Möglichkeiten, um eine WS-Policy abzurufen: a) Die Policy ist an andere Metadaten des Dienstes angehängt In diesem Fall wird WS-PolicyAttachment (vgl. Kapitel 4.3.7) genutzt, um die durch die Policy beschriebenen Anforderungen in WSDL-Definitionen einzubetten oder an UDDI-Einträge anzuhängen. Ein Client kann also die WSDL abrufen und die Dienstanforderungen extrahieren oder ein UDDI Verzeichnis abfragen. b) Die Policy wird explizit vom Dienst abgerufen In diesem Fall wird WS-MetadataExchange (vgl. Kapitel 4.3.8) genutzt, um gezielt die WS-Policy für den Dienst abzufragen. Voraussetzung hierfür ist, dass der Dienst WS-MetadataExchange unterstützt, indem ein zusätzlicher Web Service-Endpunkt bereitgestellt wird, über den die Metadaten abgefragt werden können. Ein Beispiel für eine WS-Metadata-Anfrage findet sich in Kapitel Policy des Clients laden Der Client muss seine eigene Policy laden, die beschreibt, welche Sicherheitsmechanismen und Optionen dieser unterstützt und für die Kommunikation mit Diensten nutzt. Für das Laden der Policy kommen die Möglichkeiten in Frage, die im Abschnitt eingeführt wurden. 3. Bestimmung der gemeinsamen Sicherheitsoptionen Wie im Kapitel WS-Policy beschrieben, besteht ein WS-Policy Dokument aus einer Und/Oder-Verschachtelung von Anforderungen. Damit lassen sich Optionen beschreiben, die für die Kommunikation genutzt werden können. Wenn dem Client seine eigene Policy und die Policy des Dienstes vorliegen, dann muss er die Schnittmenge an Alternativen aus beiden Policy-Dokumenten bestimmen, die von Client und Dienst gemeinsam unterstützt werden. Dazu definiert WS-Policy zwei Schritte: a) Normalisierung der Policy (Normalisation) WS-Policy definiert eine Normalform, die keine beliebige Verschachtelung von Alternativen zulässt, sondern deren Kombination auf eine einfache disjunktive und konjunktive Kombination beschränkt ist. Zudem definiert WS-Policy ein Verfahren für die Abbildung von beliebigen Verschachtelungen auf diese normalisierte Form, da eine Abbildung in jedem Fall möglich ist. b) Bildung der Schnittmenge (Policy Intersection) Die normalisierte Darstellung einer WS-Policy bildet eine Grundlage, um die Schnittmenge an gemeinsam unterstützten Alternativen leicht zu bestimmen. Die dazu notwendigen Schritte sind in der WS-Policy-Spezifikation genau vorgegeben. Die Policy mit den gemeinsam unterstützen Alternativen wird im Rahmen von WSPolicy auch effective Policy genannt. 4. Dienst mit der gemeinsamen Policy aufrufen Aus den gemeinsam unterstützen Alternativen (effektive Policy) kann dann eine Alternative ausgewählt werden, die für den Dienstaufruf genutzt wird. 204

205 Beispiel: Bestimmung gemeinsamer Policyoptionen Abbildung 66: Auswahl einer Option zur Verschlüsselung Die Bestimmung der gemeinsamen Sicherheitsanforderungen soll durch das Beispiel in Abbildung 66 verdeutlicht werden. Der Dienst in diesem Beispiel verlangt die Verschlüsselung aller ein- und ausgehender Nachrichten zur Sicherstellung der Vertraulichkeit. Dazu unterstützt der Dienst den Algorithmus AES mit der Schlüsselstärke 192 oder 256, was in seiner Policy beschrieben ist. Hingegen kann das Web ServiceFramework, welches von Client verwendet wird, Daten zwar auch mit AES verschlüsseln, unterstützt aber nur die Schlüsselstärken 128 und 192. Dies ist in der Policy des Clients beschrieben. Sobald der Client seine eigene Policy und die des Dienstes geladen hat, bestimmt dieser die Schnittmenge der gemeinsam unterstützten Optionen. Diese Policy enthält nur noch AES 192 als Option, was somit für die Verschlüsselung der Kommunikation zwischen Dienst und Client genutzt wird Sicheres Late-Binding von Diensten Das Konzept des Late Service Bindings ist in Abbildung 67 dargestellt und ermöglicht die Auswahl der zu nutzenden Dienste zur Laufzeit. Die zentrale Architekturkomponente stellt die Service-Registry dar, die Metadaten über Dienste verwaltet und von Clients genutzt werden kann, um Dienste zu finden. Im Rahmen der Web Service Technologien kann beispielsweise UDDI (vgl. Kapitel 4.3.2) als Standard für das Dienstverzeichnis Anwendung finden. Das Late Service Binding besteht aus drei Schritten: Abbildung 67: Sicheres Late Service Binding 1. Registrieren Dienste müssen im Verzeichnis registriert werden, um für die Clients verfügbar gemacht zu werden. Zudem werden Metadaten wie die Schnittstellenbeschreibung (z.b. WSDL) im Verzeichnis hinterlegt. Des Weiteren 205

206 können auch Sicherheitsanforderungen im Verzeichnis abgelegt werden. WSPolicyAttachment definiert beispielsweise die Bindung von WS-Policy Informationen an UDDI-Einträge. 2. Finden Clients können das zentrale Verzeichnis verwenden, um Dienste zu finden. Dies erfolgt üblicherweise über eine Interface-Beschreibung, kann aber ebenso je nach Möglichkeiten und Technologie des verwendeten Verzeichnisses - auch semantische Beschreibungen und Anforderungen an die Sicherheit mit einbeziehen. 3. Binden Sobald ein Client den zu verwendenden Dienst über das Verzeichnis bestimmt hat, kann er über das Verzeichnis die Adresse dieses Dienstes abfragen und den Dienst nutzen. In diesem Schritt müssen die Sicherheitsanforderungen des Dienstes, wie zuvor beschrieben, bestimmt und beachtet werden. Dazu muss der Client die Sicherheitsanforderungen des Dienstes laden, diese mit seinen eigenen abgleichen, aus der Menge der gemeinsam unterstützen Optionen eine auswählen und die Kommunikation entsprechend absichern. Die Besonderheit beim Late Service Binding in Hinblick auf die Ermittlung der Policy des Dienstes ist, dass neben der direkten Abfrage der Sicherheitspolicy vom Dienst, auch die Abfrage über das Verzeichnis eine Alternative darstellt Durchsetzung von Policies (PDP, PEP) Die Durchsetzung von Sicherheitspolicies wird durch die Komponente Policy Enforcement Point (PEP) realisiert, die deklarativ spezifizierte Sicherheitspolicies interpretieren kann und Funktionalität bietet, um die in den Policies spezifizierten Sicherheitsanforderungen durchzusetzen. Für die Umsetzung kann der PEP auch Sicherheitsdienste nutzen, die verschiedene Sicherheitsfunktionalitäten als Dienst bereitstellen (vgl. Security as a Service, Kapitel ), wie beispielsweise die Überprüfung von Informationen nach Viren, die Bereitstellung von PKI-Funktionalitäten oder von Sicherheitstoken. Zudem kann ein solcher Sicherheitsdienst auch als ein Policy Decision Point (PDP) dienen, damit zentralisiert sicherheitsrelevante Entscheidungen getroffen werden können. Dieses Konzept findet üblicherweise im Rahmen von Zugriffskontrollentscheidungen Anwendung. Ein übliches Beispiel für einen Sicherheitsdienst im Rahmen von SOA ist ein Security Token Service, wie er durch WS-Trust spezifiziert ist (vgl. Kapitel 4.5.3). Dieser kann auch Aussagen über Zugriffskontrollentscheidungen bereitstellen und somit als PDP dienen. In einer SOA gibt es grundsätzlich drei verschiedene Möglichkeiten, wie ein PEP implementiert und integriert werden kann, um einen Dienst zu schützen. 206

207 Policy Enforcement Point als Bibliothek Dienstlogik Client Sicherheitsbibliothek Dienst Abbildung 68: Policy Enforcement Point als Bibliothek In dieser Variante wird eine Bibliothek eingebunden, die Sicherheitsfunktionalitäten bereitstellt und Sicherheitspolicies interpretieren kann. Damit die Sicherheitsanforderungen durchgesetzt werden können, ist es erforderlich, dass die Logik des Dienstes diese Bibliothek einbindet und im Kontext der Kommunikation mit den Clients korrekt nutzt. Beispielsweise muss die Implementierung sicherstellen, dass alle ein- und ausgehenden Nachrichten an die Funktionen der Bibliothek übergeben werden, damit die Vertraulichkeit und Integrität sichergestellt werden kann. Somit ist die Integration der Sicherheit Service- und implementierungsspezifisch und setzt zudem spezifisches Wissen beim Programmierer voraus Policy Enforcement Point als Modul Client Sicherheitsmodule Dienstlogik Dienst Abbildung 69: Policy Enforcement Point als Modul Bei diesem Ansatz ist der PEP als ein Satz von Sicherheitsmodulen umgesetzt, die für einen Dienst konfiguriert sind. Dieser Ansatz findet üblicherweise in Web Service-Frameworks Anwendung, in denen ein- und ausgehende Nachrichten durch eine vorkonfigurierte Kette von Modulen durchgereicht werden. Jedes Modul kann übergebene Nachrichten verändern und weitergeben oder einen Fehler zurückgeben. So können beispielsweise bei eingehenden Nachrichten die Daten entschlüsselt werden oder bei ausgehenden Nachrichten Daten verschlüsselt werden. Da die Sicherheit somit von der zugrunde liegenden Web Service Plattform umgesetzt wird, ist die Dienstlogik von der Sicherheit separiert. Allerdings muss bei dieser Variante beim Deployment darauf geachtet werden, dass die Sicherheitsmodule für den Dienst auch konfiguriert und aktiviert sind. 207

208 Policy Enforcement Point als Gateway Client Sicherheitsfunktionalität Dienstlogik Gateway Dienst Abbildung 70: Policy Enforcement Point als Gateway In dieser Variante werden die Sicherheitsanforderungen zentralisiert von einem GatewayService für ein oder mehrere Dienste durchgesetzt. Das Gateway läuft als eigene abgesicherte Instanz, die Anfragen an die Dienste entgegennehmen, gemäß vordefinierter Sicherheitspolicies bearbeiten und an die Dienste weiterleiten kann. Zudem kann das Gateway vor SOA-spezifischen Angriffen (vgl. Kapitel 3.3) schützen, die auf spezielle Fehler in den von den Diensten verwendeten Web Service-Frameworks oder XML-Parsern abzielen. Es gibt zwei Möglichkeiten, wie ein solcher Policy Enforcement Punkt eingesetzt werden kann: 1. Der Gateway-Service wird direkt vor dem abzusichernden Dienst platziert. Eine Kommunikation mit dem Dienst darf nur über das Gateway möglich sein. 2. Der Gateway-Service wird genutzt, um Dienste in einer anderen Vertrauensdomäne anzubieten, beispielsweise von Partnern im Internet. Um die Kommunikation mit dem Dienst in der eigenen Sicherheitsdomäne zu schützen, muss aber noch ein zusätzlicher PEP direkt vor dem Dienst platziert werden Policy Monitoring Das Policy Monitoring und Reporting ist dafür verantwortlich, dass innerhalb des Policy Managements regelmäßig geprüft wird, ob die geschäftlichen und gesetzlichen Regelungen in geeigneter Weise von den betroffenen IT-Komponenten umgesetzt werden. Da sich Unternehmensrichtlinien oder rechtliche Vorschriften im Laufe der Zeit ändern können, sind demzufolge auch die Policies auf IT-Ebene bei Bedarf anzupassen. Ein weiterer Grund, der eine Änderung von Policies erforderlich machen kann, ist die Möglichkeit, dass Schwachstellen in einzelnen IT-Komponenten bzw. neue Risiken entdeckt werden. Das Nachverfolgen von Business-Level-Policies bis hin zu den umgesetzten Konfigurationen und Anforderungen sowie Voraussetzungen zur Laufzeit muss für ein effektives und effizientes Monitoring gewährleistet sein. Nur so kann z.b. die Ursache gefunden werden, weshalb bestimmte Richtlinien im Unternehmen nicht wie gefordert durchgeführt werden. Änderungen an Policies sollten streng kontrolliert werden, da sie mitunter erhebliche Auswirkungen auf die Abwicklung der Geschäftsprozesse und die IT-Sicherheit im Unternehmen haben können. Es bedarf aus diesem Grund zwingend organisatorischer und technischer Regelungen und Maßnahmen, die einen Zugriff auf die Policies nur autorisierten Personen oder IT-Komponenten/Dienste erlauben. Des Weiteren sollte jeder Zugriff in geeigneter Form protokolliert werden, so dass eine spätere Rückverfolgung möglich ist. 208

209 6.3 Trust Management Dienste in einer Service-orientierten Architektur können unterschiedlichen administrativen und rechtlichen Organisationseinheiten angehören. Dies ist insbesondere der Fall, wenn Dienste zur Abwicklung sicherer Geschäftsprozesse über Unternehmensgrenzen hinweg choreographiert werden. Aber auch innerhalb eines Unternehmens kann es verschiedene Vertrauensbereiche geben. Das Vertrauen zwischen den Teilnehmern einer SOA ist daher eine Grundvoraussetzung für das Funktionieren einer solchen Architektur. Dieses Kapitel beschreibt mögliche Mechanismen, um dieses Vertrauen in einer SOA zu etablieren Grundlagen Vertrauen bildet die Grundlage für jegliche geschäftliche Kooperationen. Eine übliche Definition für Vertrauen stammt von McKnight und Chervany [Kn 2000], die Vertrauen wie folgt definieren: Vertrauen ist die Bereitschaft einer Person oder Entität in einer bestimmten Situation von einer anderen Person oder Entität abhängig zu sein mit der Erwartung, dass diese sich in der gewünschten Art und Weise verhält und unter der Gefahr negativer Konsequenzen, falls sich diese Annahme als falsch herausstellt. Dieser Definition entsprechend, ist Vertrauen also immer mit einem gewissen Risiko verbunden. Es ist die Aufgabe des Trust Managements dieses Risiko abzuschätzen und daraus Trust Policies abzuleiten, die die Grundlage für die Verwaltung von Vertrauensbeziehungen bilden. Vertrauensbeziehungen sind gerichtete Beziehungen, in der eine Partei der anderen vertraut, dass sie in der gewünschten Art und Weise handelt. Im Allgemeinen unterscheidet man zwischen direkten und indirekten Vertrauensbeziehungen. Direkte Vertrauensbeziehungen existieren zwischen zwei Partnern, die sich kennen und beispielsweise durch Kooperationsverträge miteinander verbunden sind. Darüber hinaus sind aber auch indirekte Vertrauensbeziehungen möglich. Bei diesen kennen sich zwei Partner nicht direkt, besitzen jedoch eine Vertrauensbeziehung zu einer dritten Partei. Diese kann genutzt werden, um das Vertrauen zu etablieren. Beide Arten von Vertrauensbeziehungen spielen in Serviceorientierten Architekturen eine Rolle und werden im folgenden Kapitel genauer betrachtet Vertrauensbeziehungen in SOA Szenarien Die Anforderungen an die Vertrauensbeziehungen in einer SOA richten sich im Allgemeinen nach dem Szenario, welches durch die SOA umgesetzt wird und können sehr unterschiedlich sein. In vielen Fällen reicht eine Selbstregistrierung des Benutzers bei einem Dienst, um personalisierte Inhalte anzubieten. Hat man dagegen Geschäftsprozesse, die geschäftskritisch sind und zu hohen Verlusten führen können, so sind komplexe Verträge und hochsichere Zugriffsmechanismen eine Notwendigkeit, um das Risiko für die beteiligten Parteien gering zu halten. Tabelle 9 listet einige Standardfälle aus der Praxis mit ihren Vertrauensbeziehungen und den typischerweise genutzten Mechanismen, um dieses Vertrauen zu etablieren, auf. Diese Standardfälle stellen Beispiele dar ohne den Anspruch auf Allgemeingültigkeit zu erheben. Letztendlich ist das benötigte Vertrauen vom jeweiligen Anwendungsfall und von dem mit 209

210 diesem Anwendungsfall verbundenen Risko abhängig. Werden Benutzern beispielsweise anonym Informationen auf einer Webseite angeboten, so besteht für den Anbieter dieser Information kein Risiko durch einen Benutzer, der sich lediglich informieren möchte (Beispiel Internetpräsenz). Demnach benötigt der Webseitenanbieter in den Nutzer auch kein Vertrauen. In der entgegengesetzten Richtung allerdings benötigt der Benutzer durchaus ein gewisses Grundvertrauen in den Anbieter der Webseite, um auf die dort bereitgestellten Informationen vertrauen zu können. Im Allgemeinen lässt sich sagen, dass die Qualität der Vertrauensbeziehung umso höher sein muss, je höher das Risiko für die beteiligten Parteien ist. Beziehung Beispiel Hochsicher- Kreditvergabe heit Teilnehmer identifiziert über benötigtes Grundvertrauen der Parteien Kreditnehmer Kreditgeber: Eindeutige Identität mittel Kreditgeber Kreditnehmer: Sehr hoch Mechanismen Überprüfung hoheitlicher Dokumente, Verträge Unternehmensintern/ Operativ Mitarbeiter nutzt Mitarbeiterrolle die Unternehmenssoftware für die Lagerverwaltung Unternehmen Mitarbeiter: hoch B2B Unternehmen A Vertragspartner bestellt beim Unternehmen B Bauteile für die Fertigung In beide Richtungen: Hoch - mittel G2C Kunde möchte Behördliches sein Auto online Dokument, z.b. ummelden eid, elektronischer Fahrzeugschein In beide Richtungen: hoch Überprüfung eines hoheitlichen Dokumentes B2C Kunde bestellt ein Buch Selbstregistrierter Account In beide Richtungen: Kunde informiert sich über die Webseite eines Herstellers Unbekannt Kunde Anbieter: gering Internetpräsenz Arbeitsvertrag Mitarbeiter Unternehmen: gering gering Vertragliche Beziehungen auf Unternehmensebene Registrierung mit eventueller Überprüfung bestimmter Attribute, z.b. der Adresse keine Anbieter Kunde: kein Vertrauen Tabelle 9: Standardszenarien und ihre Vertrauensbeziehungen 210

211 Letztendlich lassen sich alle Anwendungsfälle auf einige grundlegende Konstellationen zurückzuführen, welche sich durch die Art der Vertrauensbeziehungen (direkt/indirekt) und die Anzahl der vorkommenden Sicherheitsdomänen unterscheiden lassen. Diese grundlegenden Architekturmuster sind im Folgenden beschrieben Vertrauensbeziehungen innerhalb einer Domäne In diesem Szenario ruft ein Client einen Dienst innerhalb einer Domäne direkt auf. Der Benutzer ist beim Dienst registriert und authentisiert sich mit der beim Dienst hinterlegten Identität. Dies ist z.b. der Fall, wenn ein Mitarbeiter beim Partnerunternehmen direkt registriert ist und dort einen Account besitzt. Abbildung 71: Direktes Vertrauen zwischen einem Client und einem Dienst Vertrauensbeziehungen Es besteht eine direkte Vertrauensbeziehung zwischen Dienst und Client. Vertrauensanforderungen Der Client muss dem Dienst vertrauen, dass dieser dessen private Daten vertraulich behandelt, nicht zur Auswertung seines Benutzerverhaltens missbraucht und nicht an unbefugte Dritte weitergibt. Der Dienst muss dem Client vertrauen, dass er seine Authentifizierungsinformationen vertraulich behandelt Vertrauensbeziehungen innerhalb einer Domäne mit zentraler Instanz In diesem Szenario wird die Verwaltung sicherheitskritischer Daten von einer zentralen Instanz innerhalb der Domäne übernommen. Dies ist z.b. der Fall, wenn ein Mitarbeiter unternehmensintern auf Anwendungen zugreift (siehe Beispiel Lagerverwaltung) und sich dafür beim unternehmensweiten Kerberosdienst authentisiert. Vertrauensbeziehungen Sicherheits dienst direktes Vertrauen direktes Vertrauen Client indirektes Vertrauen Dienst Administrative Domäne 1 Abbildung 72: Vertrauensbeziehungen in einer Domäne mit zentralen Sicherheitsdiensten 211

212 Es bestehen direkte Vertrauensbeziehungen zwischen dem Dienst und einem zentralen Sicherheitsdienst, der vertrauliche Daten wie die Benutzeridentitäten verwaltet, sowie zwischen dem Client und dem Sicherheitsdienst. Dem Client wird nach erfolgreicher Authentifizierung beim Sicherheitsdienst in der Domäne vertraut. Vertrauensanforderungen Der Client muss dem Sicherheitsservice und dem Dienst vertrauen, dass diese seine privaten Daten vertraulich behandeln, nicht zur Auswertung seines Benutzerverhaltens missbrauchen und nicht an unbefugte Dritte weitergeben. Der Sicherheitsservice muss dem Client vertrauen, dass er seine Authentifizierungsinformationen vertraulich behandelt. Der Dienst muss dem Sicherheitsservice vertrauen, dass dieser keine kompromittierten Daten ausgibt Direktes Vertrauen zwischen Domänen In diesem Szenario vertraut der Dienst direkt der anderen Domäne. Dies ist z.b. der Fall, wenn ein Mitarbeiter, der in seinem eigenen Unternehmen eingeloggt ist, auf die Dienste eines Partnerunternehmens zugreifen kann, ohne sich erneut authentisieren zu müssen. Dies ist möglich da eine Vertrauensbeziehung auf Unternehmensebene besteht. Abbildung 73: Direktes Vertrauen zwischen einem Dienst und einer Partnerdomäne Vertrauensbeziehungen Es besteht eine direkte Vertrauensbeziehung zwischen dem Dienst und der anderen Domäne, im Allgemeinen repräsentiert durch einen öffentlich zugänglichen Sicherheitsservice. Es besteht eine direkte Vertrauensbeziehung zwischen dem Client und dem Sicherheitsservice in der eigenen Domäne. Es besteht eine indirekte Vertrauensbeziehung zwischen dem Client und dem Dienst, die durch die Beziehung des Clients zum zentralen Sicherheitsservice seiner Domäne und der Beziehung des Dienstes zu diesem Sicherheitsservice etabliert wird. 212

213 Dem Client wird nach erfolgreicher Authentifizierung beim Sicherheitsdienst in der eigenen und in der Dienstdomäne vertraut. Vertrauensanforderungen Der Client muss dem Sicherheitsservice und dem Dienst vertrauen, dass diese seine privaten Daten vertraulich verhandeln, nicht zur Auswertung seines Benutzerverhaltens missbrauchen und nicht an unbefugte Dritte weitergeben. Der Sicherheitsservice muss dem Client vertrauen, dass er seine Authentifizierungsinformationen vertraulich behandelt. Der Dienst muss dem Sicherheitsservice vertrauen, dass dieser keine kompromittierten Daten ausgibt Indirektes Vertrauen zwischen Domänen In diesem Szenario vertraut der Dienst nur einem zentralen Sicherheitsdienst in seiner eigenen Domäne, der wiederum direkte Vertrauensbeziehungen zu Komponenten in anderen Vertrauensdomänen hat. Dies ist das klassische Föderationsszenario, in dem Mitarbeiter eines Unternehmens auf Ressourcen im anderen Unternehmen zugreifen können und umgekehrt. In einer Föderation vereinbaren die Geschäftspartner auf die Authentifizierung und Aussagen des jeweilig anderen zu vertrauen, um ein unternehmensübergreifendes SSO zu etablieren (vgl. Kapitel 6.4 Identitätsmanagement). Abbildung 74: Indirektes Vertrauen zwischen einem Dienst und einer Partnerdomäne Vertrauensbeziehungen Auf Unternehmensebene bestehen nur direkte Vertrauensbeziehungen zwischen den zentralen Sicherheitsdiensten zweier Domänen. Innerhalb einer Domäne bestehen direkte Vertrauensbeziehungen zu den zentralen Sicherheitsdiensten. Dem Client wird in der Zieldomäne vertraut, wenn er sich a) erfolgreich in seiner eigenen Domäne authentifiziert hat (direktes Vertrauen auf Benutzer- bzw. Anwendungsebene) und 213

214 b) wenn der Sicherheitsdienst 2 dem Sicherheitsdienst 1 vertraut (direktes Vertrauen auf Unternehmensebene). Die Vertrauensbeziehung zwischen dem Client und dem Dienst wird somit indirekt über mehrere direkte Vertrauensbeziehungen etabliert. Vertrauensanforderungen Der Client muss seinem eigenem Sicherheitsservice vertrauen, dass dieser seine privaten Daten vertraulich behandelt, nicht zur Auswertung seines Benutzerverhaltens missbraucht und nicht an unbefugte Dritte weitergibt. Der Sicherheitsservice muss dem Client vertrauen, dass er seine Authentifizierungsinformationen vertraulich behandelt. Die Sicherheitsservices müssen sich gegenseitig vertrauen, dass die gemeinsamen Sicherheitsrichtlinien eingehalten werden Konzepte und Mechanismen zur Etablierung von Vertrauen Dieses Kapitel stellt basierend auf den im vorhergehenden Abschnitt herausgestellten Szenarien, die diesen zugrundeliegenden Mechanismen zur Etablierung von Vertrauen vor. Grundsätzlich lassen sich zwei Ansätze für die Etablierung von Vertrauen unterscheiden: zum einen Vertrauen basierend auf Vereinbarungen und zum anderen Vertrauen basierend auf der Reputation einer Entität. Je nachdem, ob eine Vertrauensbeziehung zwischen zwei Unternehmen oder zwischen einem Mitarbeiter oder Kunden und dem Unternehmen etabliert werden soll, finden jeweils andere Mechanismen Anwendung. Die folgende Tabelle listet die Mechanismen zur Etablierung von Vertrauen in Abhängigkeit von der Art der Vertrauensbeziehung und der beteiligten Entitäten auf. Insgesamt lassen sich in der Praxis drei relevante Fälle unterscheiden. Direktes Vertrauen Vertrauen auf Unternehmensebene Vertrauen auf Client-Ebene (Benutzer/ Anwendung) Indirektes Vertrauen Vertrauen durch Föderationsverträge Nicht üblich (würde InterFöderationsszenarien entsprechen) Vertrauen durch Registrierung/Verifikation, Vertrauen durch Empfehlungen, Reputation Vertrauen durch Verträge Tabelle 10: Mechanismen zur Etablierung von Vertrauen Vertrauen durch Föderationsverträge Vertrauen basierend auf Vereinbarungen wie Föderationsverträgen wird durch starke Sicherheitsmechanismen wie Zertifikate und vertrauenswürdige Zertifizierungsstellen erreicht. Im Ergebnis steht eine eindeutige, binäre Entscheidung: Der Partner ist vertrauenswürdig oder nicht. Diese Mechanismen finden vor allem Anwendung in Geschäftsszenarien, in denen das Risiko einer Fehltransaktion genau eingeschätzt werden muss, um gesetzlichen Vorgaben oder den Unternehmensrichtlinien gerecht zu werden. Hat 214

215 man beispielsweise multinationale Unternehmen, die verschiedene autonome Geschäftsstellen in verschiedenen Ländern oder Regionen haben, so können die gesetzlichen Vorschriften stark voneinander abweichen. Beispielsweise gelten bezüglich des Datenschutzes in den USA weniger restriktive Regeln als in Deutschland: Während Behörden in Deutschland dem Schutz des Einzelnen verpflichtet sind, gelten Behördenakten in den USA als öffentliches Eigentum, auf die jeder Zugriff hat. Im Allgemeinen ist der Aufbau des Vertrauens in Föderationen ein mehrstufiger Prozess. Zu Beginn steht die Einigung auf gemeinsame Richtlinien zur Absicherung der Serviceorientierten Architektur. Im zweiten Schritt folgt die Umsetzung dieser Vereinbarungen in der Föderationsinfrastruktur. Föderationsvereinbarungen Föderationsvereinbarungen haben das Ziel, einen Konsens an Vereinbarungen zu finden, um den Complianceanforderungen aller Partner gerecht zu werden. Darüber hinaus balancieren sie das Risiko für die involvierten Parteien aus, um eine ebenbürtige Vertrauensbeziehung zu schaffen. Ist beispielsweise das Risiko für eine Partei deutlich geringer (man spricht hierbei auch von einer asymmetrischen Vertrauensbeziehung), so kommt oftmals gar kein Vertrag zustande, da sich der Partner mit dem höheren Risiko nicht sicher sein kann, dass sich der andere an die Vereinbarungen hält. Föderationsvereinbarungen sind letztendlich das formale Ergebnis einer Risikoanalyse und stellen Sicherheitsanforderungen dar, die sich aus der Analyse ableiten. Das Ziel dieser Risikoanalyse ist es, die Voraussetzungen dafür zu schaffen, dass ein Unternehmen auf die Identitätsmanagementinfrastruktur des anderen Partners vertrauen kann. Denn letztendlich muss ein Unternehmen im späteren Geschäftsbetrieb Entscheidungen treffen, die auf Informationen basieren, welche genau durch diese Infrastruktur verwaltet werden. Föderationsvereinbarungen beinhalten daher typischerweise Aussagen zu den folgenden Sicherheitsaspekten: Anforderungen an die Authentifizierung von Mitarbeitern z.b. welche Authentifizierungsmechanismen werden verwendet, Policies zur Passwortwahl- und -änderung, Sicherstellung, dass Passwörter nicht mehrfach verwendet werden Anforderungen an die Infrastruktur, z.b. verschlüsselte Datenbanken verschlüsselte Übertragung von Passwörtern Verwendung von Firewalls Anforderungen an die Client-Sicherheit wöchentliche Updates von Sicherheitssoftware Verwendung von kommerzieller Antivirussoftware auf allen Arbeitsrechnern Aufbau einer vertrauenswürdigen Infrastruktur Die Vereinbarungen, die mit dem Unterzeichnen der Föderationsvereinbarung getroffen wurden, müssen im System abgebildet werden. Im Allgemeinem wird dazu eine Sicherheitsinfrastruktur verwendet, die auf einer PKI beruht. Mit Hilfe einer PKI kann einer Entität, einer einzelnen Person oder einem Unternehmen der Besitz einer bestimmten Identität zertifiziert werden. Dazu verifiziert eine Zertifizierungsstelle diese Identität und stellt ein 215

216 Zertifikat aus, das der Person oder dem Unternehmen/der Behörde diese Identität bestätigt. Diese Bestätigung erfolgt mittels einer digitalen Unterschrift der Zertifizierungsstelle. Gleichzeitig ist mit diesem Zertifikat ein Schlüsselpaar verknüpft, welches es dem Subjekt des Zertifikats (Person oder Unternehmen/Behörden) erlaubt, sich eindeutig zu authentisieren. Damit kann beispielsweise überprüft werden, ob eine Nachricht auch tatsächlich von einem bestimmten Absender stammt. Für die Etablierung von Vertrauen in SOA werden im Allgemeinen die folgenden Schritte durchgeführt: Auswahl einer vertrauenswürdigen Zertifizierungsstelle Die Zertifizierung muss von einer Zertifizierungsstelle vorgenommen werden, der beide Partner vertrauen. Dies kann zum Beispiel eine vertrauenswürdige dritte Partei sein, welche beiden Partnern entsprechende Zertifikate ausstellt, die dann in der jeweiligen Sicherheitsinfrastruktur des Partners als vertrauenswürdig markiert werden. Alternativ kann natürlich auch einer der beiden Partner die Rolle der Zertifizierungsstelle übernehmen. Austausch von Metadaten (Zertifikate, etc.) Um das Vertrauen nicht nur vertraglich, sondern auch auf Systemebene zu verankern, müssen Metadaten über die Föderation ausgetauscht werden. Dazu zählen unter anderem die jeweiligen öffentlichen Schlüssel, mit denen die Partner verifizieren können, dass es sich beim Absender einer Nachricht auch tatsächlich um den Partner handelt. Pseudonymmanagement und Benutzermapping Ein weiterer Aspekt, welcher in einer Föderation Beachtung finden sollte, ist wie Benutzeraccounts in den verschiedenen Domänen auf Accounts in der jeweils anderen Domäne gemappt werden können. Dabei gibt es mehrere Möglichkeiten: Der Benutzer besitzt Accounts in beiden Domänen, welche aufeinander gemappt werden müssen. Der Benutzer besitzt nur in einer der beiden Domänen einen Account. In diesem Fall kann - sofern nötig - ein Account on-the-fly beim Partnerunternehmen erstellt werden, welcher nach einer gewissen Zeit wieder gelöscht wird. Gerade wenn mehr als zwei Partner an einer Föderation beteiligt sind, bietet sich die Verwendung von Pseudonymen an. Pseudonyme verhindern, dass die verschiedenen Partner einer Föderation Benutzeraktionen in den einzelnen Domänen miteinander korrelieren, um damit ein genaues Profil des Benutzerverhaltens zu erstellen Vertrauen durch Verträge auf Benutzerebene Vertrauensbeziehungen zwischen verschiedenen Sicherheitsdomänen bilden die Grundlage zur Ausführung von domänenübergreifenden Geschäftsprozessen, da sie es erlauben, die Dienste des Partners als vertrauenswürdig einzustufen. Dies reicht jedoch nicht aus. Letztendlich müssen nicht nur die Dienste, sondern alle an einem Geschäftsprozess beteiligten Akteure als vertrauenswürdig eingestuft werden. Dazu gehören insbesondere auch die Benutzer, in dessen Namen ein Dienst zur Abwicklung eines Geschäftsprozesses aufgerufen wird. Um das Vertrauen in den Aufrufer eines Dienstes zu etablieren, können wiederum Verträge das Mittel der Wahl sein. Möchte beispielsweise ein Mitarbeiter einen Dienst seines 216

217 Unternehmens nutzen, z.b. Preisinformationen aus einer Produktdatenbank abfragen, so ist die vertrauliche Grundlage in erster Linie der Arbeitsvertrag, welcher eine direkte Vertrauensbeziehung zwischen dem Mitarbeiter und seinem Unternehmen etabliert. Diese Vertrauensbeziehung bildet die Grundlage für die Einrichtung eines Benutzeraccounts und den damit verbundenen Zugriffsrechten Vertrauen durch Registrierung/Verifikation Genauso wie Verträge auf Benutzerebene dienen auch Registrierungs- und Verifikationsprozesse dazu, Vertrauen in die Identität des Aufrufers eines Dienstes zu etablieren. Insbesondere geht es darum eine vertrauenswürdige digitale Identität zu schaffen, mit der sich der Aufrufer während der Ausführung des Geschäftsprozesses authentisieren kann und welche verschiedenen Diensten als Grundlage für die Zugriffsentscheidung dient. Dabei ist das etablierte Vertrauen stark von der Registrierung abhängig. Die Registrierung ist ein Prozess, der eine digitale Identität für eine Person der realen Welt erschafft. Inwieweit die digitale Identität mit der Identität in der realen Welt übereinstimmt, ist abhängig von der Stärke mit der die eingegebenen Daten während der Registrierung verifiziert werden. Oftmals findet lediglich eine Überprüfung der -Adresse statt, indem der Benutzeraccount erst aktiviert wird, nachdem der Benutzer einen in der ihm zugesendeten enthaltenen Link aufgerufen hat. Welche Verifikationsverfahren letztendlich zum Einsatz kommen, entscheidet sich durch das vom Dienst benötigte Vertrauen in die Identität eines Benutzers. Bei der Eröffnung eines Kontos wird zum Beispiel häufig das PostIdent-Verfahren verwendet, bei dem die Identität des Kunden durch eine vertrauenswürdige dritte Partei (die Post) verifiziert wird Vertrauen durch Reputation Reputation ist ein eher weicher Ansatz für die Etablierung von Vertrauen, welcher auf Erfahrung und den Meinungen anderer Teilnehmer in einem Netzwerk basiert. Reputationsbasierte Ansätze greifen immer da, wo es nicht möglich ist, Vertrauen durch Policies oder feste Vereinbarungen zu etablieren. Dies ist vor allen der Fall, wenn ungeordnete Strukturen vorliegen, wie dies zum Beispiel bei User Communities im Internet vorkommt. Letztendlich wird aus der Bewertung eines Benutzers oder allgemein einer Entität, die Entscheidung abgeleitet, ob eine Vertrauensbeziehung zustande kommt oder nicht. Beispielsweise entscheidet sich ein Käufer in einem Online Shop basierend auf den Bewertungen anderer Käufer, ob er etwas bestellen möchte oder nicht. Dazu führt dieser für sich eine Risikoanalyse durch, indem er das eigene Risiko mit dem eigenen Nutzen abwägt. Ein derartiges adhoc Vorgehen ist in B2B Szenarien eher schwierig, weswegen hier die Etablierung von Vertrauen eher auf vordefinierten Entscheidungen beruht, welche nach Möglichkeit durch Verträge abgesichert sind. Jedoch gibt es auch hier Beispiele für die Nutzung reputationsbasierter Systeme. Bei B2B Handelsplattformen beispielsweise entscheiden die Teilnehmer auf Basis der Reputation des Betreibers der Handelsplattform, ob sie den dort zugelassenen Teilnehmern vertrauen. Zudem können Reputationssysteme hilfreich sein, zu entscheiden, welche Daten ein Benutzer an einen Dienst herausgeben möchte. 217

218 6.4 Identitätsmanagement in SOA Fast alle IT Systeme von mobilen Geräten bis hin zu komplexen, hoch performanten Systemen operieren auf wertvollen Informationen und Daten. Um diese vor unerlaubtem Zugriff zu schützen, muss das System, das diese Daten verwaltet, etwas über die Person oder Entität wissen, die Zugriff verlangt. Erst basierend auf diesem Wissen kann das System eine Zugriffsentscheidung treffen. In einer SOA ist die Verwaltung derjenigen, die auf einen Dienst zugreifen, ungleich schwerer als in einer monolithischen Anwendung. Die Eigenschaft von Diensten für jedermann offen und in verschiedenen Kontexten nutzbar zu sein, steht im Konflikt mit der Notwendigkeit, die Dienste vor unerlaubtem Zugriff zu schützen. Hinzu kommt, dass Benutzer eines Dienstes nicht im Vorfeld bekannt sein müssen und der Kreis derjenigen, die einen Dienst in einer SOA nutzt, sehr groß werden kann. Dieses Kapitel betrachtet verschiedene Ansätze für Identitätsmanagement im Kontext von Service-orientierten Architekturen und gibt einen Überblick über verfügbare Technologien, ihre Einsatzszenarien und mögliche Gefahren Grundlagen Digitale Identitäten stellen die digitale Repräsentation einer Identität, die durch eine Person oder Entität in der realen Welt verkörpert wird, dar. Sie umfassen eine konkrete, begrenzte Menge an Attributen, welche eine Person charakterisieren, wie z.b. deren Namen, Adresse oder Geburtsdatum. Typischerweise folgen digitale Identitäten einem allgemeinen Lebenszyklus, welcher in Abbildung 75 dargestellt ist. Abbildung 75: Lebenszyklus einer digitalen Identität Am Anfang steht die Erzeugung einer digitalen Identität durch das Zusammentragen und Speichern von Identitätsinformation in Form eines Accounts. Danach erfolgt die Benutzung einer Identität, welche vier wesentliche Schritte umfasst: die Behauptung des Besitzes dieser Identität (Identifizierung), z.b. durch die Angabe des Benutzernamens die Verifikation einer Identität durch den Prozess der Authentifizierung, z.b. durch die Überprüfung des eingegebenen Passwortes die Bereitstellung von Identitätsinformationen für Anwendungen und Dienste, z.b. durch das Auslesen der Identitätsinformationen aus der Datenbank und letztendlich 218

219 der Konsum von Identitätsinformationen durch die Anwendungen oder Dienste, z.b. die Verwendung der Adresse des Benutzers als Lieferadresse für die Bestellung eines Buches Parallel dazu können Wartungsaufgaben vorgenommen werden, um einen Account aktuell zu halten, wie z.b. das Ändern der Adresse nach einem Umzug oder die Generierung eines neuen Passwortes. Wird eine Identität nicht mehr benötigt, wird sie zerstört (Löschen eines Accounts). Es ist die Aufgabe des Identitätsmanagements diesen Zyklus zu ermöglichen und zu steuern Von domänen-basierten Ansätzen zu offenen Identitätsmanagementmodellen Dieses Kapitel beschreibt die vier grundsätzlichen Modelle für die Verwaltung von Identitäten, die in Service-orientierten Architekturen Anwendung finden. Diese sind das anwendungsspezifische, das zentralisierte, das benutzerzentrische und das föderative Identitätsmanagement. Betrachtet man diese Modelle in ihrer konzeptionellen Evolution, so lässt sich ein Trend von den klassischen domänen-basierten Identitätsmanagementlösungen hin zu immer offeneren Modellen verzeichnen, die speziell für die dezentrale und heterogene Landschaft einer SOA geschaffen wurden. Domänen-basierte Identitätsmanagementmodelle Anwendungsspezifisches Identitätsmanagement Zentralisiertes Identitätsmanagement Offene Identitätsmanagementmodelle Benutzerzentrisches Identitätsmanagement Föderatives Identitätsmanagement Tabelle 11: Einordnung der Identitätsmanagementmodelle Während domänen-basierte Modelle um den Begriff des Accounts eines Benutzers als zentrales Element angelegt sind, zielen offene Identitätsmanagementmodelle darauf ab, verschiedene Identitätsmanagementsysteme miteinander zu verbinden und zu integrieren. Insbesondere in Service-orientierten Architekturen, die das Potenzial besitzen, technologisch unterschiedliche Systeme nicht nur innerhalb eines Unternehmens, sondern auch zwischen Unternehmen zu verbinden, ist es oftmals gar nicht möglich, bestehende Identitätsmanagementlösungen zu ersetzen. Offene Identitätsmanagementmodelle ermöglichen hier die Verwaltung von Identitätsinformationen durch mehrere Quellen, so dass existierende Lösungen bestehen bleiben können. Darüber hinaus bieten sie Mechanismen, um Identitätsinformationen zwischen heterogenen Systemen auszutauschen und von einem gegebenen Format in ein Format zu transferieren, welches die Anwendungen verstehen können. Sowohl das benutzerzentrische als auch das föderative Identitätsmanagement stellen solche offenen Systeme dar. 219

220 Anwendungsspezifisches Identitätsmanagement Definition Beim anwendungs- oder Service-spezifischen Identitätsmanagement verwaltet jede Anwendung oder jeder Dienst die Benutzer selbst, d.h. alle Benutzer, die einen Dienst nutzen, müssen sich zuvor bei diesem anmelden/registrieren. Abbildung 76: Prinzip des anwendungsspezifischen Identitätsmanagements Beschreibung Das anwendungsspezifische Identitätsmanagement bietet proprietäre, auf eine Anwendung zugeschnittene Lösungen für die Verwaltung der Benutzer. In den meisten Fällen erfordert die Anwendung dazu vor der Nutzung die Erzeugung eines Benutzeraccounts und generiert für alle Benutzer bei der Registrierung Benutzername und Passwort, um diese Benutzer bei zukünftigen Transaktionen wieder eindeutig zu identifizieren und zu authentifizieren. Vor- und Nachteile Vorteile Anwendung/Dienst hat die volle Kontrolle über die Verwaltung der Benutzer Nachteile Fehlende Skalierbarkeit in Service-orientierten Architekturen Benutzer müssen sich bei jedem Dienst separat anmelden Explosion der Benutzeraccounts kostenintensive und zeitaufwendige Registrierungsprozesse Das Hauptproblem des anwendungsspezifischen Identitätsmanagements bei der Verwendung in einer Service-orientierten Architektur ist die fehlende Skalierbarkeit. Service-orientierte Architekturen stellen eine offene Umgebung dar, in der komplexe Funktionen als Komposition von Diensten realisiert werden und Aspekte wie die Wiederverwendbarkeit von Diensten oder das Late Binding von Diensten wichtige Kriterien darstellen. Dementsprechend können Dienste von einer Vielzahl von Benutzern verwendet werden, die darüber hinaus dem Dienst nicht zwangsläufig im Vorfeld bekannt sein müssen. Das anwendungsspezifische Identitätsmanagement erfordert jedoch, dass sich jeder Benutzer eines Dienstes zuvor bei diesem registriert, was bei einer Vielzahl von Benutzern, insbesondere, wenn diese aus verschiedenen Vertrauensdomänen kommen, zu einer Explosion der Benutzeraccounts und 220

221 steigenden Wartungskosten führt. Hinzu kommt, dass Registrierungsprozesse kostenintensiv und zeitaufwendig sind, insbesondere, wenn diese so sicher gestaltet sein müssen, dass ein Missbrauch der Ressourcen, die man schützen will, nahezu ausgeschlossen ist. Einsatzszenarien Während innerhalb homogener Netzwerke das anwendungsspezifische Identitätsmanagement mittlerweile nur noch sehr selten Verwendung findet, so ist das Internet außerhalb geschlossener Unternehmensgrenzen noch immer ein Netzwerk aus unabhängigen, isolierten Identitätsmanagementlösungen; oftmals auch als Identitätsinsel bezeichnet. Beispiele hierfür sind populäre Anwendungen oder Webseiten wie Amazon, Ebay oder Facebook, die alle ihre Benutzer selbst verwalten und bei denen sich jeder, der die Anwendungen nutzen möchte, zuvor in der entsprechenden Domäne registrieren muss. Technologien Technologien zur Umsetzung des anwendungsspezifischen Identitätsmanagements sind klassische Benutzerdatenbanken, in denen für jeden Benutzer ein Account gespeichert ist. Die Anmeldung am System erfolgt zumeist über Passwortverfahren. Genauso wie die Verwaltung der digitalen Identitäten übernimmt der Dienst auch die Zugriffskontrolle Zentralisiertes Identitätsmanagement Definition Beim zentralisierten Identitätsmanagement gibt es genau eine zentrale Verwaltung der Benutzer, auf die alle Anwendungen bzw. Dienste zugreifen. Abbildung 77: Prinzip der zentralisierten Verwaltung von Identitäten Beschreibung Multi-User Betriebssysteme waren unter den ersten Systemen, welche ein zentralisiertes Identitätsmanagement boten. Anders als das anwendungsspezifische Identitätsmanagement trennt das zentralisierte Modell die Verwaltung der Identitäten von den Anwendungen, das heißt, die Verwaltung der Identitäten wird von einer separaten Instanz übernommen und von den Anwendungen, die diese Identitätsinformation konsumieren, getrennt. 221

222 Vor- und Nachteile Vorteile Erlaubt Single-Sign-On über mehrere Anwendungen Dienste müssen kein Identitätsmanagement implementieren, sondern lediglich bestehende Identitätsmanagementsysteme integrieren Nachteile Anwendungen sind an die zentrale Verwaltung der Benutzer gebunden Single-Point of Failure Alle Anwendungen müssen der zentralen Benutzerverwaltung vertrauen Mit der Trennung von Benutzerverwaltung und Anwendung ergeben sich zwei wesentliche Vorteile. In erster Linie müssen sich Anwendungsentwickler nicht mehr um die Implementierung einer kompletten Verwaltung von Identitäten kümmern, sondern müssen ihre Anwendungen lediglich mit einem bestehenden Identitätsmanagementsystem integrieren. Der Nachteil hierbei ist allerdings, dass die Anwendungen eingeschränkt sind auf die Fähigkeiten und Datenmodelle des Identitätsmanagementsystems, das sie nutzen. Der zweite große Vorteil des zentralisierten Identitätsmanagements ist das Single-Sign-On. Da die Verwaltung der Identitäten zentriert erfolgt, müssen sich Benutzer innerhalb einer Domäne für gewöhnlich nur einmal anmelden, um eine ganze Reihe von Anwendungen nutzen zu können. Ein weiterer Faktor, welcher beim zentralisierten Ansatz eine wichtige Rolle spielt, ist Vertrauen (vgl Kapitel 6.3 Trust Management). Während der Benutzer beim anwendungsspezifischen Modell jeweils einer Anwendung vertrauen muss, seine Identitätsinformation sicher zu behandeln, so muss er beim zentralisierten Modell einer ganzen Domäne vertrauen. Dies ist einfach in einer beschränkten Umgebung eines einzelnen Rechners. Es funktioniert auch noch in einem Unternehmensnetzwerk, in dem der Benutzer (Arbeitnehmer) keine wirkliche Wahl hat. Jedoch in einer offenen Welt wie dem Internet bildet jede Organisation im Allgemeinen eine eigene Vertrauensdomäne und ist ggf. unwillig jemandem außerhalb der eigenen Domäne zu vertrauen. Ein Beispiel, welches zeigt, wie wichtig das Vertrauen der Benutzer in den Verwalter ihrer Benutzerdaten ist, liefert Microsoft Passport (später.net Passport, nun Windows Live ID). Microsoft Passport zielte darauf ab, ein internetweites, zentralisiertes Identitätsmanagement für Benutzer und Internetanwendungen bereitzustellen. Jedoch übertraf die Anzahl der Nutzer kaum die Anzahl der MSN Nutzer, die automatisch einen Passport Account zugewiesen bekamen. Die damaligen Erfahrungen führten zu einer Weiterentwicklung des Systems zu Information Card und Cardspace, welches nun ein Beispiel für die Verwendung des benutzerzentrischen Modells darstellt. Einsatzszenarien Zentralisiertes Identitätsmanagement findet vor allem innerhalb einer Vertrauensdomäne wie einem einzelnen Unternehmen Anwendung, da es verlangt, dass alle Parteien Vertrauen in den Verwalter der digitalen Identitäten haben. Dieses Vertrauen in Umgebungen, die mehrere Vertrauensdomänen umfassen, zu etablieren, ist sehr schwierig wie das Beispiel Microsoft Passport gezeigt hat. Innerhalb eines Unternehmens bietet das zentralisierte Identitätsmanagement allerdings erhebliche Vorteile, da die Verwaltung der Mitarbeiter an 222

223 einer zentralen Stelle durchgeführt werden kann, und wird von den meisten Unternehmen auch so eingesetzt. Technologien Innerhalb einer Vertrauensdomäne wie einem einzelnen Unternehmen ist das Identitätsmanagement üblicherweise über ein Verzeichnis zentralisiert (beispielsweise Active Directory mit Kerberos zur Authentifizierung). Neben Kerberos, welches zusammen mit den Web Service-Technologien verwendet werden kann, können weitere Formate für die Übertragung und Abfrage von Identitätsinformationen wie z.b. SAML Verwendung finden Föderatives Identitätsmanagement Definition Das förderative Identitätsmanagement vereint mehrere administrativ unabhängige Identitätsmanagementsysteme in einem Vertrauenszirkel, in dem Identitätsinformationen ausgetauscht und gemeinsam genutzt werden können. Abbildung 78: Prinzip des föderativen Identitätsmanagements Beschreibung Das Internet ist aus gutem Grund eine Umgebung von zumeist isolierten Vertrauensdomänen mit eigenständigen Identitätsmanagementlösungen. Isolation erlaubt es Organisationen die Kontrolle über ihre Identitätsmanagementlösungen zu bewahren. Da Organisationen oftmals 223

224 sehr unterschiedliche rechtliche Anforderungen und Sicherheitsrichtlinien (siehe Kapitel 5.1 und Kapitel 6.2) haben, ist es mitunter sehr problematisch, diese Kontrolle aufzugeben. Zudem besitzt jedes Unternehmen eine existierende Identitätsmanagementinfrastruktur, welche über Jahre gewachsen ist und in der Regel nicht so einfach ersetzbar ist. Um dennoch effizient mit Partnern und Kunden zusammenzuarbeiten, verfolgt das föderierte Identitätsmanagement das Konzept der Schaffung einer Föderation (Vertrauenszirkel), in der Identitätsinformation, die in verschiedenen Unternehmen gehalten werden, von allen gemeinsam genutzt werden können. Das wichtige dabei ist, dass jeder Teilnehmer der Föderation (beispielsweise Unternehmen, Behörden, akademische Institutionen) die Kontrolle über sein Identitätsmanagementsystem behält. Deshalb werden die existierenden Systeme durch Funktionalitäten ergänzt, die es erlauben digitale Identitäten (Accounts) zwischen den Identitätsmanagementsystemen zweier Teilnehmer der Föderation zu verlinken. Bestimmte Aufgaben des Identitätsmanagements wie die Authentifizierung von Benutzern oder die Bereitstellung von Informationen über einen bestimmten Benutzer werden von dem Föderationsmitglied übernommen, bei dem der Benutzer registriert ist. Wird diese Information von einem anderem Mitglied in der Föderation benötigt, so kann vom Identitätsmanagementsystem eine Bestätigung in Form eines Sicherheitstoken ausgegeben werden, welches bestimmte Benutzerattribute enthält, beispielsweise, ob ein Benutzer authentifiziert wurde, welchen Benutzernamen er besitzt oder was seine aktuelle Rolle im Unternehmen ist. Dieses Sicherheitstoken wird dann zum anderen Teilnehmer gesendet und dort ausgewertet. Dabei spielt das Vertrauen zwischen den Teilnehmern einer Föderation eine entscheidende Rolle. Um den Aussagen in dem Token Glauben zu schenken, muss das abhängige Föderationsmitglied dem Aussteller des Tokens vertrauen. Dafür sind zumeist umfassende Verträge von Nöten, die das Risiko für alle Beteiligten gering halten (vgl. Kapitel 6.3 Trust Management). Vor- und Nachteile Vorteile Erlaubt ein Unternehmensüber- greifendes Single-Sign-On bestehende Identitätsmanagementlösungen können integriert werden Nachteile Schutz der Privatsphäre des Benutzers erfordert zusätzliche Mechanismen Kompromittierung eines Accounts erlaubt dem Angreifer Zugriff auf alle föderierten Accounts Föderatives Identitätsmanagement ermöglicht Single-Sign-On über mehrere Unternehmen. Um SSO Funktionen zu nutzen, hat der Benutzer die Möglichkeit, seine Accounts in verschiedenen Unternehmen zu verbinden. Einmal authentifiziert, kann er auf alle verlinkten Accounts zugreifen, unabhängig davon, ob er diese im eigenen Unternehmen oder in einem Partnerunternehmen hat. Je mehr Unternehmen an der Förderation beteiligt sind, desto mehr Möglichkeiten für SSO bieten sich natürlich dem Benutzer. Ein wesentlicher Aspekt des föderativen Modells ist der verminderte Schutz der Privatsphäre des Benutzers. Der Verwalter einer digitalen Identität (Identitätsprovider) innerhalb einer Föderation weiß unter Umständen genau, auf welche Anwendungen der Benutzer zugreift. Zudem erlaubt das Linken von Accounts einen relativ großen Handlungsspielraum. Sollte ein Benutzer seine Credentials verlieren z.b. ein Angreifer erlangt Kenntnis des Benutzernamens und des Passworts eines Benutzers, so könnte dieser nicht nur Zugriff zu 224

225 Anwendungen im eigenen Unternehmen erlangen, sondern zu allen Anwendungen der Unternehmen, die mit diesem Unternehmen föderiert sind. Einsatzszenarien Föderatives Identitätsmanagement findet, bedingt durch die engen vertraglichen Bindungen, die einer Föderation zugrunde liegen, vor allem in Business-to-Business Szenarien Anwendung. In solchen Szenarien besitzen zwei Partnerunternehmen im Allgemeinen eine Identitätsmanagementinfrastruktur, welche fest ist und nur schwer ersetzt werden kann. Hat man nun einen unternehmensübergreifenden Geschäftsprozess, der mit Hilfe einer SOA umgesetzt wird, so bieten die Web Service Spezifikationen, wie beispielsweise WSFederation, die Möglichkeit einer föderativen Verwaltung der am Geschäftsprozess beteiligten digitalen Identitäten. Das heißt, wenn beispielsweise ein Mitarbeiter im Rahmen eines gemeinsamen Projektes auf eine Ressource im Partnerunternehmen zugreifen möchte, so muss er sich dafür nicht neu beim Partnerunternehmen registrieren, sondern kann sich wie gewohnt im eigenen Unternehmen authentifizieren. Die zugrunde liegende Föderationsinfrastruktur basierend auf einer SOA sorgt dafür, dass der Mitarbeiter auch in der fremden Vertrauensdomäne authentifiziert wird. Technologien Wie bereits erwähnt, ist das föderative Identitätsmanagement aus der Motivation entstanden, die Verwaltung digitaler Identitäten in Service-orientierten Architekturen über Unternehmensgrenzen miteinander zu verbinden. Damit Identitätsinformationen interoperabel zwischen Partnern ausgetauscht werden können, haben sich in der Vergangenheit insbesondere zwei große Initiativen geformt, die das Ziel verfolgen, einen Standard für föderatives Identitätsmanagement zu schaffen. Im Ergebnis finden sich heute auf der einen Seite die Spezifikationen der Liberty Alliance mit SAML 2.0 als Standard (vgl. Kapitel ) und auf der anderen Seite die WS-Federation Spezifikation (vgl. Kapitel ), welche durch Microsoft und IBM entwickelt wurde Benutzerzentrisches Identitätsmanagement Definition Beim benutzerzentrischen Identitätsmanagement wird die Identität des Benutzers an verschiedenen Stellen (bei so genannten Identitätsprovidern) verwaltet. Beim Aufruf eines Dienstes wählt der Benutzer, von welchem Identitätsprovider die Informationen kommen sollen, die der Dienst benötigt. 225

226 Abbildung 79: Prinzip des benutzerzentrischen Identitätsmanagements Beschreibung Benutzerzentrisches Identitätsmanagement verfolgt einen Ansatz für die Verwaltung digitaler Identitäten, welcher sehr ähnlich zu dem in der realen Welt ist. Im täglichen Leben besitzt jeder einzelne eine Reihe von Ausweisen, sei es der Führerschein, Mitarbeiterausweis oder die Kundenkarte, um bestimmte Aussagen über sich zu beweisen. Zum Beispiel nutzen wir den Führerschein, um zu beweisen, dass wir Auto fahren dürfen oder den Mitarbeiterausweis als Beweis, dass wir Mitarbeiter eines bestimmten Unternehmens sind. All diese Ausweise werden von verschiedenen Behörden oder verwaltenden Stellen ausgegeben. Genau auf diese Art und Weise funktioniert auch das benutzerzentrische Identitätsmanagement. Jeder Benutzer kann sich bei einer Reihe von Identitätsprovidern seiner Wahl registrieren, von denen er eine Art Ausweis, ein so genanntes Sicherheitstoken, ausgestellt bekommt. Dieses Token kann er verwenden, um sich bei Anwendungen oder Diensten seiner Wahl zu authentifizieren. Vor- und Nachteile Vorteile Erlaubt ein Unternehmensüber- greifendes Single-Sign-On bestehende Nachteile Im allgemeinen keine vertraglichen Bindungen Vertrauen ist schwerer zu etablieren Identitätsmanagementlösungen können integriert werden Benutzer steht im Zentrum der Interaktion und hat die Kontrolle, wer seine privaten Daten bekommt Spezifisch für das benutzerzentrische Identitätsmanagement ist, dass der Benutzer im Zentrum jeglicher Interaktion und Entscheidung steht, welches die Gefahr der Auswertung 226

227 der Benutzerdaten für schädliche Zwecke, wie beim föderativen Modell beschrieben, minimiert. Beim benutzerzentrischen Modell ist es sogar so, dass der Identitätsprovider die abhängige Partei normalerweise gar nicht kennt. Nur die abhängigen Parteien kennen den Identitätsprovider des Benutzers und entscheiden, ob sie diesem trauen oder nicht. Anders hätten sie gar keine Basis, um eine Entscheidung auf Grundlage der Information, welche sie über den Benutzer zugeschickt bekommen, zu treffen. Einsatzszenarien Bedingt durch die eher dynamischen Vertrauensbeziehungen zwischen dem Identitätsprovider und einem abhängigen Partner, findet das benutzerzentrische Identitätsmanagment eher Anwendung außerhalb von Business-to-Business Szenarien. Es eignet sich insbesondere dort, wo gar keine vertraglichen Beziehungen denkbar wären, wie z.b. zwischen einem Online Shop und dem Staat. In diesem Fall tritt der Staat als Identitätsprovider auf, welchem der Online Shop vertraut, ohne mit diesem in einer Vertragsbeziehung zu stehen. Ebenso hat der Benutzer eine Vertrauensbeziehung mit dem Staat, der dessen Identitätsdaten verwaltet. Das Vertrauen zwischen dem Benutzer und dem Online Shop wird damit indirekt über die Vertrauensbeziehung Benutzer-Staat und StaatOnline Shop etabliert. (vgl. auch Kapitel 6.3 Trust Management). Ebenso eignet sich das dezentrale Identitätsmanagement für Szenarien, in denen keine starke Identität des Benutzers gebraucht wird und damit die Frage nach der Etablierung von Vertrauen leichter beantwortet werden kann. Beispiele für mögliche Einsatzgebiete stellen Web 2.0 Anwendungen, wie FaceBook, Xing oder flikr dar, die allerdings bisher die Identitäten ihrer Benutzer isoliert verwalten. Technologien Technologien im Bereich des benutzerzentrischen Identitätsmanagements sind insbesondere auf offene Umgebungen wie das Internet ausgelegt. Populäre Technologien, die in diesen Bereich fallen, sind OpenID und InformationCard, welche in Kapitel genauer vorgestellt werden Zusammenfassung Bisherige Erfahrungen haben gezeigt, dass ein Identitätsmanagement für offene, dezentrale Umgebungen wie das Internet und SOA nur Erfolg haben kann, wenn es bestehende Lösungen nicht durch ein umfassendes, einheitliches System zu ersetzen versucht, sondern Interoperabilität zwischen verschiedenen Identitätsmanagementlösungen schafft. Sobald man die administrative Domäne eines einzelnen Unternehmens verlässt, zeigen sich erhebliche Nachteile der traditionellen Identitätsmanagementmodelle wie dem anwendungsspezifischen und dem zentralisierten Identitätsmanagement. Neue, offene Identitätsmanagementlösungen, wie das föderative und das benutzerzentrische Identitätsmanagement, adressieren diese Probleme und sind speziell für die heterogene, offene Natur einer SOA geschaffen. Beide Modelle basieren auf der Idee, dass digitale Identitäten durch mehrere Systeme verwaltet werden können, die es zu verbinden gilt. Im Vergleich zum föderativen Identitätsmanagement steht jedoch beim benutzerzentrischen Modell der Benutzer im Zentrum der Interaktion und übernimmt eine wesentlich bestimmendere Rolle. Er wählt, welchen Identitätsprovider er nutzen möchte und hat die volle Kontrolle darüber, wer welche persönlichen Daten bekommt. Im föderativen Modell dagegen ist der Benutzer eher passiv und hat lediglich die Wahl, ob er bestimmte Accounts miteinander verbinden möchte oder nicht. Die Auswahl dieser Accounts dagegen ist durch die vertraglichen Beziehungen im Hintergrund vorgegeben. 227

228 Auf der anderen Seite stellen diese vertraglichen Verbindungen beim föderativen Identitätsmanagement eine gute Basis für die Etablierung von Vertrauen dar, da das Risiko von Missbrauch durch vertragliche Bindungen reduziert werden kann. Beim benutzerzentrischen Modell bestehen im Allgemeinen keine vertraglichen Beziehungen zwischen zwei Partnern. Stattdessen entscheidet die abhängige Partei, welchen Partnern sie vertrauen möchte. Damit sind die Vertrauensbeziehungen hier wesentlich dynamischer. Die Partei, der vertraut wird, weiß oftmals gar nicht, wer ihr alles vertraut Das Identity Metasystem Wie bereits festgestellt, kann ein Identitätsmanagementsystem für dezentrale Umgebungen wie Service-orientierte Architekturen nur Erfolg haben, wenn es nicht versucht, bestehende Lösungen zu ersetzen, sondern diese zu integrieren. Beide offenen Identitätsmanagementmodelle, das föderative genauso wie das benutzerzentrische, verfolgen genau dieses Ziel. Sie verbinden verschiedene Identitätsmanagementlösungen, indem sie eine Art Meta-Identitätsmanagementsystem über existierende Identitätsmanagementsysteme bilden. Damit dies funktioniert, muss ein solches Metasystem von konkreten Implementierungen abstrahieren und zwischen verschiedenen Technologien übersetzen können. Das Identity Metasystem stellt genau diese Abstraktionsschicht dar. Es beschreibt Konzepte, die allen Identitätsmanagementsystemen gemein sind, in einem interoperablen Format und verbirgt die technologiespezifischen Details der einzelnen Systeme (so wie es beispielsweise auch bei IP über Ethernet und Token Ring geschieht). Die Web Service Spezifikationen sind in besonderer Weise dafür geeignet, ein solches Identity Metasystem zu implementieren, da sie mit SOAP als interoperabler Sprache bereits ein Format bieten, welches plattform- und technologieunabhängig verstanden wird. Wie diese Umsetzung durch die Web Service Standards genau geschieht und damit die Grundlage für die oben beschriebenen offenen Identitätsmanagementmodelle bildet, beschreibt der nachfolgende Abschnitt Die Abstraktionen, die das Identity Metasystem liefert, sind zum einen eine Beschreibung der Rollen, die in jedem Identitätsmanagementsystem vorkommen, und zum anderen eine allgemeine Beschreibung von Identitätsinformationen als Satz von Behauptungen, so genannten Claims. Ein Claim ist eine Behauptung über eine Person oder Entität, welche diese Person über sich selbst macht oder die von einer anderen Entität gemacht wird, wie z.b. das den Mitarbeiter verwaltende Unternehmen. Ein Claim bezieht sich auf ein bestimmtes Attribut einer Person, z.b. Ich bin über 18 Jahre alt, Alice kennt den symmetrischen Schlüssel oder Meine Kreditkartennummer lautet Jedes Attribut wird durch einen eindeutigen Bezeichner, eine URI, gekennzeichnet, welcher von Anwendungen verwendet werden kann, um auf die von ihnen benötigten Attribute zu verweisen. 228

229 Abbildung 80: Rollen und Beziehungen im Identity Metasystem Bei den Rollen unterscheidet das Identity Metasystem zwischen den drei in Abbildung 80 dargestellten Rollen: den Konsumenten der Identitätsinformation (die so genannte abhängige Partei), die Verwalter der Identitätsinformationen (die so genannten Identitätsprovider), und den Client. Die abhängige Partei ist ein Dienst oder eine Anwendung, welche eine Menge an Benutzerattributen benötigt, um eine bestimmte Funktion auszuführen. Statt diese Benutzerattribute selbst zu verwalten, erlaubt diese abhängige Partei einem Benutzer sich bei einem bekannten und vertrauten Identitätsprovider zu authentisieren, welcher dann die benötigten Informationen zur Verfügung stellt. Der Identitätsprovider ist die Komponente, welche die digitale Identität eines Benutzers verwaltet, d.h. bei der der Benutzer seinen Account registriert hat. Nach der erfolgreichen Registrierung eines Benutzers kann dieser sich vom Identitätsprovider eine so genannte Information Card ausstellen lassen. Information Cards stellen den Link zwischen einem Identitätsprovider und einem Benutzer dar und enthalten eine Auflistung aller Attribute, die der Identitätsprovider beglaubigt bestätigen kann. Basierend auf den Rollen und der Beschreibung der Identitätsinformationen als Claims beschreibt das Identity Metasystem zudem abstrakt die Prozesse, die in einem Identitätsmanagementsystem ablaufen. Im Detail umfasst dies 1. die Definition der benötigten Claims (Identitätsinformationen), 2. das Finden eines geeigneten Identitätsproviders und 3. die Übertragung dieser Identitätsinformationen als Sicherheitstoken vom Identitätsprovider zu der Anwendung, die sie benötigt Die Umsetzung des Identity Metasystems durch die Web Service Technologien Die Implementierung des Identity Metasystems durch die Web Service Spezifikationen bildet die Grundlage für die offenen Identitätsmanagementmodelle. Insbesondere die Spezifikationen SAML, WS-Trust, WS-Policy und WS-SecurityPolicy beschreiben die Protokolle und Formate, um Identitätsinformationen zwischen den einzelnen Teilnehmern einer SOA zu kommunizieren. 229

230 Das Zusammenspiel der Spezifikationen lässt sich am besten in einem Beispielszenario zeigen. Nehmen wir an, dass Alice für das Unternehmen A arbeitet und dementsprechend einen Mitarbeiteraccount besitzt, in dem ihre Position, ihr Name, ihre Geschäftsadresse und weitere Daten gespeichert sind. Das Unternehmen A besitzt einen Identitätsprovider, welcher einen Dienst anbietet, der auf Anfrage für die Mitarbeiter Sicherheitstoken ausstellen kann, die zum Beispiel die Postion oder den Namen von Alice beinhalten. Der Standard WS-Trust (vgl. Kapitel 4.5.3) spezifiziert dazu das Interface eines Identitätsproviders, der Identitäten als Dienst anbietet, indem er Sicherheitstoken ausstellen kann, um die Authentifizierung eines Benutzers oder bestimmte Claims zu attestieren. Möchte Alice nun auf einen Dienst zugreifen, so muss sie wissen, welche Claims der Dienst erwartet. Dazu veröffentlicht dieser Dienst seine Anforderungen als Teil der Dienstbeschreibung. Die hier zum Einsatz kommenden WS-Spezifikationen sind insbesondere WS-Policy (vgl. Kapitel 6.2 Policy Management) und WS-MetadataExchange. WS-Policy beschreibt die Anforderungen eines Dienstes während WS-MetadataExchange genutzt werden kann, um diese Anforderungen zwischen dem Dienst und Alices Client zu kommunizieren. Der Client wertet schließlich die Informationen im WS-Policy Dokument aus und gleicht sie mit Alices Identitätsprovidern ab. Anschließend formuliert der Client eine Anfrage für ein Sicherheitstoken an den von Alice gewählten Identitätsprovider basierend auf dem von WS-Trust definierten Protokoll. Der Identitätsprovider antwortet mit einem Sicherheitstoken, welches er wiederum in eine WS-Trust Nachricht verpackt. Für die Beschreibung des Sicherheitstokens kommt üblicherweise die Security Assertion Markup Language (SAML) zum Einsatz Identitätsmanagementstandards und -technologien Nachdem mit der Beschreibung der Identitätsmanagementmodelle bereits die wichtigsten Technologien und Standards eingeordnet worden sind, betrachtet dieses Kapitel nochmal einige ausgewählte Standards und Technologien genauer WS-Federation WS-Federation ist neben SAML 2.0 die wichtigste Spezifikation, welche Protokolle und Mechanismen für föderatives Identitätsmanagement beschreibt. Eine Implementierung der Spezifikation bietet beispielsweise das.net Framework von Microsoft. WS-Federation wird umfassend in Kapitel beschrieben. Kurz zusammengefasst, basiert WS-Federation auf den Spezifikationen des WS-*-Protokoll Stacks und definiert zusätzliche Mechanismen, die in föderativen Szenarien nötig sind. Dazu gehören zum Beispiel Mechanismen und Protokolle zum: Account Linking Austausch von Föderationsmetadaten Pseudonymmanagement Benutzermapping föderationsweites Single-Sign-On föderationsweites Single-Sign-Out 230

231 Darüber hinaus beschreibt und diskutiert die Spezifikation verschiedene Föderationsszenarien Liberty Alliance und SAML 2.0 Die Liberty Alliance ist ein Konsortium aus mehreren Hundert Partnern, welches das Ziel verfolgt eine umfassende Lösung für föderatives Identitätsmanagement zu entwickeln. Unter den Partnern (ca. 300) sind marktführende Unternehmen aus der Informationstechnologie, dem Finanzsektor, der Telekommunikation, den Medien sowie Regierungsorganisationen. Das Ergebnis der Arbeit der vergangenen Jahre ist eine ganze Reihe von relativ fortgeschrittenen Spezifikationen, Implementierungsrichtlinien und Best Practice Beschreibungen. Die Spezifikationen adressieren insbesondere Aspekte für den Aufbau von Föderationsinfrastrukturen für Service-orientierte Architekturen. In erster Linie: Spezifikationen für die Föderation von Identitäten (Account Linking, Transfer von Identitätsinformationen über Unternehmensgrenzen) Spezifikationen für identitätsbasierte Web Services (Liberty Identity Web Services Framework (ID-WSF)) Spezifikationen von Standard Web Services, welche häufig in Unternehmensarchitekturen vorkommen, die förderatives Identitätsmanagement verwenden. Beispiel sind Kalender, Profil oder Geo-Location Services Die Liberty Alliance baut im Wesentlichen auf SAML als Protokoll und Format für den Austausch von Identitätsinformationen (vgl. Kapitel 4.4.3) auf. Teile der Liberty Spezifikationen sind in die Version 2.0 des SAML Standards eingeflossen. Ein grundlegendes Konzept in den Spezifikationen der Liberty Alliance ist der Circle of Trust (Vertrauenszirkel), welcher den Zusammenschluss verschiedener Partner basierend auf der Liberty Architektur und operationalen Vereinbarungen, die die Vertrauensbeziehung zwischen den Partnern manifestieren, beschreibt. Innerhalb dieses Circle of Trust kann ein Benutzer seine digitalen Identitäten verbinden, um so ein Single Sign-On zwischen seinen Accounts zu erreichen. Der Prozess der Förderation von Identitäten geschieht komplett basierend auf dem SAML 2.0 Protokoll, welches in Kapitel 6.4 beschrieben ist. Darüber hinaus definiert die Liberty Alliance weitere umfassendere Konzepte, welche über die Authentifizierung und Single-Sign-On hinaus gehen. Ein großer Teil der Spezifikationen definiert Web Services, welche auf der Identität eines Benutzers operieren. So können bestimmte Ressourcen des Benutzers, wie ein persönliches Profil, sein Kalender oder die Liste seiner Lieblingsmusik, als Web Service angeboten werden. Diese können dann von anderen Web Services abgefragt werden (vorausgesetzt, die anfragende Partei besitzt die entsprechenden Rechte). Liberty betrachtet hierbei insbesondere auch den Fall der Delegation von Zugriffsrechten, welche vom Besitzer einer Ressource an denjenigen weitergeben werden können, der diese Ressource nutzen möchte. Möchte also ein Web Service auf einen anderen Service zugreifen, welcher Ressourcen des Benutzers bereitstellt, so kann vom Identitätsprovider des Benutzers ein Zugriffstoken ausgegeben werden. Dieses kann weitergegeben werden und erlaubt dem Besitzer des Tokens im Auftrag des Benutzers zu handeln. Oftmals erfordern derartige Delegations-Szenarien eine Rückfrage beim Benutzer, ob dieser mit der Herausgabe seiner Informationen einverstanden ist. Verwendet man Delegation, besteht jedoch in vielen Fällen keine direkte Verbindung vom Service Provider zum Benutzer. Die Liberty Alliance löst dieses Problem, indem sie einen Interaction Service 231

232 definiert, welcher im Rahmen des Identity Web Service Frameworks beschrieben wird. Dieser Interaction Service übernimmt die Kommunikation mit dem Benutzer und unterstützt dabei vielfältige Kommunikationskanäle wie SMS, oder eben SOAP Information Cards und CardSpace Information Card ist Microsofts Ansatz für eine interoperable Architektur zur Verwaltung und Verwendung von digitalen Identitäten und stellt eine spezifische Ausprägung des Identity-Metasystems dar. Die Identitätsinformationen eines Benutzers werden von einem Identitätsprovider, dem der Benutzer vertraut, verwaltet und können von diesem bei Bedarf bestätigt werden. Entsprechend den Sicherheitsanforderungen einer abhängigen Partei kann der Benutzer beim Zugriff auf den Dienst eine entsprechende Sicherheitsbestätigung von einem der Identitätsprovider abrufen und mitgeben. Für die Wahl eines geeigneten Identitätsproviders schreibt Information Card eine Komponente vor, welche diese Aufgabe für alle Anwendungen übernimmt. Diese Komponente wird Identity Selector genannt und wurde bereits für verschiedene Plattformen implementiert. Die Implementierung von Microsoft ist CardSpace. Sie ist in Windows Vista und Windows XP mit.net 3.5 integriert. Für eine einfache Benutzerführung orientiert sich CardSpace an der Verwaltung von Identitäten im täglichen Leben. Wird eine Person nach ihrer Identität gefragt wird, so identifiziert sich diese üblicherweise über eine Karte (beispielsweise in Form einer Visitenkarte oder eines Ausweises.) Dies imitiert CardSpace durch die Verwendung einer Benutzeroberfläche, die eine Reihe von Visitenkarten darstellt, aus denen der Benutzer auswählen kann. Benutzt wird Cardspace wie folgt: 1. Bei der Erstellung eines Accounts bei einem Information-Card-fähigen Identitätsprovider erhalten Anwender eine Information-Card in Form einer XMLDatei. 2. Der Anwender kann diese Karte in CardSpace importieren. Jede Karte dient als Referenz auf den Identitätsprovider und speichert die Informationen (Claims) über den Benutzer, die der Identitätsprovider bereitstellen kann. 3. Sobald ein Benutzer auf einen Dienst zugreift wird von der Client-Software CardSpace aufgerufen und die Anforderungen an die benötigten Claims übergeben. Im Internet Explorer ist diese Funktion bereits integriert. 4. CardSpace erscheint auf dem Bildschirm und zeigt dem Anwender einen Satz von Karten an, welche die Anforderungen erfüllen können. 5. Der Anwender selektiert einen Identitätsprovider seiner Wahl, von welchem sich CardSpace das Token holt, um es an die Clientanwendung zurückzuliefern. 6. Die Client-Software kann im Anschluss den Dienst mit diesem Token aufrufen. Nachteile von Information Cards and CardSpace Information Cards ist das Ergebnis einer umfassenden Analyse der Voraussetzungen, die ein Identitätsmanagementsystem erfüllen muss, um von Benutzern als sicher und vertrauenswürdig eingestuft zu werden. Das Resultat dieser Analyse bilden die "Laws of Identity" [Cameron2005], welche in Information Cards umgesetzt wurden. Damit verbunden ist jedoch auch eine höhere Komplexität. Beispielsweise fordern die Laws of Identity eine 232

233 einheitliche Oberfläche für die Auswahl und Verifikation einer digitalen Identität, d.h. die Authentifizierung beim Identityprovider sollte nicht durch jede Anwendung separat erfolgen, sondern durch ein einheitliches Benutzerinterface. Dies macht das Vorhandensein einer neuen, zusätzlichen Komponente auf dem Host des Benutzers notwendig. Diese Komponente, der Identity Selector, dient der Auswahl einer digitalen Identität aus einer Reihe verfügbarer Identitäten durch den Benutzer. Da der Identity Selector die Kommunikation mit dem Identityprovider durchführt, z.b. auch den Austausch der Authentifizierungsinformationen, muss dieser vertrauenswürdig sein und sollte nach Möglichkeit zertifiziert sein. Aktuell gibt es bereits mehrere Implementierungen für einen solchen Identity Selector, so dass der Benutzer hier frei wählen kann, welcher Implementierung er vertrauen möchte OpenID OpenID stammt aus der Open-Source Community und war ursprünglich entwickelt worden, um Spam-Einträge in Blogs zu unterbinden. Es bietet ein sehr leichtgewichtiges Webbasiertes Protokoll für die Authentifizierung von Benutzern im Internet. Dabei wird jeder Benutzer durch eine eindeutige URL identifiziert. Diese URL enthält neben der eindeutigen Benutzerkennung auch die Adresse des Identitätsproviders, bei dem der Benutzer seinen Account hat. Um sich mit OpenID zu authentifizieren, gibt der Benutzer seine OpenID URL bei der Webseite ein, bei der er sich einloggen möchte (= Relying Party). Diese identifiziert den Identitätsprovider des Benutzers und etabliert eine direkte Verbindung mit diesem, indem mit Hilfe des Diffie-Hellmann Verfahrens ein gemeinsamer Schlüssel erzeugt und ausgetauscht wird. Danach leitet die Webseite den Benutzer mit einer Authentifizierungsanfrage auf die Seite seines Identitätsproviders um. Ist der Benutzer bereits durch eine vorhergehende Anfrage authentifiziert (es besteht eine Session beim Identitätsprovider), so kann der Identitätsprovider die Authentifizierung des Benutzers direkt bestätigen. Im anderen Fall fordert er den Benutzer auf sich zu authentifizieren. Wie dies erfolgt, ist nicht Teil des OpenID Protokolls. Üblich sind hier Verfahren wie Benutzername und Passwort, aber auch die Authentifizierung mit Information Cards ist möglich. Mit dem Ergebnis der Authentifizierung wird der Benutzer zurück auf die Seite der Relying Party geleitet. Diese überprüft noch einmal das Ergebnis der Authentifizierung, indem sie die Unterschrift auf dem empfangenen Token mit Hilfe des zuvor ausgetauschten Schlüssels überprüft. Nachteile von OpenID Ein bekanntes Problem von OpenID ist seine Anfälligkeit für Phishing Angriffe. Hierbei wird der Benutzer statt zu seinem eigenen Identitätsprovider zu einer feindlichen Webseite weitergeleitet, die sich als sein Identitätsprovider maskiert, und ihn auffordert sich zu authentifizieren. Gibt der Benutzer nun seine Zugangsdaten ein, so erlangt die feindliche Seite Zugang zu allen Webseiten, auf denen sich der Benutzer mit Hilfe von OpenID einloggen kann. Die Gefahr dieses Angriffes hängt von der Möglichkeit ab, die einem Angreifer geboten wird, sich als der Identitätsprovider des Benutzers auszugeben und Zugang zu den Authentifizierungsinformationen des Benutzers zu bekommen. Während dies bei einer Authentifizierung mit Benutzername und Passwort relativ leicht möglich ist, bietet zum Beispiel die Authentifizierung mit Information Cards einen erfolgreichen Schutz gegen diesen Angriff, da hier die Verbindung des Benutzers mit seinem Identitätsprovider in der Information Card manifestiert ist, die der Benutzer von seinem Identitätsprovider ausgestellt bekommt. 233

234 Ein weiteres Problem, welches oft als Kritik von OpenID angeführt wird, ist die fehlende Privatsphäre des Benutzers. Da der Identitätsprovider alle Webseiten kennt, auf denen sich der Benutzer mit seiner OpenID eingeloggt hat, besteht die Gefahr, dass dieser diese Information nutzt, um ein Profil des Benutzerverhaltens zu erstellen und zum Beispiel für personalisierte Werbung zu verwenden. 6.5 Sichere Dienstkomposition zur Abbildung von Geschäftsprozessen Dieser Abschnitt befasst sich mit der Umsetzung von Sicherheitsanforderungen in Serviceorientierten Architekturen zur Gewährleistung von sicheren und vertrauenswürdigen Geschäftstransaktionen. Diese Sicherheitsanforderungen ergeben sich aus der Summe herkömmlicher Herausforderungen unter Berücksichtigung SOA-spezifischer Besonderheiten. Insbesondere wenn Prozesse einer Geschäftslogik nach außen hin geöffnet werden, werden besondere Sicherheitsanforderungen an die SOA-Implementierung gestellt. Doch auch bei Geschäftsprozessen innerhalb einer Organisation gibt es sicherheitsrelevante Anforderungen, welche in dieser Form in konventionellen IT-Systemen nicht auftreten. Dies betrifft neben der Problematik verteilter Strukturen auch den Austausch von Nachrichten. 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 Teilnehmern mit unterschiedlichen Vertrauensanforderungen verstärkt diese Sicherheitsanforderungen an Services und Lösungen. Die Umsetzung von Geschäftsprozessen durch eine SOA geht einher mit der Orchestrierung und Choreographie von Diensten. Somit sind Dienstkompositionen das Ergebnis der Abbildung von Geschäftsprozessen auf die technische Ebene. In diesem Abschnitt sollen daher grundsätzliche Sicherheitsaspekte in Hinblick auf ihre konzeptionelle und technische Umsetzung zur Absicherung von unternehmensinternen und unternehmensübergreifenden Dienstkompositionen betrachtet werden Orchestrierung und Choreographie von Diensten Eine Orchestrierung von Diensten stellt eine Zusammenschaltung von Diensten gemäß eines Ablaufplans dar, der durch eine Organisation bestimmt und kontrolliert wird. Dabei kann diese Orchestrierung auch Dienste von anderen Organisationen einbinden. Hingegen beschreibt eine Choreographie eine Interaktion von Diensten, die nicht durch eine Instanz kontrolliert wird. Ein Beispiel für die technische Umsetzung einer Orchestrierung von Diensten stellt BPEL dar (vgl. Kapitel 4.9.2). BPEL ermöglicht die Definition eines Workflows basierend auf Web Service-Technologie und erlaubt die zentralisierte Ausführung durch eine BPEL-Engine. Die BPEL-Engine führt den Workflow aus, ruft die dazu notwendigen Dienste auf und stellt den gesamten Workflow wieder als Web Service bereit. Eine Choreographie hingegen kann beispielsweise durch das in Kapitel eingeführte WSCDL beschrieben werden. Somit lässt sich durch die Orchestrierung, aber auch durch die Choreographie von Diensten eine Dienstkomposition beschreiben. Entscheidenden Einfluss auf die möglichen Sicherheitsmaßnahmen und Standards zur Absicherung von einfachen und komplexen 234

235 zusammengesetzten Diensten hat allerdings die Art der Verwendung dieser Dienste. Generell kann eine Dienstkomposition nach zwei Aspekten unterschieden werden: 1. Umfang der Nachrichtenbearbeitung durch einen zusammengesetzten Dienst a) Ausschließliche Verarbeitung der Headerinformationen Ein Dienst dieses Typs arbeitet auf den Headerinformationen einer Nachricht also den Metainformationen über eine Nachricht und lässt die eigentliche Nachricht unberührt. Ein solcher zusammengesetzter Dienst unterstützt somit die gleiche Schnittstelle wie die komponierten Dienste und ist somit gänzlich transparent für den Aufrufer. Beispielsweise könnte ein solcher Dienst: Nachrichten an weitere Dienste weiterleiten und somit als Router zur Lastverteilung fungieren. Bestimmte Header Informationen wie Zeitstempel oder Informationen zur Adressierung in die Nachricht einfügen. Ein Monitoring des Datenflusses inklusive der Fehlerverfolgung ermöglichen. Als Gateway-Service wie im Abschnitt dienen, der dahinter liegende Dienste absichert. b) Verarbeitung von Teilen der Nachricht In dieser Variante liest und arbeitet der Dienst nur auf Teilen der Nachricht. Andere Teile der Nachricht können somit unverändert für den Aufruf von weiteren Diensten verwendet werden. c) Verarbeitung der gesamten Nachricht In diesem Fall operiert der Dienst auf der gesamten Nachricht. Dabei verarbeitet und verändert der Dienst gegebenenfalls sämtliche Nachrichtenteile. 2. Art und Verteilung der komponierten Dienste zur Umsetzung eines Geschäftsprozesses a) Lokale Ausführung und Abbildung eines Geschäftsprozesses In dieser Variante wird ein Geschäftsprozess auf einen Workflow abgebildet, indem Aktivitäten im Prozess durch lokale Komponenten (Java-Beans,.Net-Assemblies, SCA-Komponenten,...) ausgeführt werden. Im einfachsten Fall können diese Aktivitäten auch auf einfache Klassen einer Programmiersprache abgebildet werden. Dieser Prozess kann dann als Web Service in der eigenen Sicherheitsdomäne oder domänenübergreifend bereitgestellt werden und realisiert somit einen monolithischen Dienst. Dennoch kann für die Umsetzung SOA-Technologie zum Einsatz kommen, beispielsweise durch Verwendung eines ESBs mit einer BPEL-Engine oder der Windows Workflow Foundation. Im Fall der Windows Workflow Foundation können die in dem Prozess definierten Aktivitäten beispielsweise durch einfache.net-klassen umgesetzt werden. Eine solche Komposition wird zu.net-code kompiliert, der mittels der Windows Communication Foundation als Dienst bereitgestellt werden kann. Der Vorteil einer solchen Umsetzung liegt in der Performance. Denn durch die Einbindung von lokalen Komponenten wird eine solche Dienstkomposition effizient im Speicher ohne Kommunikationsoverhead ausgeführt, wodurch eine Absicherung der Kommunikationskanäle innerhalb des Workflows hinfällig ist. Da eine solche 235

236 Umsetzung allerdings einen monolithischen Dienst realisiert, können Teile dieses Workflows nicht einfach in anderen Prozessen interoperabel wiederverwendet werden, wodurch die Grundeigenschaften und Vorteile von SOA für eine solche Umsetzung nicht erfüllt werden. Die Umsetzung der Sicherheit würde bei einem solchen Fall bei dem Dienst liegen, der als Web Service den Workflow nach außen anbietet. Die notwendigen Sicherheitsmaßnahmen hierfür hängen von der Art der Verwendung dieses Dienstes und den Sicherheitsanforderungen ab. Abbildung 81: Nutzung von Diensten in einer abgesicherten Umgebung b) Nutzung von Diensten in einer Sicherheitsdomäne In diesem Fall werden Dienste innerhalb einer Sicherheitsdomäne benutzt und nur innerhalb dieser angeboten (beispielsweise die Nutzung und der Konsum von Diensten innerhalb eines Unternehmens). Die Geschäftsprozesse, die durch die Komposition dieser Dienste unterstützt werden, beschreiben damit nur unternehmensinterne Abläufe. Die Aktivitäten in den Prozessen werden somit verteilt umgesetzt, beispielsweise durch Web Services. Die Verwendung von Diensten innerhalb einer Sicherheitsdomäne gehen einher mit einheitlichen Sicherheitsanforderungen für diese Dienste, die sich aus dem GRC (vergleiche Kapitel 5.1) ergeben. Da diese Variante unternehmensinternen Konsum und Offerierung von Diensten darstellt, wird das Vertrauen zwischen den Diensten und den Benutzern, wie im Kapitel beschrieben, etabliert. Abbildung 82: Nutzung von Diensten einer Sicherheitsdomäne c) Nutzung von Diensten aus verschiedenen Sicherheitsdomänen In dieser Variante werden Dienste in einer Dienstkomposition genutzt, die in verschiedenen Sicherheitsdomänen liegen können und ebenfalls verteilt als Web 236

237 Services umgesetzt sind. Beispielsweise könnten Dienste über Unternehmensgrenzen hinaus genutzt werden. Da in dieser Variante Dienste über Sicherheitsgrenzen hinaus konsumiert und offeriert werden, ist die Etablierung von Vertrauen wie im Kapitel beschrieben essentiell. Die Anforderungen und Eigenschaften der Vertrauensbeziehungen haben auch Einfluss auf die Umsetzung der Sicherheitsanforderungen, die sich aus dem GRC (vergleiche Kapitel 5.1) ergeben. Abbildung 83: Nutzung von Diensten in verschiedenen Sicherheitsdomänen Sicherheitsaspekte beim flexiblen Aufruf kooperierender Web Services Die Sicherheitsanforderungen an SOA Infrastrukturen zur Ausführung vertrauenswürdiger Geschäftstransaktionen ergeben sich aus der Summe herkömmlicher Anforderungen unter Berücksichtigung SOA-spezifischer Besonderheiten. Diese Besonderheiten ergeben sich aus der Verwendung und Komposition von Diensten, um Geschäftsprozesse abzubilden, wie sie im vorherigen Abschnitt identifiziert wurden. Diese Muster werden nun aufgegriffen, um für grundsätzliche Sicherheitsanforderungen wie in Kapitel 3.1 vorgestellt die in diesem Kompendium beschriebenen Konzepte einzuordnen und mögliche Standards zu empfehlen Authentifizierung und Identifizierung von Service Consumern In einer Service-orientierten Architektur, in der Geschäftsprozesse auf Dienstkompositionen abgebildet werden und auf verschiedene Art eingebunden und genutzt werden ist es wichtig, dass Dienste nur einem berechtigten Kreis von Service-Consumern bereitgestellt werden. Dies impliziert die Notwendigkeit, dass jeder Dienst die Identität seiner Nutzer verifiziert (Authentifizierung). Die Nutzer eines Dienstes können reale Benutzer sein, die mittels eines Clients auf den Dienst zugreifen, aber auch andere Dienste, die dann über bestimmte Attribute verfügen beispielsweise die URL oder die Zugriffsrechte die dann die digitale Identität dieses Dienstes ausmachen. In jedem Fall muss ein Dienst seine Nutzer authentifizieren und benötigt ggf. noch weitere Identitätsinformationen für die Ausführung seiner Funktionalität. Da es somit vom Dienst abhängig ist, welche Identitätsinformationen benötigt werden, kann ein Dienst seine Anforderungen in einer Sicherheitspolicy ausdrücken (vgl. Abschnitt 6.2 Policy Management). Die Bereitstellung von Identitätsinformationen geschieht üblicherweise über ein Sicherheitstoken, das einen Satz von Aussagen (Claims) hinsichtlich eines 237

238 bestimmten Attributes über einen Nutzer enthält. Ein identitätsbasierter Dienst operiert also immer auf einer Menge von Claims über einen Nutzer, die in Form eines Sicherheitstokens bereitgestellt werden. Diese Sicherheitstokens können beispielsweise Benutzername/Passwort, ein Zertifikat, ein Kerberos-Token oder ein SAML-Token sein. Für die Wahl der richtigen Technologie und des Ansatzes zur Umsetzung der Authentifizierung bei einem Dienst ist zunächst die Art und Größe des Nutzerkreises entscheidend. Wird ein Dienst nur von einem kleinen, festen Kreis von Service Consumern in Anspruch genommen (z.b. bestimmte Anwendungen) oder darf gar nur von einer anderen Instanz aufgerufen werden, beispielsweise einer BPEL-Engine, dann kann der Dienst die Aufrufer direkt authentifizieren, z.b. über die Signatur der Nachricht. Dies ist insbesondere der Fall, wenn der Dienst nicht identitätsbasiert operiert und somit keine Benutzerinformationen wie Rolleninformationen oder Berechtigungen benötigt. Die Interaktion zwischen dem Dienst und seinen Aufrufern realisiert somit eine reine Maschinezu-Maschine-Kommunikation, wobei die Aufrufer direkt authentifiziert werden können. Wird der Dienst jedoch einem großen Kreis von Anwendern verfügbar gemacht oder operiert der Dienst identitätsbasiert, dann sollte der Dienst die Identitäten der Aufrufer nicht mehr selbst verwalten, wie im Abschnitt 6.4 Identitätsmanagement herausgestellt. Stattdessen sollten die Identitäten durch eine dedizierte Instanz den Identity Provider verwaltet werden, der Nutzer authentifizieren und die Authentifizierungsentscheidung sowie zusätzlich benötigte Identitätsinformationen als Claims in Form eines Sicherheitstokens bestätigen kann. Diese Sicherheitstokens können dann verwendet werden, um auf Dienste zuzugreifen. Der Einsatz eines Identity Providers in Kombination mit offenen Standards für die Beschreibung der Sicherheitstokens ermöglicht ein Single-Sign-On und garantiert die Komponierbarkeit von unterschiedlichen Diensten. Um die Authentifizierung und Bereitstellung von Identitätsinformationen in einer Serviceorientierten Architektur konkret umzusetzen, können verschiedene Technologien und Verfahren verwendet werden. Zu unterscheiden ist allerdings zwischen der Authentifizierung bei einem Identity Provider und bei einem Dienst. 1. Authentifizierung bei einem Identity Provider Identity Provider können bestimmte Aussagen über den Service Consumer in Form eines Sicherheitstokens bereitstellen, das dann für den Zugriff auf einen Dienst verwendet wird. Daher muss sich im ersten Schritt der Service Consumer beim Identity Provider authentifizieren. Für die Authentifizierung eines Service-Consumers können herkömmliche Verfahren zum Einsatz kommen wie Benutzername/Passwort, aber auch Alternativen, die eine höhere Sicherheit aufweisen, wie beispielsweise Zertifikate. Die Wahl der Authentifizierungsmechanismen geht einher mit den Sicherheitsanforderungen, die durch die SOA Security Governance (siehe Kapitel 5.1) vorgegeben wurden. 2. Authentifizierung durch den Dienst Der Service Consumer kann das Sicherheitstoken für den Zugriff auf den Dienst verwenden. Dabei muss der Dienst zunächst den Aussteller des Tokens authentifizieren in der Regel durch eine Signatur. Ist das Token gültig und existiert eine Vertrauensbeziehung zwischen dem Identity Provider und dem Dienst, dann muss die Authentifizierungsentscheidung des Identity Providers überprüft werden und zudem festgestellt werden, ob die benötigten Identitätsinformationen im Token enthalten sind. 238

239 Die Technologie, die hierfür verwendet werden kann, ist allerdings noch davon abhängig, welche Dienste orchestriert und verwendet werden: a) Nutzung von unternehmensinternen Diensten In dieser Variante werden Dienste in einer Sicherheitsdomäne genutzt und orchestriert. Es existiert genau ein Identity Provider, der die Identitäten in dieser Domäne verwaltet und dem alle Dienste vertrauen. Das im Abschnitt beschriebene zentralisierte Identitätsmanagementmodell kann in diesem Fall Anwendung finden. Als Standard für den Austausch von Sicherheitstokens kann SAML genutzt werden, aber auch Technologien, die speziell für das zentralisierte Identitätsmanagement geeignet sind, wie beispielsweise Kerberos. Allerdings muss beachtet werden, dass Kerberos zwar eine zentralisierte Authentifizierung in einer Sicherheitsdomäne ermöglicht, aber keine Bereitstellung von beliebigen Attributen erlaubt. Die Wahl der richtigen Technologie hängt somit vom Anwendungsfall ab. b) Nutzung von unternehmensübergreifenden Diensten Dienste werden in diesem Fall orchestriert, um einen Geschäftsprozess zu unterstützen, der Dienste von verschiedenen Organisationen einbindet oder Dienste über die eigenen Unternehmensgrenzen hinaus anbietet. Fundamental ist zunächst die Bestimmung der Art der Vertrauensbeziehung zwischen den einzelnen Beteiligten wie im Abschnitt 6.3 Trust Management beschrieben. Aus technischer Sicht sind zwei Fälle zu unterscheiden: 1. Es besteht eine vertraglich geregelte B2B-Beziehung, in der die Benutzer eines Unternehmens auf die Dienste eines anderen Unternehmens Zugriff erhalten. In diesem Fall kann das föderative Identitätsmanagement-Modell angewendet werden. Mögliche Standards in diesem Rahmen wären WS-Federation oder SAML Der Dienst muss unternehmensübergreifend zur Verfügung gestellt werden, wobei die Identitätsinformationen auch von anderen Organisationen bereitgestellt und bestätigt werden, ohne dass ein Vertrag zugrunde liegt. Inwieweit die Etablierung von Vertrauen in einem solchen dezentralen Fall notwendig ist und welche Anforderungen an die Registrierung, Verifikation und Bereitstellung der Identitätsinformationen gestellt werden, hängt vom jeweiligen Anwendungsfall ab. In jedem Fall kann aber das im Abschnitt beschriebene benutzerzentrische Identitätsmangement Anwendung finden. Als Technologie kann hier ebenfalls SAML zum Einsatz kommen. Des Weiteren ist in Hinblick auf die Bereitstellung von Identitätsinformationen im Kontext der Komposition von identitätsbasierten Diensten wichtig, dass die Identitätsinformationen in Form von Sicherheitstokens durch die Dienstkomposition zu den identitätsbasierten Diensten durchgereicht werden müssen. Dazu kann es notwendig sein, dass die Sicherheitspolicies der zusammengesetzten Dienste auch die Anforderungen der orchestrierten Dienste umfassen, damit wie im Abschnitt 6.2 Policy Management beschrieben die Sicherheitsanforderungen des Dienstes an den Client zur Laufzeit kommuniziert werden können. Die Dienstkomposition kann die vom Client bereitgestellten Identitätsinformationen dann für den Aufruf der orchestrierten Dienste nutzen. 239

240 Autorisierung Durch die Autorisierung soll sichergestellt werden, dass eine Entität befugt ist, auf die angeforderten Informationen oder Ressourcen zuzugreifen. Im Kontext von SOA muss sichergestellt sein, dass bei jedem Service der innerhalb oder über Unternehmens-/ Behördengrenzen hinaus genutzt wird, eine Prüfung stattfindet, ob die Berechtigungen diesen Zugriff erlauben. Diese Prüfung geschieht typischerweise auf Basis der übermittelten Identitätsinformationen, die durch die im vorherigen Abschnitt beschriebenen Methoden bereitgestellt wurden. Somit ist es vom jeweiligen Einsatzszenario abhängig, welche Informationen für die Zugriffskontrolle herangezogen werden. Im Unternehmens-/Behördenkontext wird die Autorisierung typischerweise durch die Verwendung von Rollen und Gruppen umgesetzt. Weiterführende Informationen über die Definition, Verwaltung und Durchsetzung von Sicherheitspolicies können dem Abschnitt 6.2 Policy Management entnommen werden Datenschutz Durch den Datenschutz soll im Wesentlichen gewährleistet werden, dass personenbezogene Daten vor Missbrauch geschützt werden. Um diese Anforderung zu erfüllen, müssen diese Daten vertraulich behandelt werden und dürfen nur für den Zweck eingesetzt werden, für den sie erhoben wurden. Neben der organisatorischen Forderung, dass Unternehmen/Behörden versuchen sollten, so wenig personenbezogene Daten wie möglich zu erheben d.h. nur so viele wie unbedingt nötig, gibt es technische Rahmenbedingungen. Bei Service-orientierten Architekturen müssen personenbezogene Daten ebenfalls angemessen geschützt werden, besonders wenn diese durch die abgebildeten Geschäftsprozesse die Organisationsgrenzen überschreiten. Umgesetzt werden kann dies durch Methoden der Nachrichtenverschlüsselung zur Gewährleistung der Vertraulichkeit. Die im Abschnitt Vertraulichkeit beschriebenen Techniken zur Sicherung einzelner Nachrichtenteile ermöglichen technischen Datenschutz auf Nachrichtenebene. Zusätzlich sollte der Prozess der Datenerhebung für den Betroffenen transparent gestaltet werden. Dazu gehört der Ansatz des benutzerzentrischen Identitätsmanagements (vgl. Kapitel ), welches dem Benutzer die Kontrolle über die Verwendung seiner Identitätsinformationen gibt, indem für den Benutzer transparent gemacht wird, welche Identitätsinformationen von Diensten benötigt und bei der Nutzung der Dienste weitergegeben werden. Die Stärke des Konzeptes ist, dass Identitätsinformationen nicht automatisiert über die IT-Infrastruktur zum Dienst weitergegeben werden, sondern zentralisiert über den Benutzer, so dass dieser jederzeit die Kontrolle über die Verwendung seiner Daten hat Vertraulichkeit und Integrität von Daten Die Verwendung einer nachrichtenbasierten Kommunikation unter Verwendung von XMLbasierten Protokollen zur Sicherstellung der losen Kopplung und der Interoperabilität gehen einher mit einer einfachen Lesbarkeit und dementsprechend einfacheren Möglichkeit zur Manipulation der Kommunikation durch etwaige Angreifer. Zur Wahrung der Integrität und Vertraulichkeit der ausgetauschten Informationen können Maßnahmen eingesetzt werden, welche direkt auf der Nachrichtenebene ansetzen. 240

241 Integrität bezeichnet die Unversehrtheit von Informationen und Ressourcen. Eine Verletzung der Integrität bedeutet daher die unberechtigte oder unangemessene Modifikation von Daten. Vertraulichkeit hingegen fordert eine Geheimhaltung von sensitiven Daten, um einen unberechtigten Zugriff auf Informationen zu unterbinden. Es muss gewährleistet werden, dass nur autorisierte Entitäten auf geschützte Informationen zugreifen können. Für die Sicherstellung der zwei Sicherheitsziele Vertraulichkeit und Integrität können konzeptionell zwei verschiedene Ansätze unterschieden werden: 1. Umsetzung der Verschlüsselung und Integrität Abbildung 84: Transportorientierte Umsetzung der Verschlüsselung und Integrität In dieser Variante wird der Kommunikationskanal zwischen zwei Kommunikationspartnern abgesichert, wie in Abbildung 84 dargestellt. Die Vertraulichkeit und Integrität der Daten ist somit nur zum Zeitpunkt der Datenübertragung gewährleistet. 2. Nachrichtenbasierte Umsetzung der Verschlüsselung und Integrität Abbildung 85: Nachrichtenbasierte Umsetzung der Verschlüsselung und Integrität Dieser Ansatz setzt nicht bei der Sicherung des Übertragungswegs an, sondern führt eine Transformation der Nachricht selbst durch, vgl. Abbildung 85. Dabei werden Nachrichten durch eine Signatur und die Verschlüsselung des Nachrichteninhaltes gesichert, so dass die Daten nicht nur zum Zeitpunkt des Datentransfers geschützt sind. Zudem ist zu beachten, dass es in vielen Fällen nicht sinnvoll ist, die Sicherheit der gesamten Nachricht, sondern nur für definierte Teile zu gewährleisten. Dies kann beispielsweise aus Performance-Gründen erforderlich sein, so dass nur die hochvertraulichen Teile einer Nachricht geschützt werden. Aber auch die Notwendigkeit, dass verschiedene Nachrichtenteile beispielsweise AdressingInformationen für das Routing von Nachrichten von Zwischenstationen genutzt werden müssen, kann einen Grund darstellen, nur einen Teil der Nachricht zu verschlüsseln. Für die Entscheidung, welches Verfahren in welchem Umfang zur Absicherung herangezogen wird, sind zwei Fragen entscheidend: 1. Unter welchen Gegebenheiten sollen die Daten geschützt sein? Es kann notwendig sein, die Daten lediglich während des Datentransfers zwischen zwei Parteien zu schützen. In diesem Fall kann eine transportorientierte Umsetzung der 241

242 Vertraulichkeit und Integrität ausreichend sein. Ist allerdings die Anforderung, die Daten dauerhaft und unabhängig von der Datenübertragung zu verschlüsseln und zu signieren, dann ist eine nachrichtenbasierte Umsetzung zu empfehlen. Beispielsweise kann so die Vertraulichkeit auch bei der Speicherung der übertragenen Daten sichergestellt werden. 2. Wie sehen die zuvor beschriebenen Rahmenbedingungen für die Dienste aus? Werden Dienste in einem Unternehmen oder unternehmensübergreifend orchestriert, dann ist die Art der Nachrichtenverarbeitung entscheidend. Wenn Dienste als Zwischenstationen involviert sind, die Nachrichten auf Basis der Headerinformationen bearbeiten oder nur Teile der Nachrichten verarbeiten, dann ermöglicht die Signatur auf Nachrichtenebene die Überprüfbarkeit der Nachrichtenauthentizität aller involvierten Dienste. Zudem können Nachrichtenteile speziell für einzelne Dienste verschlüsselt werden, so dass nur diese Teile der Nachricht lesen können, während der Rest der Nachricht für alle beteiligten Dienste lesbar bleibt. Gerade in Hinblick auf das Identitätsmangement ist es beispielsweise wichtig, dass Sicherheitstokens vom Identity Provider signiert und für die abhängige Partei verschlüsselt werden Verfügbarkeit und Ausfallsicherheit Verfügbarkeit fordert, dass berechtigte Entitäten auf die benötigten Informationen und Resourcen ohne Einschränkungen zugreifen können. Um verlässliche Systeme zu bieten, muss eine Organisation garantieren, dass die Verfügbarkeit sichergestellt wird. Es ist häufig der Fall, dass die Vertraulichkeit und Integrität gewährleistet wird, aber durch einen Angriff auf die Verfügbarkeit eines Systems nicht mehr auf die benötigten Informationen zugegriffen werden kann. In einem verteilten System ist das Ausfallrisiko als relativ hoch einzuschätzen, vor allem wenn einige Teile nicht im eigenen Zugriffsbereich liegen. Daher ist ein Single-Point-ofFailure zu vermeiden und die Forderung zu erfüllen, dass auch bei Ausfall einiger Komponenten wichtige Komponenten des Gesamtsystems funktionsfähig bleiben. Bei der Implementierung von zentralen Komponenten in einer SOA können kritische Geschäftsprozesse stark beeinträchtigt werden, was dazu führen kann, dass wichtige Prozesse innerhalb einer Organisation nicht korrekt ausgeführt werden können. Dies betrifft insbesondere das Sicherheitssystem, dessen Funktionsfähigkeit gewährleistet werden muss. Auch bei Ausfall von zentralen Teilen muss die Funktionsfähigkeit beispielsweise durch lokal verteilte Logik und Policies sichergestellt werden. Daneben kann die Ausfallsicherheit sowie Skalierbarkeit durch bewährte Konzepte (LoadBalancing, Application-Server-Management, etc.) umgesetzt werden. Insbesondere die Skalierbarkeit der (Security-) Architektur muss sichergestellt sein, da in der Planungsphase nur bedingt festgelegt werden kann, wie viele Consumer auf einen Service zugreifen werden. Über die Zeit sind veränderte Nutzungsbedingungen ebenfalls zu berücksichtigen. 242

243 6.6 Sicherheit und Interoperabilität mit WS-I Grundlagen Web Services wurden entworfen, um unabhängig von Herstellern und Betriebssystemen eine plattformübergreifende Kommunikation zwischen Systemen zu ermöglichen. In der Praxis hat sich allerdings gezeigt, dass unterschiedliche Implementierungen von Web Service Standards nicht immer miteinander kompatibel sind. Das liegt zum Einen an fehlerhaften Implementierungen und zum Anderen an den Spezifikationen. Diese lassen eine hohe Flexibilität und Erweiterbarkeit der Web Service Protokolle zu, wodurch sich zahlreiche Implementierungsvarianten ergeben, die die Interoperabilität der Web Services einschränken. Das gleiche gilt bei den Standards, die Web Services um Sicherheitsfunktionen erweitern. Um diesen Problemen zu begegnen, wurde die Web Services Interoperability Organization (WS-I) gegründet. WS-I bietet technische Richtlinien (Profiles), Umsetzungsbeispiele (Sample Applications) und Test-Werkzeuge (Testing Tools), mit deren Hilfe Entwickler sicherstellen können, dass ihre Web Services interoperabel mit anderen Web Services sind. Profile (Profiles): Aufbauend auf Best Practices definieren die Profile Richtlinien für einen Satz von Spezifikationen (Standards und Verfahren), um diese zu konkretisieren. Die Profile sollen den Entwicklern helfen interoperable Web Services zu entwerfen. Umsetzungsbeispiele (Sample Applications): Sample Applications sind Web Service Anwendungen, die kompatibel mit den WS-I Richtlinien sind und Best Practices nutzen. Diese Implementierungen sind unabhängig von Plattformen, Sprachen und Programmier-Tools, und dienen dazu Interoperabilität zu demonstrieren und leicht nutzbare Ressourcen (z.b. Code-Beispiele) für Entwickler von Web Services bereitzustellen. Test-Werkzeuge (Testing Tools): Für die Überprüfung, ob ein entworfener Web Service im Einklang mit den WS-I-Leitlinien ist, werden so genannte Testing Tools bereitgestellt. Während der Spezifikation der Profile werden Tests für die Testsoftware definiert, die es den Entwicklern eines Web Service erlauben ihren Service eigenständig und automatisch auf Konformität mit dem WS-I Profil zu prüfen Darstellung der Regeln Viele Web Service Spezifikationen sind nicht eindeutig, sondern lassen einen Gestaltungsspielraum bei der Umsetzung zu. Dadurch sind unterschiedlichste Implementierungsvarianten möglich. Um die Interoperabilität zwischen den Implementierungen zu erleichtern, werden in den Profilen die Anforderungen der Spezifikationen geschärft (z.b. ersetzen von SHOULDs durch MUSTs) und die Flexibilität und Erweiterbarkeit reduziert. Hierfür gibt es unterschiedliche Regeln in den Profilen: Erweiterung: Bestehende Profile, Standards und Spezifikationen werden um Klarstellungen, Verfeinerungen, Interpretationen und Verstärkungen von Web Service Spezifikationen erweitert, um die Interoperabilität zu begünstigen. Empfehlung: Es werden zu verwendende Standards und Profile empfohlen, um z.b. die Sicherheit zu verbessern. 243

244 Einschränkung: Pflichtfelder und Optionen in den bestehenden Profilen, Standards und Spezifikationen werden eingeschränkt, um die Interoperabilität zu verbessern. Verwendung: Schreibt vor, welche bestehenden Profile, Standards und Spezifikationen verwendet werden müssen, um konform mit dem Profil zu sein. Zur Umsetzung dieser Regeln werden in den Profilen die folgenden Notationen verwendet Profil Konformität Konformitätsanforderungen (Conformance Requirements) Normative Aussagen eines WS-I Profils sind so genannte Conformance Requirements, die durch eine eindeutige ID referenziert werden können. Sie beziehen sich üblicherweise auf eine vorhandene Spezifikation und verkörpern Verfeinerungen, Erweiterungen, Interpretationen und Präzisierungen, um die Interoperabilität zu verbessern. Eine Konformitätsanforderung ist in den Profilen durch eine Zahl und das Präfix 'R' gekennzeichnet. Ein Beispiel für eine Konformitätsanforderung ist R1141 A MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0.. Konformitätsziele (Conformance Targets) Die Konformitätsanforderungen beziehen sich auf bestehende Standards und identifizieren bestimmte Konformitätsziele (Conformance Targets). Konformitätsziele werden für Artefakte (z.b. eine SOAP Nachricht, eine WSDL Beschreibung oder UDDI Registerdaten) oder Parteien (z.b. SOAP Verarbeiter oder Endnutzer) definiert, um die Profil-Anforderungen zu erfüllen und Interoperabilität zu gewährleisten. Ein Conformance Target aus dem Basic Profile 1.1 ist z.b. ENVELOPE - the serialization of the soap:envelope element and its content. Konformitätsinhalt (Conformance Scope) Der Scope eines Profils umfasst die Technologien, auf die das jeweilige Profil abzielt. Das Profil hat dann nur die Aufgabe, die Interoperabilität der Technologien im Scope zu gewährleisten. Der Scope des Profils ist wiederum durch die referenzierten Standards und Spezifikationen eingeschränkt. Anspruch der Konformität (Conformance Claim) Die Konformität eines Profils kann beansprucht werden, wenn die jeweils benannten ProfilAnforderungen von dem implementierten Web Service eingehalten werden. Die Mechanismen zur Beanspruchung der Konformität werden im so genannten Conformance Claim Attachment Mechanisms (CCAM) näher beschrieben. CCAM beschreibt, wie mittels WSDL und UDDI angegeben werden kann, dass der jeweilige Web Service konform zu dem jeweiligen Profil ist. Es kann unter abgerufen werden. 244

245 Klärende Aussagen (Clarifying Statements) Klärende Aussagen eines WS-I Profils werden als so genannte Clarifying Statements bezeichnet. Sie beseitigen Unklarheiten über die Auslegung einer Vorschrift aus einer zugrunde liegenden Spezifikation, stellen aber keine zusätzlichen Anforderungen an die Implementierungen. Ein Clarifying Statement ähnelt einem Conformance Requirement. Das es sich bei dem Statement um ein Clarifying Statement handelt, wird durch ein hochgestelltes 'C' am Ende des Statements signalisiert. Ein Beispiel für ein Clarifying Statement ist R1008 A MESSAGE MUST NOT contain a Document Type Declaration.C Sicherheitsbetrachtungen (Security Considerations) Security Considerations sind informelle Aussagen in einem WS-I Profil, die durch eine eindeutige ID referenziert werden können. Jede Empfehlung enthält ein SHOULD oder MAY, um zu signalisieren, was empfohlen wird, um die Sicherheit zu verbessern. Eine Security Consideration ist durch eine Zahl und das Präfix 'C' in den Profilen gekennzeichnet. Ein Beispiel für eine Security Consideration ist C5630 Any SIGNATURE computed over data that is subsequently encrypted SHOULD also be encrypted in order to prevent plaintext guessing attacks when the probable set of data values is small Erweiternde Aussagen (Extensibility Statements) Die zugrunde liegenden Spezifikationen verfügen unter Umständen über Erweiterungsmechanismen oder nicht spezifizierte bzw. offene Konfigurationsparameter. Diese Erweiterungspunkte werden in den Profilen als Extensibility Statements gekennzeichnet und liegen außerhalb des Scopes des Profils. Daher ist die Nutzung oder nicht Nutzung der Mechanismen und Parameter nicht relevant für die Konformität. Ein Beispiel für ein Extensibility Statements ist E Security Tokens - Security tokens may be specified in additional security token profiles WS-I Profile Zur Verbesserung der Interoperabilität hat die Web Services Interoperability Organization (WS-I) unterschiedliche Profile spezifiziert. Die Profile sind Spezifikationen und liefern Richtlinien für die Implementierung. Ziel ist es: Doppeldeutigkeiten in Spezifikationen durch deren Konkretisierung zu eliminieren (MAY, SHOULD, MUST), die Möglichkeit, unterschiedliche Interpretationen der Spezifikationen durch klärende Aussagen zu vermeiden und mögliche Lücken beim Zusammensetzen von unterschiedlichen Spezifikationen zu schließen. 245

246 Die Abbildung 86 gibt einen Überblick über die WS-I Profile Familie und deren Beziehungen untereinander. Das erste und wichtigste Profil ist WS-I Basic Profile. Es legt die Grundlage für die anderen Profile, die darauf aufbauen bzw. es erweitern. Die Basis für interoperable Sicherheitsmechanismen legt das WS-I Basic Security Profile. Es erweitert das WS-I Basic Profile und wird selbst durch die WS-I Profile Kerberos Token, REL Token und SAML Token erweitert. Wenn ein Web Service konform mit einem oder mehreren Profilen ist, dann kann der Anbieter des Service dies durch ein Conformance Claim in der WSDL-Beschreibung des Abbildung 86: Übersicht über die WS-I Profile Service oder mittels UDDI anzeigen lassen. Der Konformitätsanspruch signalisiert dem Web Service Consumer, dass der Service im Einklang mit den genannten Profilen ist. Allerdings gibt es keine Garantie, dass Web Services, die die WS-I Profile umsetzen, miteinander interoperabel sind. Nachfolgend werden die einzelnen WS-I Profile beschrieben WS-I Basic Profile 1.1 Einleitung Das Basic Profile (BP) beinhaltet einen grundlegenden Katalog von Konformitätsanforderungen für die Umsetzung der Web Service Kernspezifikationen SOAP 1.1, WSDL 1.1 und UDDI 2.0. Das Profil beschreibt, wie diese Basisstandards gemeinsam verwendet werden, um interoperable Web Services zu entwickeln. Im Jahr 2006 wurde das Profil in der Version 1.1 veröffentlicht. Zur Förderung der Interoperabilität werden im BP eine Reihe von Klarstellungen, Präzisierungen, Interpretationen und Erweiterungen für die oben genannten Web Service Standards gegeben. Grundlagen Die Spezifikationen der Basistechnologien WSDL, UDDI und SOAP einer SOA sind nicht eindeutig, sondern lassen den Entwicklern einen Gestaltungsspielraum, z.b. definiert SOAP 1.1 ein XML-Format zur Übertragung von Nachrichten. Allerdings werden keine 246

247 konkreten Aussagen gemacht, wie das SOAP Envelope Element serialisiert wird. An diesen Stellen setzt das Profil an und konkretisiert den Standard, um die Interoperabilität zu verbessern. Unter anderem wird z.b. vorgeschrieben R9701 An ENVELOPE MUST be serialized as XML 1.0. Das Profil fügt somit Einschränkungen und Klarstellungen zu den Basis-Spezifikationen hinzu. An den Stellen, an denen das Profil keine Aussage macht (d.h. keine Klärung oder Zwang), sind die Basis -Spezifikationen normativ. Wenn das Profil eine Anforderung vorschreibt in Form einer Klarstellung oder Zwang, dann ersetzt das Profil an dieser Stelle die zugrunde liegende Spezifikation. Das Profil macht Requirements Statements über die folgenden vier Bereiche: Messaging: Für den Austausch von Nachrichten über SOAP und HTTP werden Einschränkungen bei der XML Repräsentation von SOAP Nachrichten, dem SOAP Processing Model und der Nutzung von SOAP in HTTP gemacht. Service Description: Das Profil macht Einschränkung bei der Dokumentenstruktur, types, messages, port types, bindings, SOAP binding und bei der Verwendung von XML Schemata, die in den WSDL Beschreibungen der Services verwendet werden. Service Publication and Discovery: Für die Registrierung von Services und das Auffinden von Service Providern beschreibt das Profil Einschränkungen bezüglich der Flexibilität und Erweiterbarkeit bei der Nutzung von UDDI. Die Einschränkungen beziehen sich auf die Elemente bindingtemplates und tmodels. Security: Das Profil definiert Anforderungen für die Nutzung von HTTPS. Mit der Absicht zur Förderung der Interoperabilität sieht das Basic Profile Einschränkungen und Klarstellungen in unterschiedlichen Web Services Spezifikationen vor, unter anderem: Extensible Markup Language (XML) 1.0 Hypertext Transfer Protocol (HTTP) 1.1 over TLS Secure Sockets Layer Protocol Version 3.0 SOAP 1.1 Universal Description, Discovery and Integration (UDDI) 2.0 Web Services Description Language (WSDL) 1.1 XML Schema 1.0 Part 1: Structures XML Schema 1.0 Part 2: Data types Relevanz in der Praxis Das Basic Profile wird inzwischen von nahezu allen Web Service Frameworks unterstützt. Zudem wurde das BP 1.1 von der International Organization for Standardization (ISO) als ISO/IEC 29361:2008 (siehe [ISO29361]) veröffentlicht WS-I Basic Security Profile 1.0 Einleitung 247

248 Typischerweise erfolgt die Absicherung von Nachrichten im SOA-Umfeld durch Sicherheitsmechanismen für SOAP aus dem WS-Security Standard der OASIS. Alternativ können die Nachrichten auf der Transportebene mittels SSL/TLS abgesichert werden. Genau wie die grundlegenden Web Service Standards sind auch die darauf aufbauenden Sicherheitsstandards und Protokolle so verfasst, dass sie eine Vielzahl an Implementierungsvarianten zulassen. Ohne Einschränkungen in den Spezifikationen ist eine sichere Umsetzung von Web Services, die mit anderen interoperabel sind, nur schwer zu realisieren. Daher wurde das Basic Security Profile (BSP) definiert, das die Alternativen einschränkt, Felder genau spezifiziert und zusätzlich Empfehlungen gibt. Im Jahr 2007 erschien die finale Version 1.0 des BSP. Im gleichen Jahr wurde auch der Draft für BSP 1.1 veröffentlicht. Grundlagen Die Grundlage für die Definition des Basic Security Profiles ist das Dokument Security Challenges, Threats and Countermeasures Version 1.0 (siehe [WS-I SCTC]). Dieses Dokument definiert die Anforderungen und den Scope des WS-I Basic Security Profiles. In dem Dokument werden sowohl Sicherheitsherausforderungen, Bedrohungen und Maßnahmen beim Aufbau von interoperablen Web Services, als auch Einsatzszenarien und Lösungen beschrieben. Sicherheitsherausforderungen: In dem Dokument werden die Sicherheitsherausforderungen dargestellt, die in unterschiedlichen Szenarien auftreten können. Allerdings werden nicht alle Herausforderungen in dem Dokument adressiert. Es wird unterschieden zwischen Herausforderungen innerhalb und außerhalb des Scopes des WS-I Basic Security Profiles. Für die Sicherheitsherausforderungen im Scope werden die Sicherheitsaspekte weiter diskutiert. Die Herausforderungen außerhalb des Scopes werden aufgelistet, aber nicht weiter betrachtet. Die identifizierten Herausforderungen, die innerhalb bzw. außerhalb des Scopes liegen, sind der Tabelle 12 zu entnehmen. Im Scope Nicht im Scope Peer Identifizierung und Authentifizierung Verbindlichkeit Identifizierung und Authentifizierung des Datenursprungs Ausgabe von Credentials Integrität der Daten Vertraulichkeit der Daten Einzigartigkeit der Nachricht Tabelle 12: Identifizierte Herausforderungen innerhalb und außerhalb des Scopes WS-I Basic Security Profile Bedrohungen: Aufbauend auf den Sicherheitsherausforderungen werden Bedrohungen definiert, die im BSP adressiert werden. Genau wie bei den Sicherheitsherausforderungen gibt es Bedrohungen, die innerhalb und außerhalb des Scopes des WS-I Basic Security Profiles liegen. Nur für die Bedrohungen im Scope 248

249 erfolgt eine weiterführende Sicherheitsbetrachtung. Die Bedrohungen außerhalb des Scopes werden nur zur Vollständigkeit aufgeführt, allerdings nicht weiter betrachtet. Die Bedrohungen innerhalb und außerhalb des Scopes sind in Tabelle 13 aufgelistet. Im Scope Nicht im Scope Veränderte Nachrichten Schlüssel Kompromittierung/Schwache Algorithmen Vertraulichkeit Verkehrsanalyse Gefälschte Nachrichten Host Penetration Man in the Middle Netzwerk Penetration Principal Spoofing Zeitanalysen Forged claims Covert Channels Replay-Angriffe Netzwerk Spoofing Denial of Service Trojanische Pferde Viren Denial of Service (Silver Bullet/Flooding) Verbindlichkeit Fehlerhafte Implementierung Schlecht entworfene Web Services Tabelle 13: Identifizierte Bedrohungen innerhalb und außerhalb des Scopes vom WS-I Basic Security Profile Maßnahmen: Um den identifizierten Bedrohungen zu begegnen, werden verfügbare Sicherheitsmechanismen beschrieben, die alleine oder in Kombination genutzt werden können. Im Fokus stehen Sicherheitslösungen auf der Transport- und Nachrichtenebene, die anhand der Sicherheitsziele Integrität, Vertraulichkeit und Authentizität dargestellt werden. Auf der Transportebene beschränken sich die Ausführungen auf HTTP(S). Tabelle 14 fasst die Ergebnisse der Sicherheitslösungen auf der Transportebene zusammen. Für die Mechanismen auf der Nachrichtenebene werden die SOAP Message Security Spezifikationen vom OASIS SOAP Message Security Technical Committee in Verbindung mit deren Token Spezifikation betrachtet. Tabelle 15 fasst die Ergebnisse auf der Nachrichtenebene zusammen. 249

250 Sicherheitsherausforderung Genutzte Technologie auf der Transportebene Integrität SSL/TLS [RFC 2246] Vertraulichkeit SSL/TLS[RFC 2246] Provider Authentifizierung SSL/TLS [RFC 2246] Consumer Authentifizierung SSL/TLS mit Client Authentifizierung [RFC 2246] HTTP Basic Authentication [RFC 2617] HTTP Digest Access Authentication [RFC 2617] HTTP Attributes [RFC 2616] Basic Authentication oder Digest Access Authentication mit HTTPS Tabelle 14: Optionen zur Absicherung auf der Transportebene Sicherheitsherausforderung Genutzte Technologie auf der Nachrichtenebene Integrität XML Digital Signature Vertraulichkeit XML Encryption SOAP Sender Authentifizierung Verschlüsseln von Username & [Password Digest] mittels XML Encryption Username Token SOAP Attribute X.509 Certificate Kerberos Token SAML Token REL Token Tabelle 15: Optionen zur Absicherung auf der Nachrichtenebene Einsatzszenarien und Lösungen: Das Dokument beschreibt den Einsatz der Technologien zum Absichern der Kommunikation. Zum Einen werden die einzusetzenden Sicherheitsmechanismen in Abhängigkeit von den Sicherheitsherausforderungen dargestellt. Da das Basic Security Profile als eine Erweiterung des Basic Profiles konzipiert ist und auf diesem aufbaut, werden zum Anderen anhand von drei Kommunikationsszenarien (One-Way, Synchronous Request/ Response und Basic Callback) der Einsatz der Sicherheitslösungen (siehe Tabelle 14 und Tabelle 15) erläutert. 250

251 Mit dem Ziel der Förderung der Interoperabilität sieht das Basic Security Profile Einschränkungen und Klarstellungen in Web Services Spezifikationen und Normen auf der Grundlage der im Dokument dargestellten Sicherheitsbetrachtung für Web Service vor. Das Profil berührt unterschiedliche Spezifikationen, unter anderem: HTTP over TLS, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, SSL Protocol Version 3.0, TLS Protocol Version 1.0, Web Services Security: SOAP Message Security 1.0, Web Services Security: REL Token Profile 1.0, Web Services Security: SAML Token Profile 1.0, Web Services Security: SOAP Messages with Attachments (SwA) Profile 1.1, Web Services Security: Kerberos Token Profile 1.1, Web Services Security: Username Token Profile, Web Services Security: X.509 Token Profile 1.0, XML Encryption Syntax and Processing, XML Signature Syntax and Processing. Das BSP gewährleistet nicht vollständig die Interoperabilität. Allerdings adressiert es die häufigsten Probleme, die bei praktischen Umsetzungen von sicheren Web Services auftreten und erhöht so die Wahrscheinlichkeit der Interoperabilität. Der Schwerpunkt wird auf die Interoperabilität der beiden wichtigsten Technologien gelegt: HTTP over TLS: HTTP over TLS definiert eine Punkt-zu-Punkt-Verbindung, die die Vertraulichkeit aller Informationen, die über eine HTTP-Verbindung ausgetauscht werden, gewährleistet. SOAP Message Security: SOAP Message Security bietet Sicherheit für SOAP Nachrichten auch dann, wenn eine SOAP Nachricht über mehrere Intermediäre geleitet wird. Außerdem können unterschiedlichen Ebenen der Sicherheit für ausgewählte Teile einer Nachricht umgesetzt werden. Die Abbildung 87 zeigt die Einordnung des Profils im Vergleich zu den anderen Spezifikationen auf. Abbildung 87: WS-I Basic Security Profile 251

252 Relevanz in der Praxis Zum gegenwärtigen Zeitpunkt existieren erst vereinzelte Web Service Frameworks, die das Basic Security Profile vollständig umsetzen. Getestet wurde das BSP innerhalb der WS-I von SAP, Microsoft, IBM, Novell und Oracle, wenn auch teilweise mit Beta-Versionen ihrer Produkte. Es ist davon auszugehen, dass in den nachfolgenden Produktversionen das BSP unterstützt wird WS-I Attachments Profile 1.0 Das Attachments Profile wurde von IBM, Oracle und SAP AG entwickelt und liegt zur Zeit in der finalen Version 1.0 vor. Im Jahr 2008 wurde das WS-I Attachments Profile 1.0 von der ISO als ISO/IEC 29362:2008 (siehe [ISO29362]) veröffentlicht. Das Profil ergänzt das Basic Profile und dient der Unterstützung von SOAP Nachrichten, die mit Anhängen (Attachments) innerhalb von interoperablen Web Services verschickt werden. Es erweitert das Basic Profile und wird vom Basic Security Profile verwendet. Das Profil wurde entwickelt, um die Interoperabilität von SOAP Nachrichtenanhängen (SwA, siehe Kapitel 4.2.3) zu fördern. Die Spezifikation für SOAP Nachrichten mit Anhängen (SOAP with Attachments) definiert eine MIME multipart/related Struktur, um einen SOAP Envelope mit Anhängen zu verpacken. Dabei gibt das Profil vor, diese Struktur zu benutzen. Zusätzlich werden Einschränkungen für das Verpacken und Beschreiben des Anhangs einer Nachricht festgelegt. Die Abbildung 88 zeigt die Beziehungen des WS-I Attachments Profiles zu den anderen Profilen und Standards. Abbildung 88: WS-I Attachments Profile WS-I Simple SOAP Binding Profile 1.0 Das Simple SOAP Binding Profile (SSBP) liegt seit August 2004 in der finalen Version 1.0 vor. Im Jahr 2008 wurde das WS-I SOAP Binding Profile 1.0 von der ISO als ISO/IEC 29363:2008 (siehe [ISO29363]) veröffentlicht. Das SSBP wurde aus den Anforderungen des Basic Profiles 1.0 abgeleitet. Zusammen mit dem SSBP wurde das Basic Profile 1.1 spezifiziert, das keine Einschränkungen bezüglich der abgedeckten Bereiche des SSBP enthält. Beide Profile zusammen sind größtenteils äquivalent zum Basic Profile 1.0. Somit erweitert das Simple SOAP Binding Profile das Basic Profile. 252

253 Das Profil schreibt die Nutzung von SOAP 1.1 und WSDL 1.1 vor. Zusätzlich werden Einschränkungen bei deren Nutzung vorgeschrieben. Diese Einschränkungen konzentrieren sich auf die Repräsentation und Serialisierung der Nachrichten. Ein Web Service, welcher keine Anhänge (Attachments) nutzt, sollte vor allem auf WS-I-Konformität in der Verbindung des Basic Profiles 1.1 und des Simple SOAP Binding Profiles 1.0 geprüft werden. Abbildung 89: Simple SOAP Binding Die Abbildung 89 zeigt die beschriebenen Zusammenhänge WS-I Reliable Secure Profile 1.0 Das Reliable Secure Profile befindet sich noch in einer Draft-Version, ist jedoch bereits von der verantwortlichen Arbeitsgruppe als aktuelle Diskussionsgrundlage akzeptiert und veröffentlicht worden. Ziel ist es, zusammen mit den folgenden Standards und Spezifikationen eine zuverlässige und sichere Verbindung zwischen interoperablen Web Services her- bzw. sicherzustellen: Web Service ReliableMessaging 1.1 (siehe Kapitel 4.7.2), Web Service SecureConversation 1.3 (siehe Kapitel 4.5.4), Web Service Make Connection 1.0 [WSMC 2007], Web Service SecurityPolicy 1.2 (siehe Kapitel 4.5.2). Das Profil hat somit die Aufgabe, die Interoperabilitätsprobleme, die zur Zeit bei der Implementierung der genannten WS-Standards existieren, zu beseitigen. 253

254 Abbildung 90: Darstellung Reliable Secure Profile Bei diesem Profil wurden zunächst Anforderungen und Nutzungs- sowie Test-Szenarien definiert bzw. entwickelt. Ziel dieses Vorgehens ist die Identifizierung von Interoperabilitätsproblemen innerhalb einer breiten und komplexen Spanne an Web Services wie z.b. Enterprise Services oder auf mobilen Applikationen. Aufbauend auf dieser Betrachtung wurde das Profil definiert WS-I Kerberos Token Profile 1.0 Dieses Profil wurde in Kooperation zwischen Nortel Networks, Microsoft, IBM und Layer 7 entwickelt. Es ist keine offizielle, komplette bzw. finale Version. Es kann jedoch in Verbindung mit dem WS-Security Kerberos Token Profile genutzt werden, um zu beschreiben, wie die WS-Security Header genutzt werden müssen, um Kerberos Authentifizierungsinformationen zu übergeben. Dazu konkretisiert das WS-I Kerberos Token Profile das WS-Security Kerberos Token Profile. Das Profil dient speziell zur Verwendung von Kerberos Token bei Web Services, die sich interoperabel unterhalten. Abbildung 91: Darstellung WS-I Kerberos Token Profile WS-I REL Token Profile 1.0 Dieses Profil wurde ebenfalls von Nortel Networks, Microsoft, IBM und Layer 7 entwickelt. Das Dokument befindet sich in der Draft-Version 1.0, die von der verantwortlichen Working Group als aktuelle Diskussionsgrundlage akzeptiert und veröffentlicht wurde. Da dieses Dokument noch in der Entwicklungsphase ist, sollte es nicht als Vorgabe oder Final angesehen werden. Das Rights Expression Language (REL) Token Profile wird in Verbindung mit dem WSSecurity REL Token Profile genutzt, um verschiedene Mechanismen der Referenzierung von 254 Abbildung 92: Darstellung WS-I REL Token Profile

255 REL Token zu definieren. Dazu konkretisiert das WS-I REL Token Profile das WS-Security REL Token Profile. Das Profil dient speziell der Verwendung von REL Token bei Web Services, die sich interoperabel unterhalten wollen WS-I SAML Token Profile 1.0 Wie die zuvor beschriebenen Profile wurde auch dieses Profil von Nortel Networks, Microsoft, IBM und Layer 7 entwickelt. Auch dieses Dokument befindet sich in der DraftVersion 1.0, die von der verantwortlichen Working Group als aktuelle Diskussionsgrundlage akzeptiert und veröffentlicht wurde. Da dieses Dokument noch in der Entwicklungsphase ist, sollte es nicht als Vorgabe oder Final angesehen werden. Damit SAML Token interoperabel verwendet werden können, konkretisiert das WS-I SAML Token Profile das WS-Security SAML Token Profile. Dabei macht das Profil keine Einschränkungen, sondern enthält nur Claryfing Statements über die Referenzierung von SAML Assertions. Abbildung 93: Darstellung WS-I SAML Token Profile Überblick Standards und WS-I Profile Die Tabelle 16 [WS-I Matrix] gibt einen Überblick über die beschriebenen WS-I Profile und die darin verwendeten Dokumente. Die Matrix ist nicht vollständig, sondern listet nur die wesentlichen Punkte auf. X Basic Profile Version 1.1 X RFC2246: The TLS Protocol Version 1.0 X SAML Token 1.0 Basic Profile Version 1.0 (BP1.0) REL Token Profile 1.0 X Kerberos Token 1.0 Attachments Profile Version 1.0 (AP1.0) Reliable Secure 1.0 Basic Security 1.0 Simple SOAP Binding 1.0 Attachments 1.0 Basic 1.1 Referenzdokumente X 255

256 REL Token Profile 1.0 SAML Token 1.0 X Kerberos Token 1.0 RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile Reliable Secure 1.0 X Basic Security 1.0 RFC2818: HTTP over TLS Simple SOAP Binding 1.0 Attachments 1.0 Basic 1.1 Referenzdokumente X X X X X Simple SOAP Binding Profile Version 1.0 X X SOAP 1.1 X SOAP Messages with Attachments X X The SSL Protocol Version 3.0 X UDDI Version 2 X X WS-Addressing 1.0 X WSDL 1.1 X X X WS-Reliable Messaging Version 1.1 X WS-Security: Kerberos Token Profile 1.1 X WS-Security: Rights Expression Language (REL) Token Profile 1.0 X WS-Security: SAML Token Profile 1.0 X WS-Security: SOAP Message Security 1.0 X WS-Security: SOAP Messages with Attachments (SwA) Profile 1.1 X WS-Security: UsernameToken Profile 1.0 X WS-Security: X.509 Certificate Token Profile X WS-Security: X.509 Token Profile 1.0 X XML Encryption X XML-Signature X X X X X Tabelle 16: WS-I Profile und referenzierte Dokumente 256

257 6.6.5 Testing Tools Die WS-I stellt Test Tools zur Verfügung, mit denen die Entwickler ihre Web Services überprüfen können. Auf diese Weise können Entwickler feststellen, ob ihre Web Services den Kriterien zur Interoperabilität entsprechen bzw. welche der Kriterien verletzt werden Architektur Das WS-I Test Tool besteht eigentlich aus zwei Tools, dem Monitor und dem Analyzer. Während das Monitor Tool die Aufgabe hat, die Web Service Kommunikation entsprechend des Man-in-the-Middle Ansatzes zu loggen, können die gesammelten Informationen mit dem Analyzer ausgewertet werden. Der Analyzer bestimmt, ob die Web Service Artefakte (z.b. eine SOAP Nachricht, eine WSDL Beschreibung oder UDDI Registerdaten) konform gemäß den Anforderungen an die Interoperabilität sind. Die Abbildung 94 gibt einen Überblick über die Architektur des Test Tools. Abbildung 94: WS-I Testing Tool Architektur Monitor Das Monitor Tool [Mo 2003] bietet zwei Komponenten: Message Interceptor und Message Logger. Der Message Interceptor schneidet die Kommunikation zwischen Web Service Client und Web Service mit. Der Message Logger wandelt die aufgezeichneten Nachrichten in ein Standardformat um und schreibt sie in ein Log File. Mit diesen zwei Komponenten ist das Monitor Tool in der Lage, Nachrichten von mehreren Web Services aufzuzeichnen. 257

258 Die Monitor Komponente erhält als einzige Eingabe eine Konfigurationsdatei. Dabei handelt es sich um eine XML-Datei, die die Monitor Komponente steuert. Die Datei gibt die Ports an, an denen die Nachrichten abgegriffen werden und definiert, an welchen Port die Nachrichten weitergeleitet werden. Außerdem beinhaltet das XML Dokument die Konfigurationsoptionen, die der Monitorkomponente sagen, welche Nachrichten aufgezeichnet und wo diese abgespeichert werden sollen. Bei der Benutzung des Monitors erscheint dieser für den Web Service Client wie der Web Service. Alle SOAP Nachrichten werden vom Web Service Client zum Monitor geschickt. Da dies für den Client kein üblicher Modus ist, gibt es drei Möglichkeit für die Umsetzung: Änderung des Clients, sodass er auf den Monitor anstatt auf den Web Service zeigt. An die Stelle des Web Service tritt der Monitor und der Service wird an einen anderen Ort verschoben. Änderung der Web Service Endpunktinformationen, die der Client nutzt. Abbildung 95: Monitor Systemkonfigurationen (vgl. [Br 2003]) Abhängig von der Systemkonfiguration kann der Monitor an vier unterschiedlichen Stellen laufen. Die Abbildung 95 verdeutlicht die unterschiedlichen Konstellationen Analyzer Das Analyzer Tool [An 2003] bestimmt durch das Verarbeiten so genannter Test Assertions, ob die Artefakte des Web Service konform gemäß des Profils sind. Eine Test Assertion ist eine Übersetzung einer oder mehreren Requirements von einem Profile, die vom Analyzer verarbeitet werden kann. Alle Test Assertions sind in einem Testdokument enthalten. Bei dem Dokument handelt es sich um eine XML-Datei, die entsprechend der Artefakte unterteilt ist. Der Analyzer erhält als Eingabe, wie das Monitor Tool, eine Konfigurationsdatei. Dieses XML-Dokument enthält die Konfigurationsoption, die dem Analyzer angibt, wo sich die Log-Datei der Nachrichten und das Testdokument befindet. Außerdem wird festgelegt, an welche Stelle der Conformance Report geschrieben wird. Außerdem gibt das Dokument an, wo sich die zu testenden Artefakte befinden bzw. welche überprüft werden sollen. 258

259 Die Ausgabe des Analyzers ist ein so genannter Conformance Report. Dieser Report enthält die Ergebnisse für alle Test Assertions, die durchgeführt wurden. Im Report werden sowohl detaillierte Informationen über die gefunden Fehler gelistet, als auch eine Zusammenfassung der Ergebnisse der Test Assertions geliefert. Die Zusammenfassung zeigt an, welche der Artefakte des Web Service den Konformitätstest bestanden haben und welche nicht. L o g F ile A n a ly z e r K o n fig. D a te i W S D L D o k u m en t A n a ly z e r T e st A sse r tio n D o k u m en t U D D I E in tr a g C o n fo rm a n ce R ep o rt Abbildung 96: Analyzer Tool Zukünftige Entwicklung der WS- I Profile WS-I Profile waren in der Vergangenheit und werden in der Zukunft ein wichtiges Thema sein bzw. bleiben. Die Organisationen haben ein großes Interesse an der Umsetzung plattformübergreifender, interoperabler Web Services, die sowohl innerhalb, als auch außerhalb der Organisation genutzt werden können, um ihre Investitionen langfristig zu sichern. Daher ist davon auszugehen, dass die Entwicklung neuer Profile und die Pflege der vorhandenen unvermittelt fortgeführt wird. Schon heute ist das Basic Profile in vielen Web Service Frameworks realisiert. Zur Zeit arbeitet WS-I an der Finalisierung des Basic Profiles 1.2. Das Basic Profile 1.2 ist eine Überarbeitung des WS-I Basic Profiles 1.1 und wird asynchronous Messaging beinhalten. Es basiert auf den den folgenden Spezifikationen: W3C WS-Addressing 1.0 Core, W3C WS-Addressing 1.0 SOAP Binding, W3C WS-Addressing 1.0 WSDL Binding, SOAP 1.1 Binding for MTOM 1.0. Zusätzlich wird an dem Basic Profile 2.0 gearbeitet. Es basiert auf SOAP 1.2 mit Message Transmission Optimization Mechanism (MTOM) und XML-binary Optimized Packaging (XOP). Beide Profile, BP 1.2 und BP 2.0, haben gegenwärtig den Status eines Working Group Approval Drafts erreicht. Parallel zu der Entwicklung der Basic Profiles wird auch die Entwicklung des Basic Security Profiles 1.1 vorangetrieben. Das Basic Security Profile 1.1 ist eine Erweiterung des Basic Security Profiles 1.0, das Leitlinien sowohl für die Verwendung von Web Services Security: SOAP Message Security 1.1, als auch für REL, Kerberos, SAML, Username und X.509Security Token-Formate gibt. Im Bereich des zuverlässigen und sicheren Nachrichtenaustausches wird die Finalisierung des Reliable Secure Profiles 1.0 angestrebt. 259

260 7 Sichere SOA Technologien in der Praxis Dieses Kapitel fokussiert sich auf die Nutzung von SOA Technologien bzw. Tools in der Praxis, mögliche SOA Angriffsszenarien sowie geeignete Abwehrmaßnahmen. 7.1 Sicherheit von Portalen als Schnittstelle zu SOAs Unternehmens- oder Behörden-Portale stellen in vielen Fällen die Schnittstelle zu Kunden, internen Mitarbeitern, Partnerunternehmen oder allgemein Internetnutzern dar, die sich informieren oder eine bestimmte elektronische Transaktion auslösen wollen. Über entsprechende Menüelemente können die Besucher innerhalb des Portals navigieren und das Ausführen bestimmter Aktionen initiieren. In der Regel erhält der Nutzer keine Kenntnis darüber, welche Prozesse im Detail im Hintergrund ablaufen. Er bekommt lediglich das Ergebnis seiner Handlung im Webportal angezeigt. Dabei können die Hintergrundprozesse mitunter sehr komplex sein. Portale integrieren mittlerweile häufig komplette Unternehmensanwendungen oder leiten Nachrichten an Web Services weiter, die dann für die automatisierte Durchführung komplexer Geschäftsprozesse verantwortlich sind. D.h. es findet immer mehr eine Kommunikation zwischen Portal und internen Systemen bzw. Web Services statt. Vor diesem Hintergrund ist es verstärkt wichtig, Sicherheitsmaßnahmen umzusetzen, die Angriffe auf das Portal und die dahinter liegenden internen IT-Systeme verhindern. In diesem Kapitel werden Sicherheitsthemen beschrieben, die bei der Nutzung von Portalen besonders relevant sind. Da eine detaillierte Behandlung der Themen Web Application Security und sichere Webanwendungsentwicklung an dieser Stelle zu weit führen würde, werden nachfolgend eine Auswahl wesentlicher Themen betrachtet. Auswahl und Einsatz geeigneter Software/Frameworks, Authentifizierung der Nutzer, Session-Management, Autorisierung der Nutzer, Verfügbarkeit/Ausfallsicherheit, Konfigurationsmanagement und Pflege von Software, Überprüfung von übermittelten Daten Auswahl und Einsatz geeigneter Software/Frameworks Portale können mittlerweile durch zahlreiche existierende Softwarelösungen (u.a. OpenSource-Produkte) realisiert werden. Neben den eigentlichen Funktionalitäten einer Portalsoftware besitzen die Lösungen meist grundlegende Authentifizierungs- bzw. Autorisierungsmechanismen, die innerhalb des Portals genutzt werden können, um eine Basis-Sicherheit zu gewährleisten. Des Weiteren unterstützen heutige Portal-Lösungen häufig viele gängige Sicherheitsverfahren und -mechanismen, indem sie entweder bereits in der Software integriert sind oder ggf. durch Erweiterungen (zum Beispiel mittels Plugins) genutzt werden können. In Abhängigkeit der umzusetzenden oder existierenden Gesamtarchitektur ist eine bestimmte Portalsoftware aufgrund ihrer Funktionalitäten, Eigenschaften und Sicherheitsmöglichkeiten mehr oder weniger gut für ein Unternehmen oder eine Behörde geeignet. Bei Auswahl einer geeigneten Portalsoftware ist hinsichtlich der Sicherheit 260

261 prinzipiell zu beachten, dass aktuell und zukünftig benötigte Sicherheitsprotokolle sowie Schnittstellen unterstützt werden, so dass Interoperabilitätsprobleme verhindert werden. Zum Beispiel sollte gewährleistet sein, dass die entsprechende Portalsoftware Authentifizierungsdaten gesichert, bspw. über SAML (siehe Kapitel 4.4.3) und WS-Security (siehe Kapitel 4.5.1), an Web Services im internen Netz des Unternehmens bzw. der Behörde weiterleiten kann. Zur Entwicklung von eigenen Portalen oder zur Anpassung und Erweiterung von bestehenden Portalen können so genannte Frameworks eingesetzt werden, die ein Programmiergerüst darstellen und die Programmierung von Webanwendungen vereinfachen. In der Regel haben diese Frameworks bereits bestimmte Authentifizierungs- und Autorisierungsmechanismen integriert, die für das Portal komfortabel genutzt werden können. Eine Eigenimplementierung von Sicherheitsmechanismen ist daher in den meisten Fällen nicht notwendig. Damit auch zukünftige Anforderungen an die Sicherheit erfüllt werden, bietet sie zudem meist die Möglichkeit, eine Anpassung der genutzten Sicherheitsfunktionalitäten vorzunehmen oder die entwickelte Anwendung um neue Sicherheitsverfahren zu erweitern Authentifizierung von Nutzern Portale eröffnen einem Nutzer in der Regel eine Reihe von Interaktionsmöglichkeiten, indem sie spezielle Funktionalitäten bzw. Dienste gebündelt bereitstellen. Eine Authentifizierung wird meist dazu verwendet, um Nutzern das Recht zu geben, auf einen individuellen Bereich zuzugreifen und bestimmte Aktionen auszulösen. Beispielsweise kann ein Mitarbeiter nach einer erfolgreichen Authentifizierung am Unternehmensportal auf sein -Postfach zugreifen und s unter seiner Firmenadresse versenden. Des Weiteren ist es vorstellbar, dass diese Person eine Reise über das interne Reisesystem bucht, wodurch über einen speziellen Web Service die Bezahlung mit den hinterlegten Kreditkartendaten automatisiert durchgeführt wird. An den Beispielen wird deutlich, dass eine Authentifizierung zwingend notwendig ist und sicher durchgeführt werden muss. Bei der Entwicklung von Portalen ist daher insbesondere darauf zu achten, dass für die Authentifizierung sichere Algorithmen, Protokolle und Technologien genutzt werden. Ein Identitätsbetrug muss verhindert werden, damit kein Schaden durch unberechtigte Aktionen entstehen kann. Verwendung starker und aktueller Authentifizierungsmechanismen Häufig werden zur Authentifizierung an Portalen Benutzername/Passwort-Kombinationen verwendet. In diesen Fällen ist sicherzustellen, dass Angriffe durch Brute-Force oder Dictionary Attacken erkannt bzw. verhindert werden. Es sollten daher sichere Passwörter gewählt werden (ausreichende Länge, Kombination aus Buchstaben und Ziffern, usw.). Des Weiteren können Intrusion Detection Systeme eingesetzt werden, um wiederholte Authentifizierungsversuche zu erkennen und abzublocken. Um generell die o.g. Angriffe zu vermeiden, sollten nach Möglichkeit stärkere Authentifizierungsverfahren als eine Nutzername/Passwort-Kombination eingesetzt werden, beispielsweise durch Nutzung einer PKI. Erhöht werden kann die Sicherheit auch durch eine Mehrfaktor-Authentifizierung (z.b. Passwort in Kombination mit einem Hardware-Token). In heutigen Architekturen wird häufig das Ziel verfolgt, ein Single Sign-On zu ermöglichen. D.h. der Nutzer muss sich nur einmal an einem Dienst/Portal anmelden und kann dann weitere Dienste ohne erneuten Login nutzen. Eine Möglichkeit der Realisierung für ein Single Sign-On ist die Nutzung eines Identity Providers, d.h. einer Instanz, die Identitäten verwaltet. Möchte ein Nutzer sich z.b. an einem Web-Portal anmelden, wird dieser zunächst auf eine Seite seines Identity Providers weitergeleitet, bei dem er sich einloggen muss. Der 261

262 Identity Provider leitet daraufhin (z.b. mittels SAML) an das Portal entsprechende Authentifizierungsdaten (Token) weiter, so dass der Nutzer am Portal angemeldet wird. D.h. das Portal muss die Authentifizierungsinformationen empfangen, interpretieren und ggf. an eine bestimmte Komponente oder einen Dienst weiterleiten können. Innerhalb des Kapitels 6.4 werden die Verwaltung von digitalen Identitäten und aktuelle Authentifizierungsverfahren in einer SOA näher behandelt. Je nachdem welches Verfahren genutzt werden soll, hat dies unmittelbare Auswirkung auf das Portal, das entsprechende Funktionalitäten unterstützen muss. Sichere Weiterleitung von Authentifizierungsdaten Müssen Nutzer-Kennungen (Credentials) zwischen verschiedenen Systemen, z.b. wie im o.g. Szenario zwischen Identity Provider und Portal oder Portal und Web Service übertragen werden, ist neben der Interoperabilität die sichere Kommunikation (Propagation) der Daten zu gewährleisten. Nutzer-Kennungen wie das Passwort sollten immer verschlüsselt übertragen werden, so dass ein Angreifer keine sensitiven Daten einer Nachrichtenkommunikation (Authentifizierungsprozess) mitlesen kann. Ferner ist zu gewährleisten, dass Replay-Angriffe erfolgreich abgewehrt werden, d.h. für einen Angreifer darf es nicht möglich sein, Nachrichten mit Credentials abzufangen und wiederverwenden zu können. Dies kann z.b. durch die Verwendung von Zeitstempeln verhindert werden. Kontrolle von Nutzerregistrierungen Oftmals ist es erforderlich, dass Nutzer zunächst durch eine Registrierung einen Account eröffnen müssen, um sich später an dem entsprechenden Portal authentifizieren und auf die angebotenen Funktionen zugreifen zu können. Dies ist z.b. bei Social Network Plattformen oder kostenlosen Mail Service Providern der Fall. Häufig werden durch spezielle Computerprogramme (Bots) gefälschte Accounts eröffnet, um anschließend innerhalb des Portals und mittels dessen Funktionalitäten einen Betrug oder Angriff durchzuführen. Verhindert bzw. zumindest erschwert werden kann dies durch Verwendung so genannter Captchas. Captchas werden eingesetzt, um zwischen Mensch und Computer(programm) zu unterscheiden. Bei Captchas handelt es sich meist um Bilder, die Buchstaben/Ziffern in verzerrter Form darstellen. Von dem Nutzer sind die entsprechenden Zeichen korrekt einzugeben, bevor ein Account eröffnet werden kann. Der Einsatz von Captchas oder alternativen Prüfverfahren bietet sich generell an, wenn automatisierte Eingaben durch Bots erschwert werden sollen. Eine verlässliche Sicherheit bieten allerdings nur Verfahren mit einer vertrauenswürdigen Authentifizierung bzw. Registrierung wie dies z.b. im Bereich der qualifizierten Signatur oder beim elektronischen Personalausweis der Fall ist Session-Management Webanwendungen wie z.b. Portale nutzen häufig Sessions, um einem Nutzer bzw. dessen Client-Anwendung über einen längeren Zeitraum den Zugriff auf bestimmte Ressourcen oder Funktionalitäten zu gewähren. Durch die Verwendung von Sessions wird verhindert, dass sich ein Nutzer bei neuen Anfragen wiederholt bei der Webanwendung authentifizieren muss (z.b. durch erneute Eingabe von Benutzername und Passwort). Damit ein Client wiedererkannt wird, weist der Server diesem nach erfolgreicher initialer Authentifizierung eine eindeutige Kennung zu. Wichtig ist, dass diese Kennung nur für die Dauer der Nutzung gültig ist und nicht durch eine dritte Person verwendet werden kann. Sichere Übertragung von Session-Informationen 262

263 Sessioninformationen sollten stets gesichert übertragen werden, um zu verhindern, dass Angreifer eine Session übernehmen können (Session Hijacking). Findet keine verschlüsselte Übertragung der Session-ID (gültige Kennung für eine Sitzung) statt, könnte ein Angreifer durch Abfangen der Nachricht relevante Daten extrahieren und diese für eine eigene Kommunikation mit dem Zielsystem verwenden. Sicheres Beenden von Sessions Auf der Seite des Portals muss gewährleistet sein, dass Sessioninformationen nach Beendigung der Session gelöscht werden (bzw. nach einer festgelegten maximalen Nutzungsdauer). Anderenfalls wäre eine Nutzung des Portals und der angebotenen Funktionalitäten über den Berechtigungszeitraum hinaus möglich Autorisierung der Nutzer Nach einer erfolgreichen Authentifizierung am Portal hat der Nutzer bestimmte Rechte, die es ihm erlauben, auf freigegebene Daten zuzugreifen bzw. festgelegte Aktionen durchzuführen. Ein Projektmitarbeiter kann beispielsweise auf die Ergebnisdokumente seines Projektes zugreifen, jedoch nicht auf die vertraulichen Unterlagen eines fremden Projektes. Umgesetzt wird dies durch ein durchdachtes Rechtesystem und entsprechende Mechanismen hinsichtlich der Zugriffssteuerung. Bei der technischen Realisierung ist sicherzustellen, dass ein Nutzer tatsächlich nur auf die Ressourcen und Funktionalitäten zugreifen darf, für die er die notwendigen Berechtigungen besitzt. Es darf nicht möglich sein, durch Ausnutzen von Sicherheitslücken erweiterte Rechte zu erlangen (Elevation of Privilege), so dass unter Umständen vertrauliche Daten eingesehen werden können (Information Disclosure). Bei der Entwicklung von Portalen ist daher insbesondere darauf zu achten, dass für die Autorisierung sichere Algorithmen, Protokolle und Technologien genutzt werden. Falls Autorisierungsmechanismen nicht korrekt implementiert werden, besteht außerdem die Gefahr, dass eine Manipulation von Daten unbemerkt stattfindet. Sichere Durchführung der Autorisierung In Abhängigkeit der implementierten Architektur, wird die Zugriffssteuerung durch eine oder mehrere Komponenten innerhalb des Gesamtsystems übernommen. Heutige Portallösungen haben in der Regel bereits eine Rollen-basierte Zugriffssteuerung integriert, die den Zugriff auf Webseiten (URLs) für bestimmte Nutzer erlauben oder verbieten kann. Die Nutzer bekommen ferner innerhalb eines Portals nur die Bereiche zu sehen und jeweiligen Funktionen bereitgestellt, für die sie autorisiert sind. D.h. ein Nutzer kann zum Beispiel nur einen bestimmten Dienst über seinen Portalbereich aufrufen, wenn eine entsprechende Menüfunktion dort vorhanden ist. Ein Nutzer könnte potenziell jedoch diesen Mechanismus im Portal umgehen und versuchen, den Dienst bei Kenntnis der nötigen Serviceparameter direkt aufzurufen. Um diese Möglichkeit zu verhindern, sollte eine Authentifizierung des Portals vom Dienst durchgeführt werden, so dass alle Aufrufe, die nicht vom Portal stammen, erkannt und abgelehnt werden. Des Weiteren kann der Dienst durch eine Autorisierung gewährleisten, dass nur die Daten an das Portal übermittelt werden, die der Nutzer einsehen darf. Bei einer Service-orientierten Architektur ist es zudem wichtig, dass relevante Organisationsrichtlinien korrekt auf technische Policies abgebildet und durch die Dienste umgesetzt werden. Ist dies nicht gewährleistet und liegen beispielsweise fehlerhafte ZugriffsPolicies vor, werden unter Umständen vertrauliche Informationen an das Portal übermittelt, so dass angemeldete Nutzer einen unberechtigten Zugriff auf diese Daten erhalten. 263

264 Generell müssen Hintergrundsysteme ausreichend gesichert sein, so dass weder über das Portal, noch über andere Dienste oder über einen direkten Zugriff, Informationen an nicht autorisierte Personen übermittelt werden. Sichere Weiterleitung von Informationen zur Autorisierung Ein Portal übernimmt im Zusammenhang mit der Autorisierung meist die Aufgabe, Informationen über den Nutzer und die angefragte Ressource weiterzuleiten, so dass z.b. anhand einer Datenbank oder mittels Policies überprüft werden kann, ob der Nutzer auf die Ressource zugreifen darf. Da bei diesem Prozess sicherheitsrelevante Informationen zur Identität des Nutzers sowie dessen Zugriffsrechte zwischen den beteiligten Systemen übertragen werden, müssen geeignete Schutzmaßnahmen eingesetzt werden. Durch verschlüsselte und signierte Nachrichten kann die Vertraulichkeit sowie die Integrität gewährleistet werden. D.h. Dritte können die Nachrichten nicht unbemerkt manipulieren (z.b. Zugriffsrechte ändern) bzw. den Zugriff auf Ressourcen überwachen (Verhinderung eines Trackings). Innerhalb einer Service-orientierten Architektur könnte ein Portal zum Beispiel Authentifizierungsdaten mit Attributen über SAML gesichert an einen Dienst weiterleiten, der dann auf Basis von Policies entscheidet, ob ein Zugriff auf eine Ressource erfolgen darf Verfügbarkeit/Ausfallsicherheit Verfügbarkeit des Portals Stellt ein Portal den Einstiegspunkt für die Durchführung von Geschäftsprozessen dar, so ist dessen Verfügbarkeit als kritischer Faktor anzusehen. Es müssen daher verstärkt Sicherungsmaßnahmen umgesetzt werden, um insbesondere Denial of Service Attacken und damit die Nicht-Erfüllbarkeit von Leistungen zu verhindern. Sichere Konfiguration der Server, Einsatz von Paket-Filtern oder eine automatische Angriffserkennung mittels Intrusion Detection Systemen sind in diesem Zusammenhang geeignete Maßnahmen zur Bekämpfung solcher Angriffe. Da die Verfügbarkeit eines Portals ferner durch Hard- und Softwarefehler beeinträchtigt werden kann, sollten redundante bzw. entsprechende Backup-Systeme vorhanden sein. Für besonders schwerwiegende Vorfälle sollte ein Notfallkonzept existieren, so dass ein ordnungsgemäßer Betrieb schnellstmöglich wiederhergestellt werden kann. Neben Problemen wie ausgefallene Systemkomponenten, Denial of Service Angriffe, usw. kann zum Beispiel eine starke Nutzung des Portals zu einer verzögerten Durchführung der Geschäftsprozesse führen. In diesen Fällen bietet sich an, die Last auf verschiedene Systeme zu verteilen (Load Balancing). Verfügbarkeit von Hintergrundsystemen Hintergrundsysteme/Web Services, die zur Leistungserbringung erforderlich sind, müssen ebenfalls wie das Portal eine hohe Verfügbarkeit aufweisen. Fallen wichtige Hintergrundsysteme aus, kann unter Umständen ein Geschäftsprozess nicht mehr durchgeführt werden. Dies kann unmittelbare Auswirkung auf das Portal haben. Soll zum Beispiel durch einen Dienst die Verfügbarkeit von Produkten ermittelt werden und ist dieser Dienst nicht verfügbar, so kann dem Nutzer über das Portal kein Lagerbestand angezeigt werden. Für Web Services sind demzufolge o.g. Sicherheitsmaßnahmen ebenfalls relevant. 264

265 7.1.6 Konfigurationsmanagement und Pflege von Software Anpassung von Standardkonfigurationen Fehlerhafte oder unzureichende Konfigurationen in Webanwendungen führen häufig dazu, dass Angriffe überhaupt erst möglich sind. Oftmals sind Sicherheitslücken auf das Verwenden von Standardkonfigurationen zurückzuführen, die nicht umfassend genug Sicherheitsbeschränkungen festlegen. Aus diesem Grunde sind durch den Administrator die Konfigurationsoptionen gründlich an die jeweiligen Anforderungen anzupassen. Zugriffsbeschränkungen auf Administrationstools Häufig verwenden IT-Verantwortliche zur komfortableren Administration von Webanwendungen/Portalen existierende bzw. bereits integrierte (grafische) Tools. In diesem Fall ist es wichtig, dass diese ausreichend vor unberechtigtem Zugriff geschützt sind. Andernfalls könnte ein Angreifer unter Umständen erhebliche Manipulationen am Portal bewirken. Ausnahmebehandlung (Error Handling) Analog zu Web Services sollten Webanwendungen bzw. Portale möglichst wenig Informationen (z.b. keine Versionsnummern) durch Fehlernachrichten oder Stacktraces veröffentlichen. Angreifer könnten durch entsprechende Informationen bei der Suche nach geeigneten Sicherheitslücken unterstützt werden. Demzufolge sollten die Webanwendungen so konfiguriert sein, dass alle kritischen Fehlermeldungen lediglich serverseitig protokolliert werden. Protokollierung Nach Möglichkeit sollten in einem Portal nicht nur die Fehler der Webanwendung, sondern auch die Anfragen auf Ressourcen protokolliert werden. Dabei ist jedoch sicherzustellen, dass keine sensiblen Daten der Nutzer enthalten sind und die Anforderungen an den Datenschutz beachtet werden. Die Logdateien sollen letztlich dazu dienen, Angriffe zu entdecken und die Suche nach potenziellen Sicherheitslücken zu unterstützen. Pflege von Software und Konfigurationen Es ist darauf zu achten, dass kontinuierlich der Überblick über die eingesetzte Software sowie deren Konfigurationen (z.b. Zugriffsregeln) gewahrt bleibt. Ist dies nicht der Fall, ist die Wahrscheinlichkeit groß, dass bestimmte Ressourcen z.b. aufgrund geänderter IT-Strukturen nicht mehr ausreichend geschützt sind. Eine wesentliche Aufgabe des Konfigurationsmanagements betrifft die Pflege der Portalsoftware. Aktuelle Updates und Patches sind einzuspielen, um vorhandene Sicherheitslücken (wie z.b. Buffer Overflows) zu schließen. Bei Einsatz von kryptografischen Verfahren ist darauf zu achten, dass stabile und ausreichend sichere Protokolle und Standards (z.b. hinsichtlich der Schlüssellänge) eingesetzt werden. Falls sich ein Verfahren als nicht mehr sicher herausstellt, ist dieses durch einen geeigneten alternativen Sicherheitsmechanismus zu ersetzen. Zudem ist nach der Implementierung von Sicherheitsverfahren jeweils deren korrekte Anwendung zu überprüfen, da oftmals durch falsche Konfigurationen unwissentlich der gewünschte Schutz verfehlt wird. Zur Realisierung der Kommunikation zwischen Portal und Web Service können Anpassungen in der Software nötig sein, um die nötige Kompatibilität für einen sicheren Austausch von Nachrichten zu ermöglichen. 265

266 Da ein unzureichendes Konfigurationsmanagement von Portalen zu unmittelbaren Risiken für die angebundenen Web Services und IT-Systeme führen kann, sollten innerhalb der Organisation kontinuierlich Konfigurationen überprüft und bei Bedarf angepasst werden Überprüfung von übermittelten Daten Innerhalb von Portalen besitzt ein Nutzer in der Regel die Möglichkeit, Daten zu übermitteln. Diese werden dann häufig an eine Anwendung im Backend weitergereicht und verarbeitet. Bei Nutzung von Web Services werden die Daten üblicherweise in eine XML-Nachricht überführt und an den entsprechenden Dienst weitergeleitet. Systeme, Anwendungen und Dienste, die diese vom Nutzer übermittelten Daten empfangen und weiterverarbeiten, sind dabei potentiell von so genannten Injection Attacks bedroht. Bei dieser Angriffsmethode werden schadhafte Code-Inhalte als Eingabewerte übermittelt, so dass entsprechende Systeme betroffen sind, die diesen Code ausführen. Meist handelt es sich um Hintergrundsysteme wie z.b. Datenbanken, an die entsprechende Nachrichten weitergereicht werden. Nachfolgend wird an einem Beispiel-Code veranschaulicht, wie eine SQL Injection Attack aussehen könnte. Beispiel: Bei Eingabe des Ortes Bonn in einer Suchmaske des Portals würde z.b. folgender SQL Befehl ausgeführt werden: SELECT * FROM Benutzer WHERE Ort = 'Bonn' Das Ergebnis wäre eine Ausgabe aller Benutzer, bei denen der Ort Bonn angegeben ist. Gibt ein Angreifer jedoch folgendes ein: Bonn'; DROP TABLE Benutzer -- so resultiert dieses SQL-Statement: SELECT * FROM Benutzer WHERE Ort = 'Bonn'; DROP TABLE Benutzer --' Die Eingabe bewirkt nun zwei separate Befehle, die durch das Semikolon getrennt sind. Es würde zwar immer noch eine Ausgabe aller Benutzer des Ortes Bonn erfolgen, allerdings würde durch den 2. Teil des Statements die gesamte Tabelle Benutzer anschließend gelöscht werden (vorausgesetzt die Webanwendung besitzt die nötigen Datenbankrechte). Vor diesem Hintergrund sollten zwangsläufig alle Eingaben bzw. URL-Aufrufe von Nutzern überprüft und ggf. gefiltert werden. Neben dem o.g. SQL Injection Angriff existieren weitere zahlreiche Injection Angriffe, die die Sicherheit von Daten einer Organisation als auch des Nutzers gefährden können (z.b. LDAP Injection, OS Commanding, Cross Site Scripting, usw.). Zur Durchführung der Filterung können zum Beispiel entsprechende Appliances (Hard- und Software) eingesetzt werden oder Module direkt in das Portal integriert werden. 7.2 Methoden und Möglichkeiten der XML-/WS-*-Filterung Angesichts bestehender Gefahren im SOA Umfeld (vgl. Kapitel 3.3) bietet die Filterung von XML Nachrichten eine mögliche Gegenmaßnahme. Im folgenden Kapitel werden Filtermethoden und darauf basierende Mechanismen zur Filterung von SOAP Nachrichten beschrieben. Die Filtermethoden sind klassische Methoden aus dem Bereich der Intrusion 266

267 Detection Systeme, welche bei der WS-*-Filterung Anwendung finden können. Die Filtermechanismen sind spezifische Web Service/XML-orientierte Vorgehensweisen, die im SOA Bereich verwendet werden. Weiterführend wird das Konzept des WS-SecurityGateways als mögliche Architekturkomponente für die Umsetzung der Filtermechanismen erläutert. Zum Abschluss des Kapitels werden ausgewählte Angriffe auf Web Services beschrieben, denen mit der Möglichkeiten der XML-/WS-*-Filterung entgegengewirkt werden kann Klassische Filtermethoden Es gibt verschiedene Methoden, um eine Filterung von SOAP Nachrichten durchzuführen. In den letzten Jahren sind die Konzepte von Intrusion-Detection-Systemen (IDS) und Filtersystemen wie Firewalls immer weiter angeglichen worden. Grundsätzlich wird zwischen Signatur-basierter Filterung und Anomalie-basierter Filterung von Nachrichten unterschieden. Die Filtermethode einer Firewall etwa nutzt einen simplen Signatur-basierten Mechanismus zur Erkennung von zugelassenen Nachrichten. Dies ist die einfachste Methode und wird etwa bei Firewalls oder Application-Layer-Gateways, welche eine Filterung auf der Anwendungsebene durchführen, eingesetzt. Sie ist zudem sehr zuverlässig. Dabei werden alle Nachrichten gefiltert, welche bestimmten Mustern, so genannten Signaturen entsprechen. Die Anomalie-basierte Filterung kommt aus dem Bereich der Intrusion-Detection-Systeme und basiert auf Normalwerten sowie erlaubten Abweichungen Signatur-basierte Filterung Bei der Signatur-basierten Filterung werden Nachrichten basierend auf bestimmten Regeln/Mustern gefiltert. Allgemein bedeutet das, dass Nachrichten, welche einem konkreten Muster (Signatur) entsprechen, entweder zugelassen oder abgewiesen werden. Ein solches Muster besteht aus einer Menge von logischen Aussagen sowie einer Aktion. Muster: Aussagen Aktion Die Aussagen beschreiben mögliche Eigenschaften einer Nachricht und können beliebig logisch verknüpft werden. Die folgende Aussage trifft auf alle Nachrichten zu, deren WSAAction gleich IssueTokenResponse und deren SAML-Issuer ungleich ist. wsa.action=issuetokenresponse saml.issuer!= Einige mögliche Aktionen basieren auf bekannten Filtersystemen wie Firewalls und sind u.a: DROP Verwerfen der Nachricht, ACCEPT Zulassen der Nachricht, ERROR Verwerfen der Nachricht und Verschicken einer Fehlerbeschreibung an den Sender, LOG Zulassen der Nachricht und Meldung, ALERT Verwerfen der Nachricht und Meldung. Nachrichten, welche der Signatur entsprechen, werden wie in der Aktion beschrieben, behandelt. Es kann viele weitere Aktionen geben, die in einem solchen Fall durchgeführt werden. Der zu filternde Angriff muss bei dieser Methode in jedem Fall vorher bekannt und 267

268 mit einer geeigneten Signatur beschrieben sein. Bekannte Mechanismen, welche Signaturbasierte Filterung benutzen können, sind Virusfilter, Firewalls, Policy-Enforcement und SOAP Validation Anomalie-basierte Filterung Bei der Anomalie-basierten Filterung werden Nachrichten basierend auf der Erkennung so genannter Anomalien gefiltert. Eine Anomalie ist die Abweichung eines Parameters während eines Angriffs von den Werten während des Normalbetriebes. Die Werte des Normalbetriebes werden oft durch Messungen vorab ermittelt. Zusätzlich muss eine erlaubte Abweichung (ein so genannter Threshold) geeignet festgelegt werden. Die Werte der Parameter werden dann zur Laufzeit überwacht und bei Überschreitung des Thresholds werden betreffende Nachrichten gefiltert. Eine Anomaliebeschreibung besteht mindestens aus einem Normalwert für einen Parameter, einer erlaubten Abweichung sowie einer Aktion, welche bei Zutreffen der Abweichung durchgeführt wird. Anomalie: Parameter Normalwert Erlaubte Abweichung Aktion. Der Parameternormalwert beschreibt einen bestimmten Parameter einer Nachricht oder eines Nachrichtenstroms in Zusammenhang mit einer Aussage. Eine mögliche Anomaliebeschreibung sagt aus, dass n Authentifizierungsanfragen pro Stunde als normal beschrieben werden. Dieser Wert sollte vorab mittels statistischer Methoden ermittelt werden. Eine erlaubte Abweichung könnte in diesem Fall m sein und müsste durch die Analyse der Authentifizierungsanfragen über die Zeit (besonders die Anfragenpeaks) ermittelt werden. Oft muss dieser Wert auch im Nachhinein nochmals angepasst werden. Mögliche Aktionen sind identisch mit denen in der Signatur-basierten Filterung. Die Anomalie-basierte Methode hat den Vorteil, dass Angriffe vorher nicht bekannt sein müssen und auch ohne eine gültige Signatur gefiltert werden können. Die Ungenauigkeit dieser Methode birgt aber die Gefahr, dass auch Nachrichten gefiltert werden, welche durch das ungefährliche/herkömmliche Benutzen von Web Services entstehen. Weiterhin könnten unter Umständen bestimmte Angriffe nicht gefiltert werden, wenn der Treshold zu hoch eingestellt ist Filtermechanismen zur Prüfung von Web Service Nachrichten Im Kontext von Web Services gibt es zwei wichtige Mechanismen, welche zur Filterung von Inhalten eingesetzt werden können: Policy-Enforcement und XML-Schema-Validation. Zusätzlich zu diesen Mechanismen kann eine normale Stream-basierte Filterung von Inhalten durchgeführt werden, welche auf dem bitweisen Untersuchen von Nachrichten basiert. Die Stream-basierte Filterung gleicht den Filtermethoden von IDS oder Firewalls. Die Filtermechanismen basieren oft auf den klassischen Filtermethoden XML-Schema Validation Mittels XML Schemata kann die Struktur von XML Dokumenten abstrakt beschrieben werden. Es gibt verschiedene Ausprägungen solcher Beschreibungen, beispielsweise XML Schema Definition (XSD) oder Document Type Definition (DTD). Anhand solcher 268

269 Strukturbeschreibungen kann ein XML Dokument relativ einfach validiert werden. Dies wird durch die Prüfung der einzelnen XML Elemente auf Konformität zur vorliegenden Strukturbeschreibung umgesetzt. SOAP Nachrichten können so beispielsweise zur Laufzeit einfach auf Konformität zum SOAP Standard überprüft werden und erst bei erfolgreicher Validierung an einen Empfänger weitergeleitet werden. Das XML Schema könnte man hier als Signatur verstehen, welche die Aktion ACCEPT bei Übereinstimmung von Signatur und Nachricht ausführt Policy-Enforcement Beim Policy-Enforcement wird anhand bestimmter Konfigurationen dafür gesorgt, dass die Sicherheitsrichtlinien eines Unternehmens eingehalten werden. Im SOA-Umfeld bedeutet dies beispielsweise, dass Sicherheitsanforderungen an einen Dienst durch eine geeignete Konfiguration spezifiziert und durch spezielle Mechanismen geeignet umgesetzt werden. Ein Dienst, welcher nur authentifizierten Personen zugänglich sein darf, muss gegen unberechtigten Zugriff abgesichert sein, z.b. mittels WS-SecurityPolicy Beschreibungen und einem Policy Enforcement Point (PEP), welcher diese umsetzt. Es wird zwischen Policies für kommunikationsspezifische und Policies für dienstinterne Anforderungen unterschieden. Policies für kommunikationsspezifische Anforderungen umfassen die Beschreibungen, die beispielsweise Vertraulichkeit von Nachrichten auf dem Kommunikationskanal sicherstellen. Policies für dienstinterne Anforderungen umfassen die Beschreibungen, die beispielsweise eine Authentifizierung des Nutzers erzwingen. Eine Policy kann unter Anderem aus einer Signatur oder einer Anomaliebeschreibung bestehen. Beispielsweise wäre eine Policy, die auf eine bestimmte Menge von Authentifizierungszugriffen beschränkt, eine einfache Anomaliebeschreibung. In Kapitel wurden verschiedene Architekturen zur Durchsetzung von Policies vorgestellt: PEP als Bibliothek, PEP als Modul, PEP als Gateway. Basierend auf den bekannten Konzepten für Policy-Enforcement, wird im Folgenden das Konzept des PEP als WS-Security-Gateway näher erläutert, da dieses einige Vorteile mit sich bringt WS-Security-Gateway - Architektur und Konzept Es gibt verschiedene Methoden und Möglichkeiten zur Filterung einer SOAP Nachricht vor der eigentlichen Verarbeitung durch den Web Service. Eine Möglichkeit ist die Filterung von SOAP Nachrichten im Dienst selbst, indem dieser die nötigen Bibliotheken selber benutzt. Als eine weitere Möglichkeit können verschiedene Module/Handler in einer Verarbeitungskette (Handler-Chain Apache Axis2) vor den eigentlichen Service integriert werden, um die SOAP Nachricht auf schädliche Inhalte zu untersuchen. Beide Konzepte haben den Nachteil, dass eine potentiell schädliche SOAP Nachricht bereits auf dem verarbeitenden Server eingegangen ist, und gegebenenfalls Schaden anrichten kann. Ein weiteres Konzept ist die Einführung eines WS-Security-Gateways. Ein solches Gateway würde als separates Sicherheitssystem operieren und alle eingehenden (bzw. ausgehenden) Nachrichten auf schädliche Inhalte prüfen. Das Prüfen wäre so komplett vom eigentlichen Verarbeiten separiert und ein Angriff könnte nur begrenzt Schaden anrichten. Ein WSSecurity-Gateway kann die Eingangs beschriebenen Filtermethoden und Mechanismen benutzen, um Web Service Anfragen zu erkennen und bei Bedarf zu Filtern. 269

270 Abbildung 97: WS-Security-Gateway Deployment Ein WS-Security-Gateway besteht aus den folgenden Komponenten: Policy-Enforcement-Komponente, Policy-Konfiguration, SOAP Validator, Schema-Speicher, Filter-Komponente, Filter-Regeln, Reporting-Komponente. Die Policy-Enforcement-Komponente setzt konkrete Security-Policies des Unternehmens um, welche in der Policy-Konfiguration festgehalten sind. Mögliche Beispiele wären eine Zugriffsbeschränkung eines Services zu bestimmten Uhrzeiten bzw. bezüglich der Häufigkeit von Anfragen oder eine vorher nötige Authentifizierung eines Clients. Der SOAP Validator erkennt nicht valides SOAP anhand eines Vergleichs mit den Schema-Beschreibungen, welche im Schema-Speicher enthalten sind. Die Filter-Komponente erkennt streambasiert schadhafte SOAP Nachrichten anhand der Filter-Regeln, welche abhängig von der Erkennungsmethode (Signatur-basiert oder Anomalie-basiert) unterschiedliche Ausprägungen haben können. Die Reporting-Komponente protokolliert und meldet jede Filterung einer SOAP Nachricht, um Angriffe später nachvollziehen zu können. Abbildung 98 zeigt den Aufbau eines WS-Security-Gateways. 270

271 Abbildung 98: Architektur eines WS-Security-Gateways Der Einsatz eines solchen Gateways bringt von praktischer Seite einige Vorteile mit sich. Zum einen ist das System separiert und schirmt im Angriffsfall die eigentlichen Web Services ab. Weiterhin bietet es vielfältige Möglichkeiten, alle eingehenden Nachrichten zu protokollieren und zu filtern. Ein solches Gateway ist einfach erweiterbar, da es auf leicht konfigurierbaren Regeln basiert und unabhängig von den eigentlichen Services betrieben wird. Zusätzlich ist der Managementaufwand verhältnismäßig gering, da hier eine zentrale Komponente konfiguriert werden muss, und nicht eine Vielzahl verteilter Services. Die Zentralität des Konzeptes bringt allerdings auch einige Nachteile mit sich. Zum einen stellt dieses Gateway einen Single-Point-of-Failure dar: sobald dieses System ausfällt, sind alle von dem System geschützten Web Services nicht mehr erreichbar. Zur Erhöhung der Ausfallsicherheit sollte dieses System redundant vorhanden sein bzw. ein FallbackMechanismus integriert werden. Außerdem kann dieses System gezielt in den Fokus potentieller Angreifer rücken, da viele sicherheitsrelevante Informationen sowie Konfigurationen kompromittiert werden können Filterbare Bedrohungen und Risiken für Web Services Es gibt zahlreiche Bedrohungen und Risiken für Service-Orientierte Architekturen und Web Services. Basierend auf Kapitel 3.3 werden im Folgenden einige dieser Risiken genauer vorgestellt und mögliche Erkennungsmethoden basierend auf der WS-Filterung erläutert. Die Angriffe sind beispielhaft ausgewählt und werden bezüglich der Erkennungsmethode gruppiert, kurz vorgestellt und durch spezifische Eigenschaften charakterisiert Angriffe durch die überdurchschnittliche Nutzung von Services Die im Folgenden beschriebenen Angriffe benötigen zur Durchführung eine große Anzahl von Nachrichten. Neben dem Web Service Interface Probing (siehe Kapitel 3.3.1) wird zusätzlich der Bruteforce Angriff auf einen Identitätsprovider beschrieben. Beim Web Service Interface Probing wird eine Web Service Schnittstelle mittels iterativem Probieren auf Schwachstellen untersucht. Eine mögliche Methode ist das so genannte Fuzzing, welches durch zufälliges Erzeugen von Eingabewerten für die einzelnen Parameter einer Web Service Schnittstelle diese auf Fehler in der Implementierung überprüft. Je mehr verschiedene Eingabewerte man probiert, desto höher ist die Wahrscheinlichkeit, eine 271

272 Schwachstelle zu finden, wobei ein solcher Test nie garantieren kann, dass alle Schwachstellen entdeckt werden. Nach dem Finden einer Schwachstelle kann der Angreifer versuchen, diese mit herkömmlichen Methoden auszunutzen. Ein Bruteforce Angriff auf einen Identity Provider unterscheidet sich im Wesentlichen nicht von einem herkömmlichen Bruteforce Angriff auf einen normalen Nutzer-Account, etwa einen -Account im Internet. Der Angreifer benutzt ein Wörterbuch oder eine beliebig generierte Folge von Passwörtern, um das Passwort eines Benutzer-Accounts zu erraten. Befindet sich das Passwort in dem Wörterbuch oder in der generierten Folge, dann kann der Angreifer Zugriff auf den Benutzer-Account erlangen und weiteren Schaden anrichten. Auch hier erhöht die Anzahl der Versuche die Chance, das richtige Passwort zu finden. Somit muss der Angreifer viele Anfragen an den Identity Provider stellen, bis er von diesem erfolgreich authentifiziert wird. Beide Angriffe erzeugen eine große Anzahl an Nachrichten, welche einfach durch Anomaliebasierte oder Signatur-basierte Methoden zu erkennen und somit auch zu filtern sind. Beispielsweise kann der normale Mittelwert für Authentifizierungsanfragen an einen Dienst bei n pro Stunde liegen. Ein Angreifer würde mit einem solchen Angriff wesentlich mehr Anfragen erzeugen und wäre so leicht erkennbar. Nach Überschreiten eines Schwellwertes von beispielsweise m zusätzlichen Anfragen könnten alle folgenden Anfragen (bezüglich eines Accounts) verworfen werden. Ebenfalls wäre eine Signatur denkbar, welche mehr als m Authentifizierungsversuche von einem Benutzer/einer IP erkennt, wobei im Folgenden alle weiteren Anfragen temporär verworfen werden könnten. Anomalie: AuthNW=n/h S=m A=DROP mit AuthNW gemessener Normalwert für Authentifizierungsanfragen, S konfigurierter Schwellwert, A konfigurierte Aktion Replay-Attacken Unter einer Replay-Attacke versteht man das wiederholte Einspielen einer Nachricht an einen Dienst, welcher nicht zwischen zwei identischen Nachrichten zeitlich unterscheidet. Ein Beispiel ist eine wiederholt eingespielte Authentifizierungsnachricht eines Benutzers an einen AuthenticationService eines Identitätsproviders von einem Angreifer. Ist der Service anfällig gegen Replay-Attacken wird er auch den Angreifer authentifizieren, ohne dass dieser den eigentlichen Inhalt der ursprünglichen Authentifizierungsnachricht kennen muss. Zur Absicherung gegen Replay-Attacken werden in der Regel Zeitstempel oder Challenges genutzt. Solche Zeitstempel können auch im Rahmen von Filtermechanismen überprüft werden und ungültige Nachrichten daraufhin gefiltert werden. Es können beispielsweise alle Nachrichten, die älter als einen Tag sind, verworfen werden. Ohne Zeitstempel wird das Filtern solcher Nachrichten wesentlich schwieriger, da potentiell unendlich viele Nachrichten vorgehalten und mit neuen Nachrichten auf Gleichheit überprüft werden müssten, was nicht praktikabel ist. Die Filterung kann anhand einer allgemeinen Signatur geschehen. 272

273 Signatur: hatgueltigentimestamp(m) A=ACCEPT oder: hatgueltigentimestamp(m) && (timestamp(m) > timestampyesterday()) A=ACCEPT M Versandte Nachricht (SOAP), hatgueltigentimestamp() - Funktion zum Prüfen des Timestamps, timestamp() - Funktion zum Extrahieren des Zeitwertes für den Timestamp, timestampyesterday() - Funktion zum Erhalten des Zeitwertes eines gestern gültigen Timestamps, A konfigurierte Aktion Angriffe auf die XML Struktur Angriffe auf die XML Struktur adressieren fehlerhafte Implementierungen in XML Parsern. Bei der Interpretation einer ungewöhnlichen (aber unter Umständen standard-konformen) XML Struktur treten Zustände auf, welche Implementierungsschwächen des Parsers ausnutzen. Ein Beispiel sind die so genannten XML Wrapping Attacken. Dabei wird durch Verschieben von XML Elementen eine signierte Nachricht so manipuliert, dass dies unbemerkt von vielen WS-Implementierungen verarbeitet und verifiziert wird, obwohl die Signatur ungültig ist. Dies kann funktionieren, wenn die Signatur auf ein Body-Element mit einer bestimmten ID (z.b. ID=aaa) referenziert. Bei Verschieben des Body-Elements in den Header bleibt die Signatur gültig, da das Element mit der ID weiterhin existiert und nicht verändert wurde. Anstelle das originalen Body-Elements wird aber nun ein alternatives Body-Element mit anderem Inhalt in die Nachricht eingefügt. Oft verwenden Web Service Implementierungen das alternative Body-Element zur weiteren Verarbeitung, obwohl die Signatur des originalen Elements geprüft wurde. Ein Beispiel für eine schadhafte XML Struktur sind die so genannten XML-Bombs. Dabei werden rekursive Strukturen mittels einer im XML Dokument eingebetteten DTDBeschreibung genutzt, um anfällige XML-Parser soweit auszulasten, dass diese nicht mehr betriebsbereit sind. Bei Auswertung der rekursiven Struktur werden bei anfälligen Parsern große Mengen an Ressourcen verbraucht, was bei dem Parser oder bei dem bereitstellenden System zum Ausfall führen kann. Das Filtern solcher Elemente gestaltet sich schwierig, da zum Erkennen auch spezielle XMLParser verwendet werden müssen. Diese müssen gegen die genannten Attacken resistent sein und diese über spezielle Muster erkennen können. Eine oben beschriebene XML-Bomb kann zum Beispiel gefiltert werden, indem in XML-Strukturen nur eine gewisse Rekursionstiefe zugelassen wird. Alle XML Dateien mit tieferer Rekursion werden von dem Filter entfernt und können somit keinen Schaden mehr anrichten. Zum Filtern von Wrapping-Attacken muss der Parser sowohl Wissen über die Sicherheitsanforderungen als auch Logik eines Dienstes haben. So könnte dieser beispielsweise alle nicht-signierten Elemente, welche für die Verarbeitung einer Nachricht nicht benötigt werden, einfach wieder aus der XML Nachricht entfernen. Mögliche Signaturen wären wie folgt: 273

274 Signatur: hatrekursionstiefe(m) > 3 A=DROP oder: hatreferenzmittelsid(m) A=DROP M Versandte Nachricht (SOAP), hatrekursionstiefe() - Funktion zum Ermitteln der Rekursionstiefe einer Nachricht, hatreferenzmittelsid() - Funktion zum Ermitteln ob Referenzen mittels ID vorliegen, A konfigurierte Aktion Angriffe auf die XML Inhalte Angriffe auf XML Inhalte beziehen sich nicht auf die Struktur der XML Datei sondern auf deren konkreten Inhalt. Es werden hier schädliche Inhalte in die XML Datei eingebunden, welche auf der Seite des Opfers Schaden verursachen können. Ein Beispiel für einen solchen Angriff ist das Einbinden von einem Virus in eine SOAP Nachricht, so dass dieser unter Umständen auf dem Opfersystem Schaden verursachen kann. Ein solcher Virus kann beispielsweise in Form einer ausführbaren Datei im XML Dokument eingebettet sein und aktiv vom Nutzer oder vom System im Hintergrund ausgeführt werden. Zum Filtern eines Virus in einer XML Datei kann beispielsweise ein Signatur-basierter Filter wie ein Anti-Virus-Programm verwendet werden, solange dieses einzelne Entitäten in einem XML-Dokument logisch voneinander trennen und separat untersuchen kann. Ein weiteres Beispiel ist die so genannte XML-External-Entity Attack, welche externe Inhalte in ein XML-Dokument einbindet, um diese vor Filterung zu schützen. Diese externen Inhalte werden zur Laufzeit während der Verarbeitung der XML Datei ausgewertet und bei Bedarf auf das Opfersystem transferiert. Die Einbindung kann im einfachsten Fall mittels URLs stattfinden, welche auf externe Web Server mit schädlichen Inhalten oder interne Ressourcen, wie Daten auf der Festplatte oder verbundene Netzwerklaufwerke verweisen. Ein anderes Beispiel wäre der Verweis auf das Linux/Unix interne Gerät file:///dev/urandom, welches Input in unbeschränkten Mengen generiert und das System so weitreichend auslasten kann. Die Filterung externer Inhalte ist relativ einfach möglich, da es sich um klar erkennbare Zeichenketten handelt, welche leicht durch einen Signatur-basierten Filter erkannt werden können. So können beispielsweise jegliche Verweise auf bestimmte bekannte HTML Server problemlos gefiltert werden. Verweise auf interne Ressourcen können ebenfalls einfach erkannt werden, beispielsweise an der Zeichenkette file:// oder c:\. Weiterhin wäre es möglich, nur bestimmten Elementen wie beispielsweise Namespaces die Nutzung von URLs zu erlauben, diese für alle anderen Elemente aber zu verbieten. Somit könnten einfach alle anderen Elemente, welche externe Verweise enthalten, gefiltert werden. Signatur: containsexternalentity(m) A=DROP oder: contains(m, file:// ) A=DROP 274

275 M Versandte Nachricht (SOAP), containsexternalentity() - Funktion zum Ermitteln, ob externe Entitäten im XML vorliegen, contains(m, String s) - Funktion zum Ermitteln, ob String s in der Nachricht M enthalten ist, A konfigurierte Aktion Zusammenfassung In diesem Kapitel wurden die zur XML/WS-* Filterung nötigen Methoden eingeführt sowie zwei für Web Services und XML spezielle Mechanismen vorgestellt. Weiterhin wurde das Konzept eines WS-Security-Gateways als ein zentrales Konzept zur Umsetzung der XML/WS*-Filterung beschrieben. Konkrete Angriffsszenarien sowie allgemeine Signaturen zum Erkennen und Filtern dieser Angriffe wurden am Schluss vorgestellt. 7.3 Sicherheit SOA-spezifischer Repositories In den nachfolgenden Abschnitten werden Sicherheitsaspekte im Zusammenhang mit SOA Repositories dargestellt. Die unterschiedlichen Anforderungen sowie die Möglichkeiten anhand der Verzeichnisse UDDI und ebxml werden dabei beschrieben Einleitung Services in einer SOA werden in der Regel von vielen dezentralen Anbietern bereitgestellt und verwaltet. Um die Services anderen Nutzern zugänglich zu machen, werden die für den Zugriff auf die Services notwendigen Informationen in Verzeichnissen veröffentlicht, so genannten Repositories. Zu Beginn der SOA Technologie wurden die Informationen zu diesen Services mittels s, Datenbanken und Webseiten verwaltet und verteilt. Durch die Entwicklung von einfachen Services, die z.b. Wetterinformationen bereitstellen, hin zu komplexen Services, die ganze Geschäftsprozesse einer Organisation abbilden, ist es unrealistisch geworden, solche informellen Mechanismen für das Verwalten und Verteilen von Services zu verwenden. Auch ist es nicht möglich, mit der steigenden Komplexität der Servicekomponenten alle Informationen, die eine Servicekomponente beschreiben, mittels eines SOA Artefakts wie z.b. einer WSDL-Datei, darzustellen. Daher nimmt die Bedeutung von SOA Repositories im SOA-Umfeld immer weiter zu. Das SOA Repository unterstützt Organisationen bei der Verwaltung der stetig zunehmenden Komplexität und der Lösung von neuen Anforderungen der Services. Bei den Verzeichnissen kann unterschieden werden zwischen einfachen Registries und Repositories. Service Registries inventarisieren lediglich die Services mit ihren Schnittstellenbeschreibungen. Demgegenüber bieten Repositories neben dieser Grundfunktionalität noch weitere Serviceinformationen (Versionsnummern, Accounting-Informationen, Policies, ), die benötigt werden, um z.b. SOA Governance (siehe Kapitel 5.1) und Service-LebenszyklusManagement (siehe Kapitel 5.3) zu unterstützen. Ein SOA Repository sollte zudem unterschiedliche Fähigkeiten bereitstellen, um das Repository selbst abzusichern, aber auch um die Sicherheitsmechanismen in einer SOA zu unterstützen. Um diese Herausforderungen (z.b. SOA Governance, Service-Lebenszyklus-Management, Zusammenschluss 275

276 verschiedener Repositories,...) zu bewältigten, sollte ein sicheres SOA Repository unter anderem die folgenden Punkte unterstützen: Policy Management durch Repositories, Identitätsmanagement durch Repositories, Schutz vor Angriffen auf das Repository, Sicheres Einstellen und Finden von Services, Auffinden sicherer Services Policy Management durch Repositories SOA Governance erfordert das Durchsetzen der Policies einer Organisation, die in einer Syntax vorliegen, welche von Maschinen verarbeitet werden kann, z.b. im XML-Format. Diese Policies müssen über Services veröffentlicht, verwaltet und aufgefunden werden können. Darüber hinaus ist es in einer SOA Umgebung erforderlich, dass die Policies über die Organisationsgrenzen hinaus verbunden und abgestimmt werden. Policy Management, siehe Kapitel 6.2, wird heutzutage oft durch proprietäre Policy Stores erledigt, deren Umsetzung vom verwendeten Produkt abhängt. Ein Grund hierfür ist, dass es zur Zeit noch keine standardisierte Policy Expression Syntax gibt, welche die Reife hat alle Typen von Policies darzustellen. Gegenwärtig unterstützt der ebxml Standard föderiertes Policy Management für Policies für die Zugriffskontrolle auf ein Repository. Dabei wird die von der OASIS standardisierte extensible Access Control Markup Language (XACML), siehe Kapitel 4.4.4, verwendet. Ein ebxml Repository kann sowohl als XACML Policy Enforcement Point (PEP) als auch als Policy Decision Point (PDP) fungieren. Zudem erlaubt der ebxml Standard auch, dass ein ebxml Repository als ein XACML Policy Store auftreten kann. Mit UDDI können Policies für die Zugriffskontrolle auf das Repository auf zwei Wegen definiert werden. Zum Einen ist es möglich Policies über ein XML-Dokument darzustellen. Das Dokument muss unter anderem Aussagen über den Policy Enforcement Point und Policy Decision Point machen. Die zweite Möglichkeit ist die Policies innerhalb von UDDI durch die Verwendung von UDDI-Elementen zu modellieren Identitätsmanagement durch Repositories Der Trend in einer förderierten SOA Umgebung geht zu SOA Repositories, die sich mit anderen, auch über Organisationsgrenzen hinweg, zusammenschließen und als ein Repository auftreten. In einer solchen Umgebung ist es erforderlich die Identitäten zu verwalten und sicherzustellen, dass sich die Nutzer vor dem Zugriff auf die Servicekomponenten authentifizieren. Dies hat zum Einen Sicherheitsgründe und zum Anderen spielt es auch eine wichtige Rolle für das Accounting bei kommerziellen Services. Daher müssen Mechanismen etabliert werden, um die Identitäten von Nutzern (Mensch oder Maschine) sicher zu verwalten. Die Herausforderung ist, die Services fremden Nutzern zur Verfügung zu stellen und gleichzeitig die Sicherheit im gleichem Maße so aufrecht zu erhalten, als ob der Service sich in einer geschlossenen Umgebung befindet. Diese Herausforderung adressiert föderiertes Identitätsmanagement (siehe Kapitel 6.4), in dem es einen Circle of Trust über alle Services inklusive der Repositories in der SOA Umgebung etabliert. Somit unterstützt föderiertes Identitätsmanagement die sichere Authentifizierung der Nutzer und legt die Basis für den 276

277 Zugriffsschutz auf die Servicekomponenten in der föderierten SOA Umgebung. Daher sollten sichere SOA Repositories Mechanismen für Single Sign-On (SSO) und Identity und Access Management Services, die auf offenen Standards wie z.b. der Security Assertions Markup Language (siehe Kapitel 4.4.3) und Liberty (siehe Kapitel ) basieren, unterstützen. ebxml unterstützt föderiertes Identitätsmanagement auf Basis von SAML 2.0. Ein ebxml Repository kann dabei als ein SAML Service Provider fungieren. Das erlaubt dem Repository einen Identity Provider zu nutzen, um die Nutzer zu authentifizieren Schutz vor Angriffen auf das Repository Ein Repository kann als eine Web Anwendung verstanden werden. Daher sind Repositories den gleichen Bedrohungen ausgesetzt wie Portale. Dementsprechend sind die Sicherheitsmechanismen mit denen bei der Absicherung von Portalen weitgehend identisch. Die Diskussion, wie Portale und damit auch Repositories abzusichern sind, wurde bereits im Kapitel 7.1 Sicherheit von Portalen durchgeführt Sicherheitsaspekte beim Publish-Find-Bind-Triangle Die Service Provider senden ihre Servicebeschreibungen an ein Service Repository, um ihre Services zu registrieren (Publish). Der Service Consumer wendet sich an das Service Repository, um einen für ihn passenden Service zu finden (Find). Auf eine entsprechende Anfrage erhält der Service Consumer die Servicebeschreibung vom Service Repository, mit der sich der Nutzer mit dem Service verbinden kann (Bind). Nachfolgend werden die Sicherheitsaspekte anhand der drei Phasen Publish, Find, Bind erklärt Publish Beim Veröffentlichen einer Servicebeschreibung in einem Repository muss sich der Service Provider gegenüber dem Service Repository authentifizieren. Dies ist erforderlich, damit nur der Inhaber des Service seine Servicebeschreibungen bearbeiten kann. Bei ebxml beispielsweise kann sich der Service Provider auf mehrere Arten authentifizieren: Der Anbieter signiert die Anfrage mit seinem privaten Schlüssel. Das Repository überprüft diese mit dem öffentlichen Schlüssel, der im Profil des registrierten Anbieters hinterlegt ist. Dies erfordert allerdings die Verwaltung eines Schlüsselspeichers, in dem die öffentlichen Schlüssel der registrierten Anbieter gespeichert sind. Der Anbieter authentifiziert sich mit seinem SSL Client Zertifikat beim Aufbau einer HTTPS-Verbindung mit dem Verzeichnis. Verwendung von SAML 2.0 zur Authentifizierung. 277

278 Das ebxml Repository stellt Zugriffskontroll- und Autorisierungsmechanismen bereit, die auf dem Access Control Information Model [ebrim] von ebxml basieren. Dieses Modell definiert standardisierte Policies für die Zugriffskontrolle, die von jedem ebxml Repository unterstützt werden. Daneben ist auch die Verwendung von XACML definiert, das eine feingranulare Spezifikation der Policies für die Zugriffskontrolle erlaubt. Der Zugriff auf einen Web Service in einem UDDI-Verzeichnis ist nur für authentifizierte Service Provider erlaubt. Jedes UDDI Verzeichnis definiert hierfür eigene Policies für die Registrierung, Authentifizierung und Autorisierung von Service-Providern, um die Funktionen für das Lesen, Einfügen und Aktualisieren von Daten im UDDI-Verzeichnis zu schützen. Für die Authentifizierung bei UDDI gibt es ein so genanntes AuthInfo-Element, das einen Container für unterschiedlichste Authentifizierungsinformationen bildet. Welche Informationen transportiert werden, ist vom UDDI Verzeichnis abhängig. Dies können unter anderem sein: Benutzername und Passwort oder Authorization assertions (z.b. SAML, X509 Attribut Zertifikate). Nachdem sich der Service Provider authentifiziert hat und auf das Repository zugreifen kann, muss die Kommunikation zwischen dem Service Provider und dem Repository abgesichert und die Authentizität und Integrität der Einträge sichergestellt werden. Für die Absicherung der Kommunikation erlauben beide Standards die Verwendung von HTTPS, um den Inhalt der Nachricht vor dem Lesen durch unautorisierte Entitäten zu schützen. Der ebxml Standard spezifiziert weiterhin noch die Verwendung von Web Services Security: SOAP Message Security 1.0 [WSS-SMS] und Web Services Security: SOAP Messages with Attachments (SwA) Profile [WSS-SWA], die die Authentizität und Integrität der Nachricht gewährleisten. Die Authentizität und Integrität der Serviceinformationen muss auch dann noch gewährleistet sein, wenn die Informationen zwischen unterschiedlichen Repositories ausgetauscht oder über mehrere Intermediäre geleitet werden. Hierfür verwenden beide Spezifikationen XMLSignature (siehe Kapitel 4.4.2). Während ebxml das digitale Signieren der Einträge vorschreibt, ist die Verwendung bei UDDI nur optional Find Der Zugriff auf ein öffentliches Repository erfolgt in der Regel über HTTP ohne weitere Absicherung. Beim Zugriff auf ein privates Repository oder auf Services, die nur für einen beschränkten Nutzerkreis bestimmt sind, muss eine Authentifizierung, Autorisierung und Zugriffskontrolle durchgesetzt werden. In diesem Fall kommen die gleichen Sicherheitsmechanismen wie beim Einstellen eines Services in das Repository zum Einsatz (siehe Kapitel ). Nachdem der Service Consumer einen Service mit den benötigten Fähigkeiten gefunden hat, erhält er vom Repository die entsprechenden Informationen zu dem Service. Bei der Übertragung muss sichergestellt sein, dass die Informationen wirklich aus dem Repository stammen und nicht verfälscht sind,. d.h. es muss die Authentizität und Integrität der übermittelten Informationen gewährleistet sein. Bei nicht öffentlichen Services muss zudem das Sicherheitsziel der Vertrauchlichkeit der Daten umgesetzt werden. Die Absicherung der Kommunikation ist die gleiche wie beim Einstellen eines Eintrages in ein Repository. Wie bereits voran beschrieben, werden die Einträge in den Repositories digital signiert. Die 278

279 Prüfung der Echtheit der Signatur bleibt aber in der Verantwortung der Service Consumer. Ohne eine korrekte Verifikation durch den Service Consumer kann die Authentizität und Integrität nicht gewährleistet werden Bind Mit Hilfe der Informationen aus dem Repository ist der Service Consumer in der Lage, eine direkte Kommunikation mit dem Service Provider aufzubauen. Falls der Service Provider eine Absicherung der Kommunikation verlangt, enthalten die vom Repository übermittelten Informationen die Sicherheitspolicy des Anbieters oder einen Verweis darauf. In der Regel wird eine Sicherheitspolicy nicht nur einen Sicherheitsmechanismus mit einem Parameter enthalten, sondern eine Auswahl. Daher müssen sich, bevor die direkte Kommunikation erfolgt, Service Provider und Service Consumer auf die zu verwendenden Sicherheitsmechanismen und Parameter einigen. Dieser Vorgang wurde im Kapitel (Aushandeln von Sicherheitspolicies Sicheres Late Service Binding) bereits beschrieben. Beim Aushandeln einer Sicherheitspolicy zwischen Anbieter und Nutzer des Service kommt es nicht nur auf die Festlegung gemeinsamer Sicherheitsmechanismen und Parameter an, sondern es liegt auch in der Verantwortung des Service-Consumers, dass nur starke Sicherheitsmechanismen mit den entsprechenden Parametern ausgewählt werden. Daher muss der Service Consumer in seiner eigenen Sicherheitspolicy schwache Sicherheitsmechanismen, wie z.b. DES, ausschließen Auffinden sicherer Web Services Service Consumer suchen in einem Repository nach Services, welche die für sie benötigten Fähigkeiten bereitstellen. Diese Fähigkeiten können sich nicht nur auf spezielle Funktionen zur Lösung von Problemen und Aufgaben beschränken, sondern auch auf geforderte Sicherheitseigenschaften an den Service. Ein einfaches Beispiel ist die Verwendung eines Web Services, der die aktuellen Börsenkurse übermittelt. Von diesem Service wird nicht nur verlangt, dass er die aktuellen Börsenkurse zeitnah liefert, sondern auch, dass die Informationen nicht manipuliert wurden oder von einem fremden Dritten stammen. D.h. es muss die Authentizität und Integrität der übermittelten Kurse sichergestellt werden. In diesem Beispiel würde der Service Consumer im Repository nicht nur einen Service suchen, der Börsenkurse übermittelt, sondern der auch die Authentizität und Integrität der Informationen garantiert. Nachfolgend werden für UDDI und ebxml die Möglichkeiten zur Abfrage von Sicherheitseigenschaften beschrieben. UDDI Mit der Spezifikation WS-PolicyAttachment (siehe Kapitel 4.3.7) können Policies mit bestehenden Web Services verknüpft werden. Die Spezifikation ermöglicht die Bindung einer Policy an die Web Service Beschreibung (WSDL). Die Policies können auf den vier Ebenen Service Policy Subject, Endpoint Policy Subject, Operation Policy Subject und Message Policy Subject an eine WSDL-Beschreibung angehängt werden. Darüber hinaus definiert der Standard, wie Policy Expressions mit UDDI-Einträgen in Verbindung gebracht werden. Dies ermöglicht dem Nutzer die Policies eines ausgewählten Services zu überprüfen. 279

280 ebxml Die ebxml Spezifikation erlaubt den Service-Providern neben den vordefinierten Taxonomien auch eigene zu definieren und somit die vom Service Provider gewünschten Informationen zu indexieren. Für die Serviceanfragen an ein ebxml Repository besteht die Möglichkeit, neben vordefinierten Queries auch Nutzer-definierte Queries zu verwenden. Somit ist es möglich, nach unterschiedlichen Serviceeigenschaften zu suchen, auch nach Sicherheitsmechanismen, wenn diese vom Service Provider indexiert wurden Vergleich von ebxml und UDDI Die nachfolgende Tabelle 17 stellt die beiden Verzeichnisse ebxml (siehe Kapitel 4.9.4) und UDDI (siehe Kapitel 4.3.2) gegenüber und vergleicht deren Eigenschaften. Kategorie ebxml Registry 3.0 UDDI 3.0 WS-Security Standards Message Security Standards OASIS Web Service Security --- Access Control Policy Standards XACML Identity Management Standards SAML Unterstützung von Digitalen Signaturen Ja - Pflicht Ja - Optional Basic Access Control basierend auf vordefinierten Rollen und Policies Ja Ja - limitiert Security Features Nutzerdefinierte, Ja basierend auf XACML feingranulare Policies für die 1.0 Zugriffskontrolle Nein Föderiertes Identitätsmanagement Ja basierend auf SAML 2.0 Nein Audit Trail Ja Ja Vordefinierte Queries Ja Ja Nutzerdefinierte Queries Ja Nein Discovery Tabelle 17: Vergleich der Standards ebxml und UDDI (vgl. [SM 2005]) 280

281 7.3.8 DVDV Neben den beschriebenen Verzeichnissen ebxml und UDDI ist speziell für die öffentliche Verwaltung das Deutsche Verwaltungsdiensteverzeichnis (DVDV) von Bedeutung. Das DVDV bildet eine fach- und ebenenübergreifende Infrastrukturkomponente für das E-Government in Deutschland. In diesem Verzeichnisdienst werden die technischen Verbindungsparameter von Online-Diensten der öffentlichen Verwaltung hinterlegt, die zu ihrer Nutzung benötigt werden. Das DVDV erlaubt es im Behördenumfeld, Services in Form einer WSDL in dem Verzeichnis abzulegen. Zusätzlich können weitere Informationen, auch Sicherheitsinformationen, über den Service bereitgestellt werden, die dem Service Consumer helfen, den für ihn passenden Service zu finden. Die Pflege der Serviceinformationen, die über das DVDV zur Verfügung gestellt werden, erfolgt durch definierte Pflegestellen. Nur sie können die Daten innerhalb des DVDV ändern. Eine Pflegestelle kann jedoch nur die Daten ändern, für die sie auch die Verantwortung hat. Die Kommunikation über das DVDV erfolgt in der Regel mittels OSCI-Transport. Durch dieses Protokoll lassen sich wesentliche Sicherheitsziele der öffentlichen Verwaltung in Bezug auf Vertraulichkeit, Integrität aber z.b. auch Nachweisbarkeit realisieren. 7.4 Sichere Dienstbeschreibungen mit BPEL Wie in Kapitel (Orchestierung und Choreographie von Diensten) beschrieben, erfolgt eine Orchestierung von Diensten häufig mittels BPEL. Dabei kommt meist eine zentrale BPEL-Engine zum Einsatz. Mit BPEL lassen sich Workflows definieren, an denen unterschiedliche Dienste beteiligt sind. Jeder der beteiligten Dienste benötigt ggf. andere Daten, ein anderes Nachrichtenformat oder hat andere Sicherheitsanforderungen. Aufgabe des mit BPEL definierten Workflows ist es, zu entscheiden unter welchen Bedingungen welche weiteren Dienste genutzt werden und welche Daten an diese zu übertragen sind. Der BPEL Workflow an sich wird in der Regel wiederum als Dienst bereitgestellt und kann dann durch einen Service Consumer aufgerufen werden. Eine zentrale BPEL Engine bietet eine Reihe von Vorteilen. Sie kapselt z.b. die dahinter D ie n s t D ie n s t n u t z e r BPEL W o r k f lo w D ie n s t D ie n s t Abbildung 99: Zentraler BPEL Workflow liegenden Dienste, d.h. diese können nicht mehr direkt aufgerufen werden. Damit können die Angriffsmöglichkeiten auf diese Dienste erheblich reduziert werden. Ein weiterer Vorteil, 281

282 wenn alle Dienstaufrufe über eine zentrale BPEL Engine abgewickelt werden, besteht darin, dass Monitoring und Sicherheitsfunktionalitäten an einer zentralen Stelle bei der BPEL Engine eingesetzt werden können. Beispielsweise können alle Dienstaufrufe standardmäßig auf bestimmte Angriffsmuster gescannt werden. Eine zentrale BPEL Engine hat aber auch Nachteile. Fällt sie aus oder kann sie durch einen Angreifer manipuliert werden, so sind alle Dienste betroffen, da sie ja nicht direkt sondern nur über die BPEL Engine aufgerufen werden können. Aus diesem Grund muss eine solche zentrale Komponente besonders geschützt werden. Außerdem sollte sie redundant ausgelegt werden. Wird ein BPEL Workflow durch einen Service Consumer angesprochen, so erhält er im einfachsten Fall (d.h. wenn keinerlei Sicherheitsmaßnahmen getroffen wurden) vollen Zugriff auf alle Daten, die innerhalb des Aufrufs übertragen wurden. Innerhalb des Workflows wird dann anhand der Daten entschieden, welche weiteren Dienste aufzurufen sind. Es werden entsprechende Nachrichten erzeugt und an die entsprechenden Dienste übermittelt. Dies entspricht Szenario 1.c) in Kapitel (Orchestierung und Choreographie von Diensten). Werden in diesem Szenario Sicherheitsmaßnahmen wie z.b. eine Nachrichtenverschlüsselung eingesetzt, so greifen diese evtl. nur zwischen Service Consumer und BPEL Workflow. Der Workflow entschlüsselt die Nachricht komplett, um Zugriff auf die Daten der Nachricht zu erhalten. Bei Bedarf kann er dann die einzelnen Dienstaufrufe wieder verschlüsseln, um auch die Kommunikation mit den einzelnen Diensten abzusichern. D ie n s t D ie n s t n u t z e r BPEL W o r k f lo w D ie n s t V e r s c h lü s s e lu n g E n t s c h lü s s e lu n g D ie n s t Abbildung 100: Zentraler BPEL Workflow entschlüsselt Nachrichten komplett Vergleichbare Mechanismen können auf weitere Sicherheitsmerkmale wie z.b. Signaturen angewendet werden. In diesem Fall könnte die BPEL Engine die Signatur des ServiceConsumers prüfen und anschließend alle Nachrichten an die Dienste mit der eigenen Signatur signieren. Der BPEL Workflow bestätigt damit den einzelnen Diensten, dass er die Nachricht des Service-Consumers korrekt geprüft hat. Die einzelnen Dienste müssen also der BPEL Engine vertrauen. Ein solches Szenario ist z.b. denkbar, wenn BPEL Engine und Dienste unter der Kontrolle eines Unternehmens stehen. In diesem Fall können die Sicherheitsüberprüfungen durch die BPEL Engine übernommen werden (ggf. mit Hilfe entsprechender Sicherheitsservices). Die einzelnen Dienste müssen dann entsprechende Prüfungen (z.b. die Prüfung der Identität des Service-Consumers) nicht mehr durchführen. Sie müssen nur sicherstellen, dass sie durch die BPEL Engine angesprochen und das bei dieser Kommunikation alle Sicherheitsanforderungen eingehalten wurden. 282

283 Insbesondere wenn Daten mit hohem Schutzbedarf verarbeitet werden, ist es aufgrund von Sicherheitsanforderungen jedoch häufig nicht zulässig der BPEL Engine kompletten Zugriff auf die Nachrichteninhalte zu gewähren. In diesem Fall werden der BPEL Engine nur die Teile der Nachricht zugänglich gemacht, die diese braucht, um z.b. die Nachricht korrekt weiterzuleiten. Gegebenenfalls werden auch zusätzliche Daten eingefügt, die nur für die BPEL Engine gedacht sind. Dazu werden unterschiedliche Teile der Nachricht vom Service Consumer unterschiedlich verschlüsselt. D ie n s t D ie n s t n u t z e r BPEL W o r k f lo w D ie n s t V e r s c h lü s s e lu n g E n t s c h lü s s e lu n g D ie n s t Abbildung 101: Zentraler BPEL Workflow leitet verschlüsselte Nachrichtenteile weiter Die BPEL Engine kann auf die Inhalte dieser Nachrichtenteile nicht zugreifen, sondern leitet diese unverändert weiter. Erst die einzelnen Dienste können die jeweils für sie gedachten Teile der Nachricht entschlüsseln. Unterschiedliche Varianten für die Nachrichtenbearbeitung durch die BPEL Engine in einem solchen Szenario sind in Kapitel dargestellt. Welches der beschriebenen Szenarien zum Einsatz kommt, hängt von den individuellen Sicherheitsanforderungen des jeweiligen Workflows und der beteiligten Dienste ab. Auch sind generelle Architekturentscheidungen zu berücksichtigen. Häufig finden sich in der Praxis auch Mischformen der genannten Szenarien. Es zeigt sich schon heute, dass in Zukunft der Sicherheitsbedarf weiter steigen wird. Immer häufiger besteht z.b. die Anforderung Daten Ende-zu-Ende abzusichern. Dies zeigt sich z.b. an der Entwicklung von Protokollen wie OSCI-Transport, bei dem Nachrichteninhalte und Metadaten zum Transport separat abgesichert werden. Szenarien wie in Abbildung 101 dargestellt werden damit immer häufiger. Allerdings gibt es in diesem Umfeld auch noch einige offene Fragen, insbesondere dann, wenn weitere Anforderungen z.b. an die Verteilung von Sicherheitspolicies hinzukommen. 7.5 Sicherheit REST-basierter SOAs REST steht für Representational State Transfer und beschreibt einen Architekturstil, der auf den grundlegenden Prinzipien und Technologien des World Wide Web basiert. Im besonderen ist REST als Architekturmodell für große verteilte Hypermedia-Systeme konzipiert worden, bei denen jede Ressource über einen eindeutigen Bezeichner (URI) angesprochen wird. REST wurde ursprünglich im Jahr 2000 in der Dissertation von Roy Fielding definiert, der auch maßgeblich an der Entwicklung der HTTP/1.1 Spezifikation 283

284 beteiligt war. Seit ca. 2005/2006 wird REST verstärkt als leichtgewichtige Alternative zu SOAP und XML-RPC für die Realisierung von Web Services genutzt. Die nachfolgenden Abschnitte des Kapitels beschreiben die Nutzung von REST-basierten Web Services sowie sicherheitsrelevante Aspekte dieses Architekturansatzes Grundlagen von REST Verwendung von eindeutigen Bezeichnern Jeder einzelnen Ressource (z.b. Webseite, Bild, Skript, etc.) wird ein eindeutiger URI (Uniform Resource Identifier) zugeordnet, so dass diese leicht von einem Client angesprochen werden kann. Dabei ist es nicht zwingend erforderlich, dass der Pfad eines URIs mit einer im Vorfeld vorhandenen Datei/Ressource auf dem Serversystem verknüpft ist. Oftmals werden Ressourcen von einem Dienst dynamisch erstellt. Folgendes Beispiel zeigt, wie innerhalb eines Online Shops auf einfache Weise auf einen Warenkorb (Ressource) mit der Nummer 1313 zugegriffen werden kann: GET /warenkorb/1313 Zustandslosigkeit von RESTful Services Web Services, die sich strikt an die Prinzipien von REST halten (auch so genannte RESTful Services), besitzen die Eigenschaft der Zustandslosigkeit. Der Server speichert keinen Status über bereits durchgeführte Interaktionen mit dem Client. D.h. es findet keine Verwaltung von Sessions durch den Server statt. Es obliegt dem Client, fortlaufend den Status zu verwalten und Methodenaufrufe in einer bestimmten Reihenfolge durchzuführen. Der Server ist ausschließlich für das Management der Ressourcen und die Zustellung von Repräsentationen zuständig. Repräsentationen von Ressourcen Bei Repräsentationen kann es sich um verschiedenste Dateitypen handeln, die Informationen über Ressourcen sowie ggf. Verweise auf andere Ressourcen beinhalten. In der Praxis kommen als Repräsentationen von Ressourcen zumeist HTML- und XML-Dokumente zum Einsatz. Wird von einem Client z.b. eine bestimmte Ressource über den entsprechenden URI angesprochen, kann die Anfrage von dem Server mit einer XML-Datei beantwortet werden. Enthält die übertragene XML-Datei Links zu anderen Ressourcen, kann der Client entscheiden, ob er diese weiter verfolgen möchte. Ruft der Client einen neuen URI (Link) auf, so verändert sich sein Zustand durch die neu übertragene Repräsentation (HTML-/XMLDatei). Anwenden von wohldefinierten Methoden/Operationen auf Ressourcen Über HTTP (Hypertext Markup Protocol) werden innerhalb einer REST-basierten Architektur Hypermedia-Dokumente übertragen sowie Methodenaufrufe durchgeführt. Zur Realisierung der Methodenaufrufe werden bei REST in der Regel die grundlegenden Operationen verwendet, die innerhalb der HTTP-Spezifikation definiert sind. Konkret handelt es sich dabei um folgende HTTP-Methoden (auch Verben genannt): GET: GET Anfragen werden vom Client an den Server gesendet, um eine Repräsentation einer Ressource abzurufen. 284

285 Beispiel: GET /buch/ POST: Mittels POST kann einer Ressource etwas hinzugefügt werden (z.b. einem Warenkorb ein neues Buch). Beispiel: POST /warenkorb/1313 buch= PUT: PUT wird zum Anlegen neuer Ressourcen verwendet. Im nachfolgenden Beispiel wird ein neuer Bucheintrag angelegt. Beispiel: PUT /buch <buch> <titel>per Anhalter durch die Galaxis</titel> <autor>douglas Adams</autor> <verlag>heyne</verlag> <format>taschenbuch</format> <seitenzahl>204</seitenzahl>... </buch> DELETE: Mittels DELETE werden Ressourcen gelöscht. Beispiel: DELETE /buch/ Sicherheit von REST-basierten Architekturen Absicherung durch SSL/HTTPS In REST-basierten Architekturen wird meist eine HTTP Basic, HTTP Digest oder die SSL zertifikatsbasierte gegenseitige Authentifizierung eingesetzt, um Zugangsdaten abgesichert weiterzuleiten. Zum Schutz der Datenintegrität und Vertraulichkeit stellt SSL die gängigste Methode dar. Hinsichtlich der Authentifizierung ist HTTP Basic als sehr sicherheitskritisch zu bewerten, da ein Passwort lediglich Base64-kodiert, aber nicht verschlüsselt übertragen wird. Ein Angreifer könnte daher durch eine abgefangene Nachricht leicht das Passwort ermitteln. Vor diesem Hintergrund sollte HTTP Basic nur in Verbindung mit SSL zum Einsatz kommen. SSL (Secure Sockets Layer) ist ein Protokoll, das weit verbreitet ist und für viele Anwendungsszenarien im Internet zur sicheren Kommunikation eingesetzt wird. Es handelt sich zudem um einen stabilen Standard, der schon über lange Jahre Anwendung findet und mit dem die IT-Verantwortlichen vertraut sind. In der Praxis kann dies unter Umständen ein Vorteil im Vergleich zu den WS-Security Standards sein, die bei SOAP-basierten Web Services in der Regel eingesetzt werden. SSL hat jedoch auch einen wesentlichen Nachteil. SSL bietet lediglich Sicherheit auf der Transportschicht zwischen zwei Verbindungsknoten, jedoch nicht eine Ende-zu-Ende 285

286 Sicherheit auf Nachrichtenebene, wie es bspw. WS Security bei SOAP-basierten Web Services ermöglicht. Verwendung von Access Control Lists (ACLs) Access Control Lists werden in der Praxis häufig benutzt, um Zugriffe auf bestimmte Ressourcen (z.b. in Betriebssystemen) zu steuern. Werden URIs in einer REST-basierten Architektur konsequent als Ressourcen angesehen und behandelt, können auch hier Zugriffsregeln wie Access Control Lists umgesetzt werden. Zum Beispiel kann definiert werden, dass nur GET Anfragen durch externe Nutzer/Consumer möglich sind. Diese können dann nur Artikelinformationen abfragen, aber keine neuen Artikel mittels PUT anlegen. Eine solche Filterung kann durch heutige Firewalls oder entsprechende Appliances realisiert werden. HTTP-Nachrichten müssen dazu lediglich auf die jeweiligen Methoden untersucht und ggf. ausgefiltert werden. Voraussetzung für eine erfolgreiche Anwendung solcher Access Control Lists ist jedoch eine konsequente Einhaltung der definierten REST-Prinzipien. In der Praxis kommen allerdings häufig nur HTTP GET Nachrichten zum Einsatz, die in der URI Parameter als aneinandergereihte Zeichenketten nutzen. Dies stellt eine Chance für den Angreifer dar. HTTP GET Anfragen, die speziell präparierte Parameter übermitteln, können unter Umständen z.b. das Löschen bzw. Manipulieren von Ressourcen bewirken. Filterung von Zeichenketten in Anfragen (Query Strings) Falls HTTP GET Anfragen mit Parametern als Query Strings genutzt werden, die zu o.g. sicherheitskritischen Seiteneffekten führen können, sollten übliche Sicherheitsmaßnahmen für Web Anwendungen ergriffen werden. Analog zu den beschriebenen Maßnahmen hinsichtlich Injection Attacks (siehe Kapitel 3.3) sind grundsätzlich die Parameter zu validieren, um ein Weiterleiten von schadhaften Nachrichten zu verhindern. Z.B. könnte die Größe der Parameter oder der Parameterinhalt auf bekannte Angriffsmuster untersucht werden. Dabei bietet es sich an, reguläre Ausdrücke zu verwenden. Auf dem Markt existieren verschiedene Soft- und Hardwarelösungen, die URL Query Strings filtern können, so dass Angriffe über manipulierte Parameter erfolgreich abgeblockt werden. Falls neben SOAP-basierten Web Services auch REST-basierte Dienste angeboten werden, reicht es somit nicht aus, lediglich eintreffende XML-Nachrichten z.b. durch den Einsatz eines XML-Gateways zu schützen. Parallel dazu müssen Filterungsmechanismen vorhanden sein, die Angriffe über URL-Manipulationen verhindern. Nutzung von Logging-Mechanismen/Audit-Trails In REST-basierten Architekturen können die aufgerufenen URIs geloggt und für Audit-Trails leicht genutzt werden. In der Regel ist es möglich, durch minimale Änderungen in den Konfigurationsdateien eines Web Servers, das automatisierte Generieren von Logfiles zu bewirken. Übermittelte Anfragen und durchgeführte Operationen sind daher sehr leicht nachvollziehbar und unterstützen bei dem Erkennen von Angriffen bzw. Manipulationen. Beim Protokollieren von Aktionen ist jedoch immer darauf zu achten, dass keine schutzbedürftigen Informationen in den Logdateien gespeichert werden und somit ein datenschutzrechtliches Problem entsteht. Implementierung eines sicheren Identifizierungsmechanismus für REST-basierte Web Services am Beispiel von Amazon Amazon bietet Web Services (AWS) an, die von externen Personen bzw. Organisationen genutzt werden können. Da es sich bei vielen Diensten um kommerzielle Web Services handelt, bei denen der Nutzer in Abhängigkeit des jeweiligen Nutzungsumfangs (Zeit, Anzahl von Anfragen, usw.) bezahlt, wird ein sicheres Verfahren zur Identifizierung der 286

287 unterschiedlichen Nutzer benötigt. Amazon löst dies durch die Verwendung einer sog. Access Key ID und eines Secret Access Key, die jeder Nutzer erhält. Die Access Key ID wird von Amazon dazu verwendet, den Nutzer zu bestimmen, dessen Code auf den Web Service zugreift. Mit dem Secret Access Key wird hingegen eine Signatur erstellt, die Amazon nutzen kann, um eine Authentifizierung des Nutzers durchzuführen. D.h. Amazon ist aufgrund der übertragenen Signatur in der Lage, festzustellen, ob es sich tatsächlich um den Nutzer handelt, der über die Access Key ID angegeben wird. Ein Angreifer, der eine Nachricht abfängt und die Access Key ID für eigene Anfragen an den Web Service nutzt, wird keinen Erfolg haben. Ihm fehlt für die berechtigte Inanspruchnahme des Service der nötige Secret Access Key, um eine gültige Signatur zu erstellen. Die Signatur wird über den Dienst, die Operation und einen Zeitstempel gebildet und innerhalb der Anfrage an den Web Service übertragen. Mit dem Zeitstempel wird ausgeschlossen, dass eine Person eine abgefangene Nachricht für Replay Attacken nutzen kann. D.h. eine erneut übermittelte Nachricht wird von dem Web Service aufgrund des alten Zeitstempels nicht mehr akzeptiert. Anhand der Access Key ID identifiziert Amazon den Nutzer und kann den korrespondierenden Secret Access Key ermitteln. Durch diesen geheimen, gemeinsamen Schlüssel ist eine Überprüfung der Signatur möglich, so dass die Authentizität des Nutzers sichergestellt werden kann. Amazon entwickelte die beschriebene Lösung, da neben einer SOAP Variante eine RESTbasierte Kommunikationsmöglichkeit bereitgestellt werden sollte. Bei der Umsetzung des Sicherheitsmechanismus wurden Funktionalitäten implementiert, die bereits ähnlich in SOAP/WS-Security vorhanden waren (Username Token, Zeitstempelunterstützung, XML Signaturen). Im Vergleich bietet WS-Security jedoch weitaus komplexere und flexiblere Sicherungsmöglichkeiten. Kurzer Vergleich zwischen REST- und SOAP-basierten SOAs In der Öffentlichkeit bzw. unter IT-Experten wird häufig darüber diskutiert, welcher der beiden Ansätze zur Realisierung einer Service-orientierten Architektur besser geeignet ist. Betrachtet man jedoch deren ursprüngliche Ziele für die sie jeweils konzipiert wurden, wird schnell ersichtlich, dass eine allgemeine, qualifizierte Aussage diesbezüglich nicht möglich ist. Während REST hauptsächlich für den Zugriff und die Manipulation von Ressourcen in großen Hypermedia-Systemen entwickelt wurde, sollten mit SOAP-basierten Web Services (mittels Nachrichten) Funktionsaufrufe in verteilten Systemen realisiert werden. Durch diese grundlegend unterschiedlichen Ziele ergeben sich bestimmte Anwendungsszenarien bei denen REST aufgrund seiner ressourcenzentrierten Konzeption überlegen ist und andere, bei denen der Einsatz von SOAP-basierten Web Services eher sinnvoll ist, weil verstärkt Funktionsaufrufe im Vordergrund stehen oder hochgradig komplexe Datenstrukturen verarbeitet werden. Hinsichtlich der Realisierung von Sicherheitsmechanismen ergeben sich für beide Ansätze aufgrund ihre Funktionsweise unterschiedliche Möglichkeiten. Während bei REST in der Regel Sicherheitsmechanismen auf Transportebene umgesetzt werden, findet bei der SOAPbasierten Variante eine Sicherung auf Nachrichtenebene statt. Wie bereits oben erwähnt, hat die Sicherung auf Nachrichtenebene den Vorteil, dass eine Ende-zu-Ende Sicherheit gewährleistet werden kann. Zum Beispiel können vom Sender einer Nachricht bestimmte Nachrichteninhalte für verschiedene Empfänger unterschiedlich verschlüsselt werden, so dass Zwischensysteme bei der Kommunikation nur auf die für sie bestimmten Informationen zugreifen können. Findet hingegen eine Sicherung auf Transportebene statt, kann nur eine Punkt-zu-Punkt Sicherheit realisiert werden, d.h. die Vertraulichkeit von Daten ist nur bis zum ersten Zwischensystem gewährleistet. Des Weiteren existieren für SOAP Web Services eine Reihe von Security Standards (siehe Kapitel 4), die umfangreich wesentliche 287

288 Sicherheitsaspekte von organisationsübergreifenden Geschäftsprozessen adressieren. Wird für die Durchführung allerdings keine nachrichtenbasierte Sicherheit benötigt bzw. sind keine besonderen Anforderungen an die Sicherheit gestellt, ist möglicherweise eine leichtgewichtige REST-basierte Lösung für das Unternehmen oder die Behörde von Vorteil. Die Entscheidung für eine bestimmte technische Umsetzung sollte letztlich aus genannten Gründen immer von dem konkreten Anwendungsszenario abhängig gemacht werden. 7.6 Sicherheitstests in SOA Bevor eine SOA bzw. ein neuer Web Service mit integrierten Sicherheitsmechanismen in den produktiven Betrieb übergehen kann, sollten verschiedenen Sicherheitstests durchgeführt werden. Gerade in Zeiten steigender Bedrohungen sowie der Tatsache eines erhöhten Risikopotenzials innerhalb von SOA wird ein umfangreiches Testen wichtig. Es gibt verschiedene Testmethoden und Tools, die die Verantwortlichen bei der Prüfung der integrierten Sicherheitsmechanismen unterstützen Testmethoden Zur Analyse der Performance, der Sicherheit und der Interoperabilität gibt es verschiedene Testmethoden, die die Herangehensweise an einen solchen Test innerhalb einer SOA bzw. für Web Services beschreiben. Bevor ein Test durchgeführt werden kann, müssen die folgenden Schritte berücksichtigt werden. Planung Bevor Testmethoden zum Einsatz kommen, sollte eine detaillierte Vorabplanung durchgeführt werden. Diese Vorabplanung beschreibt beispielsweise die folgenden Punkte: Allgemeines Vorgehen (Zeit- und Abfolge-Planung), Angewandte Testmethoden (für Performance, Schwachstellen, Interoperabilität), Benötigte Ressourcen, Test-Ziele, Test-Umfang (intern und extern), Regulatorische Anforderungen, Standards und Bedrohungen, Beschreibung von Testfällen. Dabei können bereits erste Fragestellungen formuliert werden, die später vom Testteam gezielt bearbeitet werden. Des Weiteren ist eine Testumgebung zu planen und zu schaffen, die genau wie die spätere Produktiv-Umgebung aufgebaut wird. Dies bedeutet beispielsweise, dass gleiche Serverkomponenten, Systeme und Softwareversionen genutzt werden. Eine virtualisierte Testumgebung stellt eine sehr gute Alternative dar, da sie eine leichte Wiederherstellung der Ausgangssituation auf Grundlage eines initialen Images ermöglicht und damit die Reproduzierbarkeit von Testergebnissen erleichtert. Allerdings muss beachtet werden, dass durch den Einsatz von Virtualisierung gegebenenfalls eine Abweichung von der Produktivumgebung erfolgt, durch die Testergebnisse verfälscht werden können (z.b. Performancemessungen). Für derartige Tests kann eine Virtualisierung daher ggf. nur eingeschränkt genutzt werden. 288

289 Diese Planung ist so zu dokumentieren, dass auch im späteren Verlauf oder nach den jeweiligen Tests, Testfälle nachvollzogen und ggf. Verantwortliche identifiziert werden können. Testmethode Abbildung 102: V-Modell zur Darstellung der Testmethoden in Anlehnung an V-Modell XT[VModellXT] Tests können mit Hilfe verschiedener Testmethoden durchgeführt werden. Eine geeignete Testmethode für das Testen innerhalb einer SOA ist ein V-Modell in Anlehnung an das VModell XT. Die folgenden Darstellung zeigt, welche Testmethoden zum Test der Sicherheit auf welcher Ebene Anwendung finden. Die jeweiligen Tests werden in den folgenden Unterkapiteln näher beschrieben. Testverfahren Für die jeweiligen Tests sind Kriterien zu definieren, die in funktionale und nicht-funktionale aufgeteilt werden können. Besonderes Augenmerk ist auf die nicht-funktionalen Eigenschaften zu legen, da auch das Thema Sicherheit und Compliance als nicht-funktionale Kriterien zu sehen sind. Die folgenden sicherheitsrelevanten Punkte sind aus Sicherheitssicht Teil eines nicht-funktionalen Test: Anforderungen an die Vertraulichkeit, Anforderungen an die Integrität, Anforderungen an die Verfügbarkeit, Anforderungen an die Zugriffsschutz, Regulatorische Anforderungen (Compliance). Auf der anderen Seite beschreiben die funktionalen Kriterien die Funktionsweise der SOA oder eines einzelnen Web Service. Ein funktionaler Test ist aus Sicherheitssicht besonders dann durchzuführen, wenn beispielsweise ein Web Service eine sicherheitsrelevante Funktion ausführen soll (siehe Security as a Services, Kapitel ) oder wenn sich dieser Web Service durch einen hohen Schutzbedarf auszeichnet. Zur Durchführung eines funktionalen Tests sind Kriterien auszuwählen, die eine Bewertung der jeweilige Funktionen zulassen. 289

290 Dokumentation Der gesamte Test ist zu dokumentieren und von den Verantwortlichen abzunehmen. Dadurch werden nicht nur die beschriebenen Rahmenbedingungen festgehalten, sondern auch die Ergebnisse der verschiedenen Tests, so dass ggf. Maßnahmen zur Verbesserung eingeleitet werden können Performance-Tests Damit eine SOA effizient und effektiv eingesetzt werden kann, sollte ein Performance-Test durchgeführt werden. Ziel ist es, die Zuverlässigkeit der SOA bzw. eines Web Services zu prüfen. Innerhalb dieses Tests wird unter anderem die Skalierbarkeit und Robustheit der SOA bzw. einzelner Web Services getestet. Dabei ist beim Test der Robustheit die Frage zu beantworten, wann der getestete Service unter Last zusammenbricht. Es wird also geprüft, wie viele parallele Requests der Service unter Einhaltung einer angemessenen Bearbeitungszeit verarbeiten kann. Dabei werden vor allem gute Anfragen an den Web Service gesendet, um zu prüfen, wie viel Last ohne schadhaften Einfluss von Außen vom Web Service verarbeitet werden kann. Der Performance Test wird auch genutzt, um Denial of Service (DoS)-Angriffe auf die SOA oder einen spezifischen Web Service zu simulieren. Dieser Test soll vor allem herausfinden, ob böse Anfragen vom System erkannt und geblockt werden und ob die SOA trotz des Angriffs weiterhin funktionsfähig bleibt. Zum Anderen wird geprüft, wie schnell ein einzelner Request bearbeitet und ausgeführt werden kann. Dabei spielen die Antwortzeiten eine Rolle und es wird getestet, ob die zuvor definierten Ziele erreicht werden. Die Antwortzeiten können stark von den genutzten Sicherheitsmechanismen, die zur Absicherung der SOA oder eines Web Services genutzt werden, abhängen. Die Antwortzeiten müssen also unter Berücksichtigung der Sicherheitsmechanismen getestet werden Schwachstellen-Tests Ein Schwachstellen-Test ist der wichtigste Test, um die Sicherheit einer SOA zu testen. Durch den Aufbau eines spezifischen, auf den Ziel-Web Service abgestimmten Test, können Sicherheitsexperten Schwachstellen herausfinden und bewerten. Es ist wichtig, dass Schwachstellen geschlossen werden, bevor diese ausgenutzt werden können. Potenzielle Schwachstellen können unter anderem durch folgende Angriffe ausgenutzt werden (siehe auch Kapitel 3.3): Buffer overflows, Recursive playloads, XML- und SQL Injection, Cross Site Scripting (XSS), Schema poisoning, WSDL Enumeration, Einbettung von Malware in SOAP Nachrichten. 290

291 Für einen Schwachstellen-Test muss nach der Vorabplanung ein systematisches Vorgehen definiert bzw. eine Detailplanung erstellt werden. Dazu werden Testfälle erstellt, die Art, erwartetes Ergebnis (negativ/positiv) und Vorgehensweise des jeweiligen Tests beschreiben. Somit hat das Testpersonal ein definiertes Vorgehen, welches sicherstellt, dass alle wichtigen Schwachstellen systematisch überprüft werden. Zudem sollte das erfahrene Testpersonal so weit wie möglich bereits erste Lösungsansätze empfehlen, um eine schnelle und komplette Behebung der gefundenen Mängel zu unterstützen. Während der Tests muss das Testpersonal in der Lage sein, Schwachstellen zu erkennen sowie das richtige Vorgehen und die richtigen Tools für die Durchführung der Tests zu wählen. Dabei ist auch der Schutzbedarf der Daten, die durch den Web Service verarbeitet, gespeichert oder versendet werden, zu berücksichtigen. Je höher dieser ist, um so detaillierter und gezielter ist der Test durchzuführen. Es gibt verschiedene Möglichkeiten, einen Schwachstellen- oder auch Penetration-Test (siehe nächsten Abschnitt) durchzuführen. Bevor solch ein Test durchgeführt werden kann, sollten Kriterien wie Umfang und Vorgehensweise geklärt werden. Schwachstellen-Test (Penetration-Tests) in SOA Ein Schwachstellen-Test kann in seinem Umfang stark variieren. So kann sich der Test z.b. auf Systembestandteile, auf Organisationsbestandteile oder auf sonstige Bestandteile wie z.b. physische, personelle oder politische beschränken. Wird der Umfang definiert muss darauf geachtet werden, dass ein Test bestimmter Bestandteile, z.b. Zugriff von Außen ggf. in der Produktivumgebung durchgeführt werden muss, um ein valides Testergebnis zu bekommen. Um den Produktivbetrieb jedoch nicht zu beeinflussen, ist ein Test in dieser Umgebung eher zu vermeiden. So können zwar nicht alle Angriffsmuster und -Methoden berücksichtigt werden, man begibt sich aber auch nicht in die Gefahr, den laufenden Betrieb zu beeinflussen. Aus diesem Grund wird im Rahmen dieses Kompendiums der Schwachstellen-Test bzw. Penetration-Test der Systembestandteile und Netze nur auf technischer Ebene in einer geschlossenen Testumgebung näher betrachtet. Schwachstellen-Tests können für jedes System nach einer bestimmten Grundvorgehensweise bzw. unter Berücksichtigung bestimmter Grundkriterien immer ähnlich durchgeführt werden. Diese allgemeine Vorgehensweise bzw. Kriterien können auch bei einer SOA bzw. für Web Services angewandt werden. Wird eine solche Vorgehensweise genutzt, sind die Testfälle auf die SOA oder den Web Service anzupassen, um SOA-spezifische Bedrohungen und Schwachstellen (siehe Kapitel 3.3) aufdecken zu können. Aus der Studie Durchführungskonzept für Penetrationtests [BSI 2003] des BSI ergeben sich beispielsweise die in den folgenden Abschnitten beschriebenen Kriterien. Informationsbasis Die Informationsbasis kann je nach Art des Tests variieren. Es werden die folgenden Arten unterschieden: Black-Box Bei diesem Test hat die testende Person keinen besondere Kenntnisse über die SOA bzw. die Web Services. Hierbei wird ein Angriff eines typischen Internet-Hackers realistisch simuliert. Der Hacker muss die benötigten Informationen in öffentlich zugänglichen Datenbanken recherchieren oder von außen als Unternehmensfremder erfragen. Bei einem Test in einer geschlossenen Systemumgebung bedeutet dies, dass die Testdurchführung ohne Kenntnis der Interna der Web Services erfolgt. Es werden übliche Schwachstellen lediglich unter Nutzung der über die Web Services 291

292 verfügbaren Informationen (z.b. durch Verwendung verfügbarer WSDL-Dateien) getestet. White-Box Bei diesem Test ist das zu testende System bekannt, was bedeutet, dass z.b. der Quellcode eingesehen werden kann. Somit können bestimmte Lücken im Quelltext analysiert und geschlossen werden. Grey-Box Eine Verbindung von Back- und White-Box. Dieser Test wird vom internen Testpersonal geplant bzw. geschrieben (White-Box), bevor das eigentliche System bzw. der Web Service entwickelt wurde (Black-Box). Je nach Kritikalität der Daten, die durch die SOA bzw. den Web Service verarbeitet, gespeichert oder versendet werden, ist eine passende Testart auszuwählen. Ein Testverantwortlicher sollte sich jedoch darüber im Klaren sein, dass ein White-Box-Test nicht wirklich ausreichend ist, da somit nicht die üblichen Szenarien wie der Angriff von Außen durch unterschiedliche Typen von Angreifern wie z.b. Hobby-Angreifer, technisch versierte Angreifer oder professionelle Angreifer mit umfangreichen technischen und personellen Ressourcen betrachtet werden. Aggressivität Je nachdem, ob eine abgeschlossene Testumgebung genutzt wird oder nicht, ist die Aggressivität des Tests auszuwählen. Ein Test kann passiv, vorsichtig, abwägend oder aggressiv durchgeführt werden. Je aggressiver der Test durchgeführt wird, desto besser. Aggressiv bedeutet, dass mögliche Schwachstellen einer SOA bzw. eines Web Services auch aktiv ausgenutzt werden um definitiv nachzuweisen, dass diese Schwachstelle auch ausgenutzt werden können. Ein aggressiver Test kann dabei auch benachbarte Systeme in Mitleidenschaft ziehen (z.b. durch Überlastung von Netzwerken) und sollte deshalb nur in abgeschlossenen Testumgebungen durchgeführt werden. Umfang Ein Test kann vollständig, begrenzt und fokussiert durchgeführt werden. Dies bedeutet, dass z.b. eine vollständige SOA oder nur ein bestimmter Web Service (fokussiert) getestet wird. Es sollte ein Test in vollem Umfang durchgeführt werden was bedeutet, dass sämtliche erreichbaren Komponenten einer SOA berücksichtigt werden. Vorgehensweise Die Vorgehensweise eines Tests kann verdeckt oder offensichtlich erfolgen. Verdeckte Tests kommen z.b. dann zum Einsatz wenn zusätzlich Organisationen und Eskalationsmechanismen getestet werden sollen. Dabei ist zu beachten, dass ein verdeckter Test nur in der Produktivumgebung durchgeführt werden kann (mit den bereits angesprochenen Nachteilen), da das Verhalten von Personal nur getestet werden kann, wenn der Test nicht vorher angekündigt wurde. Wurde ein Test mit verdeckten Methoden durchgeführt, ist in jedem Fall ein weiterer Test mit offensichtlichen Methoden notwendig (z.b. Port-Scans). Dadurch erhält man nicht nur ein umfangreiches Testergebnis sondern prüft auch, ab wann ein Sicherheitsmechanismus, der eine SOA bzw. einen Web Service schützen soll, eine Aktion als Angriff identifiziert. Technik Ein Test kann mit Hilfe verschiedener Techniken durchgeführt werden. Dies beschreibt vor allem den Weg, über den ein Angriff stattfindet. Dies kann über das Netzwerk oder andere Kommunikationskanäle, durch physischen Zugang und über den Menschen durch Social 292

293 Engineering erfolgen. Ein typischer Hacker-Angriff erfolgt über das Netzwerk. Die ebenfalls genannten Angriffsszenarien sollten jedoch bei der Planung der Tests nicht vernachlässigt werden. Ausgangspunkt Der Ausgangspunkt ist eng mit der Informationsbasis verknüpft. Hierbei wird festgehalten, ob der Angriff von innen oder von außen erfolgt. Die beschriebenen Kriterien können wie folgt dargestellt werden: Abbildung 103: Kriterien für Schwachstellen-Tests[BSI 2003] Weitere Testvarianten für SOA Neben der beschriebenen Vorgehensweise und den Kriterien eines auf SOA modifizierten allgemeinen Schwachstellen-Tests gibt es noch weitere Tests, die speziell in einer SOA durchgeführt werden sollten. 293