SOA-Security-Kompendiumopensource.corisecio.com/fileadmin/user_upload/SOA... · 2013. 4. 18. ·...

SOA-Security-KompendiumSicherheit in Service-orientierten Architekturen

Version 2.0.1

In Zusammenarbeit mit:

Bundesamt für Sicherheit in der InformationstechnikPostfach 20 03 6353133 BonnTel.: +49 228 99 9582-5599E-Mail: [email protected]: https://www.bsi.bund.de/© Bundesamt für Sicherheit in der Informationstechnik 2009

https://www.bsi.bund.de/

Inhaltsverzeichnis

Inhaltsverzeichnis1 Einleitung....................................................................................................................................91.1 Motivation.........................................................................................................................................91.2 Zielbestimmung und Geltungsbereich.............................................................................................101.3 Aufbau des Kompendiums..............................................................................................................10

2 Grundlagen - Einführung in SOA und Web Services...............................................................122.1 Abstrakte Charakteristika Service-orientierter Architekturen.........................................................122.2 Ziele und Vorteile von SOA............................................................................................................152.3 Konkrete Umsetzungen...................................................................................................................162.4 Beispielszenario..............................................................................................................................20

3 Sicherheitsaspekte Service-orientierter Architekturen..............................................................223.1 Allgemeine Sicherheitsziele............................................................................................................223.2 Kategorien von Sicherheitsgefährdungen........................................................................................253.3 Konkrete Gefährdungen und geeignete Sicherheitsmaßnahmen in einer SOA...............................273.4 Sicherheitsgefährdungen und Gegenmaßnahmen veranschaulicht am Beispielprozess..................41

4 Technologien und Standards.....................................................................................................454.1 Überblick über die Web Service Spezifikationen............................................................................454.2 Grundlegende Web Service-Standards............................................................................................484.3 Dienste beschreiben und auffinden.................................................................................................574.4 Grundlegende Sicherheitsstandards.................................................................................................754.5 Dienstkommunikation absichern.....................................................................................................894.6 Messaging-Nachrichten zustellen..................................................................................................1004.7 Reliable-Messaging.......................................................................................................................1074.8 Transaction Specifications............................................................................................................1114.9 Dienste orchestrieren und choreographieren.................................................................................1184.10 Weitere Standards.........................................................................................................................1274.11 Interoperabilität.............................................................................................................................133

5 Security Management..............................................................................................................1415.1 Governance, Risk- & Compliance-Management...........................................................................1415.2 Sichere SOA Migration.................................................................................................................1565.3 SOA Lifecycle Management.........................................................................................................1725.4 Darstellung des Zusammenhangs Sicherheitsmanagement, GRC, SOA Migration und SOA

Lifecycle Management..................................................................................................................185

6 Konzepte für Sicherheit in Service-orientierten Architekturen...............................................1876.1 SOA Security Framework.............................................................................................................1876.2 Policy Management.......................................................................................................................1926.3 Trust Management.........................................................................................................................2096.4 Identitätsmanagement in SOA.......................................................................................................2186.5 Sichere Dienstkomposition zur Abbildung von Geschäftsprozessen.............................................2346.6 Sicherheit und Interoperabilität mit WS-I.....................................................................................243

Bundesamt für Sicherheit in der Informationstechnik 3

Inhaltsverzeichnis

7 Sichere SOA Technologien in der Praxis................................................................................2607.1 Sicherheit von Portalen als Schnittstelle zu SOAs........................................................................2607.2 Methoden und Möglichkeiten der XML-/WS-*-Filterung............................................................2667.3 Sicherheit SOA-spezifischer Repositories.....................................................................................2757.4 Sichere Dienstbeschreibungen mit BPEL......................................................................................2817.5 Sicherheit REST-basierter SOAs..................................................................................................2837.6 Sicherheitstests in SOA.................................................................................................................2887.7 Anwendungsszenarien...................................................................................................................296

8 Resümee und Ausblick............................................................................................................3188.1 Resümee........................................................................................................................................3188.2 Ausblick........................................................................................................................................3208.3 Forschungsbedarf..........................................................................................................................321

Anhang....................................................................................................................................325Übersicht über die Standards.........................................................................................................325Code-Beispiele..............................................................................................................................333Abkürzungsverzeichnis.................................................................................................................354Glossar..........................................................................................................................................358Referenzen.....................................................................................................................................369

AbbildungsverzeichnisAbbildung 1: Schematische Darstellung der Consumer-Provider-Beziehung...................................12Abbildung 2: Aufbau einer XML-basierten SOAP Nachricht...........................................................17Abbildung 3: Ablauf eines Dienstaufrufs unter Verwendung einer zentralen Registry.....................19Abbildung 4: Web Service-Protokollstack für die unterschiedlichen Phasen der Servicesuche bzw. -nutzung..............................................................................................................................................19Abbildung 5: Beispielszenario einer Service-orientierten Architektur unter Verwendung externer Dienste................................................................................................................................................21Abbildung 6: Beispielszenario einer Service-orientierten Architektur unter Verwendung externer Dienste................................................................................................................................................42Abbildung 7: Überblick über die Web Service Spezifikationen........................................................46Abbildung 8: Aufbau einer SOAP Nachricht.....................................................................................53Abbildung 9: Klassische Verwendung von SOAP.............................................................................54Abbildung 10: Verhältnis von UDDI zu anderen Protokollen und Standards im Web Service-Umfeld [UDDI]..................................................................................................................................62Abbildung 11: Nachrichtenkommunikation bei WS-Discovery [WS-Discovery].............................66Abbildung 12: Darstellung der Zusammenhänge zwischen WS-Policy und WS-PolicyAttachment[WSPO]..................................................................................................................69Abbildung 13: Einbindung von Policies in ein WSDL-Dokument [WSPAtt]...................................72

4 Bundesamt für Sicherheit in der Informationstechnik

Inhaltsverzeichnis

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


Inhaltsverzeichnis

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


Inhaltsverzeichnis

Abbildung 75: Lebenszyklus einer digitalen Identität......................................................................218Abbildung 76: Prinzip des anwendungsspezifischen Identitätsmanagements..................................220Abbildung 77: Prinzip der zentralisierten Verwaltung von Identitäten............................................221Abbildung 78: Prinzip des föderativen Identitätsmanagements.......................................................223Abbildung 79: Prinzip des benutzerzentrischen Identitätsmanagements.........................................226Abbildung 80: Rollen und Beziehungen im Identity Metasystem...................................................229Abbildung 81: Nutzung von Diensten in einer abgesicherten Umgebung.......................................236Abbildung 82: Nutzung von Diensten einer Sicherheitsdomäne......................................................236Abbildung 83: Nutzung von Diensten in verschiedenen Sicherheitsdomänen.................................237Abbildung 84: Transportorientierte Umsetzung der Verschlüsselung und Integrität.......................241Abbildung 85: Nachrichtenbasierte Umsetzung der Verschlüsselung und Integrität.......................241Abbildung 86: Übersicht über die WS-I Profile...............................................................................246Abbildung 87: WS-I Basic Security Profile.....................................................................................251Abbildung 88: WS-I Attachments Profile........................................................................................252Abbildung 89: Simple SOAP Binding.............................................................................................253Abbildung 90: Darstellung Reliable Secure Profile.........................................................................254Abbildung 91: Darstellung WS-I Kerberos Token Profile...............................................................254Abbildung 92: Darstellung WS-I REL Token Profile......................................................................254Abbildung 93: Darstellung WS-I SAML Token Profile..................................................................255Abbildung 94: WS-I Testing Tool Architektur................................................................................257Abbildung 95: Monitor Systemkonfigurationen (vgl. [Br 2003])....................................................258Abbildung 96: Analyzer Tool...........................................................................................................259Abbildung 97: WS-Security-Gateway Deployment.........................................................................270Abbildung 98: Architektur eines WS-Security-Gateways................................................................271Abbildung 99: Zentraler BPEL Workflow.......................................................................................281Abbildung 100: Zentraler BPEL Workflow entschlüsselt Nachrichten komplett............................282Abbildung 101: Zentraler BPEL Workflow leitet verschlüsselte Nachrichtenteile weiter..............283Abbildung 102: V-Modell zur Darstellung der Testmethoden in Anlehnung an V-Modell XT[VModellXT]..............................................................................................................................289Abbildung 103: Kriterien für Schwachstellen-Tests[BSI 2003]......................................................293Abbildung 104: Anwendungsszenario im Überblick.......................................................................297Abbildung 105: Beispielprozess für die betrachteten Anwendungsszenarien..................................299Abbildung 106: Produkt anfragen....................................................................................................300Abbildung 107: Angebot erstellen....................................................................................................300Abbildung 108: Bestellung ausführen..............................................................................................302


Inhaltsverzeichnis

Abbildung 109: Versand...................................................................................................................303Abbildung 110: Bestellung prüfen...................................................................................................305Abbildung 111: Produkt bestellen....................................................................................................306Abbildung 112: Umsatzsteuervoranmeldung...................................................................................308Abbildung 113: Verfügbarkeit prüfen..............................................................................................310Abbildung 114: Bestellung prüfen...................................................................................................311Abbildung 115: Technische Systeme im Beispielprozess................................................................315

TabellenverzeichnisTabelle 1: Beschreibung der MEPs und ihre Fehlerbehandlung........................................................59Tabelle 2: Auflistung der Metadatenformate für WS-MetadataExchange.........................................74Tabelle 3: Sicherheitspezifikationen und deren Anwendung hinsichtlich der Umsetzung von

Sicherheitsanforderungen ...............................................................................................90Tabelle 4: Übersicht über die Spezifikationen des WS-Resource Frameworks...............................128Tabelle 5: Vor- und Nachteil der Top-down Vorgehensweise.........................................................158Tabelle 6: Vor- und Nachteile der Bottom-up Vorgehensweise......................................................158Tabelle 7: Gegenüberstellung einiger Eigenschaften von monolithischen Systemen und SOA......166Tabelle 8: Beispiele für Inkompatibilitäten hinsichtlich der Umsetzung von Sicherheit in einer SOA

.......................................................................................................................................202Tabelle 9: Standardszenarien und ihre Vertrauensbeziehungen.......................................................210Tabelle 10: Mechanismen zur Etablierung von Vertrauen...............................................................214Tabelle 11: Einordnung der Identitätsmanagementmodelle.............................................................219Tabelle 12: Identifizierte Herausforderungen innerhalb und außerhalb des Scopes WS-I Basic

Security Profile..............................................................................................................248Tabelle 13: Identifizierte Bedrohungen innerhalb und außerhalb des Scopes vom WS-I Basic

Security Profile..............................................................................................................249Tabelle 14: Optionen zur Absicherung auf der Transportebene.......................................................250Tabelle 15: Optionen zur Absicherung auf der Nachrichtenebene...................................................250Tabelle 16: WS-I Profile und referenzierte Dokumente...................................................................256Tabelle 17: Vergleich der Standards ebXML und UDDI (vgl. [SM 2005]).....................................280Tabelle 18: Übersicht über die beschriebenen Standards.................................................................331Tabelle 19: Glossar...........................................................................................................................368


SOA-Security-Kompendium

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 IT-Architektur. 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.



1.2 Zielbestimmung und Geltungsbereich

Mit der ersten Version des SOA-Security-Kompendiums wurde ein frei verfügbares Nachschlagewerk geschaffen, das wichtige Standards, Konzepte und Lösungen auf diesem aktuellen Gebiet beschreibt. Die Weiterentwicklung des SOA-Security-Kompendiums 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 SOA-Security-Kompendiums 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 Service-orientierten 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.



Darauf aufbauend findet im dritten Kapitel („Sicherheitsaspekte Service-orientierter Architekturen“) eine Betrachtung allgemeiner als auch spezieller Risiken und IT-Sicherheitsbedrohungen 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 Service-orientierten 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.



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-Provider-Beziehung

Service-orientierte Architekturen unterscheiden sich wie folgt von traditionellen Architektur-Ansä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:

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 Grid-Computing (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 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-SchnittstellenEin 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 KopplungServices 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, sodass Änderungen nach Möglichkeit nur lokale Auswirkungen haben und Komponenten leicht ausgetauscht werden können.FunktionsabstraktionUm 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.WiederverwendbarkeitEin 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-AutonomieEin 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 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 ServiceOrchestrierung 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 Daten- und 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. Legacy-Anwendungen) über Services lässt sich eine Flexibilisierung von monolithischen Systemen erreichen. Auf diese Weise kann auch eine schrittweise Migration großer Legacy Systeme 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 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 XML-basierten SOAP Nachricht

Web Services finden immer größere Verbreitung. Insbesondere im Kontext Service-orientierter 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 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:



SOA Einsteiger

SOAP Response:Der Web Service antwortet mit zwei gefundenen Items im SOAP Body.

3462346123574 SOA für Einsteiger SOA Grundlagen – Serviceorientierung für Einsteiger

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.



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.



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 Management 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.6) 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.



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.


Abbildung 5: Beispielszenario einer Service-orientierten Architektur unter Verwendung externer Dienste

K u n d e

P r o d u k t A n f r a g e

H ä n d l e r

V e r f ü g b a r k e it p r ü f e n

A n g e b o t e r s t e l le n

B e s t e llu n g a u f g e b e n

B e s t e l lu n g p r ü f e n

Z a h l u n g s s e r v i c e P r o v i d e r

K r e d it k a r t e v a l id ie r e n

V e r s a n d u n d R e c h n u g s -

s t e llu n g

B e s t e l lu n g a u s f ü h r e n

P r o d u z e n t

P r o d u k t b e s t e lle n

B e s t e llu n g a u s f ü h r e n

U m s a t z s t e u e r -v o r a n m e ld u n g

B e s t e u e r u n gs -v e r f a h r e n

F i n a n z a m t

B 2 C B 2 B B 2 B G 2 B

A d r e s s d a t e n p r ü f e n

Z a h lu n g s -f ä h ig k e itp r ü f e n

P r o d u k t a u f

L a g e r ?

B e s t e ll -A b le h n u n g

e r h a lt e n

V e r s a n d -in f o r m a t io n

e r h a lt e n

B e s t e ll-in f o r m a t io n

e r h a lt e n


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 IT-Verantwortlichen 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 und somit das Mitlesen durch Dritte verhindert wird. 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 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.

Integrität

Defininition:Integrität fordert, dass sensitive Daten durch Dritte weder modifiziert noch gelöscht werden können. Diese Forderung umfasst somit sowohl den Schutz vor Verlust als auch die Fälschungssicherheit. Integrität kann durch den Einsatz von Signaturen erreicht werden.

Besondere Herausforderung bei SOA:In einer SOA ist i.d.R. wie auch zur Wahrung der Vertraulichkeit eine Sicherung auf Nachrichtenebene vorzunehmen. Dies ist insbesondere dann erforderlich, wenn Inhalte (z.B. Datensätze) einer SOAP-Nachricht während der Abarbeitung eines Geschäftsprozesses durch unterschiedliche Dienste bzw. Komponenten bearbeitet und modifiziert werden. Solche Zwischensysteme müssen ggf. Daten lesen dürfen, die durch ein anderes Zwischensystem geschrieben wurden, jedoch dürfen sie diese Daten weder löschen noch verändern.Zur Veranschaulichung sei das o.g. Beispiel zur Vertraulichkeit angeführt, bei dem im Rahmen einer Bestellung der Rechnungsbetrag, der am Ende des Geschäftsprozesses durch einen Dienstleister abgebucht wird, im Verlauf der Bestellbearbeitung nicht unberechtigt modifiziert werden darf.

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 Load-Balancing 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:

AuthentifizierungAuthentifizierung 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 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.

AutorisierungDie 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.



VerbindlichkeitVerbindlichkeit 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.

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 IT-spezifische 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.

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 Service-orientierten 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 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 SOA-spezifische 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 Service-orientierte 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.

3.3.1 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.

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 sogenannte 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) 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 XML-Parsing 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 PoisoningMittels 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 e

SOA-Security-Kompendiumopensource.corisecio.com/fileadmin/user_upload/SOA... · 2013. 4. 18. ·...

Documents

Transcript of SOA-Security-Kompendiumopensource.corisecio.com/fileadmin/user_upload/SOA... · 2013. 4. 18. ·...