Bundesamt für Sicherheit in der Informationstechnik

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.1Fehlende oder unzureichende Regelungen
G 2.19Unzureichendes Schlüsselmanagement bei Verschlüsselung
G 2.27Fehlende oder unzureichende Dokumentation
G 2.66Unzureichendes Sicherheitsmanagement
G 2.205Fehlendes Notfallvorsorgekonzept für serviceorientierte Architekturen

Menschliche Fehlhandlungen

G 3.77Mangelhafte Akzeptanz von Informationssicherheit
G 3.124Fehlende und ungenügende Implementierungen bzw. Konfigurationen in einer SOA

Technisches Versagen

G 4.22Software-Schwachstellen oder -Fehler
G 4.33Schlechte oder fehlende Authentikationsverfahren und -mechanismen
G 4.35Unsichere kryptographische Algorithmen
G 4.48Ausfall der Systeme eines Outsourcing-Dienstleisters
G 4.74Ausfall von IT-Komponenten in einer virtualisierten Umgebung
G 4.87Offenlegung vertraulicher Informationen bei Webanwendungen

Vorsätzliche Handlungen

G 5.7Abhören von Leitungen
G 5.18Systematisches Ausprobieren von Passwörtern
G 5.23Schadprogramme
G 5.28Verhinderung von Diensten
G 5.83Kompromittierung kryptographischer Schlüssel
G 5.87Web-Spoofing
G 5.143Man-in-the-Middle-Angriff
G 5.170Cross-Site Scripting (XSS)
G 5.174Injection-Angriffe
G 5.179Angriffe auf Protokolle
G 5.180Angriffe auf Registries und Repositories
G 5.181Angriffe auf das Identitäts- und Zugriffsmanagement bei Web-Services
G 5.183Angriffe auf XML
G 5.184Informationsgewinnung über Web-Services
G 5.195Ausnutzen von Schwachstellen in Backend-Anwendungen
G 5.196Unterbinden einer Informations- und Dienstesynchronisation in einer verteilten SOA-Umgebung
G 5.197Missbrauch von SAML-Token in SOA-Umgebungen
G 5.198Missbrauch der WS-Notification-Broker in einer SOA
G 5.199Ungenügende Absicherung der SOAP-Kommunikation
G 5.200Manipulation 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(Z)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

Stand: 15. EL Stand 2016