SOA-Security-Kompendium Sicherheit in Service-orientierten Architekturen
Version 2.0 In Zusammenarbeit mit:
Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 228 99 9582-5599 E-Mail: [email protected] Internet: https://www.bsi.bund.de/ © Bundesamt für Sicherheit in der Informationstechnik 2009 Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einleitung...... 9 1.1 Motivation...... 9 1.2 Zielbestimmung und Geltungsbereich...... 10 1.3 Aufbau des Kompendiums...... 10 2 Grundlagen - Einführung in SOA und Web Services...... 12 2.1 Abstrakte Charakteristika Service-orientierter Architekturen...... 12 2.2 Ziele und Vorteile von SOA...... 15 2.3 Konkrete Umsetzungen...... 16 2.4 Beispielszenario...... 20 3 Sicherheitsaspekte Service-orientierter Architekturen...... 22 3.1 Allgemeine Sicherheitsziele...... 22 3.2 Kategorien von Sicherheitsgefährdungen...... 25 3.3 Konkrete Gefährdungen und geeignete Sicherheitsmaßnahmen in einer SOA...... 27 3.4 Sicherheitsgefährdungen und Gegenmaßnahmen veranschaulicht am Beispielprozess...... 41 4 Technologien und Standards...... 45 4.1 Überblick über die Web Service Spezifikationen...... 45 4.2 Grundlegende Web Service-Standards...... 48 4.3 Dienste beschreiben und auffinden...... 57 4.4 Grundlegende Sicherheitsstandards...... 75 4.5 Dienstkommunikation absichern...... 89 4.6 Messaging-Nachrichten zustellen...... 100 4.7 Reliable-Messaging...... 107 4.8 Transaction Specifications...... 111 4.9 Dienste orchestrieren und choreographieren...... 118 4.10 Weitere Standards...... 127 4.11 Interoperabilität...... 133 5 Security Management...... 141 5.1 Governance, Risk- & Compliance-Management...... 141 5.2 Sichere SOA Migration...... 156 5.3 SOA Lifecycle Management...... 172 5.4 Darstellung des Zusammenhangs Sicherheitsmanagement, GRC, SOA Migration und SOA Lifecycle Management...... 185 6 Konzepte für Sicherheit in Service-orientierten Architekturen...... 187 6.1 SOA Security Framework...... 187 6.2 Policy Management...... 192 6.3 Trust Management...... 209 6.4 Identitätsmanagement in SOA...... 218 6.5 Sichere Dienstkomposition zur Abbildung von Geschäftsprozessen...... 234 6.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...... 260 7.1 Sicherheit von Portalen als Schnittstelle zu SOAs...... 260 7.2 Methoden und Möglichkeiten der XML-/WS-*-Filterung...... 266 7.3 Sicherheit SOA-spezifischer Repositories...... 275 7.4 Sichere Dienstbeschreibungen mit BPEL...... 281 7.5 Sicherheit REST-basierter SOAs...... 283 7.6 Sicherheitstests in SOA...... 288 7.7 Anwendungsszenarien...... 296 8 Resümee und Ausblick...... 318 8.1 Resümee...... 318 8.2 Ausblick...... 320 8.3 Forschungsbedarf...... 321 Anhang...... 325 Übersicht über die Standards...... 325 Code-Beispiele...... 333 Abkürzungsverzeichnis...... 354 Glossar...... 358 Referenzen...... 369
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 Service- Umfeld [UDDI]...... 62 Abbildung 11: Nachrichtenkommunikation bei WS-Discovery [WS-Discovery]...... 66 Abbildung 12: Darstellung der Zusammenhänge zwischen WS-Policy und WS- PolicyAttachment[WSPO]...... 69 Abbildung 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.....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...... 102 Abbildung 26: Notification Pattern...... 105 Abbildung 27: Brokered Notification Pattern...... 106 Abbildung 28: Darstellung der Funktionsweise von WS-ReliableMessaging [WSRM]...... 110 Abbildung 29: Detaillierte Darstellung des Ablaufs von WS-ReliableMessaging [WSRM]...... 111 Abbildung 30: Zusammenspiel der einzelnen Komponenten bei WS-Coordination...... 113 Abbildung 31: Szenario WS-AtomicTransaction...... 115 Abbildung 32: Darstellung eines in WSFL beschriebenen Work Flow/ Prozesses einer Ticketbestellung [WSFL]...... 119 Abbildung 33: WS-CDL Funktionsweise (vgl. [WS-CDL])...... 123 Abbildung 34: Aufbau einer elektronischen Geschäftsbeziehung mit ebXML in Anlehnung an [ebXML2]...... 126 Abbildung 35: Schematischer Aufbau einer SCA Komponente...... 131 Abbildung 36: Einordnung SOA Governance...... 142 Abbildung 37: PDCA-Cycle mit Komponenten...... 147 Abbildung 38: Einordnung SOA-Risiken...... 148 Abbildung 39: Darstellung des Risikomanagement-Prozesses...... 149 Abbildung 40: Schrittweise SOA Migration (vgl. [Gi 2008])...... 159 Abbildung 41: Vorgehen SOA Migration...... 159 Abbildung 42: SOA Maturity Model...... 165 Abbildung 43: Typische gewachsene Anwendungslandschaft einer Organisation und deren Interaktion...... 165 Abbildung 44: Arbeitsweise eines Wrapper Service...... 167
Bundesamt für Sicherheit in der Informationstechnik 5 Inhaltsverzeichnis
Abbildung 45: Abbilden der Sicherheitsmechanismen des Wrapper Service auf die Altanwendung ...... 168 Abbildung 46: Nutzung eines gemeinsamen Security Service von Wrapper Service und Anwendung ...... 168 Abbildung 47: Aufbau DMZ (vgl. [Ka 2008])...... 170 Abbildung 48: SOA Lebenszyklus...... 173 Abbildung 49: IT-System Lebenszyklus...... 179 Abbildung 50: Darstellung des V-Modells XT[VModellXT]...... 180 Abbildung 51: Nutzungszyklus eines Web Service...... 181 Abbildung 52: Übersicht der Lebenszyklen...... 182 Abbildung 53: Darstellung der Zusammenhänge...... 185 Abbildung 54: Darstellung der Zusammenhänge SOA Governance und Security Framework...... 187 Abbildung 55: Architekturansätze...... 188 Abbildung 56: Sicherheit als integraler Bestandteil der Infrastruktur einer SOA...... 189 Abbildung 57: Sicherheit als eigenständiger Service...... 190 Abbildung 58: Sicherheit als integraler Bestandteil der mit einem WS-Interface versehenden Anwendung ...... 190 Abbildung 59: Basiskomponenten für das Policy Management...... 193 Abbildung 60: Abstraktionsebenen von Policies (vgl. [PMgmt])...... 195 Abbildung 61: Lokale Speicherung von Policies und separate Administration (vgl. [PMgmt]).....199 Abbildung 62: Lokale Speicherung von Policies mit zentralisierter Administration (vgl. [PMgmt]) ...... 199 Abbildung 63: Zentrale Speicherung und Administration der Policies (vgl. [PMgmt])...... 200 Abbildung 64: Zentrale Administration sowie zentrale und dezentrale Speicherung der Policies (vgl. [PMgmt])...... 201 Abbildung 65: Dynamische Nutzung eines Dienstes unter Berücksichtigung von Sicherheitsanforderungen...... 203 Abbildung 66: Auswahl einer Option zur Verschlüsselung...... 205 Abbildung 67: Sicheres Late Service Binding...... 205 Abbildung 68: Policy Enforcement Point als Bibliothek...... 207 Abbildung 69: Policy Enforcement Point als Modul...... 207 Abbildung 70: Policy Enforcement Point als Gateway...... 208 Abbildung 71: Direktes Vertrauen zwischen einem Client und einem Dienst...... 211 Abbildung 72: Vertrauensbeziehungen in einer Domäne mit zentralen Sicherheitsdiensten...... 211 Abbildung 73: Direktes Vertrauen zwischen einem Dienst und einer Partnerdomäne...... 212
6 Bundesamt für Sicherheit in der Informationstechnik Inhaltsverzeichnis
Abbildung 74: Indirektes Vertrauen zwischen einem Dienst und einer Partnerdomäne...... 213 Abbildung 75: Lebenszyklus einer digitalen Identität...... 218 Abbildung 76: Prinzip des anwendungsspezifischen Identitätsmanagements...... 220 Abbildung 77: Prinzip der zentralisierten Verwaltung von Identitäten...... 221 Abbildung 78: Prinzip des föderativen Identitätsmanagements...... 223 Abbildung 79: Prinzip des benutzerzentrischen Identitätsmanagements...... 226 Abbildung 80: Rollen und Beziehungen im Identity Metasystem...... 229 Abbildung 81: Nutzung von Diensten in einer abgesicherten Umgebung...... 236 Abbildung 82: Nutzung von Diensten einer Sicherheitsdomäne...... 236 Abbildung 83: Nutzung von Diensten in verschiedenen Sicherheitsdomänen...... 237 Abbildung 84: Transportorientierte Umsetzung der Verschlüsselung und Integrität...... 241 Abbildung 85: Nachrichtenbasierte Umsetzung der Verschlüsselung und Integrität...... 241 Abbildung 86: Übersicht über die WS-I Profile...... 246 Abbildung 87: WS-I Basic Security Profile...... 251 Abbildung 88: WS-I Attachments Profile...... 252 Abbildung 89: Simple SOAP Binding...... 253 Abbildung 90: Darstellung Reliable Secure Profile...... 254 Abbildung 91: Darstellung WS-I Kerberos Token Profile...... 254 Abbildung 92: Darstellung WS-I REL Token Profile...... 254 Abbildung 93: Darstellung WS-I SAML Token Profile...... 255 Abbildung 94: WS-I Testing Tool Architektur...... 257 Abbildung 95: Monitor Systemkonfigurationen (vgl. [Br 2003])...... 258 Abbildung 96: Analyzer Tool...... 259 Abbildung 97: WS-Security-Gateway Deployment...... 270 Abbildung 98: Architektur eines WS-Security-Gateways...... 271 Abbildung 99: Zentraler BPEL Workflow...... 281 Abbildung 100: Zentraler BPEL Workflow entschlüsselt Nachrichten komplett...... 282 Abbildung 101: Zentraler BPEL Workflow leitet verschlüsselte Nachrichtenteile weiter...... 283 Abbildung 102: V-Modell zur Darstellung der Testmethoden in Anlehnung an V-Modell XT[VModellXT]...... 289 Abbildung 103: Kriterien für Schwachstellen-Tests[BSI 2003]...... 293 Abbildung 104: Anwendungsszenario im Überblick...... 297 Abbildung 105: Beispielprozess für die betrachteten Anwendungsszenarien...... 299 Abbildung 106: Produkt anfragen...... 300
Bundesamt für Sicherheit in der Informationstechnik 7 Inhaltsverzeichnis
Abbildung 107: Angebot erstellen...... 300 Abbildung 108: Bestellung ausführen...... 302 Abbildung 109: Versand...... 303 Abbildung 110: Bestellung prüfen...... 305 Abbildung 111: Produkt bestellen...... 306 Abbildung 112: Umsatzsteuervoranmeldung...... 308 Abbildung 113: Verfügbarkeit prüfen...... 310 Abbildung 114: Bestellung prüfen...... 311 Abbildung 115: Technische Systeme im Beispielprozess...... 315
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...... 128 Tabelle 5: Vor- und Nachteil der Top-down Vorgehensweise...... 158 Tabelle 6: Vor- und Nachteile der Bottom-up Vorgehensweise...... 158 Tabelle 7: Gegenüberstellung einiger Eigenschaften von monolithischen Systemen und SOA...... 166 Tabelle 8: Beispiele für Inkompatibilitäten hinsichtlich der Umsetzung von Sicherheit in einer SOA ...... 202 Tabelle 9: Standardszenarien und ihre Vertrauensbeziehungen...... 210 Tabelle 10: Mechanismen zur Etablierung von Vertrauen...... 214 Tabelle 11: Einordnung der Identitätsmanagementmodelle...... 219 Tabelle 12: Identifizierte Herausforderungen innerhalb und außerhalb des Scopes WS-I Basic Security Profile...... 248 Tabelle 13: Identifizierte Bedrohungen innerhalb und außerhalb des Scopes vom WS-I Basic Security Profile...... 249 Tabelle 14: Optionen zur Absicherung auf der Transportebene...... 250 Tabelle 15: Optionen zur Absicherung auf der Nachrichtenebene...... 250 Tabelle 16: WS-I Profile und referenzierte Dokumente...... 256 Tabelle 17: Vergleich der Standards ebXML und UDDI (vgl. [SM 2005])...... 280 Tabelle 18: Übersicht über die beschriebenen Standards...... 331 Tabelle 19: Glossar...... 368
8 Bundesamt für Sicherheit in der Informationstechnik 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.
Bundesamt für Sicherheit in der Informationstechnik 9 SOA-Security-Kompendium
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.
10 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 11 SOA-Security-Kompendium
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:
12 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
Bundesamt für Sicherheit in der Informationstechnik 13 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 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
Bundesamt für Sicherheit in der Informationstechnik 15 SOA-Security-Kompendium 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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
Bundesamt für Sicherheit in der Informationstechnik 17 SOA-Security-Kompendium
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:
SOAP Response: Der Web Service antwortet mit zwei gefundenen Items im SOAP Body.
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 19 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
B 2 C B 2 B B 2 B G 2 B
Zahlungsservice K u n d e H ä n d l e r P r o v i d e r P r o d u z e n t F i n a n z a m t
P r o d u k t Verfügbarkeit A n f r a g e p r ü f e n
A n g e b o t e r s t e lle n
Bestellung Bestellung Adressdaten a u f g e b e n p r ü f e n p r ü f e n
B e s t e ll- A b le h n u n g Bestellung Kreditkarte e r h a lt e n a u s f ü h r e n v a lid ie r e n
B e s t e ll- P r o d u k t Z a h lu n g s - inform ation a u f f ä h ig k e it e r h a lt e n L a g e r ? p r ü f e n
P r o d u k t Bestellung b e s t e lle n a u s f ü h r e n
V e r s a n d - Versand und inform ation R e c h n u g s - e r h a lt e n s t e llu n g
U m satzsteuer - Besteuerungs - voranm eldung v e r f a h r e n
Abbildung 5: Beispielszenario einer Service-orientierten Architektur unter Verwendung externer Dienste
Bundesamt für Sicherheit in der Informationstechnik 21 SOA-Security-Kompendium
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. 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 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:
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
Bundesamt für Sicherheit in der Informationstechnik 23 SOA-Security-Kompendium 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 25 SOA-Security-Kompendium
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
26 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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.
Bundesamt für Sicherheit in der Informationstechnik 27 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 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
Bundesamt für Sicherheit in der Informationstechnik 29 SOA-Security-Kompendium 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Meta- Informationen 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 Routing- Informationen 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 Sicherheits- Appliances).
Bundesamt für Sicherheit in der Informationstechnik 31 SOA-Security-Kompendium
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 SOA- Softwarekomponenten später die Signatur zwar überprüfen (und als gültig ansehen), jedoch den manipulierten Body weiterverarbeiten.
32 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Script- Code 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
Bundesamt für Sicherheit in der Informationstechnik 33 SOA-Security-Kompendium 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 XML- Nachrichten 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Geeignete Gegenmaßnahme: Nach Möglichkeit sollten stärkere Authentifizierungsverfahren als Benutzername/Passwort- Kombinationen verwendetet werden, beispielsweise Smartcards bzw. Public-Key- Infrastrukturen. 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.
Bundesamt für Sicherheit in der Informationstechnik 35 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Service- orientierte 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 Sicherheits- bzw. Notfallvorsorgekonzept, können geeignete Sicherheitsmaßnahmen ggf. nicht zeitnah durchgeführt werden und ein erheblicher Schaden für die Organisation entsteht.
Bundesamt für Sicherheit in der Informationstechnik 37 SOA-Security-Kompendium
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 Service- orientierten 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.
3.3.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
3.3.4 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
Bundesamt für Sicherheit in der Informationstechnik 39 SOA-Security-Kompendium 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 41 SOA-Security-Kompendium
B 2 C B 2 B B 2 B G 2 B
Zahlungsservice K u n d e H ä n d l e r P r o v i d e r P r o d u z e n t F i n a n z a m t
P r o d u k t Verfügbarkeit A n f r a g e p r ü f e n
A n g e b o t e r s t e lle n
Bestellung Bestellung Adressdaten a u f g e b e n p r ü f e n p r ü f e n
B e s t e ll- A b le h n u n g Bestellung Kreditkarte e r h a lt e n a u s f ü h r e n v a lid ie r e n
B e s t e ll- P r o d u k t Z a h lu n g s - inform ation a u f f ä h ig k e it e r h a lt e n L a g e r ? p r ü f e n
P r o d u k t Bestellung b e s t e lle n a u s f ü h r e n
V e r s a n d - Versand und inform ation R e c h n u g s - e r h a lt e n s t e llu n g
U m satzsteuer - Besteuerungs - voranm eldung v e r f a h r e 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
Bundesamt für Sicherheit in der Informationstechnik 43 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
Bundesamt für Sicherheit in der Informationstechnik 45 SOA-Security-Kompendium
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 Service- orientierter 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 zusatzlichë 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 Gerusẗ fur ̈ Serviceanforderungen jeglicher Art bildet, fullt ̈ WS-SecurityPolicy dieses mit konkreten Anforderungen bezuglicḧ 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 Vollstandigkeiẗ 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 Standard- Protokoll 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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. WS- Addressing, 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.
Bundesamt für Sicherheit in der Informationstechnik 47 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.2.1 XML
4.2.1.1 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.
4.2.1.2 Grundlagen
Die Grundfunktion von XML besteht darin, eigene Auszeichnungssprachen zu definieren und somit Regeln für die informationelle Struktur von Dokumenten bereitzustellen. Markup- Sprachen 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
Bundesamt für Sicherheit in der Informationstechnik 49 SOA-Security-Kompendium
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 XML- Dokument 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.
4.2.1.3 Schemata
Das folgende Beispiel zeigt einen Auszug aus einer XML-Schema Definition (XSD-Datei):
50 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.2.1.4 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.
4.2.1.5 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.
Bundesamt für Sicherheit in der Informationstechnik 51 SOA-Security-Kompendium
4.2.2 SOAP
4.2.2.1 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.
4.2.2.2 Grundlagen
SOAP wurde 1998 von Microsoft und UserLand Software für Remote-Procedure-Call- Aufrufe (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 WS- Addresssing 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
SO AP Envelope
O p tional: H eader P arts
S O A P B o d y
SO A P M essage Payload
O p tional: SO A P Fault
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
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.Bundesamt für Sicherheit in der Informationstechnik 53 SOA-Security-Kompendium
4.2.2.3 Schemata
Das vom W3C empfohlene Schema für SOAP ist unter http://www.w3.org/2003/05/soap- envelope oder http://schemas.xmlsoap.org/wsdl/soap/ zu finden.
4.2.2.4 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 i s t r y
SOAP
C o n s u m e r P r o v i d e r
Abbildung 9: Klassische Verwendung von SOAP
4.2.2.5 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.2.3 SOAP with Attachments (SwA)
4.2.3.1 Definition
SOAP with Attachments (SwA, SOAP mit Anhängen) bietet die Möglichkeit, SOAP Nachrichten mit unterschiedlichsten Anhängen zu versenden.
4.2.3.2 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.
4.2.3.3 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.
4.2.3.4 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.
4.2.3.5 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.
4.2.4 MTOM
4.2.4.1 Definition
MTOM (Message Transmission Optimization Mechanism) ist eine Methode, um das Übertragungsvolumen bei der SOAP Kommunikation zu optimieren, indem Teile der
Bundesamt für Sicherheit in der Informationstechnik 55 SOA-Security-Kompendium
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 XML- Elemente mit beliebigem Inhalt in einem MIME-Anhang zu serialisieren.
4.2.4.2 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 XML- Dokumentes 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
4.2.4.3 Schemata
Das Schemata für
4.2.4.4 Szenarien
Der Einsatz von MTOM erfolgt immer dort, wo größere Binärdateien, wie z.B. Audio- Dateien, 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 MTOM- Endpunkte sowohl MTOM als auch SwA, dagegen SwA-Endpunkte nicht mit MTOM optimierte Nachrichten verarbeiten können.
56 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.2.4.5 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.
4.3.1 WSDL
4.3.1.1 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.
4.3.1.2 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 Message- Exchange-Pattern spezifiziert werden. WSDL-Dokumente sind hierarchisch aufgebaut, wobei das Wurzelelement eines WSDL-2.0-Dokuments das
Bundesamt für Sicherheit in der Informationstechnik 57 SOA-Security-Kompendium
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: •
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:
•
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
MEP Beschreibung Fehlerbehandlung in-only Es werden nur Nachrichten empfangen. No Fault robust-in-only Es werden nur Nachrichten empfangen, außer im Message Triggers Fehlerfall. Fault in-out Einer eingehenden Nachricht folgt eine Fault Replaces ausgehende Nachricht. Message in-optional-out Einer eingehenden Nachricht folgt optional eine Message Triggers ausgehende Nachricht. Fault out-only Es werden nur Nachrichten gesendet. No Fault robust-out-only Es werden nur Nachrichten gesendet, außer im Message Triggers Fehlerfall. Fault out-in Einer ausgehenden Nachricht folgt eine Fault Replaces eingehende Nachricht. Message out-optional-in Einer ausgehenden Nachricht folgt optional eine Message Triggers eingehenden Nachricht. Fault Tabelle 1: Beschreibung der MEPs und ihre Fehlerbehandlung
Neben der Reihenfolge und Kardinalität der Nachrichten definiert ein Message-Exchange- Pattern 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.
4.3.1.3 Schemata
Das Schema für WSDL findet sich unter http://schemas.xmlsoap.org/wsdl/.
4.3.1.4 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
Bundesamt für Sicherheit in der Informationstechnik 59 SOA-Security-Kompendium erforderlichen Parameter, um den Dienst korrekt anzusprechen. Mit Hilfe von SOAP kann der Consumer die in dem WSDL-Dokument definierten Funktionen aufrufen.
4.3.1.5 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.
4.3.2 UDDI
4.3.2.1 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].
4.3.2.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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:
Bundesamt für Sicherheit in der Informationstechnik 61 SOA-Security-Kompendium
Abbildung 10: Verhältnis von UDDI zu anderen Protokollen und Standards im Web Service-Umfeld [UDDI]
4.3.2.3 Schemata
Das Schema für UDDI ist unter http://www.uddi.org/schema/uddi_v1.xsd zu finden.
4.3.2.4 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 UDDI- Verzeichnis. 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 WSDL- Beschreibung 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.3.2.5 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.
4.3.3 WS-Inspection
4.3.3.1 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].
4.3.3.2 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 Dienste- Consumer, 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 UDDI- Verzeichnissen 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]:
Bundesamt für Sicherheit in der Informationstechnik 63 SOA-Security-Kompendium
4.3.3.3 Schemata
Ein Standard-Schema ist unter http://schemas.xmlsoap.org/ws/2001/10/inspection/ zu finden.
4.3.3.4 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 http://www.ProvidersPage.com/inspection.wsil 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.
4.3.3.5 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.3.4 WS-Discovery
4.3.4.1 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 adhoc- und 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].
4.3.4.2 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. [WS- Discovery]). 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).
Bundesamt für Sicherheit in der Informationstechnik 65 SOA-Security-Kompendium
Abbildung 11: Nachrichtenkommunikation bei WS-Discovery [WS-Discovery]
1. Sobald ein Web Service (Ziel-Service) das Netzwerk betritt, wird ein „Multicast- Hello“ 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
(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.
4.3.4.3 Schemata
Ein Standard-Schema ist unter http://schemas.xmlsoap.org/ws/2005/04/discovery/ws- discovery.xsd zu finden.
4.3.4.4 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.
4.3.4.5 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.
4.3.5 WS-Policy
4.3.5.1 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/oder- Verknüpfungen zu definieren. Das konkrete Vokabular zur Definition der Alternativen ist Teil von domänenspezifischen Spezifikationen, wie WS-SecurityPolicy oder WS- PolicyAssertion.
Bundesamt für Sicherheit in der Informationstechnik 67 SOA-Security-Kompendium
4.3.5.2 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
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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 WS- PolicyAttachment[WSPO]
4.3.5.3 Schemata
Das Schema für WS-Policy in der Version 1.5 ist unter http://www.w3.org/2007/02/ws- policy.xsd zu finden.
4.3.5.4 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.
Bundesamt für Sicherheit in der Informationstechnik 69 SOA-Security-Kompendium
4.3.5.5 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.
4.3.6 WS-PolicyAssertion
4.3.6.1 Definition
WS-PolicyAssertion definiert einen Satz an Policy-Assertions für die Verwendung in WS- Policy, 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.
4.3.6.2 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: •
4.3.6.3 Schemata
Ein Schema für WS-PolicyAssertion ist unter http://schemas.xmlsoap.org/ws/2002/12/policy/ zu finden.
4.3.6.4 Szenarien
Durch WS-PolicyAssertion kann beispielsweise bestimmt werden, dass
70 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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.
4.3.6.5 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.
4.3.7 WS-PolicyAttachment
4.3.7.1 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.
4.3.7.2 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. 2007 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:
Bundesamt für Sicherheit in der Informationstechnik 71 SOA-Security-Kompendium
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.
4.3.7.3 Schemata
Das Schema für WS-PolicyAttachment in der Version 1.5 ist unter http://www.w3.org/2007/02/ws-policy.xsd zu finden.
4.3.7.4 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Abbildung 14: Einbettung einer Policy mit verschiedenen Assertions in ein WSDL- Dokument
4.3.7.5 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.
4.3.8 WS-MetadataExchange
4.3.8.1 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 WS- Transfer auf.
4.3.8.2 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.
Bundesamt für Sicherheit in der Informationstechnik 73 SOA-Security-Kompendium
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 WS- MetadataExchange Spezifikation definiert dazu die folgenden URI-Werte um verschiedene Datenformate zu kennzeichnen.
Dialect URI Metadata-Format http://www.w3.org/2001/XMLSchema xs:schema [XML Schema] http://schemas.xmlsoap.org/wsdl/ wsdl:definitions [WSDL] http://schemas.xmlsoap.org/ws/2004/09/policy wsp:Policy [WS-Policy] http://schemas.xmlsoap.org/ws/2004/09/policy/ wsp:PolicyAttachment attachment [WS-PolicyAttachment] http://schemas.xmlsoap.org/ws/2004/09/mex 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.3.8.3 Schemata
Ein Standard-Schema ist unter http://schemas.xmlsoap.org/ws/2004/09/mex/MetadataExchange.xsd zu finden.
4.3.8.4 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.
4.3.8.5 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.
4.4.1 XML-Encryption
4.4.1.1 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.
Bundesamt für Sicherheit in der Informationstechnik 75 SOA-Security-Kompendium
4.4.1.2 Grundlagen
Die Verschlüsselung durch XML-Encryption erfolgt im XML-Dokument und kann sehr feingranular (Dokument, Element, Elementinhalt) erfolgen. Diese Eigenschaft von XML- Encryption 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
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
76 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Entschlüsselung Zuerst wird das
4.4.1.3 Schemata
Das Schema für XML-Encryption ist unter www.w3.org/TR/xmlenc-core/xenc-schema.xsd zu finden.
4.4.1.4 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 WS- Security 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.
4.4.1.5 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.
4.4.2 XML-Signature
4.4.2.1 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 XML- Signature können XML-Dokumente oder durch das XML-Dokument referenzierte Ressourcen, typischerweise XML-Dokumente, signiert werden. Das Signieren mit XML- Signature gewährleistet die Integrität, Authentizität und Verbindlichkeit von Daten.
Bundesamt für Sicherheit in der Informationstechnik 77 SOA-Security-Kompendium
4.4.2.2 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 XML- Dokumenten 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.
Signaturvarianten Für das Signieren von XML-Dokumenten stehen drei unterschiedlichen Varianten zur Verfügung: • Enveloped Signature: Einbettung der Signatur in das XML-Dokument.
Signiertes X M L - D o k u m e n t
XML - S i g n a t u r
Abbildung 16: Enveloped Signature
• Enveloping Signature: Signatur schließt signierte Daten ein.
XML - D o k u m e n t
XML - S i g n a t u r
Signiertes 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
XML - D o k u m e n t
XML - S i g n a t u r
Signierte D aten
Abbildung 18: Detached Signature
Hauptelemente Eine XML-Signature besteht aus dem Wurzelelement
4.4.2.3 Schemata
Das Schema für XML-Signature ist unter www.w3.org/2000/09/xmldsig zu finden.
4.4.2.4 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.
Bundesamt für Sicherheit in der Informationstechnik 79 SOA-Security-Kompendium
4.4.2.5 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.
4.4.3 SAML
4.4.3.1 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.
4.4.3.2 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 6.4.4.2). 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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),
Bundesamt für Sicherheit in der Informationstechnik 81 SOA-Security-Kompendium
• 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 6.4.
4.4.3.3 Schemata
Das Schemata für SAML ist unter http://docs.oasis-open.org/security/saml/v2.0/saml-schema- protocol-2.0.xsd zu finden.
4.4.3.4 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.
4.4.3.5 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.
4.4.4 XACML
4.4.4.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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].
4.4.4.2 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.
Bundesamt für Sicherheit in der Informationstechnik 83 SOA-Security-Kompendium
Abbildung 20: XACML Architektur (vgl. [XACML_IBM])
XACML Policy Eine Policy besteht aus einer Reihe von Regeln (rules), einer Kennung für Regeln- kombinierende 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
4.4.4.3 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.
4.4.4.4 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.
Bundesamt für Sicherheit in der Informationstechnik 85 SOA-Security-Kompendium
4.4.5 SPML
4.4.5.1 Definition
SPML steht als Akronym für Service Provisioning Markup Language und ist ein XML- basiertes Framework für den Austausch von Benutzer-, Ressourcen- und Service- Provisionierungs-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].
4.4.5.2 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 HR- Systeme 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 SPML- Spezifikation. • 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.).
4.4.5.3 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.
4.4.5.4 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
Bundesamt für Sicherheit in der Informationstechnik 87 SOA-Security-Kompendium sich der Administrations- bzw. Provisionierungsaufwand durch eine Automatisierung ggf. erheblich minimieren. SPML kann dabei helfen, Provisionierungsprozesse zu vereinfachen und effizienter zu gestalten.
4.4.6 XML Key Management Specification (XKMS)
4.4.6.1 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.
4.4.6.2 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 SOA- Sicherheitsinfrastruktur 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.4.6.3 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 http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd zu finden.
4.4.6.4 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 l i e n t X K M S Service P K I S e r v e r
LocateR equest
LocateR esult
Abbildung 22: Interaktion zwischen einem Client und einem XKMS-Service (Schlüsselaustausch) in Anlehnung an [XKMS]
4.4.6.5 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.
Bundesamt für Sicherheit in der Informationstechnik 89 SOA-Security-Kompendium
Spezifikation Sicherheitsanforderungen
WS-Security 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
4.5.1 WS-Security
4.5.1.1 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.
4.5.1.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
4.5.1.3 Schemata
Ein Standard-Schema kann unter http://schemas.xmlsoap.org/ws/2002/04/secext/secext.xsd abgerufen werden.
4.5.1.4 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.
Bundesamt für Sicherheit in der Informationstechnik 91 SOA-Security-Kompendium
Abbildung 23: Einbindung von Sicherheitsmechanismen in den Header einer SOAP Nachricht durch WS-Security
4.5.1.5 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.
4.5.2 WS-SecurityPolicy
4.5.2.1 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 WS- SecureConversation – auszudrücken.
4.5.2.2 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 WS- SecureConversation 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 WS- SecurityPolicy-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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 93 SOA-Security-Kompendium
4.5.2.3 Schemata
Ein Standard-Schema ist unter http://schemas.xmlsoap.org/ws/2002/12/secext/secext.xsd oder unter http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.xsd zu finden.
4.5.2.4 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 WS- Policy 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.
4.5.2.5 Empfehlung zur Anwendung
Die Nutzung von WS-SecurityPolicy ist empfehlenswert (1), da mit Hilfe von WS- SecurityPolicy-Assertions Sicherheitsanforderungen von Web Services beschrieben werden können.
4.5.3 WS-Trust
4.5.3.1 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.
4.5.3.2 Grundlagen
Wie im Kapitel 4.5.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
4.5.3.3 Schemata
Ein Standard-Schema ist unter http://schemas.xmlsoap.org/ws/2005/02/trust/ws-trust.xsd zu finden. Des Weiteren wird eine Standard WSDL-Beschreibung unter http://schemas.xmlsoap.org/ws/2005/02/trust/ws-trust.wsdl angeboten.
4.5.3.4 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 Service- Interaktion (siehe Abbildung 24).
Bundesamt für Sicherheit in der Informationstechnik 95 SOA-Security-Kompendium
Abbildung 24: WS-Trust Szenario
4.5.3.5 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).
4.5.4 WS-SecureConversation
4.5.4.1 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 [WS- SecConv].
4.5.4.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 WS- SecureConversation 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
Die Elemente und Attribute in dem
Bundesamt für Sicherheit in der Informationstechnik 97 SOA-Security-Kompendium
4.5.4.3 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.
4.5.5 WS-Federation
4.5.5.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.5.5.2 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.
4.5.5.3 Schemata
Für die WS-Federation Spezifikation gibt es folgende Schemata: • http://schemas.xmlsoap.org/ws/2006/12/federation • http://schemas.xmlsoap.org/ws/2006/12/authorization • http://schemas.xmlsoap.org/ws/2006/12/privacy
4.5.5.4 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.
Bundesamt für Sicherheit in der Informationstechnik 99 SOA-Security-Kompendium
• 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).
4.5.5.5 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 SOAP- basiertes 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 WS- BrokeredNotification 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 1.0 - Metadata und Web Services Addressing 1.0 - 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.
4.6.1 WS-Addressing
4.6.1.1 Definition
WS-Addressing ermöglicht die Identifizierung und Referenzierung von Web Service- Endpunkten und spezifiziert einen Nachrichten-Header, um Informationen über den Nachrichtenaustausch in einer Nachricht einzufügen.
100 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.6.1.2 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 XML- Struktur, 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 Endpunkt- Referenzen 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 1.0 - 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-Information- Headers als SOAP Header.
4.6.1.3 Schemata
Ein Schema ist unter http://www.w3.org/2005/08/addressing/ zu finden.
Bundesamt für Sicherheit in der Informationstechnik 101 SOA-Security-Kompendium
4.6.1.4 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.
4.6.1.5 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).
4.6.2 WS-Routing
4.6.2.1 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).
4.6.2.2 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.
S e n d e r A Interm ediär B Interm ediär C E m pfänger 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
(01)
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.
4.6.2.3 Szenarien
WS-Routing verfolgt ein vergleichbares Ziel wie WS-Addressing. Daher wird auf das WS- Addressing Kapitel 4.6.1 verwiesen.
4.6.2.4 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 http://msdn.microsoft.com/en-us/library/ms996537.aspx), kann davon ausgegangen werden, dass WS-Routing in Zukunft keine Bedeutung haben wird. Die Spezifikation wird daher nicht empfohlen (4).
Bundesamt für Sicherheit in der Informationstechnik 103 SOA-Security-Kompendium
4.6.3 WS-Eventing
4.6.3.1 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.
4.6.3.2 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.
4.6.3.3 Schemata
Ein Schema ist unter http://schemas.xmlsoap.org/ws/2004/08/eventing/ zu finden.
4.6.3.4 Szenarien
WS-Eventing bietet sich für ähnliche Szenarien an wie auch WS-Notification. Daher wird auf das WS-Notification Kapitel 4.6.4 verwiesen.
4.6.3.5 Empfehlung zur Anwendung
Da der Standard aktuell nur als Public Draft vorliegt und sich in Konkurrenz zu WS- Notification befindet, kann der Einsatz nicht uneingeschränkt befürwortet werden. Daher ist der Standard zu beobachten (3).
104 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.6.4 WS-Notification
4.6.4.1 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.
4.6.4.2 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.
Subscribe R equest
N otification N otification P r o d u c e r C o n s u m e r
N otification 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.
Bundesamt für Sicherheit in der Informationstechnik 105 SOA-Security-Kompendium
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.
Subscribe R equest
N otification P u b l i s h e r N otification B r o k e r C o n s u m e r
Publish N otification N otification 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 WS- BaseNotification auf. Durch den WS-NotificationBroker ist es möglich, die direkte Kommunikation zwischen Publisher und Consumer gewollt zu vermeiden.
106 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
4.6.4.3 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.
4.6.4.4 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
4.7.1 WS-Reliability
4.7.1.1 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.
4.7.1.2 Grundlagen
Die WS-Reliability Spezifikation wurde vor WS-ReliableMessaging von OASIS mit der Unterstützung eines Konsortiums aus mehren Firmen – Fujitsu, Hitachi, NEC, Oracle
Bundesamt für Sicherheit in der Informationstechnik 107 SOA-Security-Kompendium
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 WS- Reliability 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]
4.7.1.3 Schemata
Ein Standard-Schema kann unter http://developers.sun.com/sw/platform/technologies/ws- reliability.schema.txt abgerufen und verwendet werden.
4.7.1.4 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 WS- ReliableMessaging beschrieben.
4.7.1.5 Empfehlung zur Anwendung
Es ist der Trend zu erkennen, dass WS-Reliability mehr und mehr von WS- ReliableMessaging 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.7.2 WS-ReliableMessaging
4.7.2.1 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.
4.7.2.2 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.
Bundesamt für Sicherheit in der Informationstechnik 109 SOA-Security-Kompendium
V e r s e n d e r E m p f ä n g e r
A pplikationsquelle A pplikationsziel
s e n d e n a u s l i e f e r n
R M Q u e l l e R M Z i e l
überm itteln b e s t ä t i g e n e r h a l t e n
Abbildung 28: Darstellung der Funktionsweise von WS- ReliableMessaging [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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
W ebservice A R eliable M essaging Protokoll W ebservice B
E tablierung von P rotokoll - B edingungen
S equen ce w ird erstellt (C reate S equ ence())
S e q u e n c e - A ntw ort w ird erstellt (C reate S equ enceR esp onse (Iden tifier = h ttp://… ))
N achricht senden (S equence (Identifier = http ://… , M essageN um ber = 1))
N achricht senden (S equence (Identifier = http ://… , M essageN um ber = 2))
N achricht senden (S equence (Identifier = http ://… , M essageN um ber = 3, LastM essage)
B estätigung erhalten (S equenceA cknow ledgem ent (Identifier = http://… , A cknow ledgem entR ange = 1,3)
B estätigung anfordern (S equence (Identifier = http ://… , M essageN um ber = 2, A ckR equested)
B estätigung erhalten (S equenceA cknow ledgem ent (Identifier = http://… , A cknow ledgem entR ange = 1...3)
S equence term inieren (Term inateS equence (Identifier = http://… ))
Abbildung 29: Detaillierte Darstellung des Ablaufs von WS-ReliableMessaging [WSRM]
4.7.2.3 Schemata
Ein Standard-Schema ist unter http://schemas.xmlsoap.org/ws/2005/02/rm/wsrm.xsd zu finden. Zudem kann ein Schema für die auf WS-ReliableMessaging zugeschnittenen Policy Assertions unter http://schemas.xmlsoap.org/ws/2005/02/rm/wsrm-policy.xsd abgerufen werden.
4.7.2.4 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.
4.7.2.5 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
Bundesamt für Sicherheit in der Informationstechnik 111 SOA-Security-Kompendium
Spezifikationen der Protokolle zur Transaktionssteuerung beschrieben. Alle im Folgenden erläuterten Spezifikationen basieren auf SOAP und WSDL und bilden eine Erweiterung dieser.
4.8.1 WS-Coordination
4.8.1.1 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.
4.8.1.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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. WS- AtomicTransaction.
4.8.1.3 Szenarien
Im folgenden Bild wird das Zusammenspiel der einzelnen Komponenten dargestellt:
Web Service
Web Service Kontext erstellen Beteiligung registrieren
Koordinator
Activation Registration Service Service
Koordinationsmodell Protokoll Service
Koordinationsprotokoll
Web Service
Abbildung 30: Zusammenspiel der einzelnen Komponenten bei WS- Coordination
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,
Bundesamt für Sicherheit in der Informationstechnik 113 SOA-Security-Kompendium
WS-Trust, WS-Policy und WS-SecureConversation diese Sicherheitsziele erreicht werden können.
4.8.1.4 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).
4.8.2 WS-AtomicTransaction
4.8.2.1 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.
4.8.2.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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.
4.8.2.3 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.
Initiator g n s i u r n e b d e r g o r f E n A
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.
Bundesamt für Sicherheit in der Informationstechnik 115 SOA-Security-Kompendium
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.
4.8.2.4 Empfehlung zur Anwendung
Der Einsatz wird zusammen mit WS-Coordination empfohlen (1).
4.8.3 WS-BusinessActivity
4.8.3.1 Definition
WS-BusinessActivity definiert auf Basis von WS-Coordination ein Koordinatorprotokoll. Im Gegensatz zu WS-AtomicTransaction stehen dabei jedoch langlaufende Transaktionen im Vordergrund.
4.8.3.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 WS- Coordination 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.
4.8.3.3 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.
4.8.3.4 Empfehlung zur Anwendung
Der Einsatz wird in Zusammenhang mit WS-Coordination empfohlen (1).
Bundesamt für Sicherheit in der Informationstechnik 117 SOA-Security-Kompendium
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.
4.9.1 WSFL
4.9.1.1 Definition
WSFL steht für Web Services Flow Language (WSFL) und ist eine XML-basierte, graphen- orientierte 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.
4.9.1.2 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 (
118 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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]
4.9.1.3 Schemata
Ein Schema zur Beschreibung der Struktur von WSFL ist in dem von IBM entwickelten WSFL-Guide unter http://xml.coverpages.org/WSFL-Guide-200110.pdf veröffentlicht worden.
4.9.1.4 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.
4.9.1.5 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 Workflow- Sprachen. 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]
Bundesamt für Sicherheit in der Informationstechnik 119 SOA-Security-Kompendium
4.9.2 BPEL
4.9.2.1 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 Workflow- Definitions-Sprachen WSFL (Web Services Flow Language), XLANG (XML Language) und BPEL4WS.
4.9.2.2 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 BPEL- Prozesses unterschieden werden, um eingehende Nachrichten den richtigen Prozessinstanzen zuzuordnen.
120 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
4.9.2.3 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: http://docs.oasis-open.org/wsbpel/2.0/OS/process/abstract/ws- bpel_abstract_common_base.xsd Executable Processes: http://docs.oasis-open.org/wsbpel/2.0/OS/process/executable/ws-bpel_executable.xsd Partner Link Type : http://docs.oasis-open.org/wsbpel/2.0/OS/plnktype/ws-bpel_plnktype.xsd Service Reference : http://docs.oasis-open.org/wsbpel/2.0/OS/serviceref/ws-bpel_serviceref.xsd Variable Properties: http://docs.oasis-open.org/wsbpel/2.0/OS/varprop/ws-bpel_varprop.xsd
4.9.2.4 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
Bundesamt für Sicherheit in der Informationstechnik 121 SOA-Security-Kompendium 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.
4.9.2.5 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 BPEL- Engines 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.
4.9.3 WS-CDL
4.9.3.1 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].
4.9.3.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 123 SOA-Security-Kompendium
• 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äftsprozess- Implementierungssprache 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]).
4.9.3.3 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.
4.9.4 ebXML
4.9.4.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
4.9.4.2 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 15000-1: ebXML Collaborative Partner Profile Agreement • ISO 15000-2: ebXML Messaging Service Specification • ISO 15000-3: ebXML Registry Information Model • ISO 15000-4: ebXML Registry Services Specification • ISO 15000-5: 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]
Bundesamt für Sicherheit in der Informationstechnik 125 SOA-Security-Kompendium
4.9.4.3 Schemata
Ein XML-Schema für Geschäftsprozesse wurde von dem Konsortium entwickelt und veröffentlicht. Dieses ist unter der folgenden Adresse zu finden: http://www.ebxml.org/specs/ ebBPSS.xsd Eine DTD wird ebenfalls angeboten: http://www.ebxml.org/specs/ebBPSS.dtd
4.9.4.4 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 XML- Encryption), 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Informationen. Diese Aktualisierung kann dann von Unternehmen A abgefragt werden, um die Anforderungen zur Aufrechterhaltung der Geschäftsbeziehung zu garantieren.
4.9.4.5 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).
4.10 Weitere Standards
4.10.1 WS-ResourceFramework
4.10.1.1 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.
4.10.1.2 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
Bundesamt für Sicherheit in der Informationstechnik 127 SOA-Security-Kompendium
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 WS- ResourceFrameworks 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 WS- Addressing-Referenz eines Endpunktes mit Policy- Informationen, 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
4.10.1.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
4.10.1.4 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.
4.10.2 Standards für Komponentenmodelle: Service Component Architecture
4.10.2.1 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.
4.10.2.2 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-Prozess- Beschreibung (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 V1.00“
Bundesamt für Sicherheit in der Informationstechnik 129 SOA-Security-Kompendium
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 SCA- Laufzeitumgebung 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 6.2.2.1. 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 4.11.1) 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 SCA- Laufzeitumgebung bestimmt werden. Nur wenn eine Komponente mit Systemen außerhalb der eigenen SCA-Domäne kommunizieren soll, muss ein Binding explizit angegeben werden.
Bundesamt für Sicherheit in der Informationstechnik 131 SOA-Security-Kompendium
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 SCA- Web 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 Service- orientierten Architektur folgt, wie es in der OASIS Referenz Architektur für Service- orientierte Architekturen beschrieben ist. In welchem Umfang Konzepte – beispielsweise hinsichtlich Sicherheit – unterstützt werden, ist jedoch von den Möglichkeiten der SCA- Ausführungsumgebung abhängig.
4.10.2.3 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.
4.10.2.4 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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.
4.10.2.5 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 Service- Spezifikationen komplett unterstützt.
4.11 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.
4.11.1 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
Bundesamt für Sicherheit in der Informationstechnik 133 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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).
Bundesamt für Sicherheit in der Informationstechnik 135 SOA-Security-Kompendium
4.11.2 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 375.000 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 730.1 – Guide for Software Quality Assurance Planning, • IEEE 754 – Gleitkomma-Arithmetik-Spezifikationen, • IEEE 802 – LAN/MAN, • IEEE 802.11 - Wireless LAN, • IEEE 802.16 - BWA Broadband Wireless Access/WiMAX, • IEEE 828 – Standard for Software Configuration Management Plans, • IEEE 829 – Standard for Software Test Documentation, • IEEE 830 - Software Requirements Specification, • IEEE 982.1 – Standard Dictionary of Measures of the Software Aspects of Dependability, • IEEE 1003 – POSIX,
136 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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 1044.1 – 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 1149.1 – 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 1471 - IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, • IEEE 15288 - Systems and software engineering — System life cycle processes.
4.11.3 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.
Bundesamt für Sicherheit in der Informationstechnik 137 SOA-Security-Kompendium
• 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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).
4.11.4 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
Bundesamt für Sicherheit in der Informationstechnik 139 SOA-Security-Kompendium 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
5.1.1 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 Steuerungs- und Regelungsstrukturen in einer Organisation beschrieben und anschließend die Einordnung der SOA Governance in diese Strukturen vorgenommen.
5.1.1.1 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.
5.1.1.2 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 IT- Investitionen, 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.
Bundesamt für Sicherheit in der Informationstechnik 141 SOA-Security-Kompendium
5.1.1.3 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.
5.1.1.4 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.
5.1.1.5 SOA Security Governance
SOA Security Governance ist eine Untermenge der gesamten SOA-Governance und steuert die Sicherheitsanforderungen einer SOA.
5.1.1.6 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 t e G o v e r n a n c e Inform ation Security G overnance I T G o v e r n a n c e
S O A G o v e r n a n c e SO A C om pliance SO A Security G o v e r n a n c e G o v e r n a n c e
Abbildung 36: Einordnung SOA Governance
142 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Compliance- Management (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.
5.1.3 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
Bundesamt für Sicherheit in der Informationstechnik 143 SOA-Security-Kompendium
• 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.
5.1.3.1 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 SOA- Strategie 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Vier- Augen-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.
5.1.3.2 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.
5.1.3.3 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.
Bundesamt für Sicherheit in der Informationstechnik 145 SOA-Security-Kompendium
5.1.3.4 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.
5.1.3.5 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Die SOA Security Governance würde die Einhaltung der Verantwortlichkeiten und die korrekte Ausübung der vergebenen sicherheitsrelevanten Rollen überprüfen.
5.1.4 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 SOA- Governance-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.
Strategische A usrichtung Strategische A usrichtung Riskom anagem ent Riskom anagem ent R essourcenm anagem ent R essourcenm anagem ent V a l u e D e l i v e r y V a l u e D e l i v e r y Perform ancem essung Perform ancem essung S O A G o v e r n a n c e F r a m e w o r k
Strategische A usrichtung Strategische A usrichtung Riskom anagem ent Riskom anagem ent R essourcenm anagem ent R essourcenm anagem ent V a l u e D e l i v e r y V a l u e D e l i v e r y Perform ancem essung Perform ancem essung Abbildung 37: PDCA-Cycle mit Komponenten
5.1.4.1 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.
Bundesamt für Sicherheit in der Informationstechnik 147 SOA-Security-Kompendium
5.1.4.2 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.
5.1.4.3 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.
5.1.4.4 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.
5.1.5 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 800-30: 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 Risikomanagement- Prozesses. Dabei werden die Unterpunkte näher erläutert und der Zusammenhang der einzelnen Unterpunkte bzw. Phasen wird beschrieben.
Bundesamt für Sicherheit in der Informationstechnik 149 SOA-Security-Kompendium
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.
5.1.5.1 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.
5.1.5.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
5.1.5.3 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.
Bundesamt für Sicherheit in der Informationstechnik 151 SOA-Security-Kompendium
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.
5.1.5.4 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 100-2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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.
5.1.5.5 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.
Bundesamt für Sicherheit in der Informationstechnik 153 SOA-Security-Kompendium
Ä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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
Bundesamt für Sicherheit in der Informationstechnik 155 SOA-Security-Kompendium
• Interne Berichtspflichten
5.2 Sichere SOA Migration
5.2.1 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.
5.2.2 Grundlagen
5.2.2.1 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 Service- fä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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
5.2.2.2 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.
Bundesamt für Sicherheit in der Informationstechnik 157 SOA-Security-Kompendium
Vorteile Nachteile
Gesamte IT-Architektur ist nach den Durch parallele Systeme entstehen hohe Bedürfnissen der Geschäftsprozesse Kosten. ausgerichtet.
Services sind aus den fachlichen ROI wird später erreicht. Anforderungen abgeleitet.
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 IT- Infrastruktur 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 Flexibilität wird reduziert. berücksichtigt.
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
B e s t e h e n d e A nw endungslandschaft s e r v i c e - orientierte A rchitektur
F lexibilität, W iederverw endbarkeit, lose K opplung, … nehm en zu
Abbildung 40: Schrittweise SOA Migration (vgl. [Gi 2008])
5.2.2.3 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.
S O A G o v e r n a n c e
Abbildung 41: Vorgehen SOA Migration
Bundesamt für Sicherheit in der Informationstechnik 159 SOA-Security-Kompendium
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 SOA- Reife kann unter anderem mit dem in Kapitel 5.2.3.2 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 SOA- Umgebung 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 5.2.2.2). 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 161 SOA-Security-Kompendium
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.
5.2.3 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.
5.2.3.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
5.2.3.2 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?
Bundesamt für Sicherheit in der Informationstechnik 163 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 r o z e s s O ptim ierung O ptim ierte SO A . B usiness Perform ance M anagem ent / B A M . R u n t i m e - Governance u n d R ichtlinien . P r o z e s s e a u s f ü h r e n Prozessausführung . Perform ance M e t r i k e n m e s s e n . S O A L i f e - Cycle M anagem ent . P r o z e s s e m odellieren Prozessm odellierung e b X M L , WS - Trust, B PEL, . S e r v i c e s identifizieren , d e f i n i e r e n u n d orchestrieren BPMN . R e c h t e , R o l l e n , R ichtlinien , S L A s d e f i n i e r e n . D e f i n i e r e n v o n Technologie s t a n d a r d s f ü r A rchitektur Services U D D I , W S - ReliableM essaging , d i e S O A WS - P o l i c y , W S - A ddressing, . R egistry/R epository e i n f ü h r e n WS - Security, SA M L . P r o z e s s e identifizieren . D e f i n i e r e n von Services In itiale S ervices XM L, W SDL, SOAP . I n i t i e r e n v o n S O A P r o j e k t e n . P l a n u n g d e r M igration von A ltsystem en . K e i n SOA A nw endungssilos
Abbildung 42: SOA Maturity Model
5.2.4 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 bteilung 1 A bteilung 2 A bteilung 3
A nw endung A A nw endung B‘
A nw endung A ‘
A nw endung B A nw endung E
A nw endung D
A nw endung C‘ A nw endung D ‘ Bundesamt für Sicherheit in der Informationstechnik 165 Abbildung 43: Typische gewachsene Anwendungslandschaft einer Organisation und deren Interaktion SOA-Security-Kompendium
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 Services können orchestriert werden und sind Anwendungen wiederverwendbar
Anwendungen stehen einem bekannten Auffindbarkeit der Services wird sichergestellt, Nutzerkreis zur Verfügung Services können von unterschiedlich vielen Instanzen genutzt werden
Nutzung der Anwendungen nur in einer Nutzung der Services in unterschiedlichen Domäne Domänen
Nutzung von proprietären Komponenten und SOA setzt auf offene Standards auf Schnittstellen 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.
5.2.4.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Service- Schnittstelle 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.
Bundesamt für Sicherheit in der Informationstechnik 167 SOA-Security-Kompendium
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-, Desktop- Anwendung, ...) 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
5.2.4.2 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
Bundesamt für Sicherheit in der Informationstechnik 169 SOA-Security-Kompendium
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 6.4.2.3) 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.
5.2.4.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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-Punkt- Verbindungen 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
Bundesamt für Sicherheit in der Informationstechnik 171 SOA-Security-Kompendium
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.
5.3.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 5.3.2.1) 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 5.3.3.2 beschrieben.
5.3.2 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:
S O A A ufbau und B etrieb und P lanung und D esign D e p l o y m e n t A b l ö s u n g Lebenszyklus E ntw icklung M a n a g e m e n t
Z e i t 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 SOA- Lebenszyklus 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
Bundesamt für Sicherheit in der Informationstechnik 173 SOA-Security-Kompendium
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.
5.3.2.1 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 5.3.3.2) 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 5.1.5 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 5.3.3.2). 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 nicht- funktional Aspekte wie z.B. die Sicherheit oder die Handhabung von Änderungen und Ausnahmen.
174 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 5.3.3.3), • 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.
Bundesamt für Sicherheit in der Informationstechnik 175 SOA-Security-Kompendium
• 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 Kern- Geschä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 Service- orientierten Architektur auf Basis der individuellen Geschäftsanforderungen möglich.
5.3.2.2 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 7.6.2 beschreibt Testmethoden und Tools, die in dieser Phase zum Einsatz kommen sollten.
176 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
5.3.2.3 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 Infrastruktur- und 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.
5.3.2.4 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 5.3.3.3) 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 Request- Antworten.
Bundesamt für Sicherheit in der Informationstechnik 177 SOA-Security-Kompendium
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.
5.3.2.5 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 5.3.3.2).
5.3.3 Rahmenbedingungen für den SOA Lebenszyklus
Dieser Abschnitt beschreibt organisatorische und technische Rahmenbedingungen, die Einfluss auf eine SOA nehmen können.
5.3.3.1 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.
5.3.3.2 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 IT- Systeme, 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 s t e m B etrieb und D e f i n i t i o n E ntw icklung D e p l o y m e n t E n t s o r g u n g Lebenszyklus W a r t u n g
Z e i t Abbildung 49: IT-System Lebenszyklus
Bundesamt für Sicherheit in der Informationstechnik 179 SOA-Security-Kompendium
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 5.3.2.2) 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 i c e Veröffen tlichen N u t z u n g s - F i n d e n B i n d e n A u s f ü h r e n R egistrieren z y k l u s Z e i t 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
Bundesamt für Sicherheit in der Informationstechnik 181 SOA-Security-Kompendium 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 s t e m B etrieb und D e f i n i t i o n E ntw icklung D e p l o y m e n t E n t s o r g u n g Lebenszyklus W a r t u n g
S O A A ufbau und B etrieb und P lanung und D esign D e p l o y m e n t A b l ö s u n g Lebenszyklus E ntw icklung M a n a g e m e n t
Vorgehensm odell S o f t w a r e - entw icklung
Service Service Nutzungs-S e r v i c e Nutzungs- Veröffen tlichen Nzyklus u t z u n g s - Veröffentlich en F i n d e n B i n d e n A u s f ü h r e n zyklus R egistrierenVeröffentlich en F i n d e n B i n d e n A u s f ü h r e n z y k l u s R egistrieren F i n d e n B i n d e n A u s f ü h r e n R egistrieren
Z e i t 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 IT- Systeme 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 IT- System 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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.
5.3.3.3 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.
5.3.4 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
Bundesamt für Sicherheit in der Informationstechnik 183 SOA-Security-Kompendium 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Governance- Verantwortlichen, 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 r n a n c e
S O A G o v e r n a n c e Sicherheitsm anagem ent Risikom anagem ent C om pliance M anagem ent
S O A A ufbau und B etrieb und P lanung und D esign D e p l o y m e n t A b l ö s u n g L ebenszyklus E ntw icklung M a n a g e m e n t
SO A M igration
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 100-1 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
Bundesamt für Sicherheit in der Informationstechnik 185 SOA-Security-Kompendium
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 IT- Systeme, 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 6.1.1 beschrieben werden. Das SOA Security Framework ist die technische Basis innerhalb der SOA Governance, die sich wiederum in die Unternehmens-Governance, wie in Kapitel 5.1.1 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
Bundesamt für Sicherheit in der Informationstechnik 187 SOA-Security-Kompendium 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.
6.1.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Verschlüsselung oder Signatur einer SOAP Nachricht auch wirklich umgesetzt wird. Agenten können daher im Sinne eines Proxy-Konzepts (siehe Kapitel 6.1.1.1) “vor” den Systemen implementiert sein oder als (Security-) Service Provider (siehe Kapitel 6.1.1.2) innerhalb einer Domäne oder Zone stehen und Funktionalität bereitstellen.
6.1.1.1 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 Credential- Mapping vorausgesetzt, sind somit auch Federation-Ansätze umzusetzen. Für die Autorisierung der Service Aufrufe ermöglicht die zentrale Komponente die Verwaltung von
Bundesamt für Sicherheit in der Informationstechnik 189 SOA-Security-Kompendium
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.
6.1.1.2 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-Key- Infrastruktur (PKI) via XKMS. Je nach Last- und Nutzverhalten sowie unter Berücksichtigung der Struktur einer Domäne ist es sinnvoll, zentralisierte Services bereitzustellen.
6.1.1.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
6.1.1.4 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.
6.1.2 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.
Bundesamt für Sicherheit in der Informationstechnik 191 SOA-Security-Kompendium
6.2 Policy Management
6.2.1 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 IT- Infrastruktur 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
Bundesamt für Sicherheit in der Informationstechnik 193 SOA-Security-Kompendium 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.
6.2.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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])
Bundesamt für Sicherheit in der Informationstechnik 195 SOA-Security-Kompendium
Ä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 Top- Down 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.
6.2.2.1 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 4.10.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
[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).
„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).
Bundesamt für Sicherheit in der Informationstechnik 197 SOA-Security-Kompendium
IntentMaps weisen den qualified Intents (s.
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]).
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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])
Bundesamt für Sicherheit in der Informationstechnik 199 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Abbildung 64: Zentrale Administration sowie zentrale und dezentrale Speicherung der Policies (vgl. [PMgmt])
6.2.4 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 Service- Technologien 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.
6.2.4.1 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 Service- Technologien 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
Bundesamt für Sicherheit in der Informationstechnik 201 SOA-Security-Kompendium
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 Beschreibung Sicherheitsanforderungen
Die Vertraulichkeit kann auf Kanalebene Sicherstellung der Vertraulichkeit sichergestellt werden oder mittels WS- durch Absicherung des Security durch die ausgetauschten Transportkanals oder durch Nachrichten. Die Web Service-Clients Absicherung der Nachricht. müssen die Absicherung gemäß den Anforderungen des Dienstes umsetzen.
WS-Security erlaubt die Absicherung verschiedener Nachrichtenteile mit Verwendung verschiedener unterschiedlichen Algorithmen und Algorithmen, Schlüsselstärken und Schlüsselstärken. Unterschiedliche Kodierungen. Implementierungen können unterschiedliche Verfahren unterstützen.
Nutzung verschiedener Formate von In WS-Security können verschiedene Arten Sicherheitstoken und unterschiedliche von Sicherheitstoken verwendet werden, zugrunde liegende um Identitätsinformationen an eine Web Vertrauensbeziehungen. 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 Service- Aufruf kann nur erfolgreich sein, wenn die richtigen Sicherheitstoken von den richtigen Identitätsprovidern abgerufen und in die Nachricht eingefügt wurden.
Unterschiedliche Verwendung der Sicherheitstechnisch macht es einen großen Spezifikationen mit unterschiedlichen Unterschied, in welcher Reihenfolge Optionen. Beispiele hierfür sind eine bestimmte Mechanismen und unterschiedliche Reihenfolge der Spezifikationen hinsichtlich Nutzung von Verschlüsselung und Verschlüsselung und Integrität angewendet Signatur in einer Nachricht und eine wurden. Daher müssen Client und Dienst unterschiedliche Reihenfolge von die Absicherung der Nachrichten identisch Sicherheitsheadern in einer SOAP vornehmen, um sicher kommunizieren zu Nachricht. 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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
Bundesamt für Sicherheit in der Informationstechnik 203 SOA-Security-Kompendium
diese Policy durch WS-Policy beschrieben unter Verwendung von WS- SecurityPolicy zur Beschreibung der Sicherheitsanforderungen (vgl. Kapitel 4.3.5 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 4.3.8. 2. 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 6.2.3 eingeführt wurden. 3. Bestimmung der gemeinsamen Sicherheitsoptionen Wie im Kapitel 4.3.5 „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 WS- Policy 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Service- Framework, 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.
6.2.4.2 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
Bundesamt für Sicherheit in der Informationstechnik 205 SOA-Security-Kompendium
können auch Sicherheitsanforderungen im Verzeichnis abgelegt werden. WS- PolicyAttachment 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.
6.2.5 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 6.1.1.2), 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
6.2.5.1 Policy Enforcement Point als Bibliothek
Dienstlogik
Client Sicherheits- bibliothek 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.
6.2.5.2 Policy Enforcement Point als Modul
Sicherheits- Client module 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.
Bundesamt für Sicherheit in der Informationstechnik 207 SOA-Security-Kompendium
6.2.5.3 Policy Enforcement Point als Gateway
Sicherheits- Dienstlogik Client funktionalität Gateway Dienst Abbildung 70: Policy Enforcement Point als Gateway
In dieser Variante werden die Sicherheitsanforderungen zentralisiert von einem Gateway- Service 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.
6.2.6 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
6.3.1 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 Service- orientierten Architekturen eine Rolle und werden im folgenden Kapitel genauer betrachtet.
6.3.2 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
Bundesamt für Sicherheit in der Informationstechnik 209 SOA-Security-Kompendium 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 Teilnehmer benötigtes Grund- Mechanismen identifiziert über vertrauen der Parteien
Hochsicher- Kreditvergabe Eindeutige Kreditnehmer → Überprüfung heit Identität Kreditgeber: hoheitlicher Dokumente, mittel Verträge Kreditgeber → Kreditnehmer: Sehr hoch
Unter- Mitarbeiter nutzt Mitarbeiterrolle Unternehmen → Arbeitsvertrag nehmens- die Mitarbeiter: hoch intern/ Unternehmens- Mitarbeiter → Operativ software für die Unternehmen: gering Lager- verwaltung
B2B Unternehmen A Vertragspartner In beide Richtungen: Vertragliche bestellt beim Hoch - mittel Beziehungen Unternehmen B auf Bauteile für die Unternehmens- Fertigung ebene
G2C Kunde möchte Behördliches In beide Richtungen: hoch Überprüfung sein Auto online Dokument, z.B. eines ummelden eID, hoheitlichen elektronischer Dokumentes Fahrzeugschein
B2C Kunde bestellt Selbstregistrierter In beide Richtungen: Registrierung ein Buch Account mit eventueller gering Überprüfung bestimmter Attribute, z.B. der E-Mail- Adresse
Internet- Kunde Unbekannt Kunde → Anbieter: keine präsenz informiert sich gering über die Anbieter → Kunde: kein Webseite eines Vertrauen Herstellers Tabelle 9: Standardszenarien und ihre Vertrauensbeziehungen
210 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
6.3.2.1 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.
6.3.2.2 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 direktes Vertrauen Vertrauen
indirektes Client Vertrauen Dienst
Administrative Domäne 1 Abbildung 72: Vertrauensbeziehungen in einer Domäne mit zentralen Sicherheitsdiensten Bundesamt für Sicherheit in der Informationstechnik 211 SOA-Security-Kompendium
• 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.
6.3.2.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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.
6.3.2.4 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
Bundesamt für Sicherheit in der Informationstechnik 213 SOA-Security-Kompendium
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.
6.3.3 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 Indirektes Vertrauen
Vertrauen auf Vertrauen durch Nicht üblich (würde Inter- Unternehmensebene Föderationsverträge Föderationsszenarien entsprechen)
Vertrauen auf Client-Ebene Vertrauen durch Vertrauen durch (Benutzer/ Anwendung) Registrierung/Verifikation, Empfehlungen, Reputation Vertrauen durch Verträge Tabelle 10: Mechanismen zur Etablierung von Vertrauen
6.3.3.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 Service- orientierten 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
Bundesamt für Sicherheit in der Informationstechnik 215 SOA-Security-Kompendium
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.
6.3.3.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
6.3.3.3 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 E-Mail-Adresse statt, indem der Benutzeraccount erst aktiviert wird, nachdem der Benutzer einen in der ihm zugesendeten E-Mail 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.
6.3.3.4 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. Reputations- basierte 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.
Bundesamt für Sicherheit in der Informationstechnik 217 SOA-Security-Kompendium
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.
6.4.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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.
6.4.2 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 Offene Identitätsmanagementmodelle Identitätsmanagementmodelle
• Anwendungsspezifisches • Benutzerzentrisches Identitätsmanagement Identitätsmanagement • Zentralisiertes 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.
Bundesamt für Sicherheit in der Informationstechnik 219 SOA-Security-Kompendium
6.4.2.1 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 Nachteile
• Anwendung/Dienst hat • Fehlende Skalierbarkeit in Service-orientierten die volle Kontrolle über Architekturen die Verwaltung der • Benutzer müssen sich bei jedem Dienst separat Benutzer 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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.
6.4.2.2 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.
Bundesamt für Sicherheit in der Informationstechnik 221 SOA-Security-Kompendium
Vor- und Nachteile
Vorteile Nachteile
• Erlaubt Single-Sign-On über • Anwendungen sind an die zentrale mehrere Anwendungen Verwaltung der Benutzer gebunden • Dienste müssen kein • Single-Point of Failure Identitätsmanagement • Alle Anwendungen müssen der zentralen implementieren, sondern lediglich Benutzerverwaltung vertrauen bestehende Identitätsmanagementsysteme integrieren
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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.
6.4.2.3 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
Bundesamt für Sicherheit in der Informationstechnik 223 SOA-Security-Kompendium 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 Nachteile
• Erlaubt ein Unternehmensüber- • Schutz der Privatsphäre des Benutzers greifendes Single-Sign-On erfordert zusätzliche Mechanismen • bestehende • Kompromittierung eines Accounts erlaubt Identitätsmanagementlösungen dem Angreifer Zugriff auf alle föderierten können integriert werden 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 WS- Federation, 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 6.4.4.2) und auf der anderen Seite die WS-Federation Spezifikation (vgl. Kapitel 6.4.4.1), welche durch Microsoft und IBM entwickelt wurde.
6.4.2.4 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.
Bundesamt für Sicherheit in der Informationstechnik 225 SOA-Security-Kompendium
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 Nachteile
• Erlaubt ein Unternehmensüber- • Im allgemeinen keine vertraglichen greifendes Single-Sign-On Bindungen → Vertrauen ist schwerer zu etablieren • bestehende 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 Staat- Online 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 6.4.4 genauer vorgestellt werden.
6.4.2.5 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.
Bundesamt für Sicherheit in der Informationstechnik 227 SOA-Security-Kompendium
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.
6.4.3 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 6.4.3.1. 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 1234 5678 3333 3333“. 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
6.4.3.1 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.
Bundesamt für Sicherheit in der Informationstechnik 229 SOA-Security-Kompendium
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.
6.4.4 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.
6.4.4.1 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 4.5.5 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Darüber hinaus beschreibt und diskutiert die Spezifikation verschiedene Föderationsszenarien.
6.4.4.2 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
Bundesamt für Sicherheit in der Informationstechnik 231 SOA-Security-Kompendium 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, E-Mail oder eben SOAP.
6.4.4.3 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 XML- Datei. 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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.
6.4.4.4 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 Web- basiertes 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.
Bundesamt für Sicherheit in der Informationstechnik 233 SOA-Security-Kompendium
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 Service- orientierten 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.
6.5.1 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 4.9.3 eingeführte WS- CDL 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 6.2.5 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
Bundesamt für Sicherheit in der Informationstechnik 235 SOA-Security-Kompendium
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 6.3.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 6.3.3 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
6.5.2 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.
6.5.2.1 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
Bundesamt für Sicherheit in der Informationstechnik 237 SOA-Security-Kompendium 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 Maschine- zu-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 Service- orientierten 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 6.4.2.2 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 2.0.
2. 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 6.4.2.4 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.
Bundesamt für Sicherheit in der Informationstechnik 239 SOA-Security-Kompendium
6.5.2.2 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.
6.5.2.3 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 6.4.2.4), 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.
6.5.2.4 Vertraulichkeit und Integrität von Daten
Die Verwendung einer nachrichtenbasierten Kommunikation unter Verwendung von XML- basierten 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Adressing- Informationen 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
Bundesamt für Sicherheit in der Informationstechnik 241 SOA-Security-Kompendium
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.
6.5.2.5 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-of- Failure 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 (Load- Balancing, 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
6.6 Sicherheit und Interoperabilität mit WS-I
6.6.1 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.
6.6.2 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.
Bundesamt für Sicherheit in der Informationstechnik 243 SOA-Security-Kompendium
• 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.
6.6.2.1 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 Profil- Anforderungen 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 http://www.ws-i.org/Profiles/ConformanceClaims-1.0-2004-11-15.html abgerufen werden.
244 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
6.6.2.2 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“.
6.6.2.3 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.“.
6.6.2.4 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 „E0002 - Security Tokens - Security tokens may be specified in additional security token profiles.“.
6.6.3 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.
Bundesamt für Sicherheit in der Informationstechnik 245 SOA-Security-Kompendium
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.
6.6.3.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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.
6.6.3.2 WS-I Basic Security Profile 1.0
Einleitung
Bundesamt für Sicherheit in der Informationstechnik 247 SOA-Security-Kompendium
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 Ausgabe von Credentials Datenursprungs
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 249 SOA-Security-Kompendium
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 Verschlüsseln von Username & [Password|Digest] Authentifizierung 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
Bundesamt für Sicherheit in der Informationstechnik 251 SOA-Security-Kompendium
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.
6.6.3.3 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
6.6.3.4 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
6.6.3.5 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.
Bundesamt für Sicherheit in der Informationstechnik 253 SOA-Security-Kompendium
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.
6.6.3.6 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
6.6.3.7 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 WS- Security REL Token Profile genutzt, um verschiedene Mechanismen der Referenzierung von
254 Bundesamt für Sicherheit in der Informationstechnik
Abbildung 92: Darstellung WS-I REL Token Profile SOA-Security-Kompendium
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.
6.6.3.8 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 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. 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
6.6.4 Ü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. Basic 1.0 Attachments 1.0 Binding SOAP Simple Basic 1.0 Secure Reliable Kerberos REL SAML Token 1.1 1.0 Security Token Token
Profile 1.0 1.0 1.0
Referenzdokumente
Attachments Profile Version 1.0 (AP1.0) X
Basic Profile Version 1.0 (BP1.0) X
Basic Profile Version 1.1 X
RFC2246: The TLS Protocol Version 1.0 X X
Bundesamt für Sicherheit in der Informationstechnik 255 SOA-Security-Kompendium Basic 1.0 Attachments 1.0 Binding SOAP Simple Basic 1.0 Secure Reliable Kerberos REL SAML Token 1.1 1.0 Security Token Token
Profile 1.0 1.0 1.0
Referenzdokumente
RFC2818: HTTP over TLS X X
RFC2459: Internet X.509 Public Key X X X X X X Infrastructure Certificate and CRL Profile
Simple SOAP Binding Profile Version 1.0 X
SOAP 1.1 X X
SOAP Messages with Attachments X
The SSL Protocol Version 3.0 X X
UDDI Version 2 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 X
WS-Security: Rights Expression Language X X X (REL) Token Profile 1.0
WS-Security: SAML Token Profile 1.0 X X
WS-Security: SOAP Message Security 1.0 X
WS-Security: SOAP Messages with X Attachments (SwA) Profile 1.1
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 Tabelle 16: WS-I Profile und referenzierte Dokumente
256 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
6.6.5.1 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
6.6.5.2 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.
Bundesamt für Sicherheit in der Informationstechnik 257 SOA-Security-Kompendium
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.
6.6.5.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 i l e
A n a l y z e r W S D L K o n f i g . D a t e i D o k u m e n t A n a l y z e r Test A ssertion UDDI D o k u m e n t E i n t r a g
Conform ance R e p o r t Abbildung 96: Analyzer Tool
6.6.6 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.509- Security Token-Formate gibt. Im Bereich des zuverlässigen und sicheren Nachrichtenaustausches wird die Finalisierung des Reliable Secure Profiles 1.0 angestrebt.
Bundesamt für Sicherheit in der Informationstechnik 259 SOA-Security-Kompendium
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.
7.1.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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.
7.1.2 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 E-Mail-Postfach zugreifen und E-Mails 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
Bundesamt für Sicherheit in der Informationstechnik 261 SOA-Security-Kompendium
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.
7.1.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
7.1.4 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 Zugriffs- Policies vor, werden unter Umständen vertrauliche Informationen an das Portal übermittelt, so dass angemeldete Nutzer einen unberechtigten Zugriff auf diese Daten erhalten.
Bundesamt für Sicherheit in der Informationstechnik 263 SOA-Security-Kompendium
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.
7.1.5 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 265 SOA-Security-Kompendium
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.
7.1.7 Ü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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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-Security- Gateways 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.
7.2.1 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.
7.2.1.1 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 WSA- Action gleich IssueTokenResponse und deren SAML-Issuer ungleich http://www.someServiceProvider.de/services/sts ist. wsa.action=IssueTokenResponse∧saml.issuer !=http://www.someServiceProvider.de/services/sts
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
Bundesamt für Sicherheit in der Informationstechnik 267 SOA-Security-Kompendium mit einer geeigneten Signatur beschrieben sein. Bekannte Mechanismen, welche Signatur- basierte Filterung benutzen können, sind Virusfilter, Firewalls, Policy-Enforcement und SOAP Validation.
7.2.1.2 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.
7.2.2 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.
7.2.2.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
7.2.2.2 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 6.2.5 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.
7.2.3 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 WS- Security-Gateway kann die Eingangs beschriebenen Filtermethoden und Mechanismen benutzen, um Web Service Anfragen zu erkennen und bei Bedarf zu Filtern.
Bundesamt für Sicherheit in der Informationstechnik 269 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 Fallback- Mechanismus 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.
7.2.4 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.
7.2.4.1 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
Bundesamt für Sicherheit in der Informationstechnik 271 SOA-Security-Kompendium
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 E-Mail-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 Anomalie- basierte 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.
7.2.4.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
7.2.4.3 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 DTD- Beschreibung 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 XML- Parser 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:
Bundesamt für Sicherheit in der Informationstechnik 273 SOA-Security-Kompendium
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.
7.2.4.4 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
• 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.
7.2.5 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.
7.3.1 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 E-Mails, 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-Lebenszyklus- Management (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
Bundesamt für Sicherheit in der Informationstechnik 275 SOA-Security-Kompendium 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.
7.3.2 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.
7.3.3 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 6.4.4.2) 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.
7.3.4 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.
7.3.5 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.
7.3.5.1 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.
Bundesamt für Sicherheit in der Informationstechnik 277 SOA-Security-Kompendium
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 XML- Signature (siehe Kapitel 4.4.2). Während ebXML das digitale Signieren der Einträge vorschreibt, ist die Verwendung bei UDDI nur optional.
7.3.5.2 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 7.3.5.1). 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
7.3.5.3 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 6.2.4.2 (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.
7.3.6 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.
Bundesamt für Sicherheit in der Informationstechnik 279 SOA-Security-Kompendium 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.
7.3.7 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 XACML 1.0 --- Standards
Identity Management SAML 2.0 --- Standards
Security Features
Unterstützung von Digitalen Ja - Pflicht Ja - Optional Signaturen
Basic Access Control Ja Ja - limitiert basierend auf vordefinierten Rollen und Policies
Nutzerdefinierte, Ja – basierend auf XACML Nein feingranulare Policies für die 1.0 Zugriffskontrolle
Föderiertes Ja – basierend auf SAML 2.0 Nein Identitätsmanagement
Audit Trail Ja Ja
Discovery
Vordefinierte Queries Ja Ja
Nutzerdefinierte Queries Ja Nein Tabelle 17: Vergleich der Standards ebXML und UDDI (vgl. [SM 2005])
280 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 6.5.1 (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 i e n s t D ienstnutzer
B P E L W o r k f l o w D i e n s t
D i e 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,
Bundesamt für Sicherheit in der Informationstechnik 281 SOA-Security-Kompendium 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 6.5.1 (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 i e n s t D ienstnutzer
B P E L W o r k f l o w D i e n s t V erschlüsselung
E ntschlüsselung D i e 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 Service- Consumers 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 i e n s t D ienstnutzer
B P E L W o r k f l o w D i e n s t V erschlüsselung
E ntschlüsselung D i e 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 6.5.1 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
Bundesamt für Sicherheit in der Informationstechnik 283 SOA-Security-Kompendium 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.
7.5.1 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-/XML- Datei).
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Beispiel: GET /buch/3453146972
POST: Mittels POST kann einer Ressource etwas hinzugefügt werden (z.B. einem Warenkorb ein neues Buch). Beispiel: POST /warenkorb/1313 buch=3453146972
PUT: PUT wird zum Anlegen neuer Ressourcen verwendet. Im nachfolgenden Beispiel wird ein neuer Bucheintrag angelegt. Beispiel: PUT /buch
DELETE: Mittels DELETE werden Ressourcen gelöscht. Beispiel: DELETE /buch/3453146972
7.5.2 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
Bundesamt für Sicherheit in der Informationstechnik 285 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium 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 REST- basierte 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 SOAP- basierten 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
Bundesamt für Sicherheit in der Informationstechnik 287 SOA-Security-Kompendium
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.
7.6.1 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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 V- Modell 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 6.1.1.2) 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.
Bundesamt für Sicherheit in der Informationstechnik 289 SOA-Security-Kompendium
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.
7.6.1.1 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.
7.6.1.2 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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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
Bundesamt für Sicherheit in der Informationstechnik 291 SOA-Security-Kompendium
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 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
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.
Bundesamt für Sicherheit in der Informationstechnik 293 SOA-Security-Kompendium
Schnittstellen-Test
Bei diesem Test wird ein Angriff auf der Nachrichtenebene an der Schnittstelle zwischen zwei Web Services durchgeführt, indem die Antworten der Web Services analysiert und verfälscht werden. Dabei wird z.B. bösartiger Code eingeschleust um evtl. Schwachstellen auszunutzen.
Policy-Validierungs-Test
Dieser Test prüft, ob die vorgeschriebenen Policies auch wirklich valide umgesetzt wurden. Gerade bei einem White-Box-Test sollte geprüft werden, ob die Security Policies innerhalb des Web Service-Quellcodes umgesetzt wurden. Bei diesem Schritt werden oftmals Schwachstellen wie beispielsweise die Nichtbeachtung von Policies aufgedeckt, die ansonsten ggf. übersehen worden wären.
7.6.1.3 Tests der Interoperabilität
Ein Test der Interoperabilität soll prüfen, ob die durch die WS-I beschriebenen Vorgaben (siehe Abschnitt 6.6.3) eingehalten werden. Die WS-Interoperability-Organisation hat für diese Testmethode bereits so genannte Test Assertions (Testaussagen) als testbare Interpretation der jeweiligen Profile definiert. Ein Test Assertion-Dokument (TAD) ist also eine formale Spezifikation eines durchgeführten Tests mit Hilfe des WS-I-Tools. Das WS-I- Tool prüft z.B. ob der Web Service konform zum Basic Security Profil ist. Die WS-I-Testmethode zur Prüfung der Interoperabilität kann, unabhängig von der genutzten Technologien (z.B. Java oder .NET), die zur Entwicklung von Web Services verwendet wurden, genutzt werden, um eine hohe Interoperabilität zwischen Web Services zu erreichen. Weitere Details zu diesem Thema finden sich in Kapitel 6.6.
7.6.1.4 Ergebnisbericht
Die Vorabplanung sowie die Ergebnisse der durchgeführten Tests werden in einem Ergebnisbericht zusammengefasst. Dabei sollten die Kernergebnisse kurz beschrieben werden, damit diese als Management Summary an die Verantwortlichen gegeben werden können. Somit bekommt das Management eine schnelle Einschätzung des allgemeinen Sicherheitsniveaus und kann auf Basis dessen eine Entscheidung über das weitere Vorgehen treffen. Zur detaillierteren Beschreibung der Ergebnisse sind die aufgedeckten Schwachstellen aufzulisten und mit einer Risikoeinschätzung zu versehen. Je nach Höhe des Risikos sollten bereits Maßnahmen zur Minimierung bzw. zur Schließung der Schwachstelle vorgeschlagen werden. Aufgedeckte Entwicklungsschwächen, die z.B. während eines Policy-Validierungs- Tests ermittelt werden, sind gesondert zu dokumentieren, um diese Erfahrung bei der Entwicklung weiterer Web Services zu berücksichtigen.
7.6.2 Tools
Es gibt verschiedenste Tools am Markt, die die in Abschnitt 7.6.1 genannten Testmethoden beinhalten und technisch umsetzen. Diese Tools lassen sich in drei Kategorien unterteilen:
294 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
7.6.2.1 Tools für nicht-funktionale Kriterien
Mit Hilfe dieser Tools können die bereits genannten nicht-funktionalen Kriterien wie z.B. Performance, Lastverhalten oder Zugriffsschutz getestet werden. Da sich SOAP als de facto Standard für die Umsetzung von Web Services in einer SOA durchgesetzt hat, spielen SOAP basierte Testtools dabei eine wesentliche Rolle. Solche Tools verfolgen ein fundamentales Vorgehen beim Testen von SOAP-basierten Web Services, welches die folgenden Schritte simuliert: • Eine SOAP Anfrage (request) erstellen • Versand der Anfrage (submit) • Bewertung der Antwort (response) Dabei können z.B. auch die Zeiten zwischen Request und Response ausgewertet werden. Werden durch die Testtools eine hohe Anzahl von Requests erzeugt, lassen sich auf diese Weise z.B. Lasttests durchführen. Auch für den Test der Interoperabilität gibt es bestimmte Tools die testen, ob die Interoperabilität zu den entsprechenden Profilen annähernd gegeben ist. Hierzu sollten vor allem die Tools der WS-I-Organisation verwendet werden. Die Organisation entwickelt für jedes Profil sukzessive Test Assertion Dokuments (TAD), die mit Hilfe der zur Verfügung stehenden Tools getestet werden können.
7.6.2.2 Tools für Penetration-Tests
Zur Durchführung von Penetration-Tests auf Netzwerk- und Systemebene gibt es eine Reihe von Tools. Ein Beispiel ist Metasploit, ein Open Source Toolkit, welches im Rahmen des Tests Netzperimeter auf Sicherheitslücken prüft und herausfindet, inwieweit SQL- oder Web- Server beziehungsweise Unix-, Linux- oder Windows-Hosts kompromittierbar sind. Mit Hilfe dieses oder vergleichbarer Tools können Angriffsmuster und -Methoden genutzt werden, um potenzielle Bedrohungen (siehe Kapitel 3.3) auf eine SOA bzw. einen Web Service zu simulieren. So können beispielsweise die folgenden Angriffe simuliert werden: • Scanning Ein Scanning-Tool kann z.B. überprüfen, welche Dienste und Schwachstellen auf einem System vorhanden sind. Diese Tools ermöglichen einfache Port-Scans aber auch das automatische Auffinden von Schwachstellen wie Buffer Overflows. • Sniffing Mit Hilfe von Sniffing-Tools können die Datenströme zwischen zwei Systemen oder Web Services mit gelesen werden. So kann geprüft werden, ob Sicherheitsmechanismen zur Verschlüsselung richtig funktionieren. • Man in the middle Angriffe, die XML-Nachrichten in einer SOA mitlesen oder ändern, können durch die geeigneten Tools unterstützt werden. Dabei schaltet sich das Testpersonal zwischen zwei Kommunikationsendpunkte und täuscht jedem Endpunkt die Identität der ursprünglichen Gegenseite der Kommunikation vor. Obwohl ein Penetration-Test die Sicherheit der SOA bzw. der Web Services und damit nicht- funktionale Kriterien testet, ist diese Tool-Kategorie separat aufgeführt. Dies unterstreicht nochmals die Wichtigkeit dieser Art zu testen.
Bundesamt für Sicherheit in der Informationstechnik 295 SOA-Security-Kompendium
7.6.2.3 Tools für funktionale Kriterien
Es kann vorkommen, dass Schwächen in der Funktionsweise der SOA oder des Web Service die Sicherheit beeinflussen. So können beispielsweise unrechtmäßig genutzte Sonderzeichen oder Rekursionen einen Service zum Absturz bringen und somit die Verfügbarkeit beeinflussen. Geeignete Tools können dies simulieren und prüfen, ob Web Services Mechanismen mitbringen, um die genannten Schwachstellen zu verhindern. Ein Tool ist beispielsweise soapUI, derzeit in der Version 2.5.1 erhältlich. Mit diesem Tool können multiple Endpunkte der Web Services getestet und somit geprüft werden, ob die Funktionen richtig ausgeführt werden.
7.6.2.4 Kriterien zur Toolauswahl
Ein geeignetes Tool sollte nicht nur die genannten Funktionalitäten und Verfahren enthalten, sondern auch dem Testpersonal ermöglichen, Anfragen zu organisieren und individuell in einer realistischen Sequenz aufzubauen, Testwerte anzupassen und die Web Services einer ausreichenden Anzahl „guter“ und „böser“ Nutzungsszenarien auszusetzen. Des Weiteren sollten Tools genutzt werden, die die Sicherheitsmechanismen der Transportschicht wie SSL (Client und Serverauthentisierung) oder Kerberos sowie auf der Nachrichtenschicht wie z.B. WS-Security, SAML oder Username Security Tokens testen und bewerten können.
7.7 Anwendungsszenarien
In diesem Kapitel werden unterschiedliche Anwendungsszenarien anhand eines Beispielprozesses erläutert. Als Beispiel wurde ein Bestellprozess gewählt. Im Zentrum des Prozesses steht ein Handelsunternehmen, welches Produkte an Endkunden verkauft. Ähnliche Prozessabläufe existieren auch in Behörden und lassen sich daher auf diese übertragen. Zur Erläuterung werden die einzelnen Prozessschritte grob dargestellt. Auf eine Darstellung der einzelnen Prozessschritte bei den Kommunikationspartnern des Handelsunternehmens wird aus Übersichtlichkeitsgründen soweit möglich verzichtet. Hier werden die Prozesse in der Regel zu jeweils einem Prozessschritt zusammengefasst. Da der Prozess lediglich zur Verdeutlichung der Anwendungsszenarien dient, werden nicht alle Prozesse und Entscheidungen dargestellt. Beispielsweise wurde auf die Darstellung der Prozesse zur Prüfung des Zahlungseingangs und des Mahnverfahrens verzichtet.
7.7.1 Beteiligte Akteure
Abbildung 104 gibt einen Überblick über die in den Geschäftsprozess involvierten Akteure. Diese sind der Kunde, das Handelsunternehmen welches den Online Shop betreibt, ein Anbieter von Zahlungsdiensten, ein Produzent dessen Waren durch den Händler verkauft werden, sowie das Finanzamt. Jeder dieser Akteure stellt eine eigene Administrationsdomäne dar, in der Benutzerkonten, Geschäftsdaten und Mitarbeiter eigenständig verwaltet werden. Im folgenden wird jede Domäne kurz charakterisiert.
296 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Abbildung 104: Anwendungsszenario im Überblick
7.7.1.1 Kunde
Bei dem Kunden handelt es sich um eine Privatperson, die unterschiedliche Online-Angebote nutzt, d.h. er ist gleichzeitig Kunde bei verschiedenen Institutionen und Unternehmen (z.B. Bank, Online Shop, …). Je nachdem, ob es sich um einen Erstkontakt handelt, ist der Kunde bei den Unternehmen bereits bekannt oder nicht.
7.7.1.2 Handelsunternehmen (Händler)
Der Händler bietet eine Reihe von Produkten für Privatkunden über einen Online Shop an. Er versucht eine hohe Anzahl Kunden zu erreichen, um seinen Umsatz möglichst zu steigern. Um seine internen Prozesse zu optimieren, setzt er auf möglichst automatisierte, elektronisch durchgeführte Prozesse. Dazu gehört auch die elektronische Abwicklung von Prozessen mit seinen Geschäftspartnern (z.B. Produzent) und Behörden.
7.7.1.3 Zahlungsservice Provider
Der Zahlungsservice Provider erbringt eine Dienstleistung, die für den Händler geschäftskritisch ist. Durch die Prüfung von Kreditkarten- und Kontodaten ermöglicht er dem Händler eine Abschätzung des Zahlungsausfallrisikos. Nur dadurch ist der Händler in der Lage, auch Neukunden eine komfortable und schnelle Bestellabwicklung zu bieten.
Bundesamt für Sicherheit in der Informationstechnik 297 SOA-Security-Kompendium
7.7.1.4 Produzent
Der Produzent stellt Waren her, die vom Händler vertrieben werden. Im Gegensatz zum Händler ist er nicht zwingend auf eine hohe Anzahl Kunden angewiesen sondern kann den Fokus darauf legen, möglichst hohe Stückzahlen über eine begrenzte Anzahl von Geschäftspartnern abzusetzen. Nur dadurch lohnt es sich, einen höheren Aufwand bei der Integration seiner Systeme mit denen seiner Geschäftspartner in Kauf zu nehmen. Auch er ist darauf bedacht, seine internen Prozesse durch IT-Unterstützung zu optimieren.
7.7.1.5 Finanzamt
Im Rahmen seiner hoheitlichen Aufgaben fordert das Finanzamt unter anderem unterschiedliche Informationen von Privatpersonen und Unternehmen an. Im Rahmen des Beispielprozesses wird der Fall der Umsatzsteuervoranmeldung von Unternehmen betrachtet. Die Beziehung zwischen Privatpersonen und Finanzamt wird daher im Folgenden vernachlässigt. Um die Belastungen für die Unternehmen durch die unterschiedlichen Informationspflichten möglichst gering zu halten und gleichzeitig die eigenen Aufwände zu reduzieren, ist das Finanzamt darauf bedacht, die Kommunikation mit den Unternehmen zu optimieren. Auch intern wird IT eingesetzt, um Verfahrensabläufe zu verbessern.
7.7.1.6 Bank
Die Bank verwaltet das Konto des Kunden. Da die Prozesse zur Rechnungsstellung und Zahlung aus Komplexitätsgründen im Rahmen des Beispielprozesses nicht aufgeführt werden, wird dies im Folgenden nicht weiter betrachtet. Allerdings kann die Bank noch weitere Aufgaben übernehmen. Beispielweise kann sie als Identitätsprovider dienen, der die Identität eines Kunden bestätigt. Kann ein Kunde eine entsprechende elektronische Bestätigung seiner Bank vorweisen, so kann ein Händler alleine aufgrund seines Vertrauens zur Bank Sicherheit über die Identität eines Kunden erlangen oder bestätigte Information über dessen Zahlungsfähigkeit bekommen. Dies wäre für den Händler zum Beispiel eine Alternative zur Nutzung des Zahlungsservice Providers. Im Rahmen des Beispielprozesses kann jedoch nicht im Detail auf unterschiedliche Alternativen zur Umsetzung der Sicherheit eingegangen werden, weswegen der Fokus im Folgenden auf der Nutzung des Zahlungsservice Providers liegen soll.
298 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
B 2 C B 2 B B 2 B G 2 B
Zahlungsservice K u n d e H ä n d l e r P r o v i d e r P r o d u z e n t F i n a n z a m t
P r o d u k t Verfügbarkeit A n f r a g e p r ü f e n
A n g e b o t e r s t e lle n
Bestellung Bestellung Adressdaten a u f g e b e n p r ü f e n p r ü f e n
B e s t e ll- A b le h n u n g Bestellung Kreditkarte e r h a lt e n a u s f ü h r e n v a lid ie r e n
B e s t e ll- P r o d u k t Z a h lu n g s - inform ation a u f f ä h ig k e it e r h a lt e n L a g e r ? p r ü f e n
P r o d u k t Bestellung b e s t e lle n a u s f ü h r e n
V e r s a n d - Versand und inform ation R e c h n u g s - e r h a lt e n s t e llu n g
U m satzsteuer - Besteuerungs - voranm eldung v e r f a h r e n
Abbildung 105: Beispielprozess für die betrachteten Anwendungsszenarien
7.7.2 B2C
Business-To-Consumer (B2C) bezeichnet Szenarien, in denen Unternehmen Geschäfte mit Privatpersonen durchführen z.B. Waren oder Dienstleistungen anbieten, die dann von Privatpersonen gekauft oder genutzt werden.
Bundesamt für Sicherheit in der Informationstechnik 299 SOA-Security-Kompendium
7.7.2.1 B2C innerhalb des Beispielprozesses Innerhalb des Beispielprozesses ergeben sich folgende B2C Kommunikationsbeziehungen:
K u n d e H ä n d l e r
P r o d u k t Verfügbarkeit A n f r a g e p r ü f e n
Abbildung 106: Produkt anfragen
Produkt anfragen Ein Kunde (C) hat ein Produkt entdeckt, welches ihn interessiert. Er fragt daher weitere Informationen und Preise zu dem Produkt ab. Verfügbarkeit prüfen Das Unternehmen (B) prüft die Verfügbarkeit des Produktes und entscheidet dann, zu welchen Konditionen er ein Angebot abgeben kann (z.B. welche Lieferzeit möglich ist).
Sicherheitsanforderungen (beispielhaft):
Prozessschritt verwertete Informationen Risikobewertung
Produkt anfragen z.B. Produktkategorie, gering, da keine Artikelnummer personenbezogene Daten im Spiel
Verfügbarkeit prüfen z.B. Produktkategorie, gering, da keine Artikelnummer personenbezogene Daten im Spiel
K u n d e H ä n d l e r
A n g e b o t e r s t e lle n
Bestellung Bestellung a u f g e b e n p r ü f e n
Abbildung 107: Angebot erstellen
300 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Angebot erstellen Das Unternehmen stellt dem Kunden alle notwendigen Informationen für eine Bestellung bereit (z.B. Preis, Lieferzeit, Versandkosten, Zahlungsmöglichkeiten usw.).
Bestellung aufgeben Der Kunde entscheidet sich für eine Bestellung. Dazu gibt er notwendige Informationen wie z.B. Name, Lieferadresse, Rechnungsanschrift und Kreditkarteninformationen an.
Bestellung prüfen Das Unternehmen prüft die Bestelldaten. Dazu nimmt es ggf. Dienstleistungen weiterer Unternehmen in Anspruch (siehe B2B).
Sicherheitsanforderungen (beispielhaft):
Prozessschritt verwertete Informationen Risikoabschätzung und Sicherheitsziele
Angebot erstellen z.B. Preis, Lieferzeit, gering, da keine Versandkosten, personenbezogene Daten im Zahlungsmöglichkeiten Spiel Sicherheitsziel Vertraulichkeit, falls kundenbezogene Rabatte gewährt werden.
Bestellung aufgeben z.B. Name, Lieferadresse, hoch für den Kunden, da Rechnungsanschrift, personenbezogene Daten Kreditkarteninformationen Sicherheitsziele Vertraulichkeit und Integrität ggf. hoch für den Händler, da bei hochwertigen Gütern oder Individualanfertigungen hohe finanzielle Schäden entstehen können Sicherheitsziele Identitätsnachweis, Nachweisbarkeit und Verbindlichkeit der Bestellung
Bestellung prüfen siehe „Bestellung aufgeben“ siehe „Bestellung aufgeben“
Bundesamt für Sicherheit in der Informationstechnik 301 SOA-Security-Kompendium
K u n d e H ä n d l e r
B e s t e ll- inform ation Bestellung e r h a lt e n a u s f ü h r e n
Abbildung 108: Bestellung ausführen
Bestellung ausführen Je nach Ergebnis der Prüfung entscheidet das Unternehmen, ob die Bestellung ausgeführt wird.
Bestellinformation erhalten Je nach Entscheidung des Unternehmens erhält der Kunde eine Nachricht, ob seine Bestellung ausgeführt wird oder eine Ausführung nicht möglich ist (z.B. weil Kreditkarteninformationen fehlerhaft sind).
Prozessschritt verwertete Informationen Risikoabschätzung und Sicherheitsziele
Bestellung ausführen siehe „Bestellung aufgeben“ siehe „Bestellung aufgeben“
Bestellinformationen erhalten z.B. Lieferzeitpunkt gering, da keine personenbezogenen Daten Sicherheitsziele ggf. Vertraulichkeit (bei der Bestätigung von Sonderkonditionen), Integrität und Nachweisbarkeit (z.B. wenn nicht eingehaltene Lieferzusagen zu Schadensersatzansprüchen führen)
302 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
K u n d e H ä n d l e r
V e r s a n d - Versand und inform ation R e c h n u g s - e r h a lt e n s t e llu n g
Abbildung 109: Versand
Versand und Rechnungsstellung Die Prozesse auf Seiten des Händlers zum Versand und zur Rechnungsstellung bleiben dem Kunden in der Regel verborgen. Lediglich das Ergebnis ist für ihn relevant (Erhalt der Ware und der Rechnung).
Versandinformation erhalten Durch die Versandinformation wird dem Kunden der Versand der Ware und damit eine Änderung des Status seiner Bestellung mitgeteilt. Für beide Seiten ist dies wichtig, um z.B. zu erkennen, ob eine Ware während des Versands verloren gegangen ist.
Prozessschritt verwertete Informationen Risikoabschätzung und Sicherheitsziele
Versand und z.B. Artikelnummer, Preis, hoch, da personenbezogene Rechnungsstellung Lieferdatum, Anschrift Daten und Daten als Grundlage für Zahlungsleistung Sicherheitsziele Vertraulichkeit, Integrität, Identitätsnachweis, Nachweisbarkeit, Verbindlichkeit
Versandinformation erhalten z.B. Lieferdatum gering, da lediglich Daten über eine Bestellung (in der Regel ohne Preis und ohne personenbezogene Daten) ggf. Sicherheitsziel Vertraulichkeit, z.B. wenn der Empfänger nicht möchte, dass bekannt wird, dass er den Artikel bestellt hat.
Bundesamt für Sicherheit in der Informationstechnik 303 SOA-Security-Kompendium
7.7.2.2 Merkmale einer B2C Beziehung
Ein wesentliches Merkmal einer solchen B2C Beziehung ist, dass Kunden in der Regel unterschiedliche Unternehmen zum Einkauf von Waren nutzen, d.h. sie sind nicht bereit sich für einen solchen Einkauf spezielle Software herunterzuladen und zu installieren. Aus Sicht einer SOA bedeutet dies, dass das Unternehmen eine in der Regel webbasierte Anwendung bereitstellen muss, die der Kunde nutzen kann. Eine solche Anwendung kann z.B. ein Webshop oder auch eine Portalanwendung sein, die dann in die SOA des Unternehmens integriert wird. Hierfür anzuwendende Sicherheitsmechanismen beschreibt das Kapitel 7.1 Sicherheit von Portalen als Schnittstelle zu SOAs. Es sind jedoch auch andere Szenarien denkbar. Kunden haben z.B. mit ihrer Bank eine wesentlich langfristigere Geschäftsbeziehung als mit einem Unternehmen, bei dem sie nur einmal einkaufen. In diesem Fall ist der Kunde auch eher bereit, entsprechende Software der Bank bei sich zu installieren. Statt webbasierten Anwendungen kommen daher auch RichClient Anwendungen in Frage, die dem Kunden einerseits mehr Komfort bieten, andererseits aber auch mehr Möglichkeiten zur Ausgestaltung von Sicherheitsmechanismen ermöglichen (z.B. Anbindung von Kartenlesern). Das Beispiel Bank zeigt auch, dass die Sicherheitsanforderungen in einem B2C Szenario durchaus sehr unterschiedlich sein können. Ein weiteres Merkmal des Beispielprozesses ist, dass Kunden dem Handelsunternehmen zunächst unbekannt sind. Meist wird mit der ersten Bestellung ein Account für den Benutzer angelegt. Der Kunde erhält ein Benutzerkonto und kann dann bei weiteren Bestellungen z.B. durch Benutzername und Passwort identifiziert werden. Eine weitere Möglichkeit stellt das dezentrale Identitätsmanagement (vergleiche Kapitel 6.4.2.4) dar. Bei dieser Variante wird die Authentifizierung durch eine vertrauenswürdige dritte Partei durchgeführt, wie z.B. einer Bank. In diesem Fall würde der Händler keine Authentifizierungsinformationen des Kunden verwalten, sondern notwendige Identitätsinformationen von der Bank beziehen. Voraussetzung ist allerdings, dass der Händler der Bank vertraut. Welche Mechanismen zur Etablierung des Vertrauens angewendet werden können, wird im Kapitel 6.3 Trust Management beschrieben. Da der Zugriff direkt über das Internet erfolgt, muss mit den in Kapitel 3.4 beschriebenen Angriffsszenarien gerechnet werden. Während bei der Übertragung der Produktinformationen in der Regel keine hohen Sicherheitsanforderungen zu beachten sind, werden insbesondere im Rahmen der Bestellung personenbezogene Daten des Kunden übertragen, die entsprechend gesichert werden müssen (insbesondere in Bezug auf Vertraulichkeit). Kapitel 6.5.2 beschreibt hierzu mögliche Mechanismen.
7.7.3 B2B
Business-To-Business (B2B) beschreibt die Beziehung zwischen Unternehmen. Im dargestellten Beispiel sind hier zwei B2B Beziehungen herausgegriffen – einmal die Beziehung zwischen Händler und Produzent und einmal die Beziehung zwischen Händler und einem Zahlungsservice Provider.
304 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
7.7.3.1 B2B innerhalb des Beispielprozesses
Zahlungsservice H ä n d l e r P r o v i d e r
Bestellung Adressdaten p r ü f e n p r ü f e n
Kreditkarte v a lid ie r e n
Z a h lu n g s - f ä h ig k e it p r ü f e n
Abbildung 110: Bestellung prüfen
Bestellung prüfen Um die Daten des Kunden zu prüfen, bedient sich der Händler (B) im Beispielprozess eines Zahlungsservice Providers (B), d.h. er gibt Informationen wie z.B. Adresse und Kreditkarteninformation an diesen weiter. Erst auf Basis der Rückmeldung des Zahlungsservice Providers entscheidet er über die Ausführung der Bestellung.
Adressdaten prüfen Im Rahmen der Prüfung der Adressdaten wird die Korrektheit der postalischen Adresse festgestellt.
Kreditkarte validieren Zur Minimierung des Risikos von Zahlungsausfällen wird die Gültigkeit der Kreditkarte geprüft.
Zahlungsfähigkeit prüfen Die Prüfung der Zahlungsfähigkeit kann z.B. über eine Schufaabfrage erfolgen. Häufig kommen hier Scores zum Einsatz, die beschreiben, wie hoch das Risiko bei der geplanten Transaktion ist.
Die genannten Prüfungen sind als Beispiele zu verstehen. Dienstleister bieten eine Vielzahl unterschiedlicher Services an, von der Prüfung von Bank Account bis zur Nutzung von Blacklists, in denen säumige Zahler aufgeführt sind. Diese Services können in unterschiedlichen Kombinationen genutzt werden.
Bundesamt für Sicherheit in der Informationstechnik 305 SOA-Security-Kompendium
Prozessschritt verwertete Informationen Risikoabschätzung und Sicherheitsziele
Bestellung prüfen z.B. Adressdaten, hoch, da personenbezogene Kreditkarteninformationen, Daten und potenzielles Kontoinformationen Zahlungsausfallrisiko Sicherheitsziele Vertraulichkeit, Integrität, Nachweisbarkeit, Verbindlichkeit, Identitätsnachweis und Autorisierung (da nur Vertragspartner des Zahlungsproviders Zugriff erhalten dürfen)
Adressdaten prüfen z.B. Adressdaten siehe „Bestellung prüfen“
Kreditkarte validieren z.B. Kreditkartendaten siehe „Bestellung prüfen“
Zahlungsfähigkeit prüfen z.B. Adressdaten, siehe „Bestellung prüfen“ Kreditkarteninformationen, Kontoinformationen
H ä n d l e r P r o d u z e n t
P r o d u k t Bestellung b e s t e lle n a u s f ü h r e n
Abbildung 111: Produkt bestellen
Produkt bestellen Die Bestellung eines Produktes im Beispielprozess erfolgt als Konsequenz einer Kundenbestellung. Alternativ ist es natürlich auch denkbar, dass eine Produktbestellung beim Produzenten immer dann erfolgt, wenn der Lagerbestand des Händlers unter einen definierten Wert sinkt.
Bestellung ausführen Der Bestellvorgang beim Produzenten ist in diesem Beispiel stark verkürzt dargestellt. Auch wenn sie hier aus Gründen der Übersichtlichkeit nicht dargestellt sind, gibt es auch dort einzelne Prozessschritte, wie z.B. die Prüfung der Bestellung.
306 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Prozessschritt verwertete Informationen Risikoabschätzung und Sicherheitsziele
Produkt bestellen z.B. Name, Lieferadresse, hoch, da personenbezogene Rechnungsanschrift, Daten Kreditkarteninformationen Sicherheitsziele Vertraulichkeit und Integrität ggf. Hoch, da bei hochwertigen Gütern oder Individualanfertigungen hohe finanzielle Schäden entstehen können Sicherheitsziele Identitätsnachweis, Autorisierung, Nachweisbarkeit und Verbindlichkeit der Bestellung
Bestellung ausführen siehe „Produkt bestellen“ siehe „Produkt bestellen“
7.7.3.2 Merkmale einer B2B Beziehung
Bei der Kommunikation mit dem Zahlungsservice Provider besteht vor Nutzung der Dienstleistung ein Vertragsverhältnis mit dem Service Provider. Das bedeutet auch, dass entsprechende Sicherheitsmechanismen vereinbart wurden. Der Händler wird z.B. bei der Nutzung der Services authentifiziert. Der Zugriff auf die Dienstleistungen des Zahlungsservice Providers wird über das Internet erfolgen, d.h. es müssen Sicherheitsmaßnahmen gegen Angriffe aus dem Internet getroffen werden. Der Zugriff basiert bei einem solchen Szenario in der Regel auf einer Maschine-Maschine- Kommunikation. Da der Service bei jeder Bestellung genutzt wird, wäre die Nutzung einer durch Mitarbeiter des Händlers zu bedienenden Weboberfläche, die der Dienstleister bereitstellt, zu zeitaufwändig. Daher erhalten hier normalerweise die Bestellsysteme des Händlers direkten Zugriff auf die Services, die vom Dienstleister z.B. in Form von Web Services bereitgestellt werden. Aus diesem Grund erfolgt die Authentisierung deshalb auch nicht auf Mitarbeiterebene sondern auf Anwendungsebene, d.h. der Dienstleister prüft nur, ob die Anfrage von einer beliebigen Anwendung des Händlers kommt. Hierbei sind unterschiedliche Sicherheitsmechanismen, wie sie z.B. im Kapitel 6.3 beschrieben sind, denkbar. Die genannten Merkmale gelten vergleichbar für die Kommunikation mit dem Produzenten. Auch hier kennen sich die beiden Kommunikationspartner. Ob der Händler Bestellungen direkt aus seinen Systemen an den Produzenten weitergeben kann, hängt insbesondere von der Tiefe der Handelsbeziehung zwischen den beiden Partnern ab. Werden nur gelegentlich Produkte bestellt, so reicht eine webbasierte Lösung, erfolgen jedoch häufige und größere Bestellungen so erfolgt dies in der Regel direkt aus den Bestellsystemen des Händlers. Auf diese Weise lassen sich z.B. einzelne Bestellanfragen bündeln. Als Sicherheitsmechanismen kommen daher auch hier einmal Mechanismen zur Absicherung webbasierter Anwendungen
Bundesamt für Sicherheit in der Informationstechnik 307 SOA-Security-Kompendium
(vergleiche Kapitel 7.1 ) und einmal Mechanismen zur Absicherung von Web Services (vergleiche Kapitel 6.5.2) zum Einsatz. Im Bereich B2B sind darüber hinaus eine Vielzahl unterschiedlicher Szenarien denkbar. Beispielsweise könnte der Händler in unserem Beispielprozess Leistungen wie Abrechnung, Mahnwesen, Lieferung und Personalwesen komplett auslagern. Es sind auch Szenarien denkbar, in denen die Systeme zweier Unternehmen sehr stark miteinander verzahnt sind. Als Beispiel sei hier die Automobilindustrie mit ihren Zulieferprozessen genannt. Um Just-In- Time Lieferungen zu ermöglichen, sind die Systeme der Lieferanten teilweise eng mit den Produktionsplanungssystemen des Automobilherstellers integriert. Die Kommunikation läuft dabei häufig nicht mehr über das Internet, sondern es werden gesicherte (virtuelle) Extranets verwendet. Dadurch sind die Anwendungen besser gegen Angriffe aus dem Internet geschützt. In derartigen Szenarien sind insbesondere Sicherheitsanforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit zu beachten. Abschließend kann gesagt werden, dass B2B Szenarien sehr vielfältig sind. Aus diesem Grund lassen sich auch kaum allgemeingültige Aussagen in Bezug auf Sicherheitsmechanismen bei B2B Kommunikationsbeziehungen treffen.
7.7.4 G2B
Government-To-Business(G2B) bezeichnet Kommunikationsbeziehungen, bei denen die öffentliche Verwaltung Leistungen z.B. Aufgaben der Ordnungsverwaltung oder Wirtschaftsförderung erbringt. In den Bereich der Ordnungsverwaltung fällt unter anderem auch der Bereich Steuern und Abgaben.
H ä n d l e r F i n a n z a m t
U m satzsteuer - Besteuerungs - voranm eldung v e r f a h r e n
Abbildung 112: Umsatzsteuervoranmeldung
7.7.4.1 G2B innerhalb des Beispielprozesses
Umsatzsteuervoranmeldung Unabhängig von den Interaktionen, die ein Händler (B) mit Kunden oder anderen Unternehmen hat, muss der Händler Informationspflichten, die dieser gegenüber dem Staat (G) hat, erfüllen. Eine solche Informationspflicht ist z.B. die Umsatzsteuervoranmeldung. Im Beispiel nutzt der Händler die vom Finanzamt bereitgestellten Services, um die Informationen digital zu übertragen.
308 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Besteuerungsverfahren Das Finanzamt prüft den Eingang und speichert die Daten ab. Diese Daten bilden die Grundlage dafür, dass das Finanzamt seine Aufgaben wahrnehmen kann.
Prozessschritt verwertete Informationen Risikoabschätzung und Sicherheitsziele
Umsatzsteuervoranmeldung z.B. Umsatzzahlen hoch, da vertrauliche Firmendaten Sicherheitsziele Vertraulichkeit, Integrität, Identitätsnachweis, Nachweisbarkeit, Verbindlichkeit
Besteuerungsverfahren siehe siehe „Umsatzsteuervoranmeldung“ „Umsatzsteuervoranmeldung“
7.7.4.2 Merkmale einer G2B Beziehung
Wie erwähnt, besteht zwischen Unternehmen und dem Staat eine Kommunikationsbeziehung. Das wesentliche Merkmal dieser Beziehung ist, dass bestimmte Informationspflichten wie z.B. Umsatzsteuervoranmeldung immer wieder an den Staat versendet werden. Da der Staat den Dienst bereitstellt, muss dieser die Sicherheitsanforderungen an die Unternehmen vorgeben. Verlangt der Staat z.B. eine sehr hohe Integrität der zu übersendenden Daten, muss der Händler diese beispielsweise signieren. Der Zugriff erfolgt direkt über das Internet, daher muss mit den in Kapitel 3.4 beschriebenen Angriffsszenarien gerechnet werden. Da teilweise vertrauliche Daten dem Staat übermittelt werden, müssen angemessene Maßnahmen zur Wahrung der Vertraulichkeit und Integrität eingeführt werden. Je nachdem, welche Informationspflicht erfüllt werden muss und vor allem wie oft, stellt der Staat eine Software zur Verfügung, die vom Unternehmen auch genutzt werden muss. In solch einem Fall wird keine Weboberfläche genutzt, sondern die bereitgestellte Software ist z.B. über eine SOA mit den Systemen der Behörde integriert. Ein Beispiel ist die Abgabe der Steuererklärung mit Hilfe von ELSTER. In diesem Fall schreibt das Finanzamt vor, dass, wenn Daten digital übertragen werden sollen, ELSTER als Tool genutzt werden muss. Es handelt sich dabei um eine Maschine-zu-Maschine-Verbindung. Ein solches Szenario eignet sich gut zur Umsetzung mit einer SOA. Beispielsweise könnte die Datenübertragung und auch die Weiterverarbeitung auf Seiten des Finanzamts auf SOA basieren. Ein anderes Beispiel ist die reine Bereitstellung von Informationen über ein Webportal. Unternehmen können sich in dem Fall Informationen abrufen oder Formulare herunter laden. Ein Merkmal dieser Verbindung ist, dass keine vertraulichen Daten versendet werden, Unternehmen dem Service Provider (Staat) unbekannt sind und keine gesonderten Sicherheitsanforderungen an den Nutzer gestellt werden. Während bei der Übertragung der unkritischen Informationen einer Website oder beim Download von Vorlagen in der Regel eine hohe Verfügbarkeit zur Erfüllung der Sicherheitsanforderungen ausreichend ist, werden insbesondere im Rahmen der Übermittlung von Informationen, die aufgrund einer Informationspflicht zu übermitteln sind, Daten
Bundesamt für Sicherheit in der Informationstechnik 309 SOA-Security-Kompendium
übertragen, die entsprechend gesichert werden müssen (insbesondere in Bezug auf Vertraulichkeit und Integrität).
7.7.5 Unternehmensinterne SOA
Neben den dargestellten Beispielen für Kommunikationsbeziehungen zu Privatpersonen, anderen Unternehmen oder der öffentlichen Verwaltung, sind beim Aufbau einer SOA insbesondere auch die unternehmensinternen Kommunikationsbeziehungen z.B. zwischen unterschiedlichen Abteilungen von Bedeutung.
7.7.5.1 Unternehmensinterne SOA innerhalb des Beispielprozesses
H ä n d l e r
Verfügbarkeit p r ü f e n
A n g e b o t e r s t e lle n
Abbildung 113: Verfügbarkeit prüfen
Verfügbarkeit prüfen Die Prüfung der Verfügbarkeit kann beispielsweise durch die Abfrage der Bestandsverwaltung oder auch der Lagersysteme des Händlers erfolgen. Es ist aber auch denkbar, dass schon an dieser Stelle Nachfragen bei Lieferanten oder Produzenten erfolgen. Aus Gründen der Übersichtlichkeit werden diese unterschiedlichen Varianten im Beispielprozess nicht dargestellt.
Angebot erstellen Das Angebot enthält alle notwendigen Informationen, die der Kunde benötigt, um eine Bestellentscheidung zu treffen.
Prozessschritt verwertete Informationen Risikoabschätzung und Sicherheitsziele
Verfügbarkeit prüfen z.B. Produktkategorie, gering, da keine Artikelnummer personenbezogene Daten im Spiel
310 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Angebot erstellen z.B. Preis, Lieferzeit, gering, da keine Versandkosten, personenbezogene Daten im Zahlungsmöglichkeiten Spiel Sicherheitsziel Vertraulichkeit, falls kundenbezogene Rabatte gewährt werden.
Bestellung prüfen Die Prüfung der Bestellung ist Grundlage für die Entscheidung, ob eine Bestellung ausgeführt wird oder nicht. Hier werden insbesondere die Daten des Kunden (ggf. durch einen externen Service Provider) überprüft.
Abbildung 114: Bestellung prüfen
Bestellung ausführen An dieser Stelle erfolgt die Entscheidung, ob ein Bestellvorgang abgebrochen wird oder entsprechende Nachrichten an die weiteren Systeme des Händlers z.B. die Lagerverwaltung weitergegeben werden.
Bundesamt für Sicherheit in der Informationstechnik 311 SOA-Security-Kompendium
Bestell-Ablehnung erhalten Wenn eine Bestellung nicht ausgeführt wird erhält der Kunde eine entsprechende Benachrichtigung mit einer Ablehnung (ggf. mit Nennung von Gründen).
Produkt auf Lager An dieser Stelle erfolgt in unserem Beispielprozess die Entscheidung, ob das Produkt direkt ausgeliefert werden kann oder erst noch beim Produzenten bestellt werden muss.
Produkt bestellen Die Bestellung des Produktes kann auf unterschiedliche Weise erfolgen. Je nachdem, wie stark der Händler seine Systeme mit den Systemen des jeweiligen Produzenten integriert hat, sind hier unterschiedliche Varianten möglich. Eine Bestellung kann vollautomatisch durch die Systeme veranlasst werden. Es ist aber genauso gut denkbar, dass die Bestellung über eine Webanwendung durch einen Mitarbeiter des Händlers per Hand erfolgt.
Versand und Rechnungsstellung Hinter Versand und Rechnungsstellung verbergen sich ebenfalls Prozesse, an denen unterschiedliche Anwendungen des Händlers beteiligt sein können. Beispielsweise muss der Versand veranlasst und der Lagerbestand reduziert werden. Wurde die Rechnung gestellt, muss im Nachgang der Zahlungseingang geprüft und ggf. ein Mahnverfahren eingeleitet werden.
Prozessschritt verwertete Informationen Risikoabschätzung und Sicherheitsziele
Bestellung prüfen z.B. Name, Lieferadresse, hoch, da personenbezogene Rechnungsanschrift, Daten Kreditkarteninformationen Sicherheitsziele Vertraulichkeit und Integrität ggf. Hoch, da bei hochwertigen Gütern oder Individualanfertigungen hohe finanzielle Schäden entstehen können Sicherheitsziele Identitätsnachweis, Nachweisbarkeit und Verbindlichkeit der Bestellung
Bestellung ausführen? siehe „Bestellung prüfen“ siehe „Bestellung prüfen“
Produkt auf Lager? z.B. Lagerbestand gering, da in der Regel keine unternehmenskritischen Daten
Produkt bestellen z.B. Name, Lieferadresse, hoch, da personenbezogene
312 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Rechnungsanschrift, Daten Kreditkarteninformationen Sicherheitsziele Vertraulichkeit und Integrität ggf. hoch, da bei hochwertigen Gütern oder Individualanfertigungen hohe finanzielle Schäden entstehen können Sicherheitsziele Identitätsnachweis, Autorisierung, Nachweisbarkeit und Verbindlichkeit der Bestellung
Versand und z.B. Artikelnummer, Preis, hoch, da personenbezogene Rechnungsstellung Lieferdatum, Anschrift Daten und Daten als Grundlage für Zahlungsleistung Sicherheitsziele Vertraulichkeit, Integrität, Identitätsnachweis, Nachweisbarkeit, Verbindlichkeit
7.7.5.2 Merkmale einer unternehmensinternen SOA
Eine unternehmensinterne SOA ist häufig wesentlich komplexer als die Beziehungen zu externen Partnern. Da das Unternehmen selbst entscheiden kann, welche Teile der IT integriert werden, lässt sich ein wesentlich höherer Integrationsgrad erreichen als bei einer Integration mit Partnerunternehmen. Wesentliches Merkmal dieser Kommunikationsbeziehungen ist, dass sie sich in der Regel innerhalb des Intranets eines Unternehmens abspielen. Die Anzahl der Nutzer ist bekannt und es lassen sich unternehmensweite Standards z.B. für das Identitätsmanagement schaffen. Zumeist ist das Identitätsmanagement innerhalb einer abgeschlossenen Domäne zentral organisiert, was die Verwaltung zusätzlich vereinfacht. (vergleiche Kapitel 6.4.2.2) Der Zugriff auf Dienste innerhalb der SOA erfolgt sehr unterschiedlich. Hier sind sowohl Maschine-Maschine-Kommunikationen als auch die Nutzung von Webanwendungen möglich. Auch die Sicherheitsanforderungen können sehr unterschiedlich sein. Insbesondere, wenn kritische Geschäftsgeheimnisse betroffen sind, sind sie sehr hoch. In derartigen Fällen werden häufig separate Netze genutzt, die vollständig vom Intranet des Unternehmens getrennt sind. Während bei der Kommunikation mit Partnern in der Regel moderne Schnittstellen z.B. auf der Basis von Web Services zum Einsatz kommen, findet man innerhalb des Unternehmens
Bundesamt für Sicherheit in der Informationstechnik 313 SOA-Security-Kompendium häufig noch Legacy Anwendungen, die nicht umgestellt werden. Aus diesem Grund ist die Schnittstellenvielfalt innerhalb eines Unternehmens meist höher als bei der Kommunikation mit Partnern. Bei der Konzeption einer SOA kann man sich daher nicht darauf verlassen, dass bei allen Schnittstellen vergleichbare Sicherheitsanforderungen umsetzbar sind. Die Festlegung von übergreifenden Sicherheitsstandards gestaltet sich daher schwieriger.
7.7.6 Sonstige Szenarien
Neben den genannten Szenarien werden teilweise noch weitere Szenarien unterschieden. Consumer-To-Business (C2B): Während hier teilweise eine Umkehrung des Einkaufsverhaltens bezeichnet wird, indem Privatpersonen über entsprechende Plattformen Angebote von mehreren Unternehmen anfordern, um z.B. den besten Preis zu erhalten, werden mit C2B auch Szenarien bezeichnet, in denen Privatpersonen Leistungen für Unternehmen erbringen. Beispielsweise gibt es Bilddatenbanken, in denen Privatpersonen ihre Bilder an Unternehmen verkaufen können. Da der Begriff bisher nicht eindeutig definiert ist und sich das Szenario nicht wesentlich von einem B2C oder B2B Szenario unterscheidet, wird auf eine separate Darstellung an dieser Stelle verzichtet. Consumer-To-Consumer (C2C): Hiermit werden Szenarien bezeichnet, bei denen Privatpersonen Leistungen für andere Privatpersonen erbringen. Ein klassisches Beispiel für C2C sind Auktionsplattformen. Wesentliches Merkmal derartiger Szenarien ist, dass in der Regel ein Vermittler existiert, wie z.B. die Auktionsplattform, die die beiden Privatpersonen zusammenbringt. In Bezug auf Sicherheitsaspekte ähneln derartige Szenarien daher den B2C Szenarien und werden daher hier nicht separat betrachtet. Business-To-Government (B2G) bezeichnet Kommunikationsbeziehungen, bei denen die Wirtschaft Leistungen für die öffentliche Verwaltung erbringt (z.B. Waren oder Dienstleistungen liefert). Da ein solches Szenario aus Sicht einer SOA mit dem B2B Szenario zu vergleichen ist, wird es hier nicht weiter betrachtet.
7.7.7 Technische Umsetzung
Aus technischer Sicht sind bei der Umsetzung eines solchen Prozesses eine Reihe unterschiedlicher Systeme beteiligt. Eine Möglichkeit zur Umsetzung des Beispielprozesses ist in nachfolgender Abbildung dargestellt. Aus Gründen der Übersichtlichkeit wurden die Systeme dabei insbesondere bei Zahlungsservice Provider, Produzent und Finanzamt vereinfacht und zusammengefasst dargestellt. Zu beachten ist, dass der Aufbau einer SOA unter Berücksichtigung der notwendigen Sicherheitsanforderungen sehr komplex ist. Häufig gibt es unterschiedliche Varianten um einzelne Sicherheitsziele zu erreichen. Die Umsetzung einer SOA muss daher sehr sorgfältig geplant werden. Die Auswahl einer geeigneten Umsetzungsvariante muss auf Grundlage der individuell ermittelten Sicherheitsanforderungen erfolgen. Auf eine pauschale Empfehlung für oder gegen einzelne Sicherheitsmaßnahmen zur Umsetzung des Beispielprozesses wird daher an dieser Stelle verzichtet. Sie würde den Rahmen des Kompendiums sprengen. Als weiterführende Literatur zu diesem Thema bietet sich [TeleTrust] an, welches unterschiedliche Design Pattern zur Umsetzung von Sicherheitsanforderungen im SOA Umfeld vorstellt und bewertet.
314 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Zahlungsservice K u n d e H ä n d l e r P r o v i d e r P r o d u z e n t F i n a n z a m t
Firew all / Proxy / DM Z Firew all / Proxy / DM Z Firew all / Proxy / DM Z Firew all / Proxy / DM Z W e b b r o w s e r
W ebserver / S e r v ic e B e s t e ll- P o r t a l / Service U m satzsteuer - P r ü f - S e r v ic e s Portal / O nline N u t z u n g s e r v ic e O n lin e - S h o p voranm eldung S h o p
Auftragsm anagement / Lagerverw altung usw .
U nternehm ensinterne U nternehm ensinterne Behördeninterne SOA: SOA: SOA: Fachanw endungen, Fachanw endungen, Fachanw endungen, Datenbanken, Datenbanken, Datenbanken, Sicherheit usw . Sicherheit usw . Sicherheit usw .
Datenbanken S e c u r it y S e r v ic e s Abbildung 115: Technische Systeme im Beispielprozess
7.7.7.1 Kunde
Um dem Kunden eine Bestellung möglichst zu erleichtern, erfolgt die Kommunikation mit dem Händler browserbasiert, d.h. der Kunde benötigt keine spezielle Software. Möglicherweise sichert der Kunde seinen PC ebenfalls über eine Firewall ab. Der Händler kann sich jedoch darauf nicht verlassen. Er muss immer davon ausgehen, dass der Rechner des Kunden ggf. ungeschützt ist.
7.7.7.2 Händler
Der Händler stellt mittels Webserver, Portal und/oder Online-Shop seine Waren im Internet bereit. Da er neue Kunden zunächst nicht kennt, kann der Zugriff nicht auf bestimmte Nutzer eingeschränkt werden. Allerdings kann er einem Kunden, der durch bereits durchgeführte Bestellungen bereits beim Händler bekannt ist, zusätzliche Funktionalitäten (z.B. Zahlungsmöglichkeiten) anbieten. Der Zugriff auf diese Funktionalitäten muss besonders abgesichert werden. Da der Händler immer mit Angriffen aus dem Internet rechnen muss, ist es wichtig, den Zugriff auf die eigenen Systeme entsprechend zu sichern. Deshalb erfolgt der Zugriff immer über Systeme wie Firewalls, Proxies oder eine Demilitarisierte Zone (DMZ). Ein direkter Zugriff auf die internen Fachanwendungen(z.B. Auftragsmanagement und Lagerverwaltung) aus dem Internet ist nicht notwendig und wird daher durch entsprechende
Bundesamt für Sicherheit in der Informationstechnik 315 SOA-Security-Kompendium
Sicherheitsmechanismen ausgeschlossen. Alle notwendigen Daten des Kunden erhalten die internen Fachanwendungen indirekt über Portal und Online Shop. Der Händler kann den Bestellservice des Produzenten nutzen, indem er sich einer browserbasierten Lösung, die vom Produzenten in Form eines Portals oder Online Shops bereitgestellt wird, bedient. Dies hat jedoch den Nachteil, dass die benötigten Daten per Hand von den Mitarbeitern des Händlers im Browser eingegeben werden müssen. Komplizierter in der Umsetzung, aber wesentlich einfacher in der Nutzung ist daher die Nutzung des Bestellservice des Produzenten, d.h. die Anwendungen des Händlers (z.B. die Lagerverwaltung) kann direkt auf den Bestellservice des Produzenten zugreifen. Dazu bedient sich die Lagerverwaltung einer Serviceschnittstelle beim Händler (Service Nutzung), die die Kommunikation mit dem Service des Produzenten übernimmt. Auch diese Kommunikation wird zusätzlich über Firewalls etc. abgesichert. Die Kommunikation mit Services des Zahlungservice Providers und des Finanzamts werden analog zu diesem Vorgehen abgewickelt, d.h. auch hier kommt eine Komponente zur Service Nutzung beim Händler zum Einsatz. Auch die internen Fachanwendungen des Händlers sind in der Regel stark miteinander integriert. Diese Integration kann als unternehmensinterne SOA bezeichnet werden. Sie umfasst auch die Integration von Datenbanken und Security Services. Innerhalb dieser SOA kommen naturgemäß andere Sicherheitsmechanismen zum Einsatz, da die beteiligten Nutzer und Anwendungen in der Regel bekannt sind. Allerdings sind die Sicherheitsanforderungen auch höher, da häufiger mit geschäftskritischen Daten umgegangen wird (z.B. interne Preiskalkulationen).
7.7.7.3 Zahlungsservice Provider
Im Gegensatz zum Händler handelt es sich bei den Kunden des Zahlungsservice Providers um Unternehmen, mit denen Verträge über die Nutzung der Services bestehen. Die Services werden von den Kunden häufig genutzt. Daher lohnt es sich, einen gewissen Aufwand für die Integration zu treiben. Um die Services einfach nutzen zu können, werden sie direkt durch die Anwendungen der Unternehmen angesprochen, d.h. es handelt sich um eine reine Maschine- Maschine Kommunikation. Für den Zahlungsservice Provider ist es dabei unerheblich, welcher Mitarbeiter des jeweiligen Unternehmens zugreift, wichtig ist für ihn nur, dass der Zugriff durch ein dazu berechtigtes Unternehmen erfolgt und er die erbrachte Leistung entsprechend abrechnen kann. Da der Zugriff auch hier über das Internet erfolgt, muss sich auch der Zahlungsservice Provider gegen Angriffe aus dem Internet schützen. Die hinter den Services liegenden internen Anwendungen sind ebenfalls integriert und bilden eine unternehmensinterne SOA.
7.7.7.4 Produzent
Neben einem Bestellservice bietet der Produzent analog zum Händler ein Portal und einen Online Shop an. Dadurch ermöglicht er Händlern, die nur selten Produkte bei ihm kaufen, eine browserbasierte Bestellmöglichkeit, die keine Anpassungen in den Systemen des Händlers voraussetzt. Im Gegensatz zum Online Shop des Händlers darf er jedoch keine Bestellungen von Endkunden zulassen, d.h. der Zugriff auf den Online Shop muss entsprechend abgesichert sein, so dass nur bekannte Händler Zugriff erhalten. Auch der Produzent verfügt über eine unternehmensinterne SOA. Dadurch können z.B. unterschiedliche Produktionsstandorte integriert werden um eine übergreifende Produktionsplanung auf Basis der Bestelleingänge durchzuführen.
316 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
7.7.7.5 Finanzamt
Aus technischer Sicht ist der Aufbau einer SOA innerhalb einer Behörde, wie z.B. dem Finanzamt, vergleichbar mit einer SOA in einem Unternehmen. Allerdings bestehen teilweise andere Anforderungen an die Sicherheit, die sich auch in der Ausgestaltung der einzelnen Systeme niederschlägt. Beispielsweise hat ein Händler die Möglichkeit bei der Authentisierung seiner Kunden im Rahmen eines Bestellvorgangs Kosten zu sparen oder die Komplexität bei der Nutzung seiner Systeme zu verringern, indem er Sicherheitsanforderungen reduziert. Er nimmt damit ein höheres Risiko für manipulierte Bestellungen in Kauf. Dies kann sich aber lohnen, wenn das Kostenrisiko durch diese Manipulationen geringer ist als die Kosten für Sicherheitsmaßnahmen, um diese Manipulationen zu unterbinden. Eine Behörde hat diese Möglichkeit nicht. Beispielsweise darf eine Behörde nicht einfach eine beliebige elektronische Signatur als Äquivalent zu einer handschriftlichen Unterschrift akzeptieren, sondern muss auf einer qualifizierten elektronischen Signatur bestehen. Nicht immer erfolgt die Kommunikation innerhalb einer SOA rein Web Service-basiert. Beispielweise ist es denkbar, dass durch das Finanzamt statt eines Web Service auch eine Software bereitgestellt wird, um Umsatzsteuervoranmeldungen zu generieren und diese Dateien dann beispielsweise über einen FTP Service an das Finanzamt zu übertragen. In diesem Fall werden zusätzliche Sicherheitsmaßnahmen notwendig, da die von FTP bereitgestellten Mechanismen in Bezug auf Authentizität, Integrität und Vertraulichkeit nicht ausreichend sind.
7.7.8 Zusammenfassung
Beim Aufbau einer SOA lassen sich eine Reihe unterschiedlicher Anwendungsszenarien identifizieren. Jedes dieser Szenarien lässt jedoch eine Vielzahl unterschiedlicher Möglichkeiten und Varianten zu. Auch die Sicherheitsanforderungen können daher sehr unterschiedlich sein. Festzuhalten bleibt aber auch, dass vergleichbare Sicherheitsmaßnahmen in unterschiedlichen Anwendungsszenarien genutzt werden können.
Bundesamt für Sicherheit in der Informationstechnik 317 SOA-Security-Kompendium
8 Resümee und Ausblick
8.1 Resümee
Service-orientierte Architekturen werden immer beliebter, da sie die Möglichkeit bieten, Geschäftsprozesse auf flexible und effiziente Weise mittels IT zu unterstützen. Die Durchführung der einzelnen Aktivitäten innerhalb eines Geschäftsprozesses wird dabei durch Dienste realisiert, die über mehrere Organisationen verteilt sein können. Durch diese verteilte Bereitstellung und flexible Nutzung von Diensten ergeben sich für die jeweiligen Unternehmen und Behörden allerdings auch umfassendere Anforderungen an die Sicherheit. Bereits im Einsatz befindliche Sicherheitsmechanismen und Technologien müssen ggf. angepasst, erweitert oder vollständig durch neue Sicherheitstechnologien und -verfahren ersetzt werden, wenn ein Service-orientierter Ansatz in einer Organisation Anwendung finden soll. Mittlerweile existieren zahlreiche Sicherheitsstandards, die die Verwendung von verschiedenen Sicherheitskonzepten in einer SOA ermöglichen, um geeignete Authentifizierungs- und Autorisierungsmechanismen, sowie Verschlüsselungs- und Signaturverfahren umzusetzen. In diesem Kompendium werden alle wesentlichen SOA und SOA Security Standards vorgestellt, um IT-Verantwortliche bei der Auswahl geeigneter Standards und Sicherheitslösungen zu unterstützen. In einem Überblick erhält der Leser des Weiteren wichtige Informationen zu Sicherheitsbedrohungen, die auf dem Gebiet der Service- orientierten Architekturen von Bedeutung sind. Neben Gefahren, die auch auf andere Architekturen zutreffen, werden insbesondere die Bedrohungen erläutert, die sich aufgrund der nachrichtenbasierten Kommunikation zwischen Web Services ergeben. Damit Unternehmen und Behörden diesen Gefahren angemessen begegnen können, werden den Gefahren jeweils empfehlenswerte Sicherheitsmaßnahmen gegenübergestellt. Bei der Realisierung einer SOA müssen jedoch von Beginn an auch wichtige Security Management Themen berücksichtigt werden, um die Nachhaltigkeit der Maßnahmen und die Ganzheitlichkeit des Ansatzes zu gewährleisten. Kapitel 4 des Kompendiums geht daher verstärkt in diesem Kontext auf relevante Themen wie zum Beispiel SOA Lifecycle Management oder Governance-, Risk- und Compliance-Management ein. Es werden Ansätze beschrieben, die Unternehmen und Behörden unterstützen sollen, ein angemessenes Sicherheitsniveau mittels kontinuierlich durchgeführter Prozesse langfristig aufrecht zu erhalten. Vor dem Hintergrund, dass für viele Organisationen aufgrund der Kosten und der bereits vorhandenen IT-Systeme ein sofortiger Umstieg hin zu einer Service-orientierten Architektur nicht realisierbar ist, wird zusätzlich das Vorgehen bei einer systematischen und sicheren SOA Migration beschrieben. In Kapitel 5 findet eine Betrachtung wesentlicher Konzepte statt, die weitere Sicherheitsaspekte adressieren und gleichzeitig Möglichkeiten sowie Vorgehensweisen für eine sichere Umsetzung aufzeigen. Der Abschnitt „SOA Security Framework“ erläutert zunächst, welche Sicherheitsaspekte grundlegend innerhalb einer Service-orientierten Architektur von IT-Verantwortlichen zu berücksichtigen sind. In den danach folgenden Abschnitten werden dann ausgewählte, besonders sicherheitsrelevante Themenbereiche genauer behandelt. Im Kapitel „Security Policy Management“ wird umfassend die Bedeutung von Policies verdeutlicht, die in Service-orientierten Architekturen die Grundlage bilden, um Sicherheitsanforderungen zu veröffentlichen und an Clients zu kommunizieren. Zum Beispiel kann eine Policy die Sicherheitsprotokolle vorgeben, die für die Kommunikation mit einem
318 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Dienst verpflichtend sind. Dies ermöglicht einen Client, sich dynamisch an den Dienst zu binden. Der Abschnitt zum Security Policy Management befasst sich verstärkt damit, wie ausgehend von allgemeinen Richtlinien innerhalb einer Organisation eine technische Abbildung mittels Policies erfolgen kann, die anschließend von den jeweiligen Diensten durchgesetzt werden. Im weiteren Verlauf des Kapitels werden ferner der Aufbau und die Verwaltung von Vertrauensbeziehungen beschrieben (Trust Management), sichere Kompositionen von Diensten erläutert sowie Hinweise zur Gewährleistung einer interoperablen Kommunikation zwischen Diensten gegeben. Einen weiteren Schwerpunkt bildet das Themengebiet „Verwaltung von digitalen Identitäten in einer SOA“. Bei der Abwicklung von Geschäftsprozessen spielen digitale Identitäten eine wesentliche Rolle, da sie für die Authentifizierung der involvierten Teilnehmer/Ressourcen benötigt werden und beeinflussen, welche Identität auf einen bestimmten Dienst zugreifen darf. Eine große Herausforderung stellt bei der Nutzung von digitalen Identitäten in organisationsübergreifenden Geschäftsprozessen die Verteilung und Haltung der Identitätsdaten dar. Kapitel 5 stellt daher verschiedene Konzepte vor, die auch in verteilten Systemen eine effiziente und komfortable Identitätsverwaltung ermöglichen. Da letztlich zur Umsetzung geeigneter Sicherheitsmaßnahmen in der Praxis bestimmte Technologien benötigt werden, widmet sich das letzte Kapitel des Kompendiums diesem genannten Thema. Es wird u.a. die Sicherheit von Portalen betrachtet, da sie häufig für Geschäftsprozesse die Kommunikationsschnittstelle zum Kunden bzw. Internetnutzer bilden. Portale müssen umfassend geschützt werden, damit keine Angriffe auf die Dienste stattfinden können, die im Hintergrund die Ausführung der über das Portal initiierten Geschäftsprozesse übernehmen. Daten, die über das Portal übermittelt werden, müssen daher intensiv geprüft und ggf. gefiltert werden. Zusätzlich sollte auch eine Filterung auf Nachrichtenebene, d.h. der Nachrichten im XML-Format stattfinden, bevor die enthaltenen Daten weiterverarbeitet werden. Unter Umständen könnten sich schadhafte Inhalte in der Nachricht befinden, die verschiedene Angriffe ermöglichen. Kapitel 6 zeigt geeignete Filtermethoden auf, die solche nachrichtenbasierten Attacken verhindern. Des Weiteren wird erläutert wie SOA-spezifische Repositories geschützt werden können, sichere Dienstbeschreibungen mit BPEL in der Praxis erstellt werden und welche Tools zur Durchführung von Sicherheitstests in einer SOA verfügbar sind. In Kapitel 6 erfolgt zudem eine Betrachtung von Sicherheitsaspekten REST- basierter Web Services, die in der Praxis neben SOAP-basierten Web Services häufig genutzt werden, aber vergleichsweise deutlich weniger Sicherheitsmöglichkeiten offerieren. Abschließend werden im vorliegenden Kompendium exemplarisch verschiedene Anwendungsszenarien eines Geschäftsprozesses betrachtet, um dem Leser sicherheitsrelevante Prozesse in Service-orientierten Architekturen zu veranschaulichen. Insgesamt verfolgt das SOA-Security-Kompendium das Ziel, durch Beschreibung aktueller SOA-Sicherheitsthemen, IT-Verantwortliche bei der Umsetzung geeigneter Sicherheitsmechanismen innerhalb von SOA zu unterstützen bzw. Hinweise zu geben, dass bekannte Sicherheitsmechanismen auch in SOA ihre Anwendung finden. Da insbesondere auf dem Gebiet der Service-orientiertenArchitekturen die Entwicklung jedoch rasant voranschreitet, sind künftig weitere wichtige bzw. neue Standards, Konzepte und Technologien zu erwarten. Nachfolgend werden daher allgemeine Entwicklungstendenzen aufgezeigt, die sich sowohl aus den momentanen Forschungsbemühungen wissenschaftlicher Einrichtungen als auch aus aktuellen wirtschaftlichen Gegebenheiten und Anforderungen ableiten lassen.
Bundesamt für Sicherheit in der Informationstechnik 319 SOA-Security-Kompendium
8.2 Ausblick
In den vorangegangen Kapiteln wurden unterschiedliche Konzepte und Verfahren vorgestellt, die die Umsetzung einer sicheren und interoperablen SOA ermöglichen. Diese Ansätze schaffen die erste technologische Basis für eine SOA. Allerdings entwickeln sich sowohl SOA-Strategien und deren Umsetzungen weiter als auch die Organisationen und ihre Interaktionen und es gibt neue Anforderungen auf der Seite der Nutzer. Daher werden nachfolgend einige zukünftige und erstrebenswerte Entwicklungen aufgelistet.
Standards konsolidieren Einen Baustein für eine sichere SOA bilden die Spezifikationen, wie sie in Kapitel 4.4 beschrieben wurden. Diese Standards ermöglichen die Einbindung und Nutzung verschiedener Sicherheitskonzepte im Kontext der Web Service Spezifikationen, um eine SOA abzusichern. Allerdings gehen diese Spezifikationen auch mit einer hohen Komplexität einher, was dazu führt, dass standardkonforme Implementierungen nicht zwangsläufig interoperabel sind. Dieses Problem wird allerdings durch die Bemühungen der WS-I (siehe Kapitel 6.6) adressiert, welche durch Profile die Spezifikationen einschränkt und Unklarheiten beseitigt. Während sich die grundlegenden Web Service Spezifikationen etabliert haben und dort keine gravierenden Änderungen zu erwarten sind, wird es bei einigen Spezifikationen in neueren Versionen noch zu Anpassungen kommen. Dies ist insbesondere der Fall, wenn es konkurrierende Standards von unterschiedlichen Organisationen gibt und in neueren Spezifikationen eine Harmonisierung angestrebt wird.
Repositories ausbauen Die gegenwärtige Entwicklung, Geschäftsprozesse zwischen Organisationen immer weiter zu verzahnen, führt dazu, dass die Repositories über die Organisationsgrenzen hinweg verstärkt miteinander zusammenarbeiten und ihre Services untereinander vermitteln. Dies erfordert jedoch eine umfassende Unterstützung der Web Service-Spezifikationen durch die genutzten Frameworks, damit ein Late-Service-Binding realisierbar ist (siehe Kapitel 6.2.4) und sich Clients dynamisch über die Repositories an die Dienste binden können. Zudem ist zu erwarten, dass aufgrund der Notwendigkeit eine wachsende SOA zu steuern und zu kontrollieren, auch die Repositories weitere Aufgaben zur Verwaltung der SOA und damit Teile des SOA Governance (siehe Kapitel 5.1) übernehmen werden.
IT konsolidieren In vielen Organisationen ist es heute noch üblich, dass die IT-Anwendungen, die für die Ausübung der Tätigkeit notwendig sind, sehr stark in den Fachabteilungen verankert sind und von diesen verwaltet und weiterentwickelt werden. Mit der Entwicklung von monolithischen Anwendungslandschaften hin zu einer Service-orientierten Architektur lässt sich vermuten, dass in Zukunft diese Aufgabenverteilung aufgebrochen wird. Die Services könnten dann überwiegend zentral, z.B. durch ein IT-Dienstleistungszentrum der Organisation, verwaltet werden. Hier gilt es Lösungsansätze zu entwickeln, wie mit Services und deren ggf. existierenden SLAs im Rahmen einer IT-Konsolidierung umzugehen ist.
Compliance in SOA durchsetzen Auf Basis der rechtlichen Anforderungen und der steigenden Anzahl interner Policies und Vorgaben ist davon auszugehen, dass das Thema Compliance in Zukunft noch stärker in den Mittelpunkt der strategischen Ausrichtung rückt. Um Compliance zu erreichen, müssen bereits bei der Planung einer SOA die regulatorischen Anforderungen berücksichtigt und die
320 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Tools zur Umsetzung aus SOA Frameworks um Komponenten erweitert werden, die die Einhaltung der Anforderungen verbessern und eine ständige Kontrolle erleichtern. Als Beispiele für solche Anforderungen wäre hier die Gewährleistung der Sicherheit personenbezogener Daten oder die Nachvollziehbarkeit von Transaktionen gemäß BilMoG, KontraG, GdPDU etc. bei der Nutzung von Services zu nennen.
Testmanagement auf SOA-Spezifika ausrichten Die gegenwärtigen Test-Tools, z.B. von der WS-I (siehe Kapitel 6.6.5), erlauben lediglich die Prüfung, ob ein Service entsprechend den Anforderungen umgesetzt wurde. Damit kann allerdings nicht umfassend die Frage beantwortet werden, ob der Service mit anderen innerhalb der Organisation reibungslos zusammenarbeitet. Erschwerend kommt hinzu, dass durch die lose Kopplung der Services nicht alle an einem Prozess beteiligten Service vorab bekannt sind, sondern sie sich unter Umständen erst zur Laufzeit finden. Durch die organisationsübergreifende Verwendung von Services nimmt die Komplexität der Prüfung der Interoperabilität und der Sicherheitsaspekte weiter zu. Daher ist ein vorausschauendes Test Management erforderlich, das alle Aspekte der Prüfung berücksichtigt. Aufgrund dieser Herausforderungen sollte eine Entwicklung von Best Practices und Standards in diesem Bereich angestrebt werden, die den Organisationen verlässliche Vorgaben und Methoden für Tests geben.
Lean Management in einer SOA berücksichtigen Genau wie Lean Management erlaubt auch SOA, Prozesse einer Organisation zu modellieren und zu optimieren. Während das Lean Management vornehmlich aus dem Spezialgebiet der Betriebswirtschaft kommt hat SOA ihren Ursprung in der Software-Architektur. Daher sollten die beiden Ansätze in Zukunft kombiniert werden, um das Prozessmanagement mit der Informationstechnologie zu verknüpfen. Dies erlaubt die gegenseitige Unterstützung, um die Bestrebungen der Organisation nach einer Verbesserung der Effizienz und Qualität sowohl auf der IT-Ebene als auch auf der Geschäftsprozessebene zu fördern.
ITIL/CobiT und SOA verknüpfen Sowohl ITIL, CobiT als auch SOA liegt der Gedanke zugrunde, die Effizienz der IT zu verbessern und sie stärker mit den geschäftlichen Anforderungen zu verzahnen. Daher können sich durch die Einführung einer SOA und Nutzung der ITIL/CobiT Frameworks Synergieeffekte ergeben. Allerdings wird mit der Einführung einer SOA auch die Komplexität der ITIL/ CobiT-Disziplinen erhöht. Daher sollten, vor allem im Bereich des Governance und des Managements, Good Practices erarbeitet werden, um ITIL/ CobiT in einer SOA zu realisieren.
8.3 Forschungsbedarf
Aus der ursprünglichen Idee von SOA, Funktionalität als Dienst verfügbar zu machen, sind im Laufe der Entwicklung eine ganze Reihe neuer Visionen entstanden für die Service- orientierte Architekturen die Basis bilden. Mit den Web Service Spezifikationen und deren Implementierungen in verschiedenen Frameworks und Produkten existiert mittlerweile eine gute technologische Basis. Nichtsdestotrotz ist SOA noch ein junges Architekturparadigma und Unternehmen, Behörden und Regierungsorganisationen stehen erst am Anfang der Möglichkeiten, die es eröffnet. In diesem Kapitel werden verschiedene Visionen und Themen aufgezeigt, in denen SOA als grundlegende Technologie zum Einsatz kommen kann, zusammen mit den Fragen, die es auf dem Weg zu deren Umsetzung noch zu lösen gilt.
Bundesamt für Sicherheit in der Informationstechnik 321 SOA-Security-Kompendium
Eine Vision, die häufig mit der weltweiten Vernetzung und Nutzung von Diensten zwischen Unternehmen, Behörden und Privatpersonen genannt wird, ist das „Internet der Dienste“. Hinter diesem Schlagwort steckt die Idee eines globalen Marktplatzes, auf dem jeder Teilnehmer Dienste anbieten und konsumieren kann. Der Dienst als „Ware“ ist eine Vision, die Unternehmen große Flexibilität in der Planung und Zusammenstellung ihrer Geschäftsprozesse verspricht. Mit einem solchen Marktplatz könnten Unternehmen Dienste aus einem breiten Portfolio auswählen und je nach Bedarf in ihre eigenen Prozesse einbinden, aber auch selbst Dienste anderen Nutzern anbieten. Zunehmend können alle Arten von Geschäftsvorgängen durch Internetdienste repräsentiert werden, womit sich das gesamte Wirtschaftgeschehen ins Netz verlagert. Dafür ist es notwendig, Dienstleistungen im globalen Netz zu finden, zu handeln, zu verhandeln und zu neuen Prozessen zusammenzufügen, welche wiederum als Dienstleistung bereitgestellt werden können.
Dienste global finden Um Dienste zu finden, dienen Spezifikationen wie UDDI und ebXML dazu Dienstbeschreibungen in Verzeichnissen zusammenstellen und zu durchsuchen. Für ein Internet der Dienste bedarf es globaler Repositories, welche von Unternehmen gemeinsam genutzt werden, um Dienste einzustellen und zu suchen. Während dies technisch kein Problem darstellt, so stellt sich doch die Frage nach der Administration dieser Repositories. Ein globales Repository, in dem jeder Dienste einstellen kann, bedarf letztendlich der Verwaltung durch eine einzelne administrative Domain. Dies bedeutet auch, dass alle Parteien Vertrauen in die Verwalter des internetweiten Repositories haben müssen, ein Anspruch der sich zum Beispiel im Falle einer internetweiten Datenbank für digitale Identitäten nicht erfüllt hat. Neben dem Vertrauen stellt sich zudem die Kostenfrage. Die Anforderungen an die Zuverlässigkeit und Sicherheit eines globalen Repositories sind hoch und die Kosten für die Instandhaltung und Wartung der technischen Systeme nicht unerheblich. Demzufolge ist es fraglich, ob sich jemals ein Markt für den Aufbau eines oder mehrerer globaler Repositories bilden wird oder die Forschung nicht eher ein dezentrales Modell zum Suchen und Finden von Diensten hervorbringen wird.
Dienste organisationsübergreifend verhandeln Um Dienste zur Laufzeit zu verhandeln und zu nutzen, bieten die Policy-Spezifikationen eine Reihe von Möglichkeiten, wie im Kapitel Policy Management/Late Service Binding beschrieben. So lassen sich technische Parameter wie die Art der unterstützten Verschlüsselungsalgorithmen zur Laufzeit zwischen Service Provider und Service Consumer festlegen, um somit eine Interoperabilität zur Laufzeit zu garantieren. Jedoch sind die Möglichkeiten der verhandelbaren Parameter auf die durch die Spezifikationen vorgegebenen Parameter beschränkt und beziehen sich auf technische Aspekte hinsichtlich der Nachrichtenabsicherung. Für die weltweite Nutzung von kommerziellen Diensten sind insbesondere auch nicht-technische Dienstparameter, wie Kosten und Nutzungsbedingungen interessant und müssen letztendlich in den Dienstbeschreibungen ausgedrückt werden können. Die Eigenschaft der Selbstbeschreibung von Diensten, welche sich im Moment weitestgehend auf die Funktionen und Sicherheitsanforderungen eines Dienstes beschränkt, muss sich auch auf die Ebene der Geschäftsmodelle und Unternehmenskooperationen beziehen.
Benutzerzentrische Verwaltung von Identitäten Die sichere Nutzung von Diensten setzt die Identifizierung und Authentifizierung des Service-Consumers voraus. Bei der Nutzung von Diensten über Unternehmensgrenzen hinaus – und somit insbesondere im Kontext des Internets der Dienste – stellt sich die Frage nach
322 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium den Vertrauensbeziehungen und der Art des Identitätsmanagements. Wie im Kapitel 6.4 Identitätsmanagement beschrieben, zeigen gerade die offenen Identitätsmodelle durch ihre dezentrale Struktur eine Lösung auf, die auch im Rahmen des Internets der Dienste umsetzbar ist. Hervorzuheben ist hierbei das benutzerzentrische Identitätsmanagement, welches mit der Art und Weise wie wir Identitäten in der realen Welt verwalten, vergleichbar ist. Wie in der realen Welt bestätigen Ausweise den Besitz einer bestimmten Eigenschaft, sei es das Alter, der Name oder die Zugehörigkeit zu einer bestimmten Gruppe. Dabei können diese Ausweise von unterschiedlichen ausstellenden Stellen stammen. Kennzeichnend ist, dass diese ausstellenden Stellen im allgemeinen eine unterschiedliche Glaubwürdigkeit aufweisen. Je nach Sicherheitsanforderung der abhängigen Partei kann ein bestimmter Ausweis ausreichend sein oder nicht. Wie auch im realen Leben, setzen sichere digitale Identitäten eine vertrauenswürdige Institution voraus, welche die in der digitalen Identität gespeicherten Informationen überprüft hat, bevor sie diese in Form eines Tokens bescheinigt. Bei einer globalen Bereitstellung und Nutzung von Diensten stellt sich allerdings die Frage, welche Institutionen von einem Dienst als vertrauenswürdig eingestuft werden können und wie dieses Vertrauen etabliert werden kann, wie im Kapitel 6.3 Trust-Management beschrieben. Bei einer Nutzung von Diensten im Kontext des Internets der Dienste werden Reputationsverfahren zur Bewertung von Diensten und Institutionen ein wichtiger Aspekt sein, deren Anwendung im Rahmen der Web Service-Technologien noch Gegenstand der Forschung sind. Eine weitere Möglichkeit ist die Bereitstellung einer staatlichen vertrauenswürdigen Instanz. Um dies umzusetzen gibt es eine Reihe von Länderinitiativen für eine Einführung einer elektronischen ID-Karte, auf deren Basis eine sichere und eindeutige Identifizierung im Netz möglich wird, um so zum Beispiel Onlinetransaktionen sicherer zu machen. Für SOA stellt sich hier insbesondere die Frage wie die neuen Technologien mit SOA integriert werden können, um eine sichere Identifizierung von Service-Consumern zu erreichen. Des Weiteren muss die abhängige Partei in der Lage sein Identitätsinformationen in geeigneter Weise bewerten zu können. Während wir in der realen Welt beispielsweise relativ leicht einen Studentenausweis als solchen erkennen können, stellt sich die Frage, ob und wie dies auch in der digitalen Welt möglich ist. Semantische Technologien und Metainformationen, die mit den Sicherheitstoken übertragen werden, können beispielsweise helfen hier eine Bewertung zu erlauben.
Sichere Komposition von Diensten Dienste in einer SOA weisen die Grundeigenschaft auf, dass diese selbstbeschreibend und komponierbar sind. Im Kontext des Internets der Dienste ist die Idee, dass Dienste einfach über Organisationsgrenzen hinaus angeboten und zusammengestellt werden können. Beispielweise könnte ein Online-Shop einen Bestelldienst anbieten, der als ein zusammengesetzter Dienst verschiedene Diente von anderen Anbietern orchestriert. Dies stellt jedoch auch neue Herausforderungen an die Beschreibung der Sicherheitsanforderungen. Beispielsweise könnte ein Bestelldienst fordern, dass eine Nachricht vom Kunden und vom Zwischenhändler signiert werden muss. Die Beschreibung der Anforderung hinsichtlich der Einbettung der Identität des Aufrufers und der mehrfachen Signatur von Nachrichten durch verschiedenen Instanzen ist technisch zwar abbildbar und durch WS-Security Policy beschreibbar, erlaubt aber noch kein automatisiertes Binden und Verwenden in einer unternehmensübergreifenden Dienstkomposition. Zudem müssen die Sicherheitsanforderungen der orchestrierten Dienste aggregiert und durch die Dienstkomposition weitergegeben werden. Verlangt beispielsweise der Bestelldienst ein signiertes und verschlüsseltes Token mit einer Kreditkartennummer, dann muss die
Bundesamt für Sicherheit in der Informationstechnik 323 SOA-Security-Kompendium
Dienstkomposition diese Anforderung in ihrer Sicherheitspolicy mit aufnehmen und das Token beim Aufruf der Dienstkomposition an den orchestrierten Dienst weitergeben. Dies wird von den gängigen Frameworks noch nicht unterstützt. Eine weitere Vision, die in verschiedenen Facetten Gegenstand der aktuellen Forschung ist, ist das „Internet der Dinge“. Unter diesem Schlagwort wird die Nutzung und Integration von Service-orientierten Architekturen mit allgegenwärtigen, in Gegenstände und die Umgebung eingebetteten Computern bezeichnet. Die Eigenschaft der Plattformunabhängigkeit von Service-orientierten Architekturen erlaubt eine relativ leichte Integration von mobilen Geräten und eröffnet gerade in diesem Bereich eine Vielzahl von Möglichkeiten – von Überwachungsszenarien im e-Health Bereich bis hin zu der Verknüpfung von Geschäftsvorgängen, die in der realen Welt ablaufen mit den Online-Systemen im Hintergrund, die die Geschäftslogik enthalten. Hier ergeben sich neue Herausforderungen vor allem aus der Ressourcenbeschränktheit eingebetteter Systeme. Für die sichere Verschlüsselung von Daten, werden beispielsweise neue, ressourcensparende kryptographische Verfahren benötigt. Ein weiterer Aspekt stellt die sichere Identifizierung der Komponenten und der Benutzer dar, um einen Missbrauch der Systeme auszuschließen. Auch hier werden Verfahren zur ressourceneffizienten und zuverlässigen Zugriffskontrolle auf die Funktionen der eingebetteten Komponente benötigt.
324 Bundesamt für Sicherheit in der Informationstechnik SOA-Security-Kompendium
Anhang
Übersicht über die Standards
Tabelle 18 fasst die im Kapitel 4 verwendeten Standards zusammen. Für jeden Standard werden die Organisation, Status, Version, Veröffentlichungsdatum, die getroffene Empfehlung aus dem Kapitel und ein Verweis auf die Spezifikation aufgelistet.
Bundesamt für Sicherheit in der Informationstechnik 325 Anhang
Veröffent- Empfehlung zur Standard Organisation Status Version Spezifikation lichung Anwendung
W3C XML W3C 1.0 26.11.08 Empfohlen http://www.w3.org/TR/REC-xml/ Recommendation
W3C SOAP W3C 1.2 27.04.07 Empfohlen http://www.w3.org/TR/soap12-part1/ Recommendation
http://www.w3.org/TR/SOAP- SOAP with Attachments W3C W3C Note 1.0 11.12.00 Nicht Empfohlen attachments
W3C MTOM W3C 1.0 25.01.05 Empfohlen http://www.w3.org/TR/soap12-mtom/ Recommendation
W3C WSDL W3C 2.0 26.06.07 Empfohlen http://www.w3.org/TR/wsdl20/ Recommendation
UDDI Spec UDDI OASIS Technical 3.0.2 19.10.04 Empfohlen http://uddi.org/pubs/uddi_v3.htm Committee Draft
IBM und http://www.ibm.com/developerworks/lib WS-Inspection Draft 1.0 01.10.01 Angeregt Microsoft rary/specification/ws-wsilspec/
Microsoft, BEA, http://specs.xmlsoap.org/ws/2005/04/dis WS-Discovery Canon, Intel und --- 01.04.05 Angeregt covery/ws-discovery.pdf webMethods
W3C WS-Policy W3C 1.5 04.09.07 Empfohlen http://www.w3.org/TR/ws-policy/ Recommendation
326 Bundesamt für Sicherheit in der Informationstechnik Anhang
Veröffent- Empfehlung zur Standard Organisation Status Version Spezifikation lichung Anwendung
BEA, IBM, http://xml.coverpages.org/ws- WS-PolicyAssertions Microsoft und Public Draft 1.1 28.05.03 Empfohlen policyassertionsV11.pdf SAP
W3C WS-PolicyAttachments W3C 1.5 04.09.07 Empfohlen http://www.w3.org/TR/ws-policy-attach/ Recommendation
BEA, Computer Associates http://download.boulder.ibm.com/ibmdl/ International, WS-MetaDataExchange Public Draft 1.1 01.08.06 Empfohlen pub/software/dw/specs/ws- IBM, SAP, Sun mex/metadataexchange.pdf Microsystems und webMethods
W3C XML-Encryption W3C 1.0 10.12.02 Empfohlen http://www.w3.org/TR/xmlenc-core/ Recommendation
XML-Signature (Second W3C W3C 1.0 10.06.08 Empfohlen http://www.w3.org/TR/xmldsig-core/ Edition) Recommendation
http://docs.oasis-open.org/security/saml/ SAML OASIS OASIS Standard 2.0 15.03.05 Empfohlen v2.0/saml-2.0-os.zip
http://docs.oasis- XACML OASIS OASIS Standard 2.0 01.02.05 Empfohlen open.org/xacml/2.0/access_control- xacml-2.0-core-spec-os.pdf
327 Bundesamt für Sicherheit in der Informationstechnik Anhang
Veröffent- Empfehlung zur Standard Organisation Status Version Spezifikation lichung Anwendung
http://www.oasis- SPML OASIS OASIS Standard 2.0 01.04.06 Angeregt open.org/committees/download.php/177 08/pstc-spml-2.0-os.zip
XKMS W3C W3C Note 1.0 30.03.01 Empfohlen http://www.w3.org/TR/xkms/
http://www.oasis- open.org/committees/download.php/167 WS-Security OASIS OASIS Standard 1.1 01.02.06 Empfohlen 90/wss-v1.1-spec-os- SOAPMessageSecurity.pdf
http://docs.oasis-open.org/ws-sx/ws- WS-SecurityPolicy OASIS Committee Draft 1.2 04.12.06 Empfohlen securitypolicy/200512/ws- securitypolicy-1.2-spec-cd-01.pdf
http://docs.oasis-open.org/ws-sx/ws- WS-Trust OASIS OASIS Standard 1.3 19.03.07 Empfohlen trust/200512/ws-trust-1.3-os.html
http://docs.oasis-open.org/ws-sx/ws- WS-SecureConversation OASIS OASIS Standard 1.3 01.03.07 Empfohlen secureconversation/200512/ws- secureconversation-1.3-os.html
BEA Systems, BMC Software, http://download.boulder.ibm.com/ibmdl/ CA, IBM, Layer 7 pub/software/dw/specs/ws-fed/WS- WS-Federation Public Draft 1.1 01.12.06 Empfohlen Technologies, Federation-V1-1B.pdf? Microsoft, Novell S_TACT=105AGX04&S_CMP=LP und VeriSign
328 Bundesamt für Sicherheit in der Informationstechnik Anhang
Veröffent- Empfehlung zur Standard Organisation Status Version Spezifikation lichung Anwendung
W3C http://www.w3.org/TR/2006/REC-ws- WS-Addressing W3C 1.0 09.05.06 Empfohlen Recommendation addr-core-20060509/
W3C Working http://www.w3.org/TR/2009/WD-ws- WS-Eventing W3C 17.03.09 Beobachten Draft eventing-20090317/
http://www.oasis- WS-Notification OASIS OASIS Standard 1.3 01.10.06 Beobachten open.org/committees/tc_home.php? wg_abbrev=wsn
http://msdn.microsoft.com/de-de/library/ WS-Routing Microsoft --- 16.10.01 Nicht Empfohlen ms951272(en-us).aspx
http://docs.oasis-open.org/wsrm/ws- WS-Reliability OASIS OASIS Standard 1.1 15.11.04 Beobachten reliability/v1.1/wsrm-ws_reliability-1.1- spec-os.pdf
http://docs.oasis-open.org/ws- WS-ReliableMessaging OASIS OASIS Standard 1.1 14.06.07 Empfohlen rx/wsrm/200702/wsrm-1.1-spec-os- 01.pdf
http://docs.oasis-open.org/ws-tx/wstx- WS-Coordination OASIS OASIS Standard 1.2 02.02.09 Empfohlen wscoor-1.2-spec.pdf
http://docs.oasis-open.org/ws-tx/wstx- WS-AtomicTransaction OASIS OASIS Standard 1.2 02.02.09 Empfohlen wsat-1.2-spec-os.pdf
329 Bundesamt für Sicherheit in der Informationstechnik Anhang
Veröffent- Empfehlung zur Standard Organisation Status Version Spezifikation lichung Anwendung
http://docs.oasis-open.org/ws-tx/wstx- WS-BusinessActivity OASIS OASIS Standard 1.2 02.02.09 Empfohlen wsba-1.2-spec.pdf
http://xml.coverpages.org/WSFL-Guide- WSFL IBM --- 1.0 01.05.01 Beobachten 200110.pdf
http://docs.oasis- BPEL OASIS OASIS Standard 2.0 11.04.07 Empfohlen open.org/wsbpel/2.0/OS/wsbpel-v2.0- OS.html
W3C Candidate WS-CDL W3C 1.0 09.11.05 Angeregt http://www.w3.org/TR/ws-cdl-10/ Recommendation
http://docs.oasis- ebXML Registry OASIS OASIS Standard 3.0 02.05.05 Beobachten open.org/regrep/v3.0/regrep-3.0-os.zip
Committee Draft http://docs.oasis-open.org/wsrf/wsrf- WS-ResourceFramework OASIS 1.2 23.05.06 Empfohlen 02 primer-1.2-primer-cd-02.pdf
330 Bundesamt für Sicherheit in der Informationstechnik Anhang
Veröffent- Empfehlung zur Standard Organisation Status Version Spezifikation lichung Anwendung
BEA Systems, Cape Clear Software, IBM, Interface21, IONA Technologies, Oracle, Primeton Technologies, http://www.osoa.org/download/attachme SCA Progress Software, 1.0 15.03.07 Beobachten nts/35/SCA_AssemblyModel_V100.pdf Red Hat, Rogue Wave Software, SAP, Siemens, Software AG, Sun Microsystems, Sybase, TIBCO Software
Tabelle 18: Übersicht über die beschriebenen Standards
331 Bundesamt für Sicherheit in der Informationstechnik Anhang
8.4 Code-Beispiele
Die nachfolgenden Code-Beispiele dienen als Unterstützung für das bessere Verständnis der im Kompendium beschriebenen Standards. Allerdings haben die Code-Beispiele keinen Anspruch auf Vollständigkeit und Anwendbarkeit.
XML Das folgende Beispiel zeigt ein einfaches Verzeichnis mit XML:
SOAP Das folgende Code-Beispiel zeigt den Aufbau einer SOAP Nachricht. Es sei an dieser Stelle nochmals darauf hingewiesen, dass der Header optional ist.
SwA Das folgende Beispiel zeigt eine SOAP Nachricht mit einem Anhang. Es ist darin exemplarisch zu sehen, wie der Anhang innerhalb der SOAP Nachricht mit Hilfe von MIME beschrieben wird.
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
332 Bundesamt für Sicherheit in der Informationstechnik Anhang start="
--MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID:
--MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: binary Content-ID:
--MIME_boundary— […]
MTOM Das nachfolgende Code-Beispiel [MTOM] zeigt, wie eine Binärdatei mit Hilfe von MTOM als MIME-Attachment versendet wird.
Content-Type: multipart/related boundary=MIMEBoundary4A7AE55984E7438034; type="application/xop+xml"; start="<[email protected]>"; start-info="text/xml; charset=utf-8"
--MIMEBoundary4A7AE55984E7438034 content-type: application/xop+xml; charset=utf-8; type="application/soap+xml;" content-transfer-encoding: binary content-id: <[email protected]>
Bundesamt für Sicherheit in der Informationstechnik 333 Anhang
... --MIMEBoundary4A7AE55984E7438034 content-type: application/octet-stream content-transfer-encoding: binary content-id: <[email protected]>
Binary Data..... --MIMEBoundary4A7AE55984E7438034—
WSDL Das nachfolgende Code-Beispiel zeigt exemplarisch den Aufbau einer WSDL-Beschreibung. In diesem Fall werden Auszüge einer WSDL-Beschreibung zum Buchen eines Fluges beschrieben.
334 Bundesamt für Sicherheit in der Informationstechnik Anhang UDDI Das folgende einfache Code-Beispiel [UDDI] zeigt einen kleinen Eintrag in einem UDDI- Verzeichnis. Ein umfassendes, leicht abgewandeltes Beispiel für einen Microsoft-Eintrag ist unter http://www.xmlmodeling.com/models/uddi/article/BusinessDetail.xml zu finden. Bundesamt für Sicherheit in der Informationstechnik 335 Anhang WS - Inspection Das folgende Beispiel zeigt ein einfaches WS-Inspection-Dokument für einen Services, der Aktienkursinformationen zur Verfügung stellt. Der Service hat ein korrespondierendes, über http zugängliches WSDL-Dokument, welches wiederum die Schnittstelle beschreibt. WS- Discovery Das folgende Code-Beispiel [WS-Dis] zeigt eine Anfragenachricht (Probe) eines Clients, der einen Drucker sucht. Eine solche Nachricht wird versendet, sobald ein Service gesucht wird. In diesem Beispiel deutet das 336 Bundesamt für Sicherheit in der Informationstechnik Anhang Das folgende Code Beispiel zeigt eine WS-Policy mit dem WS-Security Namespace. In diesem Beispiel repräsentiert die erste Alternative eine Signatur einer Nachricht. Die zweite Alternative repräsentiert die Verschlüsselung der Nachricht. Dabei wird das WS -PolicyAssertion Das folgende Beispiel zeigt die mit WS-PolicyAssertion beschriebenen Policy-Aussagen für die Festlegung der Textkodierung, der Sprache, einer spezifischen Version die genutzt werden soll (in diesem Fall SOAP 1.1) und der Anforderung, dass ein Security Header vorliegen muss. Bundesamt für Sicherheit in der Informationstechnik 337 Anhang WS -PolicyAttachment Das folgende Beispiel zeigt einen Auszug einer Eingliederung eines externen Anhangs. WS -MetatdataExchange Das folgende Beispiel zeigt eine “GetMetaData”-Anfrage einer anderen Ressource. XML- Encryption Im folgenden Code-Beispiel [XENC]werden die sensiblen Kredikarteninformationen von John Smith verschlüsselt, um sie vertraulich zu übertragen. 338 Bundesamt für Sicherheit in der Informationstechnik Anhang Original Dokument: Verschlüsseltes Dokument (Verschlüsselung eines Elementes): XML- Signature Das Code-Beispiel zeigt den Einsatz von XML-Signature bei einer Enveloped Signature. Bundesamt für Sicherheit in der Informationstechnik 339 Anhang SAML Das nachfolgende Code-Beispiel [SAML] zeigt eine Assertion mit einem Authentication Statement. Das SPML Nachfolgend werden zwei Listings aus dem Standard dargestellt, die beispielhaft eine Modifikations- und Passwortoperation veranschaulichen sollen. 340 Bundesamt für Sicherheit in der Informationstechnik Anhang Änderung einer E-Mail Adresse: Passwort neu setzen: XKMS XKMS Anfrage XKMS Antwort WS - Security Das folgende Beispiel zeigt die Anwendung eines Security-Token und einer Signatur. Bundesamt für Sicherheit in der Informationstechnik 341 Anhang WS -SecurityPolicy Das folgende Beispiel zeigt die Nutzung einer SymmetricBinding Assertion, welche eine Token Assertion enthält und fordert, dass beide kommunizierenden Parteien die Web Service-Nachrichten mit einem Kerberos-Token absichern müssen. Zudem schreiben die Assertions SignedParts und EncryptedParts vor, dass die Header und der Body einer SOAP Nachricht signiert und verschlüsselt werden müssen. 342 Bundesamt für Sicherheit in der Informationstechnik Anhang WS- Trust Das folgende Beispiel zeigt eine Anfrage (RST) an einen Security Token Service (STS), um ein SAML-Token anzufordern. WS - Federation Das folgende Code-Beispiel [WS-Fed] zeigt ein Federation Metadata-Dokument, das Teilnehmer in drei Federations identifiziert. Bundesamt für Sicherheit in der Informationstechnik 343 Anhang WS - Addressing Das folgende Beispiel zeigt einen typischen Transfer request zum Abrufen von Metadaten über einen Web Service Endpunkt: (01) 344 Bundesamt für Sicherheit in der Informationstechnik Anhang (12) (13) (14) Folgendes Beispiel veranschaulicht den Mechanismus in einer SOAP 1.2 Nachricht (01) Zeile (02) bis (09) zeigen den Header der SOAP Nachricht in dem der soeben beschriebene Mechanismus verwendet wird. In Zeile (02) wird der Identifier für die Nachricht spezifiziert und in Zeile (04) bis (06) der Referenz Endpunkt. Zeile (03) bis (08) bilden den message addressing header Block. In Zeile (07) wird die URI des Empfängers der Nachricht definiert. Zeile (08) definiert eine Aktions URI um die zu erwartende Semantik zu identifizieren. Der Body wird in Zeile (10) bis (12) beschrieben. WS- Eventing Das folgende Beispiel zeigt eine Anfrage zur Erstellung einer Subscription. Zur Registrierung an einer Eventquelle sendet eine Applikation eine Subscription-Nachricht in folgender Form: (01) Bundesamt für Sicherheit in der Informationstechnik 345 Anhang (12) In Zeile (04) wird im Nachrichtenheader der Action URI der Wert http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe zugewiesen und der subscribe Vorgang eingeleitet. Daraufhin wird im Body (10) durch die Applikation der Senke wse:Delivery eine URI zugewiesen. Optional ist es möglich, durch wse:Expires und wse:EndTo auf einen optionalen Endzeitpunkt zu referenzieren. Zudem besteht die möglich mit wse:Filter einen Filter zu definieren. Ressourcen (WS-Resource) werden erzeugt sobald sich Subscriber bei einem NotificationProducer registrieren. Die Spezifikationen WS-Resource oder WS-ResourceLifetime werden für das Management von Ressourcen benötigt, um die Verwaltung der Lebenszeit von Subkriptionsressourcen zu ermöglichen. Beispiel 2 beschreibt die Rückantwort auf eine Subscriptions Anfrage: (01) Die Eventquelle sendet als Antwort auf die Subscriptions Anfrage (03)-(05) die Action URI http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscribeResponse. Der Body (11)-(12) zeigt eine Endpunkt-Referenz des SubscriptionManagers sowie die zu setzende Laufzeit. WS-Routing Ein Code-Beispiel ist bereit im Kapitel „WS-Routing“ enthalten. WS - Reliability Das Beispiel zeigt eine Anfrage, in welche die WS-Reliability Elemente eingebettet wurden. 346 Bundesamt für Sicherheit in der Informationstechnik Anhang WS -ReliableMessaging Das folgende Code Beispiel [WS-RelMes] zeigt die Integration von ReliableMessaging Policy Assertions in eine WS-Policy. Bundesamt für Sicherheit in der Informationstechnik 347 Anhang WSFL Das folgende Code Beispiel zeigt den Aufbau der beschriebenen Modelle: Flow Model Global Model 348 Bundesamt für Sicherheit in der Informationstechnik Anhang BPEL Das nachfolgende Code-Beispiel [BPEL] zeigt in Auszügen einen Prozess zur Kreditgewährung. Bundesamt für Sicherheit in der Informationstechnik 349 Anhang 350 Bundesamt für Sicherheit in der Informationstechnik Anhang CAP Code Struktur SCA Das folgende Beispiel zeigt die Konfiguration einer Beispielanwendung mit der Service Component Architecture. Als Grundlage für das Beispiel dient der bereits in Kapitel 2.3 auf Seite 16 eingeführte Geschäftsprozess Bestellung bei einem Buchhändler. Die dort gezeigte Clientanwendung, das Portal, könnte beispielsweise durch JavaServerPages realisiert sein und den Dienst Auftragsabwicklung aufrufen, welcher von einer SCA Komponente Auftrag Component bereitgestellt wird. Die Komponentenimplementierung könnte durch einen BPEL-Prozess realisiert sein, welche Referenzen auf die einzelnen Services Auftragsdaten überprüfen und Versenden enthält. Der Service Auftragsdaten überprüfen verwendet wiederum den Service Kreditkartendaten validieren. Da die Services Auftragsdaten überprüfen und Versenden Teil des selben Composites sind wie die BPEL Komponente, kann die Kommunikation hier über ein domänenspezifisches Protokoll erfolgen. Sind beide Komponenten beispielsweise durch eine Java-Klasse implementiert, dann könnte der Aufruf hier direkt über das Java-Interface erfolgen. Bundesamt für Sicherheit in der Informationstechnik 351 Anhang Für die Kommunikation mit dem Service Kreditkartendaten validieren, welcher durch einen externen Partner bereitgestellt wird, wären hingegen Web Service-Technologien das Mittel der Wahl, die durch ein entsprechendes Binding konfiguriert werden können. Das folgende XML Fragment zeigt das Beispiel in der Service Component Description Language: 352 Bundesamt für Sicherheit in der Informationstechnik Anhang Abkürzungsverzeichnis Abkürzung Beschreibung 2PC Two-Phase Commit ACID Atomar, Konsistent, Isoliert und Dauerhaft ACL Access Control List AIEE American Institute of Electrical Engineers B2B Business-to-Business B2C Business-to-Consumer BDSG Bundesdatenschutzgesetz BPEL Business Process Execution Language BPEL4WS Business Process Execution Language For Web Services BPML Business Process Modeling Language BPMN Business Process Modeling Notation BSI Bundesamt für Sicherheit in der Informationstechnik CA Zertifizierungsstelle (Certificate Authority) CAP Collaboration Agreement Protocol CISO Chief Information Security Officer COBIT Control Objectives for Information and Related Technology Corp. Corporation CPP Collaboration Protocol Profile CPPA ebXML Collaborative Partner Profile Agreement DMZ Demilitarized Zone DTD Document Type Definition EAI Enterprise Application Integration ebXML Electronic Business using XML EPR Endpoint Reference ESB Enterprise Service Bus ERP Enterprise Resource Planning FDML Flow Definition Markup Language FTP File Transfer Protocol G2C Government-to-Consumer GRC Governance, Risk & Compliance Bundesamt für Sicherheit in der Informationstechnik 353 Anhang Abkürzung Beschreibung GUID Globally Unique Identifier GXA Global XML Web Services Architecture HR-System Personalsystem (Human Resources System) HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol HTTPS HyperText Transfer Protocol Secure IBM International Business Machines Corporation ID Identität ID-FF Liberty Identity Federation Framework ID-WSF Liberty Identity Web Services Framework IEEE Institute of Electrical and Electronics Engineers IP Internetprotokoll ISO International Standard Organisation IT Informationstechnik ITU International Telecommunication Union J2EE Java 2 Platform, Enterprise Edition JTC1 Joint Technical Committee 1 KPI Key Performance Indikator LDAP Lightweight Directory Access Protocol MEP Message Exchange Pattern MIME Multipurpose Internet Mail Extensions MSN Microsoft Network MTOM Message Transmission Optimization Mechanism NIST National Institute of Standards and Technology OASIS Organization for the Advancement of Structured Information Standards OGSA Open Grid Services Architecture OGSI Open Grid Services Infrastructure PAP Policy Adminstration Point PDCA Plan-Do-Check-Act PDP Policy Decision Point PEP Policy Enforcement Point PIP Policy Information Point PKI Public-Key-Infrastruktur 354 Bundesamt für Sicherheit in der Informationstechnik Anhang Abkürzung Beschreibung PSO Provisioning Service Object PSP Provisioning Service Provider PST Provisioning Service Target RA Requesting Authority REL Rights Expression Language RIM ebXML Registry Information Model ROI Return on Investment RPC Entfernter Funktionsaufruf (Remote Procedure Call) RS ebXML Registry Services Specification RST Request for Security Token RSTR Request for Security Token Response RUP Rational Unified Process SAML Security Assertion Markup Language SCA Service Component Architecture SCDL Service Component Definition Language SDO Standards Development Organization SGML Standard Generalized Markup Language SLA Service Level Agreement SMTP Simple Mail Transfer Protocol SOA Service-orientierte Architektur SOAP ursprünglich Simple Object Access Protocol SOX Sarbanes-Oxley Act of 2002 SPML Service Provisioning Markup Language SSL Secure Sockets Layer SSO Single Sign-on STS Security Token Service SwA SOAP Messages with Attachments SwA SOAP with Attachments TLS Transport Layer Security TMG Telemediengesetz UDDI Universal Discovery Description and Integration UML Unified Modeling Language Bundesamt für Sicherheit in der Informationstechnik 355 Anhang Abkürzung Beschreibung UN/CEFACT United Nations Center For Trade Facilitation And Electronic Business UN/ECE United Nations Economic Commission for Europe URI Uniform Resource Identifier URL Uniform Resource Locator UTF Unicode Transformation Format W3C World Wide Web Consortium WCF Windows Communication Foundation WS Web Service WS-CDL Web Services Choreography Description Language WS-I Web Services Interoperability Organization WS-I BP WS-I Basic Profile WS-I BSP WS-I Basic Security Profile WS-I SSBP WS-I Simple SOAP Binding Profile WS-RM WS-ReliableMessaging WSDL Web Service Description Language WSFL Web Services Flow Language WSIL Web Services Inspection Language WSN WS-Notification WSRF WS-ResourceFramework X-KISS XML Key Information Service Specification X-KRSS XML Key Registration Service Specification XACML eXtensible Access Control Markup Language XKMS XML Key Management Specification XLANG XML Language XML eXtensible Markup Language XOP XML Binary Optimized Packaging XPath XML Path Language XPDL XML Process Definition Language XSD XML Schema Definition XSLT Extensible Stylesheet Language Transformation SQL Structured Query Language XXE XML External Entity Attacks 356 Bundesamt für Sicherheit in der Informationstechnik Anhang Glossar Das Glossar listet und erklärt Fachbegriffe, die in den unterschiedlichen Kapiteln verwendet werden. Dabei sind die im Kapitel „Technologien und Standards“ beschrieben Spezifikationen nicht enthalten. Für die Standards gibt es sowohl eine tabellarische Übersicht (siehe Übersicht über die Standards) als auch die Beschreibung im Kapitel selbst. Begriff Beschreibung ACL Access Control List. Methode zur Darstellung von Zugriffsrechten auf Ressourcen Administrative Technisch und geschäftlich eigenständig und unabhängig verwalteter Domäne Bereich innerhalb einer Organisation AIEE American Institute of Electrical Engineers. Verband der amerikanischen Elektroingenieure, der von 1884 bis 1963 existierte. Akteur/Actor Teilnehmer in einer SOAP-basierten Kommunikation – dies kann sowohl ein Endpunkt als auch ein Intermediär sein, der über eine URI erreichbar ist und unter der er SOAP Nachrichten entgegennimmt. Menschliche Benutzer oder Browser sind keine Akteure. 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. Assertions Bezeichnet allgemein Aussagen über eine bestimmte Eigenschaft einer Entität (Dienst/Client/Benutzer) Awareness Sicherheitsbewusstsein B2B Business-to-Business. Beziehung zwischen zwei Unternehmen B2C Business-to-Consumer. Beziehung zwischen Unternehmen und Konsument B2G Business-to-Government. Beziehung zwischen Unternehmen und öffentlicher Verwaltung BPEL Siehe WS-BPEL BPEL4WS Business Process Execution Language for Web-Services. BPEL4WS ist der Vorgänger von WS-BPEL. Bundesamt für Sicherheit in der Informationstechnik 357 Anhang Begriff Beschreibung BPM 1. Business Process Management (Geschäftsprozessverwaltung). Ziel des BPM ist die Möglichkeit Geschäftsprozesse auf einem hohen Abstraktionsgrad zu identifizieren, definieren, modellieren und zu verifizieren. Zudem umfasst das BPM die Durchführung sowie das Management und die Überwachung von Prozessen. 2. Business Process Modeling (Geschäftsprozessmodellierung). Die Geschäftsprozessmodellierung ist ein Aspekt der Geschäftsprozessverwaltung und befasst sich mit der Modellierung und Darstellung von Geschäftsprozessen. BPM Business Process Management. BPM bietet die Möglichkeit Geschäftsprozesse auf einem hohen Abstraktionsgrad zu definieren sowie die Fähigkeit, Prozesse zu managen und zu überwachen. BPML Business Process Modeling Language. BPML ist ein Vorschlage für eine XML-basierte Metasprache zur Beschreibung von Geschäftsprozessen, die allerdings zu Gunsten von BPEL keine Unterstützung fand. BPMN Business Process Modeling Notation. BPMN ist eine grafische Spezifikationssprache zur Modellierung von Geschäftsprozessen und Arbeitsabläufen. Brute-Force Systematisches Ausprobieren sämtlicher Buchstaben- und Zahlenkombinationen Buffer Overflow Beim Buffer Overflow (Pufferüberlauf) wird eine zu große Datenmenge in einen reservierten Speicherbereich geschrieben, wodurch die Informationen in anderen Speicherbereichen überschrieben werden. CA Certificate Authority. Eine CA ist eine Organisation, die digitale Zertifikate herausgibt. CDL4WS Choreography Definition Language for Web-Services ist der Vorläufer von BPEL. Circle Of Trust Zusammenschluss verschiedener Partner basierend auf der Liberty Architektur und operationalen Vereinbarungen, die die Vertrauensbeziehung zwischen den Partnern manifestieren. CISO Chief Information Security Officer. Verantwortlicher für die Informationssicherheit in einer Organisation. Claim Zu verifizierende Aussage über ein Subjekt, die dieses Subjekt über sich selbst macht oder die von einer dritten Partei über dieses Subjekt gemacht wird. COBIT Control Objectives for Information and Related Technology. COBIT ist ein internationales Framework zur IT-Governance. Compliance Compliance umfasst die Einhaltung der Richtlinien, Organisationsziele, Regeln und Leitlinien denen die Geschäftsprozesse, Services und Anwendungen unterworfen sind. 358 Bundesamt für Sicherheit in der Informationstechnik Anhang Begriff Beschreibung Composite Als Composite werden zu einer größeren Einheit zusammengefasste Komponenten bezeichnet. CORBA Common Object Request Broker Architecture. CORBA ist eine Architektur zur Verwaltung von und Vermittlung zwischen über mehrere Systeme verteilten Objekten. CPP Collaboration Protocol Profile. Dokument das die Fähigkeiten einer Organisation im XML-Format beschreibt. CPPA ebXML Collaborative Partner Profile Agreement. Standard zur Konfiguration und zum Austausch von technischen Kommunikationskontrakten (Partner Profile) zwischen Geschäftspartnern. Credential Ein Credential ist ein Identifikations- und Berechtigungsnachweis, mit dem ein Subjekt nachweisen kann, dass es auf bestimmte Informationen oder Ressourcen zugreifen oder bestimmte Aktionen ausführen darf. Denial of Service Angriff auf Systeme, um deren Funktionsweise zu verlangsamen oder schlimmstenfalls einen kompletten Ausfall hervorzurufen. 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. Dienst Siehe Service. Digitale Identität Konkrete, abgeschlossene Menge von Attributen (Claims), welche eine Person oder Entität der realen Welt in der Online-Welt repräsentiert DMZ Demilitarized Zone. DMZ bezeichnet einen Netzwerkbereich zwischen dem internen Netzwerk und dem Internet, der im Allgemeinen durch Firewalls abgetrennt ist und für deren Systeme strenge Zugriffskontrollregeln definiert sind, um das interne Netz zu schützen DTD Document Type Definition. Mit den DTDs werden Regeln definiert, die festlegen, welche Elemente und Attribute in einem XML-Dokument verwendet werden dürfen. Endpoints Zugangspunkte, über die Services erreicht werden können. Enterprise Enterprise Application Integration (EAI) ist ein Konzept zur Application unternehmensweiten Integration der Geschäftsfunktionen entlang der Integration Wertschöpfungskette, die über verschiedene Applikationen auf unterschiedlichen Plattformen verteilt sind, und die im Sinne der Daten- und Geschäftsprozessintegration verbunden werden können. Bundesamt für Sicherheit in der Informationstechnik 359 Anhang Begriff Beschreibung Enterprise Service Der Begriff des ESB beschreibt eine Kommunikationsinfrastruktur, welche Bus den nachrichtenbasierten Informationsaustausch der Services steuert. ESBs bieten üblicherweise Unterstützung für den Dienstaufruf, die Nachrichtenverarbeitung, Transformation sowie das Routing, die Dienstorchestrierung und die Choreographie. Da der Begriff ESB allerdings ist nicht eindeutig definiert ist, sind diese Eigenschaften auch nicht allgemeingültig festgelegt. ERP Enterprise Resource Planning. Software zur Steuerung und Auswertung betriebswirtschaftlicher Abläufe FDL Flow Definition Markup Language. Ein IBM-Format das für die Beschreibung von Geschäftsprozessen in WebSphere Application Server genutzt wird. Federation Verbund von verschiedenen Sicherheitsdomänen mit dem Ziel der gemeinsamen Nutzung von Identitätsdaten Framework Programmiergerüst um die Entwicklung einer Anwendung zu vereinfachen. FTP File Transfer Protocol. Ein Standardprotokoll zum Austausch von Dateien über TCP/IP-basierte Netzwerke. Governance Governance befasst sich allgemein mit übergeordneten Organisationsstrukturen und notwendigen Mechanismen zur Steuerung und Regelung der Organisation. GUID Globally Unique Identifier. Ein GUID ist eine global eindeutige Zahl mit 128 Bit, die in verteilten Systemen zum Einsatz kommt. Z.B. {936DA01F- 9ABD-4d9d-80C7-02AF85C822A8} GXA Global XML Web Services Architecture. GXA ist ein Protokoll-Framework, um ein einheitliches Modell für den Aufbau von Protokollen auf der Infrastrukturebene für Web-Services und Anwendungen bereitzustellen. Hash Mittels einer Einwegfunktion wird eine Zeichenfolge mit beliebiger Länge auf eine Zeichenfolge mit fester Länge abgebildet. Die neue Zeichenfolge wird als Hash oder Hashwert bezeichnet. Hijacking Übernahme einer Verbindung, Internetdomäne oder eines Benutzerkontos durch einen Angreifer Host Ein Host ist ein Rechner in einem Netzwerk, auf dem ein oder mehrere Anwendungen betrieben werden. HTML Hyper Text Markup Language, eine Markup-Sprache die aus Tags und Attributen besteht und zur Entwicklung statischer Webseiten genutzt wird. HTTP Hypertext Transfer Protocol. HTTP ist ein Übertragungsprotokoll, das hauptsächlich zur Übertragung von Seiten im World Wide Web genutzt wird. 360 Bundesamt für Sicherheit in der Informationstechnik Anhang Begriff Beschreibung HTTPS HyperText Transfer Protocol Secure. Variante von HTTP, die es erlaubt, die Datenübertragung mittels kryptographischer Protokolle abzusichern. ID-FF Liberty Identity Federation Framework. Das Liberty Identity Federation Framework (ID-FF) ermöglicht die Erstellung eines standardisierten Identity Federation Netzwerks. ID-WSF Liberty Identity Web Services Framework. Framework für den Aufbau von interoperablen Identitäts-Services. Identitätsprovider Dienst, welcher Funktionen zur Verwaltung einer digitalen Identität anbietet. Dieser ermöglicht die Authentifizierung von Nutzern und die Bereitstellung von Identitätsinformationen zur Nutzung durch Dienste. Injection Attack Bei dieser Angriffsmethode werden schadhafte Code-Inhalte als Eingabewerte übermittelt, so dass entsprechende Systeme betroffen sind, die diesen Code ausführen. Intermediär SOAP-basierte Kommunikation zwischen zwei Endpunkten kann über eine Kette von Zwischenstationen erfolgen – den so genannten Intermediären. Neben einer reinen Weiterleitungsfunktion können diese auch Mehrwerte auf den Nachrichten erbringen wie z.B. das Anbringen eines kryptographisch gesicherten Zeitstempels oder die Prüfung von Signaturen. IP Internetprotokoll. Netzwerkprotokoll für Computernetze ITIL IT Infrastructure Library. De-facto Standard zur Umsetzung von IT- Servicemanagement J2EE Java 2 Platform, Enterprise Edition. Programmierplattform für Server in der Programmiersprache Java JTC1 Joint Technical Committee 1. Komitee von der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC), die sich mit Fragen um das Thema IT beschäftigt. Kanonisierung Die Kanonisierung dient der Überführung von XML-Dokumenten in eine einheitliche Form. KPI Key Performance Indikator. Kennzahl, anhand derer der Erfolg oder der Erfüllungsgrad der von einer Organisation gesetzten Ziele gemessen wird. Kryptographische Siehe Algorithmen https://www.bsi.bund.de/cln_136/ContentBSI/grundschutz/kataloge/m/m02/m02164.html und Algorithmenkatalog der Bundesnetzagentur, www.bundesnetzagentur.de Late Service Als Late Service Binding wird die Auswahl der zu nutzenden Dienste zur Binding Laufzeit bezeichnet. LDAP Lightweight Directory Access Protocol. LDAP ist ein Standardprotokoll für Verzeichnisdienste im Intra-/Internet. LDAP ist eine vereinfachte Form des Directory Access Protocol (DAP). Legacy- Legacy-Anwendung (Altanwendung) ist eine etablierte, historisch Anwendung gewachsene Anwendung in einer Organisation. Bundesamt für Sicherheit in der Informationstechnik 361 Anhang Begriff Beschreibung Liberty Alliance 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. Load Balancing Als Load Balancing wird das Verteilen der Last auf verschiedene Systeme bezeichnet. MEP Message-Exchange-Pattern. MEP spezifiziert die Reihenfolge und die Kardinalität der Nachrichten einer Operation. Metadaten Daten, die Informationen über andere Daten enthalten. MIME 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. Multicast Multicast bedeutet, dass der Web Service eine Nachricht zu einer Vielzahl von Clients sendet, um jeden möglichen Nutzer des Web Service zu benachrichtigen. Nonce Eine Nonce ist eine Zahlen- und/oder eine Buchstabenkombination, die nur einmalig verwendet wird. OGSA Die Open Grid Service Architecture (OGSA) ein allgemeiner architektonischer Rahmen zur Beschreibung und Organisation von Grid- Infrastrukturen. OGSI Die Open Grid Service Infrastructure (OGSI) war der erste Versuch, Grid Services als Web Service standardisiert zu implementieren. PAP Policy Administration Point. Der PAP schreibt Policies sowie Policy Sets und stellt sie dem PDP zur Verfügung. PDCA Plan-Do-Check-Act. PDCA ist ein vierstufiger, iterativer Problemlösungsprozess. PDP Policy Decision Point. Der PDP besitzt die Aufgabe, auf der Grundlage von Policies Entscheidungen zu treffen. PEP Policy Enforcement Point. Der PEP ist für die Durchsetzung von Policies verantwortlich. PIP Policy Information Point. Der PIP ist ein Attributservice, der vom PDP und PEP genutzt werden kann. PKI Eine Public-Key-Infrastructure (PKI) ist ein Infrastruktur zum Erstellen, Verteilen, Verifizieren sowie Widerrufen von digitalen Zertifikaten. Die innerhalb einer PKI ausgestellten Zertifikate ermöglichen eine sichere Authentifizierung und den vertraulichen Austausch von Daten über ein potentiell unsicheres Netz. Plugin Zusatzmodul, das eine Anwendung um zusätzliche Funktionen erweitert. PSO Provisioning Service Object. Ein Provisioning Service Object ist vereinfacht ein Objekt, das eine Datenentität oder Informationsobjekt eines Targets darstellt. 362 Bundesamt für Sicherheit in der Informationstechnik Anhang Begriff Beschreibung PSP Provisioning Service Provider. 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. PST Provisioning Service Target. Ein Provisioning Service Target (kurz Target) stellt einen Endpunkt dar, den ein Provider für Provisionierungs-Aktionen zur Verfügung stellt und verwaltet. QoS Quality of Service. QoS gibt die Dienstgüte an. RA Requesting Authority. Eine Requesting Authority (kurz Requestor) ist eine Software-Komponente, die syntaktisch korrekte SPML Anfragen an einen Provisioning Service Provider stellt. REL Rights Expression Language. REL ist eine maschinenlesbare Sprache, die Rechte und Berechtigungen deklariert. Relying Party/ Eine Person, Organisation oder Dienst, welche auf die von einer fremden Abhängige Partei Partei bestätigten Claims über ein Subject vertraut und diese für eigene Zwecke nutzt Replay Attacke Bei einer Replay-Attacke werden Informationen, die von einer Anwendung akzeptiert wurden, von einem Angreifer nochmals verwendet. Repository Verzeichnis in dem Informationen, z.B. über Web Services, veröffentlicht werden. RIM ebXML Registry Information Model. Das RIM ist eine High-Level-Konzept für die Meta-Daten in einem ebXML Registry. Risk Management Risikomanagement ist die systematische Erfassung und Bewertung von Risiken sowie die Steuerung von Reaktionen und das Umsetzen von Maßnahmen auf festgestellte Risiken. Roadmap Eine Roadmap ist ein Ablaufplan, nach dem z.B. ein Projekt umgesetzt werden soll. ROI Return on Investment. Renditekennzahl für die Gesamtkapitalrentabilität RPC Remote Procedure Call. RPC ist ein Aufruf einer Funktion in einem entfernten System. RS ebXML Registry Services Specification. ebXML Registry Services Specification beschreibt, wie die Registry Services aufgebaut werden, um Zugriff auf die Informationen in einem ebXML Registry zu bekommen. RST Request for Security Token. Durch WS-Trust spezifizierte Anfrage für einen Token. RSTR Request for Security Token Response. Durch WS-Trust spezifizierte Antwort auf ein RST. RUP Rational Unified Process. RUP ist ein objektorientiertes Vorgehensmodell zur Softwareentwicklung. Bundesamt für Sicherheit in der Informationstechnik 363 Anhang Begriff Beschreibung SCDL Service Component Definition Language. SCDL ist eine XML-basierte Sprache zur Beschreibung von SCA-Elementen. SDO Standards Development Organization. Organisation, deren Hauptaktivitäten in der Entwicklung, Koordinierung, Verbreitung, Überarbeitung, Änderung, Neuausstellung, Aufrechterhaltung von Standards liegt, die einer breiten Öffentlichkeit zugänglich sind. Security Token Ein Container (Software/Hardware) für eine Menge von Claims. Ein Security Token dient meist als Identifikations- oder Berechtigungsnachweis. Security Token Der Security Token Service (STS) bezeichnet einen Sicherheitstokendienst, Service der zum Anfordern, Erneuern oder Überprüfen von Sicherheitstokens genutzt wird. In der WS-Trust Spezifikation werden die Basisaktionen eines STS definiert. Service Ein Service (Dienst) bietet Ressourcen und Funktionalitäten zur Nutzung an. Im Kontext einer Service-orientierten Architektur werden Dienste 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 einen Service Response. Aus Sicht der Geschäftsprozesse ist ein Service zugleich aber auch ein(e) Dienst(leistung) mit gewissem (Mehr-)Wert. Session Eine Session ist ein zeitweise Verbindung zwischen Kommunikationspartnern. SGML SGML steht für Standard Generalized Markup Language, war ein erster Versuch, die logische Struktur eines Dokumentes zu beschreiben und stellt einen ersten Ansatz dar, Dokumente plattformunabhängig zu speichern. SLA Service Level Agreement. Ein Service Level Agreement ist eine Vereinbarung zwischen Nutzern von Services - also zum Beispiel der jeweiligen Behörde - und dem IT-Dienstleister (auch Provider) über die Dienstgüte. SMTP Simple Mail Transfer Protocol. SMTP ist ein Protokoll, das zum Austausch elektronischer Nachrichten (E-Mails) im Internet eingesetzt wird und im RFC 821 beschrieben ist. SOA Service-orientierte Architektur. SOA bezeichnet einen Architekturansatz zum Zusammenwirken heterogener Softwaresysteme auf Basis von Diensten. Diese Dienste weisen dabei die folgenden Eigenschaften auf: Lose Kopplung, Selbstbeschreibung, Autonomie, Wiederverwendbarkeit, Kombinierbarkeit, Zustandslosigkeit und Auffindbarkeit. SOAP Intermediäre Zwischenstationen, über die SOAP Nachrichten übertragen werden. SOX Sarbanes-Oxley Act of 2002. Sarbanes-Oxley Act of 2002 ist ein US- Bundesgesetz, das die Verlässlichkeit der Berichterstattung von Organisationen verbessern soll. Spoofing Spoofing ist das Vortäuschen einer falschen Identität durch einen Angreifer. 364 Bundesamt für Sicherheit in der Informationstechnik Anhang Begriff Beschreibung SQL Structured Query Language. Sprache zum Abfragen und Bearbeiten von Datenbanken SSL Secure Socket Layer. SSL ist ein Standard-Protokoll der IETF (Internet Engineering Task Force) zur sicheren Datenübertragung im Internet. SSO Single-Sign-on. SSO bezeichnet einen Mechanismus zur einmaligen Authentifizierung für unterschiedliche Systeme und Dienste. STS Security Token Service. STS ist ein Web Service, der im Rahmen von WS- Trust Security Tokens herausgibt, die mit WS-Security kompatibel sind. Subject Natürliche oder juristische Person, auf die ein Security Token personalisiert ausgestellt wird. Das Token enthält somit Credentials zu dieser Person. Tag Tags (engl. Markierung) sind anwendungsspezifische Elemente, mit denen Informationen bzw. Daten in Auszeichnungssprachen (z.B. XML) ausgezeichnet werden. TLS Transport Layer Security, ehemals SSL (Secure Socket Layer). Das TLS- Protokoll ist ein hybrides kryptographisches Protokoll, das die Vertraulichkeit und Authentizität der Nachrichtenübertragung auf der Transportebene ermöglicht. Token Träger von Authentifizierungsdaten Tracking Tracking ist das Verfolgen von Bewegungen von Objekten. Transformation Mit der Transformation werden referenziert Daten in einem XML- Dokument umgewandelt und die Teilbäume eines XML-Dokuments vor der Signaturerstellung ausgewählt. UML Unified Modeling Language. UML ist eine standardisierte Sprache zur Visualisierung, Konstruktion und Dokumentation von Modellen. UN/CEFACT United Nations Center For Trade Facilitation And Electronic Business. UN/ CEFACT ist verantwortlich für die Entwicklung von Konzepten und Strategien zur Förderung des internationalen Handels. UN/ECE United Nations Economic Commission for Europe. Kommissionen zur Verbesserung der wirtschaftlichen Zusammenarbeit. URI Uniform Resource Identifier. URI ist eine Zeichenfolge zur einheitlichen Bezeichnung von Ressourcen. URL Uniform Resource Locator. Eine URL gibt an, wo eine bestimmte Ressource verfügbar ist und mit welchem Mechanismus sie abgerufen werden kann. UTF Unicode Transformation Format UTF ist eine Methode, um Unicode- Zeichen (z.B. lateinischen Standardbuchstaben oder Ziffern) auf Folgen von Bytes abzubilden. Bundesamt für Sicherheit in der Informationstechnik 365 Anhang Begriff Beschreibung Vertrauensdomäne Einer Vertrauensdomäne dient zur Unterteilung der Infrastruktur, wobei alle Akteure in einer Domäne untereinander eine Vertrauensbeziehung unterhalten. Somit vertrauen alle Dienste in einer Vertrauensdomäne allen Identity Providern in dieser Domäne und allen durch diese Provider verwalteten Identitäten. W3C World Wide Web Consortium. Das W3C ist ein Gremium aus Vertretern von Institutionen und Wirtschaftsunternehmen zur Entwicklung von interoperablen Technologien und Standards im Internetumfeld. WCF Windows Communication Foundation. WCF ist eine Service-orientierte Kommunikationsplattform für verteilte Anwendungen. Web Service Ein Web Service ist eine über einen Fernzugriff aufrufbare Anwendungskomponente, die definierte Methoden über eine standardisierte Schnittstelle anbietet und über eine URI (Uniform Resource Identifier) eindeutig identifizierbar macht. Als Kommunikationsprotokoll dient meist SOAP (W3C Recommendation), mit dem Daten zwischen Systemen ausgetauscht werden können. WS-* Sammlung von Spezifikationen bezüglich Web Services. WS-BPEL WS-Business Process Execution Language. BPEL (ehemals BPEL4WS) ist eine XML-basierte Sprache zur Beschreibung von ausführbare Geschäftsprozessen, deren Aktivitäten durch Web-Services implementiert werden und deren Nachrichtenaustausch über XML-Dokumente erfolgt. WS-Transfer WS-Transfer definiert die einfachen Resourcenoperationen GET, PUT, DELETE auf SOAP Ebene. X-KISS XML Key Information Service Specification (X-KISS) ermöglicht Bezug und Validierung der Zertifikate mittels Abfrage beim entsprechenden PKI- Dienstleister. X-KRSS XML Key Registration Service Specification. X-KRSS ist eine Komponente von XKMS und sorgt für das Management der Zertifikate. XLANG XML Language. Eine auf XML-basierende Sprache, die komplexe Transaktionen unterstützt, die unter Umständen unterschiedliche Web Services betreffen. XOP XML Binary Optimized Packaging. XOP ist eine vom W3C empfohlene Konvention, die für die für effiziente Serialisierung der XML-Information Sets, die eine Mischung von Binär-und Text-Daten und ganz allgemein für die Speicherung von binären Daten in XML-Tags, definiert wurde. XPath XML Path Language. XPath ist eine Sprache, um Teile von XML- Dokumenten zu adressieren. XPDL XML Process Definition Language. XPDL ist eine XML-basierte Prozessbeschreibungssprache zur Ausführung durch Workflow Management Systeme. 366 Bundesamt für Sicherheit in der Informationstechnik Anhang Begriff Beschreibung XSD XML Schema Definition. XML Schemas definieren die Struktur eines XML Dokuments. XSL Extensible Stylesheet Language. Mit dieser Programmiersprache können für XML-Dokumente Formatvorlagen für Präsentation in anderen Medien (Web-Seite, WAP, Printmedien) erstellt werden. Dadurch kann man bestimmen, wie einzelne Elemente des XML-Quelldokuments im jeweilig anderen Medium dargestellt werden sollen. Inhaltliche Änderungen brauchen nur im XML-Dokument vorgenommen werden. XSLT Extensible Stylesheet Language for Transitions. Eine XML Sprache, um XML-Dokumente in ein anderes Dokument zu transformieren. Das resultierende Dokument kann ein beliebiges Format besitzen wie XML, HTML oder Text. Zeichenketten- Zeichenketten sind Zeichenfolgen aus einem fest definierten Zeichensatz basiert Tabelle 19: Glossar Bundesamt für Sicherheit in der Informationstechnik 367 Anhang Referenzen [An 2003] Testing Working Group, WS-I Analyzer Tool Functional Specification, 26.6.2003, http://www.ws-i.org/Testing/Specs/AnalyzerFunctionalSpecification_BdAD_10.pdf [BE 2005] Sonic Software Corporation, AmberPoint Inc., BearingPoint, Inc., Systinet Corporation: A New Service-Oriented Architecture (SOA) Maturity Moddel, 2005 [BNetzA] Algorithmenkatalog der Bundesnetzagentur, www.bundesnetzagentur.de [BPEL] http://sun-n1-webservice-plugin.googlecode.com/svn/ [Br 2003] Peter Brittenham: Understanding the WS-I Test Tools, 2003, http://www.ibm.com/developerworks/webservices/library/ws-wsitest/ [BSI 2003] Bundesamt für Sicherheit in der Informationstechnik (BSI): Durchführungskonzept für Penetrationstests, November 2003, https://www.bsi.bund.de/cln_164/ContentBSI/Publikationen/studien/pentest/index_htm.html [Cameron2005] The Laws of Identity, Kim Cameron, Microsoft, http://www.identityblog.com/stories/2004/12/09/thelaws.html [ebXML] ebXML specifications, http://www.ebpml.org/ebxml.htm [ebXML2] Stuart Campbell: Conducting Business via ebXML:http://www.gca.org/papers/xmleurope2001/papers/html/s03-2.html [ebRIM] ebXML Registry Information Model, Version 3.0, http://www.oasis- open.org/committees/regrep/documents/3.0/specs/regrep-rim-3.0-cs-01.pdf [Fabric3] http://www.fabric3.org/index.html [Gi 2008] R. Gimnich: SOA Migration in Practice – Methods, Tools, and Projects. In: Proc. The Open Group Enterprise Architecture Practitioners Conference, San Francisco, January 2008, https://www.opengroup.org/conference-live/uploads/40/15777/gimnich.pdf [Ho 2009] Hohner, André: Risikomanagement in einer SOA-Welt. http://soa-know-how.de/index.php?id=45&tx_bccatsandauthors[catid]=187 (20.04.2009) [ISO29361] ISO, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45422 [ISO29362] ISO, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45423 [ISO29363] ISO, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45424 [IT-GSK] IT-Grundschutz-Kataloge Standardwerk zur IT-Sicherheit Loseblattsammlung – jährliche Ergänzung, ISBN 3-88784-915-9 [Ka 2008] Kanneganti, Ramarao; Chodavarapu, Prasad: SOA Security. Manning Publications 2008 [Kn 2000] D. Harrison McKnight, Norman L. Chervany, The Meanings of Trust, 2000 368 Bundesamt für Sicherheit in der Informationstechnik Anhang [Melzer2008] Ingo Melzer et al.: Service-orientierte Architekturen mit Web Services, Spektrum Akademischer Verlag, 2008 [Mo 2003] Testing Working Group, WS-I Monitor Tool Functional Specification, 26.6.2003, http://www.ws-i.org/Testing/Specs/MonitorFunctionalSpecification_BdAD_10.pdf [MTOM] http://ws.apache.org/axis2/1_0/mtom-guide.html [OASIS_Arch] OASIS: Reference Architecture For Service Oriented Architecture, Version 1.0, Public Review Draft 1, 23. April 2008, http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf [OASIS_Mod] OASIS: Reference Model For Service Oriented Architecture 1.0, OASIS Standard, 12. Oktober 2006, http://docs.oasis-open.org/soa-rm/v1.0/ [PDCA] ISO, http://www.iso.org/iso/iso_catalogue/management_standards/understand_the_basics.htm [PMgmt] Günter Waller, Detlef Sturm: Policy-Management, Service-orientierte Architekturen – Leitfaden und Nachschlagewerk, BTIKOM 2009, http://soa-know-how.de/ [RFC 2246] IETF, The TLS Protocol Version 1.0, http://www.ietf.org/rfc/rfc2246.txt [RFC 2616] IETF, Hypertext Transport Protocol – HTTP 1.1, http://www.ietf.org/rfc/rfc2616.txt [RFC 2617] IETF, HTTP Authentication: Basic and Digest Access Authentication, Juni 1999, http://www.ietf.org/rfc/rfc2617.txt [Rosenberg] Jothy Rosenberg, David L. Remy: Securing Web Services with WS-Security, Sams Publishing, 2004 [SAML] http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview- 2.0-draft-03.pdf [SCAPolicy] OSOA: SCA Policy Framework, SCA Version 1.00, März 2007, http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications [SM 2005] SUN Microsystems: EFFECTIVE SOA DEPLOYMENT - USING AN SOA REGISTRY REPOSITORY, September 2005, http://www.sun.com/products/soa/registry/soa_registry_wp.pdf [SPML] OASIS: OASIS Service Provisioning Markup Language (SPML) Version 2, OASIS Standard, 1. April 2006, http://www.oasis-open.org/committees/provision/docs/ [TeleTrust] TeleTrust SOA-Security Arbeitsgruppe, "Metriken und Pattern für eine Umsetzung von SOA Security in der Praxis" [Tuscany] http://tuscany.apache.org/home.html [UDDI] http://winfx.members.winisp.net/karstenj/docs/rss_in_uddi.aspx [UDDI_XML] XML.org: UDDI, http://uddi.xml.org/uddi-101 [VModellXT] Das V-Modell XT, November 2008, http://www.cio.bund.de/DE/IT-Methoden/V-Modell_XT/v-modell_xt_node.html Bundesamt für Sicherheit in der Informationstechnik 369 Anhang [VM 2008] http://www.cio.bund.de/cln_102/DE/IT-Methoden/V-Modell_XT/V-Modell_XT_ %C3%9Cberblick/v-modell_xt_ueberblick_node.html (20.04.2009) [WS-CDL] W3C: Web Services Choreography Description Language Version 1.0, W3C Candidate Recommendation, 9. November 2005, http://www.w3.org/TR/ws-cdl-10/ [WS-Dis] http://msdn.microsoft.com/en-us/library/bb706924.aspx [WS-Discovery] Microsoft, BEA Systems, Canon, Intel, webMethods: Web Services Dynamic Discovery (WS-Discovery), April 2005, http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf [WSDL] Web Services Description Language, W3C, http://www.w3.org/TR/wsdl20/ [WS-Fed] http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf [WSFL] Guoqiang Wang: Web Services Flow Language, Oktober 2002, http://www.cs.ucf.edu/~dcm/Teaching/ProcessCoordination/Fall02Class/Research Presentations/GuaquangWang.ppt [WS-I Matrix] http://www.ws-i.org/deliverables/matrix.aspx [WS-I SCTC] WS-I, Security Challenges, Threats and Countermeasures, 6. Mai 2005, http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf [WS-Inspection] IBM, Microsoft: Web Services Inspection Language (WS-Inspection) 1.0, http://www.ibm.com/developerworks/library/specification/ws-wsilspec/ [WSMC 2007] OASIS, Web Services Make Connection (WS-2 MakeConnection) Version 1.0, Committee Specification, 11 April 2007, http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cs-01.pdf [WS-MetadataExchange] WS-MetadataExchange, W3C http://www.w3.org/TR/ws-metadata-exchange/ [WSPAtt] BEA Systems, Inc.: Web Service Policy Attachment (WS-PolicyAttachment), September 2007, http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/ [WSPO] Brian Garback, Tutorials on the Components of Web Services – WS-Policy, Februar 2004, http://www.cs.virginia.edu/~acw/security/doc/Tutorials/WS-Policy.ppt [WS-Policy] WS-Policy, W3C, http://www.w3.org/TR/ws-policy/ [WS-PolicyAttachment] WS-PolicyAttachment, W3C, http://www.w3.org/TR/ws-policy-attach/ [WS-RelMes] http://specs.xmlsoap.org/ws/2005/02/rm/WS-RMPolicy.pdf [WSR] OASIS: Web Services Reliable Messaging TC WS-Reliability 1.1, November 2004, http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf [WSRF] The Globus Alliance: The WS-Resource Framework, Januar 2004, http://www.globus.org/wsrf/ [WSRM] IBM: WS-ReliableMessaging Februar 2005, http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-rm/ws- reliablemessaging200502.pdf 370 Bundesamt für Sicherheit in der Informationstechnik Anhang [WS-SecConv] OASIS: WS-SecureConversation 1.3, OASIS Standard, 1. März 2007, http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws- secureconversation-1.3-os.pdf [WSS-SMS] Web Services Security: SOAP Message Security 1.0, http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-soap-messagesecurity-1.0.pdf [WSS-SWA] Web Services Security: SOAP Message with Attachments (SwA) Profile 1.0, http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10902/wssswa-profile-1.0-cd- 01.pdf [XACML] OASIS: eXtensible Access Control Markup Language (XACML) Version 2.0, OASIS Standard, 1. Februar 2005, http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf [XACML_IBM] IBM: XML Security: Control information access with XACML, http://www.ibm.com/developerworks/xml/library/x-xacml/ [XENC] http://www.w3.org/TR/xmlenc-core/ [XKMS] Verisign, Microsoft, webMethods: XML Key Management Specification, März 2001, http://www.w3.org/TR/xkms/ [XML] W3C: Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation, 26. November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/ [XML Schema] XML Schema, W3C, http://www.w3.org/XML/Schema Bundesamt für Sicherheit in der Informationstechnik 371