Service Oriented Architecture by Rene Buest

Seminararbeit im Studiengang M.Sc. IT-Management and Information Systems an der Fachhochschule der Wirtschaft (FHDW)

Service Oriented Architecture

Vorgelegt von: Björn Schrader und René Büst

Prüfer: Prof. Dr. Eckhardt Koch

Eingereicht am: 18. Juli 2009

Verzeichnisse

Inhaltsverzeichnis Inhaltsverzeichnis

Abbildungsverzeichnis

Thematische Einleitung 1.1 Thematische Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Thematische Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1

SOA Einleitung

Situationsanalyse 3.1 Architektur vor der SOA Einführung . . . . . . . . . . . . . . . . . . . . 3.2 Architektur nach der SOA Einführung . . . . . . . . . . . . . . . . . . . 3.3 Vergleich der Architekturen . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3 4

SOA Strategie 4.1 Ziele einer SOA Strategie . . . . . . . . . . . . . . . . . . 4.2 Betriebswirtschaftliche Analyse der SOA Strategie . . . . 4.2.1 Besserer ROI für bestehende IT-Systeme . . . . . 4.2.2 Verbesserte Kundenzufriedenheit . . . . . . . . . 4.2.3 Bessere Abstimmung von IT- und Business-Zielen 4.3 Technische Analyse der SOA Strategie . . . . . . . . . . . 4.3.1 Technische Eigenschaften . . . . . . . . . . . . . 4.3.2 Technische Vorteile nach Einführung einer SOA .

5 5 5 6 7 7 8 8 9

. . . . . . . .

Erkenntnisse der SOA Strategie 5.1 Bekannte Probleme bei der Einführung einer SOA . . . . . . . . . . . . . 5.2 Bekannte Missverständnisse zum Thema SOA . . . . . . . . . . . . . . . 5.2.1 "Wenn du SOA einführst, sind alle deine Komponenten automatisch kompatibel zu einander" [SoaThe] . . . . . . . . . . . . . . 5.2.2 "Wenn du Web Services verstehst, hast du keine Probleme eine SOA aufzubauen." [SoaThe] . . . . . . . . . . . . . . . . . . . . 5.2.3 "SOA löst fachliche Probleme" [SoaThe] . . . . . . . . . . . . . SOA und der Bezug zu E-Business

10 10 12 12 12 13 13

Verzeichnisse

Unternehmen und deren SOA Einsatz 7.1 Deutsche Post Brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Gründe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Wiederverwendung von Services und Vermeidung redundanter Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Kürzere Projektlaufzeiten und schneller Time-To-Market . . . . . 7.5.3 Niedrigere Wartungskosten . . . . . . . . . . . . . . . . . . . . . 7.5.4 Bessere Reaktionsfähigkeit auf neue Geschäftsanforderungen . .

16 17 17 17

SOA & Sicherheit 8.1 Anforderungen . . . . . . . . . . . . . . 8.1.1 Authentifizierung . . . . . . . . . 8.1.2 Autorisierung . . . . . . . . . . . 8.1.3 Vertraulichkeit/ Privatsphäre . . . 8.1.4 Integrität . . . . . . . . . . . . . 8.1.5 Verfügbarkeit . . . . . . . . . . . 8.2 Risiken & Bedrohungen . . . . . . . . . 8.2.1 Replay Attacks . . . . . . . . . . 8.2.2 XML Spezifische Angriffe . . . . 8.2.3 WSDL- und Service Scanning . . 8.2.4 Kompromittierung eines Service . 8.2.5 Unberechtigte Servicenutzung . . 8.3 Konzepte . . . . . . . . . . . . . . . . . 8.3.1 Sicherheit auf Transportebene . . 8.3.2 Sicherheit auf Nachrichtenebene . 8.3.3 XML-Firewalls/ XML-Gateways . 8.3.4 Sicherheit auf Fachlicher Ebene . 8.3.5 Applikationssicherheit . . . . . . 8.3.6 Security as a Service . . . . . . . 8.3.7 Security as Infrastructure . . . . . 8.4 Standardisierte Sicherheitsmaßnahmen . . 8.4.1 XML-Security . . . . . . . . . . 8.4.2 WS Security . . . . . . . . . . .

18 18 18 18 18 18 19 19 19 19 21 21 21 21 21 22 23 23 23 24 24 25 25 25

. . . . . . . . . . . . . . . . . . . . . . .

14 14 14 14 15 16

Verzeichnisse

8.5

8.4.3 Security Assertion Markup Language . . . . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LITERATUR

iii

26 26 28

Verzeichnisse

Abbildungsverzeichnis 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Vergleich der Architekturen . . . . . . . . . . . . . . . . . . . . . . . . The Context of IT Investment Projects . . . . . . . . . . . . . . . . . . QM-Prozessmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements Management & Development Assurance . . . . . . . . . SOA-based Business Services and Solutions level . . . . . . . . . . . . Erfolgreichen Prozess- und Organisationsoptimierung im Unternehmen Wichtige Eckpunkte der SOA . . . . . . . . . . . . . . . . . . . . . . . E-Business/Service Providers Infrastructure . . . . . . . . . . . . . . . Der Zugriff 체ber Services auf Applikationsdom채nen . . . . . . . . . . . Der Service Kundenmanagement . . . . . . . . . . . . . . . . . . . . . Eine XML Bomb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XPath-Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sicherheit auf Transportebene . . . . . . . . . . . . . . . . . . . . . . Sicherheit auf Nachrichtenebene . . . . . . . . . . . . . . . . . . . . . Security as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

4 6 7 8 9 10 11 13 15 16 20 20 22 22 24

1 1.1

SOA EINLEITUNG

Thematische Einleitung Thematische Gliederung

Im ersten Teil der Diskussion über die serviceorientierte Architektur (SOA) werden wir uns sehr stark mit der Einführung und den betriebswirtschaftlichen Aspekten rund um die SOA Strategie beschäftigen. Nach der betriebswirtschaftlichen Diskussion wird ein technischer Abschnitt folgen, der abschließend um Empfehlungen aus praktischen Erfahrungen und bekannten Missverständnissen ergänzt werden soll. Der zweite Teil soll ein praxisnahes SOA Beispiel geben. Wir haben uns für die Deutsche Post entschieden und werden Ziele, Umsetzung und auch den Nutzen der SOA Einführung analysieren. Sicherheitsaspekte und die sich daraus ergebenen Sicherheitsanforderungen sollen den letzten Teil bilden. Hier werden bekannte Risiken und Bedrohungen sowie Sicherheitskonzepte und -Maßnahmen genauer erläutert.

1.2

Thematische Abgrenzung

Wir haben für die gesamte Ausarbeitung Schwerpunkte der SOA Thematik ausgewählt und diese intensiv untersucht. Eine Abdeckung aller Themengebiete rund um SOA ist an dieser Stelle nicht möglich, da dieses den vorgegebenen Rahmen der Ausarbeitung überschreiten würde.

SOA Einleitung

"Eine service-orientierte Architektur ist einer der wichtigsten Wegbereiter für das Unternehmen des 21. Jahrhunderts" [SagSoC] SOA wird heute als Trend in weltweit agierenden Unternehmen vermarktet und ist am Markt als solcher akzeptiert. Als erfolgreiches Beispiel soll das SOA Konsortium erwähnt

SOA EINLEITUNG

werden, das weltweit agierende, SOA unterstützende und betreibende Unternehmen bündelt und die SOA Strategie und das einheitliche Verständnis über die Thematik weiter vorantreibt. "Um die Vorteile der SOA zu nutzen sind signifikante Änderungen in der IT und im Business notwendig" [SagSoC] In dieser Ausarbeitung möchten wir das zentrale Statement herausarbeiten, dass SOA mehr als eine technische Architektur darstellt. Vielmehr handelt es sich um eine Strategie die signifikante Änderungen am Unternehmen sowohl auf Seite des Business Prozesses als auch auf Seite der technischen Architektur voraussetzt.

SITUATIONSANALYSE

Situationsanalyse

Um den Wechsel der Strategien vor und nach der Zeit um die SOA Einführung zu beschreiben, sollen zum Einstieg sowohl die bestehende als auch die geplante Architektur auf einem abstrakten Level genauer analysiert und erläutert werden.

3.1

Architektur vor der SOA Einführung

Vor der SOA Einführung wurden in Unternehmen oft separate Datensilos geschaffen, die sich schwer in bestehende Infrastrukturen integrieren ließen. Wenn man diese Datensilos einmal genauer untersucht, so stellt man fest, dass sie oft sehr schwerfällig und von anderen Systemen getrennt sind. Die logische Folgerung ist, dass sich die Systeme als sehr unflexibel darstellen und eine Interaktion bzw. Integration nur sehr eingeschränkt ermöglichen. Die eben beschriebenen "Silos" verwalten oft ganze Anwendungen und Daten kompletter Geschäftsprozesse. Eine fehlende Kompatibilität hat zur Folge, dass diese Daten bei Bedarf nicht weiter verwendet und somit aufwändig neu angelegt werden müssen. Resultierend war eine aufwändige bzw. teure Pflege. Zusätzlich ergab sich ein komplexer Wartungsprozesse der Systeme und deren Informationen.

3.2

Architektur nach der SOA Einführung

Wenn wir über eine Zeit nach der gelungenen Einführung einer SOA Strategie sprechen, so analysieren wir gemeinsam genutzte Services über Systemgrenzen hinaus. Die Installation dieser Services erlaubt eine Zusammenarbeit bzw. Interaktion verschiedener Dienste untereinander. Auch die Integration bestehender Services in Neuentwicklungen ist mit der SOA problemlos möglich. Folgen der SOA Einführung sind, dass Funktionalitäten bzw. Geschäftsprozesse, die durch einzelne Funktionalitäten abgebildet werden, in Services ausgelagert werden. Diese Services sind in der Regel lose gekoppelt. Nach der Einführung von Services sollte zum Beispiel keine manuelle Datenintegration im Backend-Bereich mehr notwendig sein. Information werden von entsprechenden Diensten auf Anfrage zur Verfügung gestellt. Anfragende Komponenten werden in diesem Fall ebenfalls von Services abgebildet.

3.3

SITUATIONSANALYSE

Vergleich der Architekturen

Ein direkter Vergleich der Architekturen der Vergangenheit und der Zukunft zeigt den Wandel von geschlossenen, monolithischen System zu gemeinsam genutzten, kompatiblen und integrierten Services. Wurden in der Architektur vor der Einführung von SOA Zugriffe auf Informationsquellen bzw. Funktionalitäten separat und für jede Notwenigkeit neu implementiert, so können heute standardisierte Services einmalig implementiert und in der Zukunft wiederholt genutzt werden.

Abbildung 1: Vergleich der Architekturen Quelle: www.ibm.com (Juli 2009)

Wieder verwendbare Abbildungen von Geschäftsprozessen erlauben es außerdem, bestehende Services zu neuen, übergreifenden Services zu kombinieren (siehe Abbildung 1). Die resultierende kurze Implementierungsphase bietet einen erkennbaren Mehrwert für den Kunden und damit einen Vorteil gegenüber Konkurrenzarchitekturen, die für wiederholte Kundenanfragen einen großen Aufwand generieren. Zudem zeigt die Abbildung eine klare Trennung in die verschiedenen Service Layer. Mit Hilfe dieser Trennung in Applikationsschichten lassen sich einzelne Services ganzer Applikationen leicht austauschen, kosteneffizient erweitern und anpassen.

SOA STRATEGIE

SOA Strategie

Nach der Einführung in die Thematik und der abstrakten Analyse der Architekturen sollen die Ziele der SOA Strategie analysiert werden. Zudem werden sowohl betriebswirtschaftliche als auch technische Eigenschaften diskutiert.

4.1

Ziele einer SOA Strategie

Ziel einer SOA Strategie ist die Bereitstellung fachlicher Dienste als Services und die Bereitstellung von Funktionalitäten über standardisierte Schnittstellen. "Die service-orientierte Architektur ist ein Systemarchitektur-Konzept, das die Bereitstellung fachlicher Dienste und Funktionalitäten in Form von Services vorsieht. Ein Service ist in diesem Kontext eine Funktionalität, die über eine standardisierte Schnittstelle in Anspruch genommen werden kann." [SOAErNu] Das SOA einführende Unternehmen untersucht im Rahmen der Einführung interne Prozesse und deren Abbildung in der Technologie. Anschließend wird über Anpassungen dieser Services die Möglichkeit geschaffen, komplette Business Prozesse über Services abzubilden. Vorteile dieser Architektur sind eine leichtere Verständlichkeit der durch komplexe Technologien umgesetzten Funktionalitäten für nicht Techniker (es handelt sich weiterhin "nur" um einen abstrakten Business Prozess) und eine flexiblere Ausrichtung des Unternehmens an die Anforderungen des Marktes. Im Idealfall bildet die SOA komplette Geschäftsprozesse mit Hilfe der IT ab.

4.2

Betriebswirtschaftliche Analyse der SOA Strategie

Nach der Diskussion von Zielen einer SOA gilt es nun die betriebswirtschaftlichen Vorteile dieser Strategie genauer zu erläutern.

SOA STRATEGIE

4.2.1

Besserer ROI für bestehende IT-Systeme

Zu Beginn soll der bessere Return on Investment (ROI) für die bestehenden IT Systeme erwähnt werden.

Abbildung 2: The Context of IT Investment Projects Quelle: http://www.ctg.albany.edu (Juli 2007)

Abbildung 2 zeigt die Abhängigkeit des ROI von den zugrundeliegenden Projekten aus den Business Prozessen. Aktuelle Erfahrungen zeigen, dass durch die Einführung einer SOA selten bestehende Anwendungen ersetzt werden. Vielmehr bietet sich die Möglichkeit Funktionen von Legacy-Programmen durch Transformation in Services in die neu angelegte Architektur zu integrieren und die Lebensdauer der Altsysteme zu erhöhen. Durch die Integrierung der Alt-Systeme werden somit historische Investitionen geschützt. Zusätzlich ermöglicht eine Integration bestehender Alt-System einen reibungslosen Übergang zwischen den Architekturgenerationen.

SOA STRATEGIE

4.2.2

Verbesserte Kundenzufriedenheit

Abbildung 3: QM-Prozessmodell Quelle: http://www.haufe.de (Juli 2009)

Nach heutigen Erfahrungen und statistischen Erhebung ist es für den Kunden immer wichtiger bestehende oder nach Kundenwünschen implementierte Geschäftsprozesse verstehen, analysieren und bewerten zu können. Abbildung 3 zeigt die Transformation von Kundenforderung in die zu erbringende Kundenzufriedenheit. Die Abbildung kompletter Geschäftsprozesse durch die IT ermöglicht eine leichtere Kundenanalyse und lässt eine offene Diskussion über Geschäftsprozesse und deren Implementierung zu. Zusammen mit der Flexibilität der SOA ermöglicht dieses eine schnelle Reaktion auf Kundenbedürfnisse und eine direkte Verbesserung der Kundenzufriedenheit.

4.2.3

Bessere Abstimmung von IT- und Business-Zielen

Wie im vorherigen Kapitel beschrieben liefert eine SOA im Idealfall ein komplettes Abbild der gesamten Unternehmensprozesse. Durch die mögliche Abbildung der Schlüsselprozesse durch visuelle Hilfsmittel (z.B. die formale Methode der Modellierung von Systemen und deren Prozessen mit Hilfe von Petri-Netzen) wird es den Fachabteilungen und auch dem Kunden ermöglicht umgesetzte Prozesse besser analysieren zu können. Dieses beutet sowohl auf technischer Ebene als auch aus Sicht der Manager eine leichtere Umsetzung der Prozesse (siehe Abbildung 4).

SOA STRATEGIE

Abbildung 4: Requirements Management & Development Assurance Quelle: http://www.modernanalyst.com (Juli 2009)

Ist eine bessere Verständlichkeit gegeben, so lassen sich Innovationsentscheidungen gegenüber Entscheidungsträgern besser argumentieren, was im Endeffekt zu einer Steigerung der Unternehmensdynamik beiträgt. In einer SOA sind die Chancen das Unternehmen durch Innovationen voranzutreiben in der Regel deutlich erhöht. Wenn zudem sowohl auf wirtschaftlicher als auch auf technischer Ebene über die gleichen Ziele und mit dem gleichen Verständnis der notwendigen Änderungen gesprochen wird, ermöglicht dieses eine bessere Abstimmung und Einhaltung der strategischen Unternehmensziele.

4.3

Technische Analyse der SOA Strategie

Nach der Diskussion der betriebswirtschaftlichen Eigenschaft gilt es im nächsten Schritt die technischen Eigenschaften zu analysieren.

4.3.1

Technische Eigenschaften

Die Einteilung der zu erbringenden Funktionalitäten in Services bietet betriebswirtschaftliche Vorteile. Aus technischer Sicht fördert diese Einteilung die architektonische Komponierbarkeit separierter Services zu einer Gesamtapplikation.

SOA STRATEGIE

Abbildung 5: SOA-based Business Services and Solutions level Quelle: http://www.ibm.com (Juli 2009)

Durch die Verwendung offener Standards wie XML, SOAP oder JMS (siehe Abbildung 5) wird die Möglichkeit der gezielten Wiederverwendung gefördert. Die Verwendung offener Standards erlaubt zudem die unternehmensübergreifende Nutzung entstandener Services.

4.3.2

Technische Vorteile nach Einführung einer SOA

Zu den technischen Vorteilen nach der Einführung der SOA kann gesagt werden, dass durch die Einführung von Services eine verbesserte Integration bestehender Lösungen in die neue Architektur möglich ist. Die vereinfachte Integration mindert Kosten und stellt einen Wettbewerbsvorteil gegenüber Mitbewerbern dar. Die Investitionen in eine einheitliche Kommunikationsstruktur, ebenfalls abgebildet durch bestehende Standards, führen durch die sich erübrigende Diskussion der aufzusetzenden Kommunikationsstruktur zu einer Performanceverbesserung zu Projekt- / Produktionsbeginn. Services in einer SOA werden über bekannte Schnittstellen sowohl intern als unternehmensübergreifend genutzt. Der Vorteil der SOA ist, dass Clients unabhängig vom Aufbau bzw. der Realisierung des Services erstellt werden können und sich nur um den Aufruf, die Interaktion mit dem Service kümmern müssen. Wichtig ist "nur" die Einhaltung der Definition der Schnittstelle. Beim Aufruf bestehender SOA Services spricht man daher von dem Aufruf einer Blackbox.

ERKENNTNISSE DER SOA STRATEGIE

Abbildung 6: Erfolgreichen Prozess- und Organisationsoptimierung im Unternehmen Quelle: http://www.trigonum.de (November 2008)

Auf Kostenseite erlauben standardisierte Schnittstellen bzw. festgelegte architektonische Richtlinien schnelle und kostengünstige Entwicklungen. Zusammen mit der erhöhten Verständlichkeit der zu erbringenden Lösung und der flexiblen (IT)-Prozessstrukturen ergibt sich ein Argumentationsvorteil in der Diskussion um eine SOA Einführung. Flexible und immer wieder angepasste (Geschäfts-) Prozesse bieten die Möglichkeit einen kontinuierlichen Verbesserungsprozess (siehe Abbildung 6) dauerhaft zu implementieren.

Erkenntnisse der SOA Strategie

Nach der betriebswirtschaftlichen und technischen Analyse der SOA wollen wir uns mit der Praxis beschäftigen und bekannte Probleme der SOA Einführung und entstandenen Missverständnissen genauer erläutern.

5.1

Bekannte Probleme bei der Einführung einer SOA

In den letzten Jahren ist SOA zu einem Schlagwort in Unternehmensstrategie(n) geworden. Bei der Einführung der SOA haben sich allerdings immer wieder Probleme ergeben (siehe Abbildung 7), die an dieser Stelle diskutiert werden sollen.

ERKENNTNISSE DER SOA STRATEGIE

Abbildung 7: Wichtige Eckpunkte der SOA Quelle: http://www.ap-verlag.de (Juli 2009)

Ein häufig auftretendes Problem ist, dass die neu eingeführte Strategie immer nur so lange auf bekannten Standards aufsetzt, bis die Architektur an unternehmensspezifische Grenzen stößt. Wenn man an dieser Stelle den standardisierten Weg verlässt und unternehmensspezifische Anpassungen implementiert muss jeden Unternehmen bewusst sein, dass ein Großteil der Vorteile der SOA (z.B. unternehmensübergreifende Verwendung) nicht mehr genutzt werden kann. Lassen sich SOA Standards im Unternehmen nicht anwenden, so deutet dieses oft auf falsch definierte Prozesse hin. An dieser Stelle sollten zuerst bestehende Prozesse genauer analysiert werden, bevor über die strategische Entscheidung der unternehmensspezifischen Anpassung der SOA nachgedacht wird. Ein weiteres Problem ergibt sich in der Planung einer SOA Einführung. In dieser Planung wird oft ein hoher Aufwand in die technische Gestaltung der neuen Architektur gesteckt. Die Migration der Bestandsdaten bzw. bestehender Altsysteme wird vernachlässigt, so dass es bei der Einführung zu Problemen kommt. Diese Probleme können durch eine intensivere Situationsanalyse vermieden werden. Werden heute vornehmlich die technischen Vorteile der Architektur gesehen, so versäumt man in der Planung häufig die Anforderungen der SOA an Performance und Security zu berücksichtigen. Probleme ergeben sich in der Regel nicht auf den ersten Blick. Erst eine langfristige Analyse deckt schwächen der Umgebung auf. An dieser Stelle sollte auf Erfahrungen von Partnerunternehmen oder auf Fachpublikationen zurückgegriffen werden. Eine nachträgliche Änderung der Umgebung kann für ein Unternehmen sehr aufwändig und kostenintensiv werden.

ERKENNTNISSE DER SOA STRATEGIE

Erfahrungen haben gezeigt, dass durch eine intensive Planung zur Einführung der SOA die meisten (bekannten) Probleme vermieden werden können. Ein Unternehmen sollte gerade beim Thema SOA lieber möglichst viel Zeit in die Planung investieren als später über Monate die eingeführte Lösung auf Schwachstellen und Fehler zu analysieren.

5.2

Bekannte Missverständnisse zum Thema SOA

Während den letzten Jahren halten sich in der Wirtschaft immer mehr Missverständnisse zum Thema SOA. Die zum Verständnis wichtigsten sollen an dieser Stelle genauer beleuchtet werden:

5.2.1

"Wenn du SOA einführst, sind alle deine Komponenten automatisch kompatibel zu einander" [SoaThe]

Laut Definition sind in einer SOA alle Komponenten kompatibel zu einander. Dieses bedeutet allerdings nicht, dass durch die Einführung von SOA alte, bestehende Komponenten problemlos kompatibel zu Neuentwicklungen nach SOA sind. Um dieses zu gewährleisten müssen die betroffenen Funktionalitäten und Schnittstellen der Alt-Systeme analysiert und in die SOA, also in Services transformiert werden.

5.2.2

"Wenn du Web Services verstehst, hast du keine Probleme eine SOA aufzubauen." [SoaThe]

Sehr große und intensive Diskussionen gibt es immer wieder um Web Services und den Zusammenhang zur SOA. Wer in der heutigen Zeit mit WS arbeitet hat mit Sicherheit einen großen Vorteil gegenüber den Unternehmen, in denen dieses Know-how fehlt. WS beschreiben allerdings nur einen kleinen, wenn auch wichtigen Teil der SOA. Wichtig ist, dass ein Verständnis dafür besteht, wie die Business Prozesse mit der Applikationslogik zusammen arbeiten und wie dieses bestmöglich in die SOA integriert werden kann. SOA erfordert somit weit mehr als "nur" WS Know-how. Es geht darum ein Verständnis für das Geschäft und die IT aufzubauen. Zusätzlich ist das Know-how über die Verknüpfungsmöglichkeiten dieser Themengebiete zwingend erforderlich.

SOA UND DER BEZUG ZU E-BUSINESS

5.2.3

"SOA löst fachliche Probleme" [SoaThe]

Das wohl größte Missverständnis ist, dass SOA fachliche Probleme löst. Durch SOA alleine können keine fachlichen Probleme gelöst werden. SOA soll vielmehr als ein Denkanstoß gesehen werden, um fachlichen Prozesse zu überdenken und in Richtung SOA aufzustellen. In diesem Veränderungsprozess können bestehende Probleme in den Business Prozessen behoben werden.

SOA und der Bezug zu E-Business

"E-Business ist die integrierte Ausführung aller automatisierbaren Geschäftsprozesse eines Unternehmens mit Hilfe von Informations- und Kommunikationstechnologie." [DeEbWi] Bei der SOA Strategie sprechen wir davon, einzelne Geschäftsprozesse in spezielle Services auszulagern und von einander lose zu koppeln. Wirtschaftlich versucht die SOA Geschäftsprozesse zu optimieren und diese aus technischer Sicht optimal in die Umgebungsarchitektur zu integrieren.

Abbildung 8: E-Business/Service Providers Infrastructure Quelle: http://www.advantech.com.tw (Juli 2009)

Wenn wir diese Zielsetzung mit der Definition von E-Business vergleichen, so ist die SOA optimal für den Einsatz im E-Business geeignet, da die Anforderungen (siehe Abbildung 8) des E-Business optimal umgesetzt werden können. Über die SOA lässt sich ein E-Business sehr gut konzipieren, betreiben, verwalten und gegebenenfalls gegen neue Anforderungen erweitern.

7 7.1

UNTERNEHMEN UND DEREN SOA EINSATZ

Unternehmen und deren SOA Einsatz Deutsche Post Brief

Die Deutsche Post Brief ist der größte Unternehmensbereich der Deutschen Post World Net und größter Briefdienstleister in Europa. Das folgende praxisnahe SOA Beispiel [SOAPuP] verdeutlicht, wie die Deutsche Post Brief ihre SOA entwickelt hat und zeigt dabei die Ziele, Umsetzung sowie den Nutzen dieser Einführung.

7.2

Gründe

Die IS-Architektur der Deutschen Post Brief wurde mit Blick auf die Vergangenheit nicht zentral geplant. Das führte dazu, dass Kerninformationen wie Kundendaten, Kosten oder Informationen über den Wettbewerb nicht von jedem System gleichermaßen verarbeitet werden konnten und daher jedes Teilsystem über einen eigenen Datenbestand verfügte. Ein weiterer entscheidender Faktor war die immer komplexer werdende Anzahl von IT-Projekten. Diese Schlüsselfaktoren führten dazu, dass neue Geschäftsanforderungen zunehmend seltener in dem gewünschten zeitlichen Rahmen umgesetzt werden konnten. Eine mangelnde projektübergreifende Koordination und Planung sorgte des Weiteren für eine große Anzahl von spezialisierten sowie in sich geschlossenen Anwendungssystemen. Die Folge waren redundante Funktionen in Anwendungen sowie eine mehrfache Datenhaltung geschäftsspezifischer Informationen. Heterogene, schlecht dokumentierte Schnittstellen einzelner Anwendungen, deren Abhängigkeiten nicht nachvollzogen werden konnten, führten zu einem enormen Anpassungsaufwand und geringer Wiederverwendung bei neuen Projekten. Zu guter Letzt stiegen die Investitionen in die Wartung/ Bertrieb der historisch gewachsenen IS-Architektur und IT-Infrastruktur, wodurch nicht mehr ausreichend IT-Budget für die Neu-/ Weiterentwicklung der bestehenden Systeme zur vorhanden war.

7.3

Ziele

Das aus den oben genannten Gründen abgeleitete Ziel der Deutschen Post Brief war eine zentral gesteuerte und geschäftsorientierte Applikationsarchitektur. Dabei sollte die

UNTERNEHMEN UND DEREN SOA EINSATZ

Applikationsarchitektur als eine Richtlinie zum Entwickeln von redundanzfreien Anwendungen hinsichtlich der Implementierung, Funktionalität und Datenhaltung dienen. Die Erwartung war eine bessere Wiederverwendbarkeit aller Funktionen zur Unterstützung neuer Prozesse und die Möglichkeit gezielt und isoliert neue Funktionen zu implementieren. Das Ergebnis aller Anforderungen war eine fachliche SOA, in denen voneinander isolierte Anwendungsdomänen und Schnittstellen die den Zugriff auf sämtliche Funktionen und Daten in diesen Domänen bereitstellen zum Einsatz kommen.

7.4

Umsetzung

Nach der Identifizierung der Kern-Geschäftsprozesse wurde aufbauend auf dieser Analyse eine fachliche Applikationsarchitektur entwickelt. In dieser wurde die fachliche Funktionalität sowie die Daten prozessunabhängig und ohne Redundanzen in die jeweiligen Applikationsdomänen abgebildet. Abbildung 9 illustriert das vorgehen. Dabei finden sämtliche Zugriffe auf die jeweiligen Domänen über spezielle Serviceschnittstellen statt, die jeweils in der Lage sind mehrere Operationen auszuführen. Alle Services wurden objektorientiert nach den Geschäftsobjekten Kunde, Rechnung, oder Vertrag abgebildet und stellen Funktionen wie z.B. anlegen, suchen oder löschen bereit.

Abbildung 9: Der Zugriff über Services auf Applikationsdomänen Quelle: [SOAPuP]

Die Umstellung der Applikationslandschaft auf die SOA soll anhand des Service Kundenmanagement - siehe dazu auch Abbildung 10 - vorgestellt werden. Der Service stellt

UNTERNEHMEN UND DEREN SOA EINSATZ

u.a. den Call-Center- oder CRM-Systemen Operationen wie seek, get, create, update, delete, getChildNodes und checkAdress bereit. Damit haben die Nutzer die Möglichkeit sämtliche Kundendaten zentral zu erfassen und zu verwalten. Die Menge an unterschiedlichen Anwendungen und ihrer lokalen Datenhaltung wurde zu einer zentralen Stammdatenbank migriert. Die bereits bestehenden Anwendungen sowie die neu implementierten verwenden diese Datenbank über die Serviceschnittstellen. Mobile Anwendungen, die nicht über einen dauerhaften Online-Zugang verfügen, speichern und arbeiten weiterhin mit lokalen Daten, welche aber regelmäßig mit der zentralen Datenbank synchronisiert werden.

Abbildung 10: Der Service Kundenmanagement Quelle: [SOAPuP]

7.5

Nutzen

Nach der erfolgreichen Umsetzung der Service Oriented Architecture identifizierte die Deutsche Post Brief folgenden Nutzen durch die Umstellung.

7.5.1

Wiederverwendung von Services und Vermeidung redundanter Softwareentwicklung

Die Services werden im Schnitt zwei- bis dreimal von unterschiedlichen Systemen wiederverwendet. Auf Grund der Wiederverwendung und systemweiten Harmonisierung

UNTERNEHMEN UND DEREN SOA EINSATZ

führte zu einer Reduzierung von Redundanzen und somit zu einer optimierten Datenkonsistenz.

7.5.2

Kürzere Projektlaufzeiten und schneller Time-To-Market

Die Entwicklung neuer Anwendungen lässt sich mittels der Wiederverwendung vorhandener Services von vielen Monaten auf einige Tage bzw. Wochen verringern.

7.5.3

Niedrigere Wartungskosten

Die Komplexität und Redundanzen der Applikationsarchitektur verringerten sich durch den Einsatz und die Bildung von Anwendungsdomänen sowie die bessere Kontrolle der Serviceschnittstellen. Das wirkte sich positiv auf die Kostenstruktur zur Wartung und Betrieb der IS-Architektur aus, wodurch ca. 7% mehr IT-Budget für die Entwicklung neuer Anwendungen zur Verfügung stehen.

7.5.4

Bessere Reaktionsfähigkeit auf neue Geschäftsanforderungen

Mit der Entwicklung einer Domänen- und Servicearchitektur schaffte die Deutsche Post Brief einen Vermittler zwischen der Prozess- und der Applikationsarchitektur. Dabei werden alle Daten und Funktionen der Applikationsarchitektur von einer technischen in eine fachliche Sicht übersetzt, wodurch sich die Kommunikation zwischen dem Fachbereich und dem IT-Bereich deutlich verbessert. Des Weiteren erhält der Fachbereich damit mehr Verantwortung, da dieser nun auch für Daten und Services einzelner Anwendungsdomänen zuständig ist.

SOA & SICHERHEIT

SOA & Sicherheit

8.1

Anforderungen

8.1.1

Authentifizierung

Soll die Verifikation einer Identität in einem System sicherstellen. Dabei kann es sich um eine Person, ein Gerät oder einen anderen Service handeln. Mittels der Authentifizierung kann kontrolliert werden, wer oder was einen bestimmten Service aufruft. In der Regel sollten Sicherheitsfunktionen wie eine Public Key Infrastructure, in der Zertifikate verwendet werden, zum Einsatz kommen. Damit können weitere Anforderungen wie die Integrität und Vertraulichkeit sichergestellt werden.

8.1.2

Autorisierung

Dient der Prüfung, ob eine bestimmte Identität Zugriff auf eine Ressource erhalten darf. Dabei handelt es sich z.B. um eine Kontrollfunktion, ob ein bestimmter Service aufgerufen werden darf. In der Regel wird in diesem Kontext das Rollenkonzept verwendet. Darin werden Benutzer bestimmten Rollen und Gruppen zugewiesen, die dann mit Rechten ausgestattet sind.

8.1.3

Vertraulichkeit/ Privatsphäre

Der Transport der Daten muss vertraulich behandelt werden. Das bedeutet, dass ein nicht autorisierter Zugriff auf die Daten in jedem Fall verhindert werden muss. Nur autorisierte und authentifizierte Identitäten dürfen auch Zugriff auf die Daten erhalten. Die Vertraulichkeit umfasst das Lesen, Verändern und Löschen von Daten und kann mittels kryptografischer Verfahren gewährleistet werden.

8.1.4

Integrität

Integrität wird in Datenintegrität und Herkunftsintegrität unterteilt. Die Datenintegrität soll sicherstellen, dass die Daten während der gesamten Übertragung nicht manipuliert

SOA & SICHERHEIT

werden. Die Herkunftsintegrität hingegen ist für die korrekten Absenderdaten verantwortlich. Das beinhaltet, dass der Absender die Daten vertrauensgemäß hinterlegt hat und dass diese während der Übertragung nicht verändert worden sind.

8.1.5

Verfügbarkeit

Das System muss resistent gegenüber Angriffen sein, die versuchen das System so zu überlasten, dass es nicht mehr reagieren kann und nicht erreichbar ist. Des Weiteren muss das System für alle autorisierten Identitäten zu jeder Zeit zugänglich sein, so dass diese Zugriff auf ihre gewährten Informationen und Ressourcen haben. Ein Single-Point-ofFailure sollte daher in jedem Fall vermieden und auf eine lose Kopplung aller Komponenten geachtet werden.

8.2 8.2.1

Risiken & Bedrohungen Replay Attacks

Das erneute Senden einer bereits gesendeten Nachricht. Ein System merkt sich nicht, welche Nachrichten bereits bearbeitet wurden. Eine Replay Attacke kann wie folgt beschrieben durchgeführt werden. Ein Angreifer fängt eine Nachricht auf dem Weg zur Versandabteilung ab. Er sendet diese Nachricht zu einem späteren Zeitpunkt erneut an das System. Da das System nicht erkennt, dass die Nachricht bereits verarbeitet wurde, kann z.B. ein kostenpflichtiger externer Service mehrmals aufgerufen werden. Handelt es sich bei dem externen Service z.B. um eine Kreditkartenvalidierung, würde für das angegriffene Unternehmen dadurch Kosten entstehen.

8.2.2

XML Spezifische Angriffe

XML-Bombs XML-Bombs sind endlose Rekursionen innerhalb von XML-Dokumenten. Dabei wird Die XML Funktion DOCTYPE ausgenutzt, die zur Definition von Entitäten verwendet, die als Platzhalter dienen. Das folgende Beispiel illustriert die Funktionsweise.

SOA & SICHERHEIT

Abbildung 11: Eine XML Bomb

Um das Beispiel zu erläutern, fangen wir am Ende an. Dem Entity /d/ wird der Werte wow zugewiesen. In der Zeile darüber wird dem Entity /c/ drei Mal das Entity /d/ zugewiesen. Das bedeutet, dass /c/ drei mal den Wert von /d/ beinhaltet. In der darüber liegenden Zeile wird dem Entity /b/ drei Mal der Wert von /c/ zugewiesen und letztendlich erhält das Entity /a/ drei Mal den Wert von /b/. Wird nun einmal das Entity /a/ aufgerufen erhalten wir eine Ausgabe, in der 27 Mal der Wert w ausgegeben wird.

XPath-Injection XPath-Injection kann das Verhalten der Anwendung ändern, indem in Platzhaltern für Daten (Variablen) ein spezielles Code-Stück platziert wird. Es ist auch als SQL-Injektion für Datenbankabfragen bekannt. Das folgende Beispiel illustriert die Funktionsweise.

Abbildung 12: XPath-Injection

SOA & SICHERHEIT

Die obere Maske lässt Eingaben für den Benutzer und sein Passwort zu. Wird für die Variable /user/ der String ’user’ und für die Variable /passwort/ der String ’or ’1’=’1’ eingetragen, liefert die Ergebnismenge alle Benutzer des Systems, denn 1=1 ist immer Wahr. Das funktioniert aber nur dann, wenn die Spalte der Benutzer in der Datenbank auch ’user’ lautet.

8.2.3

WSDL- und Service Scanning

Details und Parameter eines Web-Service sind öffentlich zugänglich. Damit stehen ausreichend Informationen zur Verfügung, die verwendet werden können. Mittels einer Softwareanalyse kann ein Angriff den Dienst auf Schwachstellen untersuchen und damit weitere Angriffsmöglichkeiten entdecken.

8.2.4

Kompromittierung eines Service

Services sind in der Regel (öffentlich) verteilt - wenn die SOA externe Services berücksichtigt. Durch manipulieren eines Service oder platzieren eines ’schlechten’ Service im Repository können andere Services bzw. Geschäftsprozesse beeinflusst werden.

8.2.5

Unberechtigte Servicenutzung

Möglichkeiten dürfen nie ausgeschlossen werden, die es erlauben, dass ein nicht korrekt autorisierter Nutzer Zugriff auf einen Teil des Geschäftsprozesses bzw. auf einen oder mehrere Services erhält. Das muss administrativ (z.B. durch Security Policies) strikt überprüft und unterbunden werden.

8.3 8.3.1

Konzepte Sicherheit auf Transportebene

Die Absicherung der Protokolle kann mittels SSL/ TLS verschlüsselt und damit geschützt werden. Statt z.B. HTTP wird dann HTTPS verwendet. In diesem Fall spricht man von Sicherheit auf Transportebene. Hierbei handelt es sich allerdings nur um eine Punkt zu Punkt Verschlüsselung zwischen zwei Systemen. Das bedeutet, dass die Daten nur auf

SOA & SICHERHEIT

dem Transportweg geschützt und keine Ende-zu-Ende Verschlüsselung von Absender zu Empfänger über mehrere Host vorhanden ist. Systeme welche die Daten weiterleiten haben somit Zugriff auf die Daten, da die Daten selber nicht verschlüsselt sind.

Abbildung 13: Sicherheit auf Transportebene Quelle: [BSI]

8.3.2

Sicherheit auf Nachrichtenebene

Da bei einer SOA aber Nachrichten-basierte Systeme eingesetzt werden, die offene, einfach zu lesende Standards (XML) verwenden, muss die Integrität der Daten auf Nachrichtenebene sichergestellt werden. Hierbei wird nicht nur der eigentliche Übertragungsweg geschützt, sondern ebenfalls eine Änderung an der Nachricht selbst vorgenommen. Bei einer SOA ist zudem wichtig, dass eine Nachricht nicht immer vollständig, sondern nur Teile von ihr geschützt werden. Gründe dafür sind zum einen die Geschwindigkeit zum Übermitteln der Nachricht, zum anderen der Gesamtprozess der Übermittlung. Im zweiten Fall kommt es in der Regel vor, dass ein Empfänger eine Nachricht weiterverarbeiten muss und diese anschließend weiterleitet, aber nicht den Inhalt der gesamten Nachricht lesen darf. Ein Beispiel wäre eine Bestellung, in der unterschiedliche Daten des Kunden vorhanden sind. Die Bestellung durchläuft unterschiedliche Empfänger (Stationen, Prozesse), die nur Zugriff auf die für sie bestimmten Informationen erhalten dürfen.

Abbildung 14: Sicherheit auf Nachrichtenebene Quelle: [BSI]

Im einfachsten Fall werden die Daten vom Sender anhand eines kryptografischen Verfahrens verschlüsselt, bevor dieser die Daten zum Empfänger sendet. Die Daten werden in diesem Zustand durch alle dazwischen liegende Systeme übertragen. Nur der Empfänger

SOA & SICHERHEIT

der Daten kann diese am Ende entschlüsseln. Man spricht daher auch von einer Ende-zuEnde Sicherheit. Nur der Payload (Nutzdaten) werden i.d.R. verschlüsselt. Die Daten die für den Transport notwendig sind, befinden sich in einem separaten Header.

8.3.3

XML-Firewalls/ XML-Gateways

XML-Firewalls/ Gateways blocken invalide bzw. schädliche XML Dokumente. Dafür existieren unterschiedliche Möglichkeiten, wie und wo die Firewall bzw. das Gateway platziert wird. Zentrale Firewall, die alle eingehenden Dokumente prüft bietet keine Endezu-Ende Sicherheit, sondern nur Punkt-zu-Punkt. Eine andere Möglichkeit besteht darin, denzentrale Firewalls einzusetzen. Dabei wird vor jedem Webservice wird eine Firewall geschaltet. Dies ist allerdings sehr kostenintensiv und schwer zu verwalten. XMLGateways können im Gegensatz zu Firewalls auch Transformationen an den Dokumenten vornehmen. Die Dokumente müssen immer für Firewall/ Gateway verschlüsselt werden, da sonst die XML-Validierung fehlschlägt. Das liegt daran, dass die Firewall/ Gateway nicht in ein verschlüsseltes Dokument hineinschauen kann. Das kann zu Problemen führen, wenn das XML-Dokument an einen inneren Geschäftsprozess gerichtet ist.

8.3.4

Sicherheit auf Fachlicher Ebene

Die Sicherheit wird in die fachlichen Schnittstellen der Services implementiert. Es werden z.B. eigene Sicherheitstoken entwickelt, die dann untereinander ausgetauscht werden. Eine weitere Möglichkeit besteht darin, dass die Verschlüsselung bzw. Entschlüsselung selber definiert wird. Diese Formate müssen dann Bestandteil des Service-Vertrags sein.

8.3.5

Applikationssicherheit

Die Anwendungslogik wird von der Sicherheitslogik getrennt. Die Sicherheitsanforderungen einer Anwendung müssen bereits vor der eigentlichen Entwicklung erfasst und koordiniert werden. Werden die Sicherheitsmaßnahmen erst nachträglich implementiert, wird es wesentlich teurer und der Schutz ist im Vergleich zur Implementierung der Sicherheit während des Entwicklungsprozess der Anwendung niemals so hoch und sicher. Sicherheit muss aus diesem Grund ein wesentlicher Bestandteil des gesamten Lebenszyklus einer Anwendung sein.

SOA & SICHERHEIT

8.3.6

Security as a Service

Innerhalb einer SOA Architektur wird auch der Anspruch erhoben, die Sicherheit von der Anwendungslogik zu trennen und somit als einen eigenen wieder verwendbaren Service bereitzustellen. Der Begriff Security as a Service verkörpert dabei Sicherheitsmethoden, die als Dienst mittels standardisierte Schnittstellen zur Verfügung gestellt werden und von allen Anwendungen bzw. Komponenten gleichermaßen verwendet werden können. Die Wiederverwendbarkeit eines solchen Konzepts steht dabei besonders im Mittelpunkt, da die Sicherheitsmethoden von unterschiedlichen Anwendungen gleichermaßen genutzt werden können. Eine Methode von Security as a Service ist die Authentifizierung und Autorisierung von Entitäten. Dabei handelt es sich um ein zentrales System, i.d.R. einen so genannten Identitätsanbieter. Dieser verwaltet die Entitäten mit ihren zugehörigen Rollen und Profilen und gewährt ihnen von zentraler Stelle aus den Zugriff auf Dienste und Ressourcen.

Abbildung 15: Security as a Service Quelle: www.soa-know-how.de (Juli 2009)

8.3.7

Security as Infrastructure

Security as Infrastructure wird dann eingesetzt, wenn die Sicherheits und von Anwendungslogik getrennt werden soll. In der Regel werden Systeme während der Kommunikation von speziellen Komponenten (Appliances oder Proxys) geschützt. Ein Proxy dient dabei als eine Art Vermittler, der zwischen den Anwendungen und Netzwerken und den eigentlichen Systemen (Services) steht. Proxies sind in der Lage Informationen innerhalb

SOA & SICHERHEIT

der Nachrichten zu kontrollieren, bzw. zu platzieren oder auszulesen, da sie unmittelbar zwischen den jeweiligen Hosts agieren.

8.4 8.4.1

Standardisierte Sicherheitsmaßnahmen XML-Security

XML Encryption Dabei handelt es sich um die Verschlüsselung von XML Dokumenten. Dabei kann das gesamte Dokument, oder nur Teile verschlüsselt werden z.B. ’nur die Kredikartennummer’ oder ’alles außer dem Benutzernamen’. XML-Signatur Wird für das digitale Signieren von XML Dokumenten verwendet und dient dem Sicherstellen der Integrität und Authentizität der Daten. XML Key Management (XKMS) Wird für die Verwaltung der Schlüssel/ Zertifikate bei der XML-Signatur verwendet.

8.4.2

WS Security

Ist ein Standard für die Authorisierung und Integrität von Web-Services und dem Protokoll SOAP. Es handelt sich dabei um Verfahren für die Integration von Token, Schlüssel, Signaturen in eine SOAP-Nachricht. WS Trust Ist ein Standard für das Ausstellen, Erneuern und Validieren von Sicherheitstoken. Dient zur Etablierung, Vermittlung und Beurteilung sicherer Beziehungen. WS Security-Policy Ermöglicht das Herausfinden, welcher Service-Anbieter welchen Sicherheitsstandard unterstützt bzw. erwartet. WS SecureConversation

SOA & SICHERHEIT

Dient zum Etablieren eines gemeinsamen Sicherheitskontext für den Austausch mehrerer Nachrichten. Damit sollen Anfragen zu einer Session an einen Identitätsanbieter reduziert werden. WS Federation Definiert Mechanismen für die Integration und den Zusammenschluss unterschiedlicher Sicherheitsbereiche durch gegenseitigen Austausch von Identitäten, Attributen und Authentifizierungen.

8.4.3

Security Assertion Markup Language

Wird verwendet um erweiterte Sicherheitsinformationen in SOAP-Dokumente zu integrieren. Dabei wird auf ein beliebiges "Subject" bezug genommen, z.B. einen Service Consumer der einen Web-Service aufruft. Diese Subects werden als Assertions integriert. Assertions definieren drei zusätzliche Einträge um Eigenschaften zu definieren. Attribute Statement Damit können vertrauenswürdige Aussagen über beliebige Attribute eines Subjects z.B. einer Email Adresse gemacht werden. Authentication Decision Statement Entscheidung ob ein Subject autorisiert ist auf eine Ressource zuzugreifen wird in die Nachricht integriert Authentication Statement Erweiterte Authentifizierungsinformationen können damit in eine SOAP-Nachricht eingebunden werden, z.B. ein Zertifikat etc.

8.5

Fazit

Innerhalb von SOA-Infrastrukturen kommen überlicherweise dieselben Sicherheitsaspekte und Mechanismen zum Einsatz, wie sie aus dem Bereich der verteilten Systeme bekannt sind. Zusätzlich zu diesen Konzepten müssen bei einer SOA weitere Dinge beachtet werden. [SOAidP]

SOA & SICHERHEIT

• Innerhalb einer SOA arbeiten viele (fremde) Systeme miteinander zusammen, was die Verwendung von Standard Sicherheitskonzepten stark reduziert. • Dabei müssen die jeweiligen heterogenen Sicherheitskonzepte der Systeme berücksichtigt werden. • Durch den Einsatz von verteilten Systemen, bei denen die Nachrichten über unterschiedliche Systeme übertragen und dabei von verschiedenen Services aufgerufen werden, reicht eine Punkt zu Punkt Sicherheit nicht mehr aus. • Die Daten müssen auf Nachrichtenebene geschützt werden, was dadurch zu einer Ende zu Ende Sicherheit führt. • Innerhalb einer SOA greifen die unterschiedlichsten Entitäten auf Services und Ressourcen zu. Daher müssen die Sicherheitsprüfungen zur Laufzeit stattfinden. Abschließend sollten Sicherheitskonzepte als Service (Security as a Service) bereitgestellt werden um einen einheitlichen Ansatz zu definieren. Auf diesen sollte die gesamte Architektur aufbauen, damit alle Anwendungen und Komponenten darauf zentral zugreifen können.

LITERATUR

LITERATUR [SoRzOs] Roger Zacharias. Serviceorientierung: Der OO-König ist tot, es lebe der SOA König!, OBJEKTspektrum, April 2005 [SoaThe] Thomas Erl. Service-Oriented Architecture: Concepts, Technology, and Design, Indiana: Prentice Hall International, 2006 [SagSoC] Service Oriented Architecture (SOA) advocacy group. SOA Consortium http://www.soa-consortium.org, 2009. [SOAErNu] SOA erfolgreich nutzen, JavaSPEKTRUM, März 2006 [DeEbWi] Wikipedia. Definition E-Business http://de.wikipedia.org/wiki/E-Business, Juli 2007. [SOAPuP] Roger Heutschi. Serviceorientierte Architektur (Business Engineering), Berlin: Springer, 2007 [BSI] Bundesamt für Sicherheit in der Informationstechnik. Sicherheitskompendium für Service-orientierte Architekturen (SOA) http://www.bsi.bund.de/literat/studien/soa/SOA-Security-Kompendium.pdf, 2009. [SOAidP] Nicolai Josuttis. SOA in der Praxis: System-Design für verteilte Geschäftsprozesse, Heidelberg: Dpunkt Verlag, 2008