B 5.26 Serviceorientierte Architektur

Beschreibung
Serviceorientierte Architekturen (SOA) beschreiben einen allgemeinen Ansatz zur Umsetzung verteilter Systeme, um Institutionen mittels IT in ihren Geschäftsprozessen effizient zu unterstützen. Die einzelnen Aktivitäten innerhalb eines Geschäftsprozesses werden dabei von Diensten übernommen, die so auch für andere Aktivitäten in anderen Geschäftsprozessen wiederverwendbar sind. Durch Zusammensetzen der Dienste (Orchestrierung) lassen sich dann zum Beispiel neue Geschäftsprozesse umsetzen. Das SOA-Konzept verspricht viele bestehende Probleme bei der Integration und Interaktion unterschiedlicher Teilsysteme zu lösen.
Ausgangspunkt für die Darstellung in diesem Baustein ist das Referenzmodell SOA-RM (Reference Model for Service Oriented Architecture, Version 1.0) der OASIS (Organization for the Advancement of Structured Information Standards), das sich unter anderem auf eine infrastrukturbezogene Diensteumgebung abstützt, repräsentiert in einem Enterprise Service Bus (ESB) und einem anwendungsunabhängigen Transportprotokoll, wie dem Simple Object Access Protocol (SOAP). Für die Sicherheitsarchitektur im Bereich der Anwendungssicherheit ist SOAP maßgebend. SOAP ist ein Protokollstandard des W3C, der auch die notwendigen Sicherheitsprotokollelemente wie WS-Security bereitstellt. Weiterhin ermöglicht SOAP die standardisierte Kommunikation zwischen verteilten Applikationen und Objekten insbesondere im SOA/ESB-Umfeld. Allerdings können auch andere XML-Transportcontainer wie REST (Representational State Transfer) verwendet werden. Aufgrund der Flexibilität von SOAP wird diese Spezifikation hier bevorzugt.
Das Referenzmodell der OASIS für SOA geht über reine Webanwendungen, wie sie in den Bausteinen B 5.21 Webanwendungen und B 5.24 Web-Services enthalten sind, hinaus und beschreibt ein allgemeines Modell, wie Dienste und Dienstprofile, auch und gerade in der Verteilung durch Benutzer verwendet und zu neuen Fähigkeiten verbunden werden können. Um eine solche Dienstenutzung von unterschiedlichen Diensteerbringern zu ermöglichen, werden standardisierte Dienstzugangspunkte genutzt.
In den meisten serviceorientierten Architekturen wird zum Nachrichtenaustausch SOAP und als Transportmedium HTTP verwendet. SOAP als Kommunikationsprotokoll und HTTP als Transportprotokoll unterstützen in ihrer Basisform keinerlei Sicherheitsanforderungen. Daten werden vielmehr im Klartext übermittelt. SOAP-Nachrichten werden vorwiegend mittels HTTP über SSL 3.0 beziehungsweise TLS 1.0 oder 1.2 (HTTPS) ausgetauscht.
In SOAP-basierten Plattformen wird für mittels SOAP übertragene Informationsobjekte zusätzlich ein "Objektschutz" eingeführt und zusammen mit der ursprünglichen SOAP-Nachricht übermittelt. Dieser Objektschutz kann grundsätzlich aus den folgenden Elementen bestehen:
- Angabe über die Einstufung des Informationsobjektes,
- Angabe über den Ersteller und/oder die berechtigten Benutzer,
- Angabe über den Integritätsschutz und
- Angabe über den Vertraulichkeitsschutz.
Als primäre Technik hierfür hat sich der OASIS-Standard WS-Security etabliert. WS-Security setzt auf bereits existierende Standards wie XML-Verschlüsselung, XML-Signaturen und X.509-Zertifikaten auf. WS-Security ist eine grundlegende Erweiterung des SOAP-Standards, um den Anforderungen hinsichtlich Integrität, Vertraulichkeit und Authentizität von Nachrichten sowie beteiligter Entitäten gerecht zu werden. Dabei wird die Authentisierung und Autorisierung basierend auf SAML (Security Assertion Markup Language) eingesetzt.
Der Zugriff auf SOAP-basierte Informationsobjekte in IT-Systemen unterliegt unterschiedlichen Zugriffsbeschränkungen, solange diese Objekte nicht als frei zugänglich deklariert sind. Die wesentlichen Kriterien hierbei sind die Klassifikation, wie der Einstufungsgrad und zusätzliche Kennzeichnungen, der beabsichtigte Empfängerkreis und falls erforderlich ein Verfallsdatum für die Information, oder Teile von dieser, im Informationsobjekt.
Zugriffsinformationen zu Informationsobjekten werden in einem Label vermerkt. Um diese Zusatzinformationen (Metainformationen) während der gesamten Lebensdauer eines Informationsobjektes fälschungssicher zu machen, müssen diese fest an das Informationsobjekt gebunden werden, wie auch alle anderen Bestandteile der SOAP-Nachricht. Dies geschieht normalerweise durch eine zusätzliche Signatur.
Der Baustein stellt die Gefährdungen von serviceorientierten Architekturen vor und beschreibt Maßnahmen, um den Informationsverbund angemessen abzusichern.
Gefährdungslage
Für den IT-Grundschutz werden pauschal die folgenden Gefährdungen als typisch im Zusammenhang mit serviceorientierten Architekturen angenommen:
Organisatorische Mängel
- | G 2.1 | Fehlende oder unzureichende Regelungen |
- | G 2.19 | Unzureichendes Schlüsselmanagement bei Verschlüsselung |
- | G 2.27 | Fehlende oder unzureichende Dokumentation |
- | G 2.66 | Unzureichendes Sicherheitsmanagement |
- | G 2.205 | Fehlendes Notfallvorsorgekonzept für serviceorientierte Architekturen |
Menschliche Fehlhandlungen
- | G 3.77 | Mangelhafte Akzeptanz von Informationssicherheit |
- | G 3.124 | Fehlende und ungenügende Implementierungen bzw. Konfigurationen in einer SOA |
Technisches Versagen
- | G 4.22 | Software-Schwachstellen oder -Fehler |
- | G 4.33 | Schlechte oder fehlende Authentikationsverfahren und -mechanismen |
- | G 4.35 | Unsichere kryptographische Algorithmen |
- | G 4.48 | Ausfall der Systeme eines Outsourcing-Dienstleisters |
- | G 4.74 | Ausfall von IT-Komponenten in einer virtualisierten Umgebung |
- | G 4.87 | Offenlegung vertraulicher Informationen bei Webanwendungen |
Vorsätzliche Handlungen
- | G 5.7 | Abhören von Leitungen |
- | G 5.18 | Systematisches Ausprobieren von Passwörtern |
- | G 5.23 | Schadprogramme |
- | G 5.28 | Verhinderung von Diensten |
- | G 5.83 | Kompromittierung kryptographischer Schlüssel |
- | G 5.87 | Web-Spoofing |
- | G 5.143 | Man-in-the-Middle-Angriff |
- | G 5.170 | Cross-Site Scripting (XSS) |
- | G 5.174 | Injection-Angriffe |
- | G 5.179 | Angriffe auf Protokolle |
- | G 5.180 | Angriffe auf Registries und Repositories |
- | G 5.181 | Angriffe auf das Identitäts- und Zugriffsmanagement bei Web-Services |
- | G 5.183 | Angriffe auf XML |
- | G 5.184 | Informationsgewinnung über Web-Services |
- | G 5.195 | Ausnutzen von Schwachstellen in Backend-Anwendungen |
- | G 5.196 | Unterbinden einer Informations- und Dienstesynchronisation in einer verteilten SOA-Umgebung |
- | G 5.197 | Missbrauch von SAML-Token in SOA-Umgebungen |
- | G 5.198 | Missbrauch der WS-Notification-Broker in einer SOA |
- | G 5.199 | Ungenügende Absicherung der SOAP-Kommunikation |
- | G 5.200 | Manipulation von Richtlinien in einer SOA |
Maßnahmenempfehlungen
Um einen Informationsverbund abzusichern, müssen gemäß den Ergebnissen der Modellierung nach IT-Grundschutz zusätzlich zu diesem Baustein weitere Bausteine umgesetzt werden. Bereits in übergreifenden Bausteinen und in entsprechenden System-, Netz- und Anwendungsbausteinen angeführte Maßnahmen werden hier nicht nochmals genannt. Diese Bausteine und Maßnahmen sind im Einzelfall so anzuwenden, dass sie auch für eine SOA sinnvoll sind.
Für serviceorientierte Architekturen sollten die folgenden gemäß den Lebenszyklusphasen strukturierten Maßnahmen umgesetzt werden.
Planung und Konzeption
Bei der Planung einer serviceorientierten Umgebung müssen eine Reihe von Rahmenbedingungen bedacht werden. Im ersten Schritt ist eine Sicherheitsarchitektur für SOA-basierte Systeme zu erstellen, die eine sichere, verteilte Dienstenutzung, auch über Domänengrenzen hinweg, ermöglicht (siehe z. B. M 2.1 Festlegung von Verantwortlichkeiten und Regelungen, M 2.378 System-Entwicklung sowie M 2.561 Erstellen spezifikationskonformer SOA-Implementierungen und Konfigurationen). Bei der Kommunikation von SOA-basierten Systemen untereinander sollten bei durchgängigen, homogenen XML-Transportcontainern integrierte Sicherheitsmechanismen verwendet werden. Als primäre Technik hierfür hat sich der OASIS-Standard WS-Security etabliert. Dabei sollte eine Authentisierung und Autorisierung basierend auf SAML (Security Assertion Markup Language) eingesetzt werden.
Umsetzung
Bei der Umsetzung eines SOA-basierten Ansatzes ist darauf zu achten, dass die Kommunikation zwischen den Teilnehmern (z. B. Client, Server) abgesichert ist (M 4.450 Absicherung der Kommunikation bei Web-Services) und die Ressourcen vor einer Blockade geschützt sind (siehe M 4.405 Verhinderung der Blockade von Ressourcen (DoS) bei Webanwendungen und Web-Services). Außerdem muss eine geeignete Ein- und Ausgabevalidierung umgesetzt werden (siehe M 4.393 Umfassende Ein- und Ausgabevalidierung bei Webanwendungen und Web-Services). Wenn innerhalb einer SOA vertrauliche Daten übertragen werden, sind zudem die XML-Transportcontainer zu schützen (siehe M 4.473 Schutz vor Abhören von XML-Transportcontainern in einer SOA). Weiterhin sollten durch vorgeschaltete Authentisierungs- und Autorisierungsmechanismen die Angriffschancen auf die Backend-Anwendungen eingeschränkt werden (siehe M 4.474 Schutz vor Schwachstellen in Backend-Anwendungen einer SOA).
Betrieb
Es muss verhindert werden, dass die Benutzer die Benutzerumgebung in einer verteilten SOA-Umgebung verändern. Außerdem ist sicherzustellen, dass sie nur auf Ressourcen zugreifen können, auf die sie auch zugreifen sollen (siehe M 4.453 Einsatz eines Security Token Service (STS) sowie M 4.480 Schutz von WS-Resource in SOA-Umgebungen). Läuft die Verbindung zwischen einem Service-Consumer und einem Service-Provider über ein unsicheres Netz, sind Vorkehrungen zu treffen, damit die Kommunikation nicht belauscht, verändert oder gestört werden kann (siehe M 5.68 Einsatz von Verschlüsselungsverfahren zur Netzkommunikation).
Notfallvorsorge
Ein Ausfall einzelner Dienste innerhalb einer SOA-Umgebung sollte weitestgehend durch die Nutzung redundanter Diensterbringer ausgeglichen werden können (siehe M 6.161 Redundante Hardware-Komponenten in serviceorientierten Architekturen). Da vom Ausfall einzelner Service-Provider zumeist eine größere Anzahl Anwender betroffen sein kann, sind Maßnahmen zu ergreifen, damit der daraus resultierende Schaden verringert wird. In einem Business Continuity Plan sind daher alle Maßnahmen zu beschreiben, die erforderlich sind, falls es aufgrund eines Ausfalls einzelner Service-Provider nur noch zu einem eingeschränkten Betrieb innerhalb einer SOA-Umgebung kommt (siehe M 6.160 Notfallvorsorgekonzept für SOA-Umgebungen).
Nachfolgend wird das Maßnahmenbündel für den Baustein "SOA" vorgestellt.
Planung und Konzeption
- | M 2.1 | (A) | Festlegung von Verantwortlichkeiten und Regelungen |
- | M 2.378 | (A) | System-Entwicklung |
- | M 2.560 | (Z) | Integration eines SOA-basierten Need-to-share-Konzepts in das Sicherheitsmanagement |
- | M 2.561 | (W) | Erstellen spezifikationskonformer SOA-Implementierungen und Konfigurationen |
- | M 5.68 | (Z) | Einsatz von Verschlüsselungsverfahren zur Netzkommunikation |
Umsetzung
- | M 2.447 | (A) | Sicherer Einsatz virtueller IT-Systeme |
- | M 4.393 | (B) | Umfassende Ein- und Ausgabevalidierung bei Webanwendungen und Web-Services |
- | M 4.400 | (B) | Restriktive Herausgabe sicherheitsrelevanter Informationen bei Webanwendungen und Web-Services |
- | M 4.405 | (C) | Verhinderung der Blockade von Ressourcen (DoS) bei Webanwendungen und Web-Services |
- | M 4.450 | (A) | Absicherung der Kommunikation bei Web-Services |
- | M 4.453 | (Z) | Einsatz eines Security Token Service (STS) |
- | M 4.454 | (A) | Schutz vor unerlaubter Nutzung von Web-Services |
- | M 4.473 | (B) | Schutz vor Abhören von XML-Transportcontainern in einer SOA |
- | M 4.474 | (C) | Schutz vor Schwachstellen in Backend-Anwendungen einer SOA |
- | M 4.475 | (B) | Schutz vor Spoofing-Angriffen auf Identitätsdienste |
- | M 5.175 | (Z) | Einsatz eines XML-Gateways |
Betrieb
- | M 3.5 | (A) | Schulung zu Sicherheitsmaßnahmen |
- | M 4.476 | (B) | Schutz einer WS-Notification-Subscription im Broker |
- | M 4.477 | (B) | Schutz einer WS-Notification |
- | M 4.478 | (C) | Schlüsselmittelverwaltung bei SOA |
- | M 4.479 | (B) | Schutz von Richtlinien in einer SOA |
- | M 4.480 | (C) | Schutz von WS-Resource in SOA-Umgebungen |
- | M 4.481 | (C) | Sichere Nutzung verbindungsloser SOAP-Kommunikation |
- | M 5.147 | (C) | Absicherung der Kommunikation mit Verzeichnisdiensten |
- | M 5.150 | (Z) | Durchführung von Penetrationstests |
Notfallvorsorge
- | M 6.160 | (A) | Notfallvorsorgekonzept für SOA-Umgebungen |
- | M 6.161 | (Z) | Redundante Hardware-Komponenten in serviceorientierten Architekturen |
- | M 6.162 | (Z) | Reaktion bei praktischer Schwächung eines Kryptoverfahrens |