Zusammenfassung

Sicherheitsservices für Service Oriented Architecture (SOA) am Fallbeispiel Enterprise SOA

Service Oriented Architecture - Durch sie ist es möglich, Geschäftsprozesse zu automatisieren und dabei völlig flexibel auf unternehmensspezifische Veränderungen einzugehen. Hierfür müssen Unternehmen jedoch ihre bisher im Einsatz befindlichen Sicherheitsmechanismen anpassen und für Geschäftspartner öffnen. So wird es möglich, durchgängige und automatisierte Geschäftsprozesse abzubilden und damit die Vorteile der globalen Märkte mit Hilfe des neuen Architekturgedankens zu nutzen. Dies birgt neben den Chancen aber auch Risiken.

Unternehmen müssen sich dieser Gefahren bewusst werden und sie bewerten, nur so können entsprechende Maßnahmen zur Reduzierung des Risikos ermittelt werden. Hierfür ist ein strukturiertes und prozessorientiertes Vorgehen notwendig. Im von der Autorin beschriebenen Verfahren wird zu diesem Zweck zunächst der Schutzbedarf für den zu analysierenden Geschäftsprozess ermittelt. Anschließend werden Risiken identifiziert und deren Risikohöhe mit Hilfe der Eintrittswahrscheinlichkeit und des Schadensausmaßes bestimmt. Mittels dieser Werte kann eine Aussage über die Notwendigkeit der Risikominimierung gemacht werden, um effektive Kontrollmaßnahmen zu ermitteln, beginnend beim kritischsten Risiko.

Grundlegender Gedanke und Nutzen einer SOA ist die Wiederverwendbarkeit. Dies trifft auch auf die Sicherheitsaspekte zu. Mithin demonstrierte die Autorin das zuvor beschriebene Verfahren an zwei Geschäftsprozessen, so dass auf Basis der erhaltenen Kontrollen Sicherheitsservices bestimmt werden konnten. Diese enthalten sinnvolle Kombinationen von technischen und nicht-technischen Maßnahmen zur ganzheitlichen Absicherung von Geschäftsprozessen und können immer wiederverwendet werden. Schließlich wurden die Sicherheitsservices in die SAP-spezifische Lösung der SOA, die Enterprise SOA, übernommen. Zur sicheren Realisierung der Enterprise SOA beim Kunden müssen darüber hinaus weitere Aspekte berücksichtigt werden. Aus diesem Grund wurde beispielsweise aufgezeigt, wie interne Governance-Richtlinien einbezogen, gesetzliche Vorschriften eingehalten oder auch bisherige Sicherheitsmechanismen in die Enterprise SOA über- tragen werden.

Abstract

Security services for Service Oriented Architecture (SOA) on the paradigm Enterprise SOA

Service Oriented Architecture enables automation of business processes. It is flexible and can be adapted to the specific requirements of organizations, thereby making the more responsive to occurring changes. In order to fully realize all benefits, it is required for companies to open their IT security infrastructure for direct communication with business partners. This would allow mapping and automation of business processes along the entire value chain and across global markets. The advantages do not come without risks, however.

Organizations need to know and understand these risks so that they can be properly managed and mitigated. Therefore, a structured, processoriented approach is essential. In the technique described by the author, the first step is to identify the required security level for the business process being analyzed. Next, the security risks must be identified and categorized taking into account the parameters for likelihood and impact. According to the various categories it is then possible to assess the need for mitigation and institute appropriate security inspection measures, beginning with the most critical risk.

One of the major benefits of SOA is reusability. This applies to security as well. Using the process-oriented approach described above on two business process examples the author created so called security services derived from the obtained security measures. These involves suitable combinations of technical and non-technical procedures to safeguard the business processes and are completely reusable.

Finally, the security services are introduced into the Enterprise SOA, which is an SAP-specific implementation of SOA. However, there are additional security issues to be considered in implementing Enterprise SOA for a customer. The author discusses how to develop internal governance policies, how to comply with legal regulations, and how to maintain existing security mechanisms for Enterprise SOA.

Danksagung

An dieser Stelle möchte ich allen Personen danken, die wesentlich zum erfolgreichen Erstellen meiner Arbeit beigetragen haben. Ich danke

• Prof. Dr. Heinz Jürgen Müller für die Betreuung meiner Arbeit von BA-Seite aus und die vielen interessanten Gespräche,

• Barbara Mayer (SAP) für die zahlreichen inhaltlichen und fachlichen Tipps, die interessanten und anspruchsvollen Aufgaben, auch neben der Diplomarbeit, die ständige Sorge um mein Wohlbefinden und die sehr gute Zusammenarbeit, wodurch ich mich in den paar Monaten bei SAP sehr heimisch gefühlt habe,

• Max Larsson und Dr. Markus Schumacher (Fraunhofer SIT) für die inhaltlichen und rechtschreiblichen Anmerkungen, die sehr gute kollegiale Kommunikation und die unkomplizierte Zusammenarbeit.

Darüber hinaus gab es zahlreiche andere Personen, welche mich permanent unterstützten oder weitere Ideen für die Arbeit gaben. So danke ich

• meinem Mann Marko Hamel (SAP) für das permanente Korrektur-Lesen, die zahlreichen fachlichen Diskussionen, die vielen Momente zum Knetschen, damit ich Abstand zur Arbeit gewinnen und anschließend wieder voller Elan weiter arbeiten konnte, die hervorragende Hilfe im Haushalt und bei unseren Kindern, ohne welche mein Kopf nicht so frei für die Arbeit hätte sein können und die vielen anderen Dinge, die mir das gesamte Studium erst ermöglichten,

• meinen Eltern Brigitte und Klaus Mäder für das finale Korrektur-Lesen, so dass nun ziemlich alle Rechtschreib- und Tippfehler beseitigt sein müssten, und für all die Dinge, die sie mir in meinem Leben mitgaben und beibrachten, so dass mir dieses Studium und nun ein erfolgreicher Berufsstart möglich wurde,

DANKSAGUNG

unbewusst zum Gelingen der Arbeit verhalfen. All diese sollen hier nicht vergessen bleiben, denn auch ihnen gilt mein Dank dafür.

II

Inhaltsverzeichnis

  Abbildungsverzeichnis  VII

Tabellenverzeichnis   IX

  Listingverzeichnis  XI

  Abkürzungsverzeichnis  XIII

1  Einleitung  1

1.1  Fragestellungen und Zielsetzung  2

1.2  Aufbau der Arbeit  3

1.3  Hinweise zur Arbeit  6

2  Forschungsgrundlagen  7

2.1  Definitionen  8

2.1.1  Schutzbedürfnisse  8

2.1.2  Risiko  11

2.1.3  Kontrolle  12

2.1.4  Sicherheitsservices  13

2.2  Von Web Services zur Service Orientierten Architektur  14

2.2.1  Web Services  14

2.2.2  Service Orientierte Architektur (SOA)  16

2.3  Standards bei Web Services  26

2.3.1  Grundstandards  26

2.3.2  Sicherheitsstandards  34

3  Risikoanalyse und -klassifizierung  43

3.1  Methoden zur Risikoanalyse und -klassifizierung  44

3.1.1  Bekannte Verfahren  45

3.1.2  Vorgehen im Kontext der Arbeit  49

3.2  Erstellen eines Risikokataloges für die Service Orientierte Ar-  

  chitektur  51

3.2.1  Beispiel 1: Purchase to Pay  51

3  2 2 Beispiel 2: SEPA-Überweisung  69

INHALTSVERZEICHNIS

4  Implementierung von Kontrollmaßnahmen  89

4.1  Methoden zur Bestimmung geeigneter Kontrollmaßnahmen  90

4.1.1  Bekannte Verfahren  90

4.1.2  Vorgehen im Kontext der Arbeit  91

4.2  Erstellen eines Kontrollkataloges zur Absicherung der Service  

  Orientierten Architektur  97

4.2.1  Ermitteln von Kontrollmaßnahmen  97

4.2.2  Ermitteln von Sicherheitsservices  123

4.2.3  Bewerten der Sicherheitsservices  138

5  Paradigma: Enterprise SOA  161

5.1  Aufbau und Funktionsweise  162

5.1.1  Entwicklung  162

5.1.2  SAP NetWeaver  163

5.1.3  Enterprise SOA  168

5.2  Sicherheitsbetrachtung  174

5.3  Prozessorchestrierung mit Enterprise SOA  176

5.3.1  SAP NetWeaver Composition Environment  176

5.3.2  Prozess orchestrieren  177

5.3.3  Zuweisung der Sicherheitsservices  181

5.4  Enterprise SOA-Sicherheit in der Beratungspraxis  182

5.4.1  Rechtliche Sicherheitsaspekte für die IT  183

5.4.2  Vorgehensweise im Projekt  185

6  Fazit  191

A  Listings zu Web Service-Standards  193

B  Abbildungen zur Prozessorchestrierung mit Enterprise SOA205  

  Glossar  215

  Literaturverzeichnis  219

VI

  Abbildungsverzeichnis  

1.1  Forschungsfragen und Aufbau der Arbeit  4

2.1  Zusammenspiel von Web Services  15

2.2  Web Services Architecture Stack  16

2.3  Aufbau einer SOA  19

2.4  Modell eines SOA-Stacks  20

2.5  Das ESB-Konzept  22

2.6  SL&I-Modell nach Offermann  25

2.7  WSDL-Script  29

2.8  UDDI-Registry der SAP AG  30

2.9  Erweiterungen von WS-Security  39

2.10  Beispiel-Szenario für die Verwendung von SPML  41

3.1  Risikomangement-Prozess  44

3.2  Zusammenwirken der Analyse-Verfahren  46

3.3  Kategorisierung der Analyse-Methoden  48

3.4  Matrix zur Bestimmung der Risikohöhe  50

3.5  Prozess „Zulieferer auswählen“  53

3.6  Prozess „SEPA-Überweisung“  72

4.1  Funktionsweise der Sicherheitsservices und des ESB  130

5.1a  Monolithische Anwendungsstruktur  163

5.1b  Zweischichtige Anwendungsstruktur  163

5.1c  Dreischichtige Anwendungsstruktur  164

5.1d  Derzeitige Unternehmensstruktur  164

5.1e  Enterprise Services Architecture  165

5.2  Kernbereiche des SAP NetWeaver  166

5.3  SAP NetWeaver Process Integration als Basis für Enterprise  

  SOA  167

5.4  Enterprise SOA und SAP NetWeaver  170

5  5 SAP NetWeaver Security  175

  ABBILDUNGSVERZEICHNIS  

  B.1 SAP Developer Network  206

  B.2 Enterprise Service Workplace  207

  B.3 Enterprise Services Index nach Prozesskomponenten  208

  B.4 Prozesskomponente „Purchase Request Processing“  209

  B.5 Enterprise Service „Manage Purchase Request In“  210

  B.6 Enterprise Services Operation „Create Purchase Request“  211

  B.7 Informationen zur ES Operation „Create Purchase Request“  212

  B.8 Business Object „Purchase Request“  212

  B.9 Link zur detaillierten Feldbeschreibung für die ES Operation  

  „Create Purchase Request“  212

  B.10 Detaillierte Feldbeschreibung für die ES Operation „Create  

  Purchase Request“  213

VIII

  Tabellenverzeichnis  

2.1  Bei XML-Signature verwendete Algorithmen  38

3.1  Beispiel für Bewertung des Schutzbedarfs  49

3.2  Beispiel zur Auflistung der identifizierten Risiken  51

3.3  Beispiel für den Risikokatalog  51

3.4  Schutzbedarf im Prozess „Zulieferer auswählen“  56

3.5  Risiken für den Prozess „Zulieferer auswählen“  59

3.6  Risikokatalog für den Prozess „Zulieferer auswählen“  69

3.7  Schutzbedarf im Prozess „SEPA-Überweisung“  74

3.8  Risiken für den Prozess „SEPA-Überweisung“  78

3.9  Risikokatalog für den Prozess „SEPA-Überweisung“  87

4.1  Beispiel zur Auflistung von Kontrollmaßnahmen  92

4.2  Beispiel zur Klassifizierung der Risiken  93

4.3  Beispiel zur Auflistung von Sicherheitsservices  94

4.4  Beispiel zur Zuordnung von Kontrollmaßnahmen und Sicher-  

  heitsservices  95

4.5  Beispiel für den Kontrollkatalog  96

4.6  Liste von Kontrollmaßnahmen  106

4.7  Klassifizierung der Risiken für den Prozess „Zulieferer aus-  

  wählen“  108

4.8  Klassifizierung der Risiken für den Prozess „SEPA-Überwei-  

  sung“  117

4.9  Liste von Sicherheitsservices  129

4.10  Kontrollmaßnahmen und Sicherheitsservices für den Prozess  

  „Zulieferer auswählen“  133

4.11  Kontrollmaßnahmen und Sicherheitsservices für den Prozess  

  „SEPA-Überweisung“  137

4.12  Kontrollkatalog für den Prozess „Zulieferer auswählen“  148

4  13 Kontrollkatalog für den Prozess „SEPA-Überweisung“  160

  TABELLENVERZEICHNIS  

5.1  Prozess „Zulieferer auswählen“ mit benötigten Enterprise Ser-  

  vices  180

X

  Listings  

  A.1 XML-Script  194

  A.2 SOAP-Script  195

  A.2 SOAP-Script (Forts.)  196

  A.3 HTTP-Header  196

  A.4 WSDL-Script  197

  A.4 WSDL-Script (Forts.)  198

  A.4 WSDL-Script (Forts.)  199

  A.5 UDDI - Anmelden eines businessEntity-Elements bei der Re-  

  gistry  199

  A.6 Prozessformulierung mit BPEL  200

  A.7 GET-Request in REST-Architektur  200

  A.8 XML Encryption  201

  A.9 XML Signature  202

  A.10 Syntax einer SOAP Nachricht mit WS-Security  202

A  11 Authentifizierung mit SAML  203

ABKÜRZUNGSVERZEICHNIS

AG Aktiengesellschaft

API Application Programming Interface

A2A Application-to-Application

BAPI Business Application Programming Interface BDB Bund Deutscher Banken BPEL4PEOPLE WS-BPEL Extension for People BI Business Intelligence BIC Bank Identifier Code

BO Business Object

BPEL Business Process Execution Language BPEL4WS BPEL For Web Services BPM Business Process Management BPML Business Process Modelling Language BSI Bundesamt für Sicherheit in der Informationstechnologie BSP Building as a Service Provider B2B Business-to-Business

CAF Composite Application Framework CE Composition Environment CEO Chief Executive Officer

CFO Chief Financial Officer CIA Central Intelligence Agency CIO Chief Information Officer CORBA Common Object Request Broker Architecture CRM Customer Relationship Management CSM Clearing & Settlement Mechanismus

DCOM Distributed Component Object Model DoS Denial of Service DTD Document Type Definition

EAI Enterprise Application Integration EBICS Electronic Banking Internet Communication Standard EC Electronic Cash ECM Enterprise Content Management

EDIFACT Electronic Data Interchange For Administration, Commerce and Transport

EIPP Electronic Invoice Presentment and Payment EJB Enterprise JavaBeans EPC European Payments Council ERM Enterprise Risk Management ERP Enterprise Resource Planning

ES Enterprise Service ESB Enterprise Service Bus

ESRRA Einzelsystem-Restrisiko-Analyse EU Europäische Union EU-Kommission Europäische Kommission

XIV

ABKÜRZUNGSVERZEICHNIS

EVT Extrem Value Theory EW Eintrittswahrscheinlichkeit EZB Europäische Zentral-Bank

FMEA Failure Mode and Effects Analysis FTP File Transfer Protocol

GUI Graphical User Interface

HR Human Ressources HTML HyperText Markup Language HTTP HyperText Transport Protocol HTTPS HTTP Secure

IBAN International Bank Account Number ICM Internet Connection Manager ID IDentifier IdAS Identity Attribute Service IDE Integrated Development Environment IDL Interface Description Language IFX Interactive Financial Exchange IIOP Internet Inter ORB Protocol IM Identity Management IP Internet Protocol IT Information Technology

JCA Java Cryptogrphy Architecture JCo Java Connector JDBC Java DataBase Connector

XV

JEMS JBoss Enterprise Middleware Suite JSF JavaServer Faces J(2)EE Java (2) Platform, Enterprise Edition

KonTraG Gesetz zur Kontrolle und Transparenz im Unternehmensbereich

MARCO MAximized Risk COntrol MDA Model Driven Architecture MOM Message-Oriented Middleware

OASIS Organization for the Advancement of Structured Information Standards

PDF Portable Document Format PE-ACH Pan European Automated Clearing House PI Process Integration PIC Process Integration Content Council PKI Public Key Infrastructure

QoS Quality of Service

R Risikohöhe RBAC Role Based Access Control REST REpresentational State Transfer RFC Remote Function Call RMI Remote Method Invocation RoI Return on Investment RPC Remote Procedure Call RR Rest-Risiko

SA Schadensausmaß

XVI

ABKÜRZUNGSVERZEICHNIS

SaaS Software as a Service SAML Security Assertion Markup Language

SDN SAP Developer Network SDO Service Data Object SEPA Single Euro Payments Area

SGML Standard Generalized Markup Language SIT Sichere InformationsTechnologie SLCM Solution Life Cycle Management SL&I Service-Layers and -Interactions SMTP Simple Mail Transport Protocol SOA Service Oriented Architecture SOX Sarbanes-Oxley-Act SPML Service Provisioning Markup Language SSL Secure Sockets Layer STP Straight Through Processing

SWIFT Society for Worldwide Interbank Financial Telecommunication SWOT Strengths, Weaknesses, Opportunities and Threats

TCP Transmission Control Protocol TLS Transport Layer Security

UBR UDDI Business Registry

UDDI Universal Description Discovery and Integration UNIFI UNIversal Financial Industry URI Uniform Resource Identifier URL Uniform Resource Locator

XVII

VaR Value at Risk

VoIP Voice over IP VPN Virtual Private Network

WCF Windows Communication Foundation W3C World Wide Web Consortium WSA Web Service Architecture

WS-BPEL Web Services Business Process Execution Language WSCI Web Services Choreography Interface WSDL Web Services Description Language

XACML eXtensible Access Control Markup Language XI eXchange Infrastructure X-KISS XML Key Information Service Specification XKMS XML Key Management Specification X-KRSS XML Key Registration Service Specification XML eXtensible Markup Language

ZKA Zentraler Kredit-Ausschuss

XVIII

1

Auf dem Weg zur Globalisierung bleiben IT-Systeme nicht unbeteiligt. Sie müssen äußerst flexibel sein, um sich den ständig neuen Gegebenheiten anpassen zu können. So ist es notwendig, die Vernetzung zwischen einzelnen Standorten eines Unternehmens, zwischen Unternehmen und Kunden und

zwischen verschiedenen Unternehmen zu ermöglichen und zu verbessern. Da- bei sollen die Kosten jedoch möglichst gering gehalten werden. Eine Lösung für dieses Problem ist die Automatisierung von Vorgängen, die einfach und monoton sind, gleiche oder ähnliche Eigenschaften aufweisen und sehr häufig durchgeführt werden. Was liegt also näher, als das große etablierte Internet zu nutzen. Es werden Web-Services angeboten, welche die Kommunikation zwischen mehreren Rechnern gestatten und so Abfragen oder andere Dienste um ein Vielfaches beschleunigen. Doch das allein reicht noch nicht aus. Ein System, welches die angebotenen Web Services koordiniert, verfügbar und somit flexibel nutzbar macht, ist vonnöten. Die Lösung heißt Service Oriented Architecture (SOA) und ist mittlerweile in aller Munde. So hatte die CeBIT in diesem Jahr einen eigenen Bereich namens SOA World eingerichtet. Die Spezialausgabe der Computerwoche für die CeBIT fokus- sierte das Thema und druckte alleine in der Ausgabe vom 19.03. mindestens drei Artikel, z.B.:

„SOA verlässt die Experimentierphase“ [Herrmann 2007c] „Der ökonomische Vorteil von Service-orientierten Architekturen ist messbar.“ [Herrmann 2007d]

KAPITEL 1. EINLEITUNG finden:

Die Liste ließe sich unendlich fortführen. SOA ist also ein Hypethema, aber was passiert wirklich in diesem Bereich, insbesondere im Hinblick auf die Sicherheit? Zwar sind bereits einige technische Sicherheitsmaßnahmen standardisiert, umgesetzt und berücksichtigt, aber:

1.1 Fragestellungen und Zielsetzung

Am Anfang stand die Idee, Prozesse, insbesondere auch Geschäftsprozesse, besser in der Information Technology (IT) abbilden und flexibler nutzen zu können. So wurde bereits in den 90ern des letzten Jahrhunderts von Web Ser-

vices gesprochen, welche in den verschiedensten Schriften diskutiert werden. Jedoch ist das Verständnis trotz mehrerer Definitionen durch Standardisie- rungsgremien wie das World Wide Web Consortium (W3C) nicht einheitlich. Mittlerweile hat sich die Systematik weiterentwickelt und es wird zusätzlich von der SOA gesprochen.

In beiden Fällen werden Daten über das Internet oder Intranet ausgetauscht oder verbreitet. Dies birgt einige Sicherheitsrisiken, wovon manche werden bereits mit Standardtechnologien minimiert werden. Weil jedoch die Thematik der SOA noch sehr jung ist und es somit erst wenige Lösungen

2

1.2. AUFBAU DER ARBEIT

gibt, sind auch die Sicherheitslücken noch nicht oder nur teilweise erforscht. Aus diesem Grund ist es Aufgabe dieser Arbeit, mögliche Schwachstellen einer SOA ausfindig zu machen, daraus resultierende Risiken aufzuzeigen und Maßnahmen dagegen zu ermitteln. Darüber hinaus sollen Anhaltspunkte zum Vorgehen beim Kunden aus der Sicht von IT-Security-Beratern gegeben werden.

Um dieses Ziel zu erreichen, lässt sich vorliegende Arbeit in drei Schwerpunkte unterteilen. Im ersten Schwerpunkt soll eine einheitliche Wissensbasis geschaffen werden, indem mit Hilfe von Definitionen die Grundelemente erläutert werden. Dabei wird eine konkrete Abgrenzung zwischen Web Services und SOA vorgenommen. Auf Grund des bisher sehr unscharfen Verständnisses einer SOA wird diese inklusive bestehender Zusammenhänge genau beschrieben.

Der zweite Schwerpunkt bezieht sich auf die Sicherheit einer SOA. Es soll hierbei geklärt werden, welches Risikopotenzial vorliegt und mit welchen Kontrollmaßnahmen es gemindert werden kann. Dieser Sachverhalt stellt damit den wichtigsten Teil der Arbeit dar.

Schwerpunkt drei assoziiert die bisher gewonnenen Erkenntnisse schließlich auf die SAP-spezifische Lösung Enterprise SOA. Dabei werden speziell für die Umsetzung bei Kunden relevante Lösungen vorgestellt. Folgende zentrale Forschungsfragen stehen somit im Vordergrund:

1. Was sind Web Services und was macht eine SOA aus? 2. Welche Bedrohungen wirken auf eine SOA? 3. Welche Kontrollmaßnahmen können eingeführt werden? 4. Wie kann (Enterprise) SOA-Sicherheit in der Beratungspraxis realisiert werden?

Dabei können, wie in Abbildung 1.1 (S. 4) visualisiert, die Forschungsfragen 2 und 3 dem zweiten Schwerpunkt zugeordnet werden. Forschungsfrage 1 ist Teil des ersten Schwerpunktes und Forschungsfrage 4 kann in den dritten Schwerpunkt eingegliedert werden. Daraus ergibt sich auch der Aufbau der Arbeit, der im nächsten Abschnitt genauer dargestellt wird.

1.2 Aufbau der Arbeit

Web Services und SOA lassen immer noch viel Raum für eigene Interpretationen, auch wenn es beide Ideen schon sehr lange gibt. Es herrscht Uneinigkeit darüber, wie beide Technologien zusammenhängen und zusammenwirken. Für einige sind Web Services nur sinnvoll innerhalb der Web Service

3

  KAPITEL 1. EINLEITUNG  

  Abbildung 1.1: Forschungsfragen und Aufbau der Arbeit  

4

1.2. AUFBAU DER ARBEIT

Architecture (WSA) nutzbar [vgl. z.B. Bengel 2004], andere betrachten die WSA jedoch bereits als SOA [vgl. z.B. Burghardt 2004, S. 15f]. Beim Leser führt dies natürlich zu Verwirrung. Um aber die Thematik der vorliegenden Arbeit sinnvoll erarbeiten zu können, ist ein genaues Verständnis notwendig. Daher werden im Kapitel 2 alle für die Erfassung der folgenden Forschungssachverhalte notwendigen Grundlagen erläutert und definiert. Schwerpunkt dieser Arbeit bildet die Absicherung der Service Orientier-

ten Architektur nach für Geschäftsprozesse relevanten Kriterien. Dazu wer- den im Kapitel 3 zunächst Bedrohungen und Risiken aufgezeigt, die in dem Zusammenwirken verschiedener Services innerhalb der SOA auftreten kön- nen. Aber auch Angriffsmöglichkeiten auf die SOA selbst oder unter Nutzung von Schwachstellen dieser Architektur sollen dargelegt werden. Nun ist es natürlich wichtig, mögliche Risiken nicht nur zu kennen, es muss auch etwas zur Reduzierung oder Beseitigung dieser getan werden. Aus diesem Grund werden im Anschluss daran im Kapitel 4 auf Basis des in Kapitel 3 aufgestellten Risikokataloges mögliche Lösungswege identifiziert, bestimmt und dokumentiert.

Die dabei analysierte SOA ist sehr allgemein gehalten, da sie systemunabhängig funktionieren soll. Um sie jedoch in bestehende Systeme besser integrieren zu können, haben verschiedene Unternehmen ihre eigene spezifische Lösung entwickelt. So gibt es auf dem Markt unter anderem Centra-Site (SOA-Governance) und Crossvision (SOA-Suite) von der Software AG (http://www.softwareag.com/de), IBM SOA Foundation von IBM (http: //www.ibm.com/de), AMADEE (http://www.amadee.de) hat alle 4 Produkte auf SOA ausgerichtet, wobei die AMADEE Platform die Basis bildet, ARIS SOA Architect aus der ARIS Implementation Platform von IDS Scheer (www.ids-scheer.de) oder auch die Open Source-Plattform JBoss Enterprise Middleware Suite (JEMS) von JBoss und viele weitere.

Die Lösung von SAP (www.sap.de) heißt Enterprise SOA. Im Kapitel 5 wird auf die Besonderheiten dieser Form der SOA eingegangen. Hierfür findet zunächst eine Beschreibung des Aufbaus und der Funktionsweise statt, um anschließend unter Beachtung der in Kapitel 3 und 4 gewonnenen Erkenntnis- se ein praktisches Vorgehen zur Umsetzung der Enterprise SOA bei Kunden aufzuzeigen. Dabei müssen verschiedenste Richtlinien und Grundsätze, sowie bereits vorhandene IT-Lösungen einbezogen werden. Es wird somit darge- stellt, wie bei der Realisierung vorzugehen ist und was dabei berücksichtigt werden muss.

Abbildung 1.1 auf Seite 4 stellt diesen Aufbau grafisch dar.

5

KAPITEL 1. EINLEITUNG

1.3 Hinweise zur Arbeit

Diese Arbeit dient der Erarbeitung einer Herangehensweise zur Absiche-

rung einer Service Orientierten Architektur. Somit werden insbesondere IT- Security-Experten angesprochen, welche sich in das neue und zukünftig sehr wichtige Gebiet einarbeiten möchten. Jedoch kann die Thematik nicht kom- plett dargestellt werden. Es gibt immer wieder neue Richtlinien und neue Erkenntnisse, welche ständig in den gesamten Prozess integriert werden müs- sen.

Nicht Bestandteil dieser Arbeit ist die grundsätzliche Beschreibung einer SOA. Daher wird nicht erklärt, wie eine solche Architektur im eigenen Unternehmen aufzubauen ist und welche Herangehensweise an ein derartiges Projekt vonnöten ist. Im Rahmen des vorliegenden Textes wird lediglich die SOA kurz erklärt, um von einem einheitlichen Verständnis ausgehen zu

können und im weiteren Verlauf das Arbeiten mit den Begrifflichkeiten zu erleichtern. Für Leser, welche sich mehr für einzelne Aspekte wie Aufbau, Realisierung, Governance usw. interessieren, empfiehlt die Autorin das Buch „SOA-Expertenwissen“ von Starke und Tilkov [2007].

Abschließend weist die Autorin darauf hin, dass aus Gründen der Lesbarkeit auf die explizite Verwendung weiblicher Formen (z.B. Mitarbeiterin) verzichtet wurde. Mit männlichen Bezeichnungen sind in dieser Arbeit daher männliche und weibliche Personen gleichermaßen gemeint.

6

Was sind Web Services und was macht eine SOA aus?

2

Oder wie der Volksmund sagt: No Risk, no fun!. Wie diese Zitate aussagen, ist es nicht Ziel der Risikoanalyse alle Risiken zu vermeiden, denn dadurch ist eine Weiterentwicklung nicht möglich. Vielmehr sollen Risiken ermittelt und ihre Eintrittswahrscheinlichkeit und/oder ihr Schadensausmaß durch geeignete Kontrollmaßnahmen minimiert werden. Nur so ist es möglich, für ein Projekt notwendige Gefahren einzugehen, um schließlich erfolgreich ans Ziel zu kommen.

Mittlerweile gibt es zahlreiche Literatur über IT-Sicherheit und Risikomanagement. Beinahe ebenso vielfältig sind die Erläuterungen der verschiedenen Begrifflichkeiten. Daher sollen im Abschnitt 2.1 die für die vorliegende Arbeit notwendigen Bezeichnungen in diesem Abschnitt aufgeführt und die Form der Verwendung erläutert werden.

Im Abschnitt 2.2 (S. 14) wird ein gemeinsames Verständnis für Web-Services und SOA gelegt. Schließlich soll im Abschnitt 2.3 (S. 26) auf die bereits verfügbaren Sicherheitsstandards bei Web-Services eingegangen wer- den.

KAPITEL 2. FORSCHUNGSGRUNDLAGEN

2.1 Definitionen

2.1.1 Schutzbedürfnisse

In der Literatur werden Schutzbedürfnisse meist als Schutzziele oder Sicher- Schutzbedürfnis

heitsziele bezeichnet [vgl. Eckert 2005; Hansen und Neumann 2005; Klett und Verlangte

^{sicherheitsrelevante} Kersten 2005]. Dabei wird davon ausgegangen, bestimmte sich auf die Sicher- Eigenschaft

heit von unternehmerischen Eigentums ((elektronische) Dokumente, Hard-, Systems.

Software, . . . ) beziehende Ziele zu erreichen. Ein Ziel ist jedoch „etwas, worauf jmds. Handeln, Tun o. Ä. ganz bewusst gerichtet ist, was man als Sinn und Zweck, angestrebtes Ergebnis seines Handelns, Tuns zu erreichen sucht“ [Duden 2005]. Es ist demnach ein erwünschter Zustand in der Zukunft. [vgl. Schneck u. a. 2005, S. 1116]

Ziele müssen quantifizierbar und messbar sein. Beides ist bei den nachstehenden Eigenschaften nicht gegeben. Erst folgende beispielhafte Formulierung würde zu einer Zielbeschreibung führen: „Die Verfügbarkeit des Produktivsystems muss bis zum dd.mm.yyyy auf eine Mindestverfügbarkeitszeit von 99,9% verbessert werden.“ Der Bezug ist hierbei der aktuelle Zustand. Es ist zu erkennen, dass ein Ziel durch den Zielinhalt (was soll erreicht werden: Verfügbarkeit verbessern), den Zeitbezug (wann: bis zum dd.mm.yyyy), den sachlichen Geltungsbereich (wo, was: Produktivsystem) und das Zielausmaß (wie: Mindestverfügbarkeitszeit von 99,9%) charakterisiert ist. [HA 2006b; Schneck u. a. 2005]

Die Autorin wählt daher den Begriff Bedürfnis, denn laut Duden [2005] bedeutet dies: „Gefühl, jmds., einer Sache zu bedürfen“. Schneck u. a. [2005, S. 107] beschreiben „Bedürfnis“ mit: „Gedanklicher Ausgangsprozess eines Kaufentscheidungsprozesses, der einen Mangelzustand kennzeichnet, auf dessen Überwindung ein Individuum hinarbeitet.“ In HA [2006a, S. 654f] lässt sich finden, dass „sich ein Bedürfnis durch ein Mangelerlebnis (Stärke des

Bedürfnisses), ein Anmutungsmoment (Bildhaftigkeit des Bedürfnisses), ein Antriebsmoment (triebhafter Bedürfnisdruck) sowie durch ein Richtungsmo- ment bzw. Gegenstandsmoment“ auszeichnet. „Im Verlauf der Bedürfniskon- kretisierung gelangt ein Bedürfnis vom Zustand äußerster Unbestimmtheit,

Ungerichtetheit, Vielschichtigkeit und Situationsabhängigkeit allmählich zu einem Zustand äußerster Bestimmtheit, Objektausrichtung und Bedarfsäu- ßerung.“

Als Beispiel diene wiederum die Verfügbarkeit. Zu Beginn einer Risikoanalyse ist noch völlig unbekannt, in welchem Umfang und welchem Ausmaß sie erreicht werden soll. Für welche Dokumente oder Systeme soll sie gelten? Es liegt also ein völlig unbestimmter und ungerichteter Zustand vor. Einzig bekannt ist, dass Verfügbarkeit erwünscht ist und gebraucht wird. Erst im

8

2.1. DEFINITIONEN

Laufe der Analyse werden Maßzahlen und Maßnahmen festgelegt, um dies zu erreichen. Nun entwickelt sich unter Umständen auch ein Ziel daraus, aber die Eigenschaft Verfügbarkeit an sich bleibt ein Bedürfnis, das in einem bestimmten Maß erreicht werden soll. Nach der Begriffsklärung kann definiert werden: Definition 2.1 - Schutzbedürfnisse:

Schutzbedürfnisse sind verlangte sicherheitsrelevante Eigenschaften eines Systems.

Im Folgenden werden die wichtigsten Schutzbedürfnisse näher beschrieben.

Authentizität Definition 2.2 - Authentizität:

Authentizität (authenticity) ist die nachweisliche Identifikation eines Objekts ^{Authentizität} oder Subjekts. [vgl. Hansen und Neumann 2005; Eckert 2005]. Nachweisliche

Identifikation.

Die Überprüfung dieser erfolgt mittels verschiedener Authentifizierungsmaßnahmen. Hierzu zählen z.B. Passwörter, Schlüssel, elektronische Zutrittskarten, usw. Authentizität ist notwendig, damit nur die Personen (oder auch Gegenstände, wie z.B. Acces Points) zu einem bestimmten Bereich oder auf bestimmte Daten Zugriff haben, die dazu berechtigt sind. Somit kommt hier auch ein Rollen-Berechtigungs-Konzept mit ins Spiel.

Autorisierung Definition 2.3 - Autorisierung:

Autorisierung (authorization) ist die Vergabe von Zugriffsrechten für be- Autorisierung

stimmte Informationen, Services oder Funktionen an eine Person, einen Com- oder ein Gerät. Die Autorisierung erfolgt aufgrund der Identität

einer Person, eines Computerprozesses oder Gerätes, die bei der Authentifizierung verifiziert wird. [SAP 2007a]

Sie prüft also „Rechte auf Daten und Funktionen und sichert diese gegenüber einem ungerechtfertigten Gebrauch, z.B. über ein Benutzerberechtigungssystem.“ [Seibold 2006, S. 29]

Vertraulichkeit

Dieses Schutzbedürfnis setzt die beiden zuvor genannten, Authentizität und Autorisierung, voraus, denn:

9

KAPITEL 2. FORSCHUNGSGRUNDLAGEN

Definition 2.4 - Vertraulichkeit:

Vertraulichkeit (confidentiality) bedeutet, dass Informationen unbefugten Drit- Vertraulichkeit

ten unzugänglich bleiben. [vgl. Eckert 2005; Hansen und Neumann 2005; Informationen bleiben

^Unbefugten Klett und Kersten 2005]

unzugänglich.

Wird dies gewährleistet, können vertrauliche Daten und Informationen sicher archiviert, bearbeitet und ausgetauscht werden. Damit dies möglich ist, stellen die Authentizität und die Autorisierung sicher, dass nur bestimmte, nämlich identifizierte und berechtigte Personen oder Objekte Zugriff haben. Gleichzeitig müssen aber auch noch andere Maßnahmen ergriffen werden, wie z.B. die Verschlüsselung der Daten.

Integrität

Auch die Integrität setzt die Schutzbedürfnisse Authentizität und Autorisie- Integrität

rung voraus. Nach Eckert [2005, S. 7] wird die (Daten-) Integrität gewährleis- Modifikationvon

^{Daten durch} tet, „wenn es Subjekten nicht möglich ist, die zu schützenden Daten unauto- Unbefugteoder auf

risiert und unbemerkt zu manipulieren.“ Ähnlich beschreiben es auch Hansen unzulässige Weise ist

nicht möglich.

und Neumann [2005, S. 286]. Im Gegensatz zu Eckert wollen sie jedoch die Unverändertheit von Daten nachweisen. Dennoch sind sich alle einig, dass Modifikationen an Daten ausschließlich durch Befugte stattfinden dürfen. Es lässt sich demnach festhalten: Definition 2.5 - Integrität:

Die (Daten-) Integrität (integrity) meint, dass Daten nicht durch Unbefugte Dritte gelesen oder gar manipuliert (ändern, löschen oder hinzufügen von Daten) bzw. durch Befugte unzulässig verändert werden können. Dies schließt auch die fehlerhafte Übertragung ein. Eine unautorisierte und unzulässige Modifikation muss nachweisbar sein.

Verfügbarkeit

Bei diesem Schutzbedürfnis sind sich alle einig, es lässt auch wenig Spiel- Verfügbarkeit

raum für Interpretationen. Daher wird die folgende Definition in Anlehnung Daten oder Systeme

^{stehen Befugten bei} an Klett und Kersten [2005, S. 44] übernommen, die am einfachsten und

Bedarf und in

zutreffendsten erscheint: akzeptabler Zeit zur

^Verfügung. Definition 2.6 - Verfügbarkeit:

Unter Verfügbarkeit (availability) wird die Eigenschaft von Daten und Systemen verstanden, für Befugte bei Bedarf und dann in aktzeptabler Zeit zur Verfügung zu stehen.

10

2.1. DEFINITIONEN

Das bedeutet, dass authentifizierte und autorisierte Personen oder Objekte in erlaubter Art und Weise auf die gewünschten Informationen oder Dienste zu jeder Zeit Zugriff erhalten. Hierbei wird eine meist zentral festgelegte Verzögerungszeit als normal und aktzeptiert angesehen. Ist die Nutzung nicht mehr möglich oder ist die Verzögerungszeit inakzeptabel, liegt womöglich eine Überlastung vor, die durchaus durch Unberechtigte erzeugt worden sein kann.

Es ist festzustellen, dass auch für dieses Schutzbedürfnis die zwei erst genannten Voraussetzung sind.

Rechtsverbindlichkeit

Die Rechtsverbindlichkeit wird in der Literatur auch Verbindlichkeit oder ^{Rechtsverbindlichkeit} Nicht-Abstreitbarkeit genannt. Ungeachtet dessen ist die Definition dieses

^{Handlungen sind nicht} Schutzbedürfnisses sehr ähnlich:

abstreitbar.

Definition 2.7 - Rechtsverbindlichkeit:

Rechtsverbindlichkeit (non-repudiation) besagt, dass alle Mitwirkenden eine durchgeführte Aktion nicht abstreiten können. Wurde zum Beispiel eine Mail zwischen zwei Personen versandt, ist es somit dem Absendenden nicht möglich das Versenden zu dementieren. Ebenso wenig kann der Empfänger den Erhalt leugnen. Um solche Handlungen nachweisbar machen zu können, sind auch hier Authentifizierung und Autorisierung notwendig.

Da, wie aus den vorherigen Erläuterungen ersichtlich wird, Authentizität und Autorisierung grundlegende Anforderungen sind, die erfüllt sein müssen, um auch die anderen Schutzbedürfnisse erfüllen zu können, werden in der Praxis meist nur die vier letztgenannten Schutzbedürfnisse betrachtet. Folglich soll in der vorliegenden Arbeit daran festgehalten werden. Alle nachfolgenden Betrachtungen werden nur noch den Schutzbedürfnissen Vertraulichkeit, Integrität, Verfügbarkeit und Rechtsverbindlichkeit unterworfen.

2.1.2 Risiko

In der Literatur wird zwischen den Begriffen Bedrohung und Risiko unter- ^Risiko schieden. Hierbei meint die Bedrohung ein Ereignis oder einen Umstand, der

die Schutzbedürfnisse gefährdet [vgl. Coester und Hein 2005; Eckert 2005]

bzw. durch den ein Schaden entstehen kann [vgl. BSI 2005, S. 174]. Das Ri- ergibt sich dabei aus der Wahrscheinlichkeit des Eintretens einer Bedrohung und dem daraus resultierenden Schadensausmaß [vgl. Coester und Hein 2005; BSI 2005; Königs 2006; Eckert 2005]. Eine zweite häufige Definition des

11

KAPITEL 2. FORSCHUNGSGRUNDLAGEN

Begriffs Risiko meint die Unterscheidung in möglichen Schaden im negativen oder mögliche Chance im positiven Fall [vgl. BSI 2005, S. 180]. Lachnit und Müller [2006, S. 203] beschreiben Risiken mit „Zielverfehlungen als ‚Streuung des Zukunftserfolgs wirtschaftlicher Aktivitäten‘ “ und unterscheiden ebenfalls in positive (Chancen) und negative (Risiken) Abweichungen. Im Folgenden wird allgemein von Risiko gesprochen, da bei dem Ermitteln von Bedrohungen im Regelfall bereits mindestens von einer minimalen Eintrittwahrscheinlichkeit ausgegangen wird und somit ein Risiko vorliegt. Es lässt sich demzufolge definieren: Definition 2.8 - Risiko:

Stellt einen Umstand oder ein Ereignis dar, dessen Eintreten möglich ist und einen mehr oder weniger hohen Schaden anrichten kann. Dabei sind auch solche Geschehnisse gemeint, deren Eintreten mit einer sehr niedrigen Wahrscheinlichkeit und das Ausmaß des resultierenden Schadens mit sehr gering bis nicht relevant bewertet werden.

2.1.3 Kontrolle

Weitere Bezeichnungen sind Schutzmaßnahme [Pohlmann und Blumberg 2004], Kontrolle

Sicherheitsmaßnahme [Klett und Kersten 2005] oder einfach nur Maßnahme Minimiert die

^{Eintrittswahrschein-} [Hansenund Neumann 2005; Königs 2006; Lachnit und Müller 2006; Sei- lichkeitund/ oder das

bold 2006]. Solche, die erst nach Schadenseintritt aktiv werden, heißen auch Schadensausmaß eines

Risikos.

Schadensreduzierungsmaßnahme [vgl. Seibold 2006, S. 31]. Kontrollen wirken sich auf die Eintrittswahrscheinlichkeit und/oder das Schadensausmaß von Risiken aus. Dadurch werden diese reduziert oder gar eliminiert, so dass schließlich das verbleibende Risiko minimiert oder vermieden wird. Sie können nach Seibold [2006, S. 31] in (1) aktive (ursachenbezogene) und (2) passive (wirkungsbezogene) Schutzmaßnahmen differenziert werden. Dabei reduzieren passive Kontrollen erst nach dem Eintreten des Risikos das Schadensausmaß und werden somit auch als korrektiv bezeichnet. Zudem ist häufig der Begriff detektiv zu finden. Alleinstehend ist dies jedoch nicht sinnvoll, da erst eine nachgelagerte Handlung zur Minimierung des Risikos führt und damit eine Korrektur erfolgt. Beides zusammen, also die detektive Kontrolle, die einen Schadensfall ermittelt, und die nachgelagerte, das Schadensausmaß oder die Eintrittswahrscheinlichkeit reduzierende Maßnahme, ergibt schließlich die korrektive Kontrolle. Aktive Schutzmaßnahmen minimieren bereits vor dem Schadensfall die zwei Stellgrößen Eintrittswahrscheinlichkeit und Schadensausmaß, wirken also direkt darauf ein. Sie sind demnach präventiv. [vgl. Seibold 2006; MSIGroup]

12

2.1. DEFINITIONEN

oder (3) technisch sein. Unter die organisatorischen Schutzmaßnahmen fallen alle geplanten Handlungen, die ein normiertes Prozedere zur Erzielung der notwendigen Sicherheitsniveaus gestatten. Die regelmäßige Einspielung von Sicherheitspatches ist eine Maßnahme, die zu den administrativen gehört. Sie begleiten daher ständig den Betrieb der IT-Landschaft. Technische Schutzmaßnahmen sind schließlich Hard- und Softwarekomponenten, die den gewünschten Grad an Sicherheit erzeugen. [vgl. Pohlmann und Blumberg 2004, S. 190]

Klett und Kersten [2005, S. 83f] unterscheiden sogar in 5 Kategorien: (1) vertragliche, (2) organisatorische, (3) personelle, (4) infrastrukturelle und (5) technische Maßnahmen. Unter vertraglichen Regelungen verstehen die Autoren alle in Verträgen festgelegten Bestimmungen zur Einhaltung der Sicherheit aller Beteiligten. Personelle Maßnahmen sind solche, die der Qualifizierung von Personal dienen, um diese zu sensibilisieren, zu schulen und zu trainieren, um so Gefahrenquellen durch falsches Handeln zu minimieren oder zu vermeiden. Zugangskontrollen zu bestimmten Bereichen, Alarmsicherungen und weitere technische und bauliche Maßnahmen werden zu den infrastrukturellen gezählt. Organisatorische und technische Schutzmaßnahmen werden genauso definiert wie bereits oben erläutert. In dieser Arbeit wird der Begriff Kontrolle, zusammen mit oben genannten Synonymen wie folgt genutzt: Definition 2.9 - Kontrolle:

Ist eine Maßnahme jeglicher Art, welche die Eintrittswahrscheinlichkeit und/ oder das Schadensausmaß eines Risikos minimiert. Sie kann sowohl präventiv als auch korrektiv bzw. detektiv wirksam werden.

2.1.4 Sicherheitsservices

Mit Hilfe unterschiedlicher Aneinaderreihungen von (Web) Services werden ^{Sicherheitsservice} verschiedene Geschäftsprozesse und Szenarien abgebildet und automatisiert.

Hierbei wirken auf einzelne Stellen eine Reihe von einander abweichender

Bedrohungen, deren Risiken gesondert durch Kontrollmaßnahmen reduziert

oder beseitigt werden. Jedoch sollen die Geschäftsprozesse im Ganzen, also

End-to-End statt Point-to-Point, betrachtet werden, da sonst leicht Schwachstellen an den Schnittstellen entstehen können. Mehrere eingesetzte Kontrollen, welche die Einhaltung der Schutzbedürfnisse bewirken, können in einem Service zusammengefasst werden. Dieser wird als Sicherheitsservice bezeichnet. Als Definition bedeutet das: Definition 2.10 - Sicherheitsservices:

13

KAPITEL 2. FORSCHUNGSGRUNDLAGEN

Ein Sicherheitsservice umfasst verschiedene Kontrollmaßnahmen innerhalb eines vollständigen Geschäftsprozessszenarios zur Wahrung der für diesen Prozess definierten Schutzbedürfnisse.

2.2 Von Web Services zur Service Orientierten Architektur

Web Services und SOA, zwei Begrifflichkeiten, die momentan in aller Munde sind. Aber was sind Web Services? Und was ist SOA? Gibt es überhaupt Unterschiede? Können sie einzeln existieren oder gehören sie irgendwie zusammen?

Diese und weitere Fragen sollen folgend beantwortet werden. Hierzu erfolgt zunächst eine Klärung des Begriffes Web Service, wobei deren Eigenschaften erläutert werden. Anschließend soll auf die Bezeichnung SOA eingegangen werden. Es wird aufgezeigt, was eine SOA ausmacht und damit eine Abgrenzung zu Web Services geschaffen.

2.2.1 Web Services

^{Web Services} Dienen der Maschine-Kommunikation unter Nutzung von auf

XML-basierenden

Standard-Protokollen.

tion for the Advancement of Structured Information Standards (OASIS). Was sagen sie aus? Web Services dienen der Kommunikation zwischen Maschinen. Dabei nutzen sie Standard-Protokolle, die auf eXtensible Markup Language (XML) basieren. Sie zeichnen sich durch ihre starke Interoperabilität, also „die Fähigkeit zweier verschiedener Computer zusammenzuarbeiten und zu

14

2.2. VON WEB SERVICES ZUR SERVICE ORIENTIERTEN ARCHITEKTUR

Abbildung 2.1: Zusammenspiel von Web Services [in Anlehnung an Hauser und Löwer 2004; Kupsch 2006]

kommunizieren“[Babylon 2000], und Erweiterbarkeit aus. Zudem sind Web Services lose gekoppelt, so dass komplexe Angebote erstellt werden können. Kurz gesagt: „Web Services sind eine über das Internet zugängliche Schnittstelle zu Anwendungsfunktionen, die mit Hilfe von Standardtechniken des Web realisiert wird.“ [Bengel 2004, S. 267]

Laut des Online-Lexikons IT-Wissen gehören zu Web Services „alle Maßnahmen, die die Kommunikationshemmnisse zwischen verschiedenen E-Services beheben.“ [vgl. IT Wissen] Sie schaffen universelle Sprachen, fungieren also als Dolmetscher zwischen den einzelnen Systemen, die untereinander Informationen austauschen wollen. Bis hier herrscht somit im Großen und Ganzen Einigkeit, so dass in dieser Arbeit mit folgender Definition, angelehnt an die vorherigen, gearbeitet wird:

Definition 2.11 - Web Services:

Web Services dienen der Maschine-zu-Maschine-Kommunikation unter Nutzung von auf XML-basierenden Standard-Protokollen und führen (Teil-) Funktionalitäten verschiedener Granularität eines Gesamtprozesses durch. Die vom Fraunhofer Institut für Sichere Informations-Technologie (SIT) entwickelte Software für Gebäudemanagement, facilityboss, ist ein sehr gutes Beispiel dafür, wie Web Services sinnvoll und gewinnbringend verwendet werden können. Hierbei wird das Gebäude als ein Service-Anbieter gesehen (Building as a Service Provider (BSP)), wobei alle Elemente eines Hauses, von der Beleuchtung und Beheizung bis hin zur Zugangskontrolle und IT-Netzwerk, in Form von Services angebunden werden können. Damit sind auch Planungen, Simulationen und Analysen möglich. [vgl. facilityboss] Zur Umsetzung von Web Services sind plattformunabhängige Techniken

15

KAPITEL 2. FORSCHUNGSGRUNDLAGEN

Abbildung 2.2: Web Services Architecture Stack [W3C 2004, S. 64, übersetzt durch die Autorin]

notwendig, darüber sind sich alle einig. So benötigen Web Services XML für den Funktionsaufruf, SOAP für den Datenaustausch (Austausch der Nachrichten) und HyperText Transport Protocol (HTTP), Simple Mail Transport Protocol (SMTP) oder andere Protokolle für den Datentransfer. Des Weiteren benötigen sie Web Services Description Language (WSDL) für die Beschreibung der Schnittstellen (Input, Output) von Web Services und Universal Description, Discovery and Integration (UDDI) zur Veröffentlichung und zum Finden geeigneter Dienste in den Web Service Repositories (s. Abb. 2.1, S. 15 und Abb. 2.2). Was hier beschrieben wurde, wird als Web Services Architektur bezeichnet. [vgl. z.B. Bengel 2004; Kupsch 2006] Oder ist das bereits die SOA? [vgl. z.B. Burghardt 2004; Hauser und Löwer 2004] Zur Orchestrierung von Web Services für die Modellierung von Geschäftsprozessen sind die auf XML-basierenden Sprachen Business Process Execution Language (BPEL), Business Process Modelling Language (BPML) und Web Services Choreography Interface (WSCI) bekannt. [vgl. IT Wissen] Aber soll nicht auch die SOA der Orchestrierung dienen? Im folgenden Abschnitt wird daher versucht, den Begriff der SOA genauer einzugrenzen.

2.2.2 Service Orientierte Architektur (SOA)

Im vorherigen Abschnitt wurde deutlich, dass Web Services alleinstehend, also ohne eine SOA genutzt werden können. Auch Geschäftsprozesse können

16