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

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Listingverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Fragestellungen und Zielsetzung
1.2 Aufbau der Arbeit
1.3 Hinweise zur Arbeit

2 Forschungsgrundlagen
2.1 Definitionen
2.1.1 Schutzbedürfnisse
2.1.2 Risiko
2.1.3 Kontrolle
2.1.4 Sicherheitsservices
2.2 Von Web Services zur Service Orientierten Architektur
2.2.1 Web Services
2.2.2 Service Orientierte Architektur (SOA)
2.3 Standards bei Web Services
2.3.1 Grundstandards
2.3.2 Sicherheitsstandards

3 Risikoanalyse und -klassifizierung
3.1 Methoden zur Risikoanalyse und -klassifizierung
3.1.1 Bekannte Verfahren
3.1.2 Vorgehen im Kontext der Arbeit
3.2 Erstellen eines Risikokataloges für die Service Orientierte Ar- chitektur
3.2.1 Beispiel 1: Purchase to Pay
3.2.2 Beispiel 2: SEPA-Überweisung

4 Implementierung von Kontrollmaßnahmen
4.1 Methoden zur Bestimmung geeigneter Kontrollmaßnahmen
4.1.1 Bekannte Verfahren
4.1.2 Vorgehen im Kontext der Arbeit
4.2 Erstellen eines Kontrollkataloges zur Absicherung der Service Orientierten Architektur
4.2.1 Ermitteln von Kontrollmaßnahmen
4.2.2 Ermitteln von Sicherheitsservices
4.2.3 Bewerten der Sicherheitsservices

5 Paradigma: Enterprise SOA
5.1 Aufbau und Funktionsweise
5.1.1 Entwicklung
5.1.2 SAP NetWeaver
5.1.3 Enterprise SOA
5.2 Sicherheitsbetrachtung
5.3 Prozessorchestrierung mit Enterprise SOA
5.3.1 SAP NetWeaver Composition Environment
5.3.2 Prozess orchestrieren
5.3.3 Zuweisung der Sicherheitsservices
5.4 Enterprise SOA-Sicherheit in der Beratungspraxis
5.4.1 Rechtliche Sicherheitsaspekte für die IT
5.4.2 Vorgehensweise im Projekt

6 Fazit

A Listings zu Web Service-Standards

B Abbildungen zur Prozessorchestrierung mit Enterprise SOA205

Glossar

Literaturverzeichnis

Abbildungsverzeichnis

1.1 Forschungsfragen und Aufbau der Arbeit

2.1 Zusammenspiel von Web Services

2.2 Web Services Architecture Stack

2.3 Aufbau einer SOA

2.4 Modell eines SOA-Stacks

2.5 Das ESB-Konzept

2.6 SL&I-Modell nach Offermann

2.7 WSDL-Script

2.8 UDDI-Registry der SAP AG

2.9 Erweiterungen von WS-Security

2.10 Beispiel-Szenario für die Verwendung von SPML

3.1 Risikomangement-Prozess

3.2 Zusammenwirken der Analyse-Verfahren

3.3 Kategorisierung der Analyse-Methoden

3.4 Matrix zur Bestimmung der Risikohöhe

3.5 Prozess „Zulieferer auswählen“

3.6 Prozess „SEPA-Überweisung“

4.1 Funktionsweise der Sicherheitsservices und des ESB

5.1a Monolithische Anwendungsstruktur

5.1b Zweischichtige Anwendungsstruktur

5.1c Dreischichtige Anwendungsstruktur

5.1d Derzeitige Unternehmensstruktur

5.1e Enterprise Services Architecture

5.2 Kernbereiche des SAP NetWeaver

5.3 SAP NetWeaver Process Integration als Basis für Enterprise SOA

5.4 Enterprise SOA und SAP NetWeaver

5.5 SAP NetWeaver Security

ABBILDUNGSVERZEICHNIS

B.1 SAP Developer Network
B.2 Enterprise Service Workplace
B.3 Enterprise Services Index nach Prozesskomponenten
B.4 Prozesskomponente „Purchase Request Processing“
B.5 Enterprise Service „Manage Purchase Request In“
B.6 Enterprise Services Operation „Create Purchase Request“ .
B.7 Informationen zur ES Operation „Create Purchase Request“
B.8 Business Object „Purchase Request“
B.9 Link zur detaillierten Feldbeschreibung für die ES Operation „Create Purchase Request“
B.10 Detaillierte Feldbeschreibung für die ES Operation „Create Purchase Request“

Tabellenverzeichnis

2.1 Bei XML-Signature verwendete Algorithmen

3.1 Beispiel für Bewertung des Schutzbedarfs

3.2 Beispiel zur Auflistung der identifizierten Risiken

3.3 Beispiel für den Risikokatalog

3.4 Schutzbedarf im Prozess „Zulieferer auswählen“

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

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

3.7 Schutzbedarf im Prozess „SEPA-Überweisung“

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

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

4.1 Beispiel zur Auflistung von Kontrollmaßnahmen

4.2 Beispiel zur Klassifizierung der Risiken

4.3 Beispiel zur Auflistung von Sicherheitsservices

4.4 Beispiel zur Zuordnung von Kontrollmaßnahmen und Sicher- heitsservices

4.5 Beispiel für den Kontrollkatalog

4.6 Liste von Kontrollmaßnahmen

4.7 Klassifizierung der Risiken für den Prozess „Zulieferer aus- wählen“

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

4.9 Liste von Sicherheitsservices

4.10 Kontrollmaßnahmen und Sicherheitsservices für den Prozess „Zulieferer auswählen“

4.11 Kontrollmaßnahmen und Sicherheitsservices für den Prozess „SEPA-Überweisung“

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

4.13 Kontrollkatalog für den Prozess „SEPA-Überweisung“

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

Listings

A.1 XML-Script
A.2 SOAP-Script
A.2 SOAP-Script (Forts.)
A.3 HTTP-Header
A.4 WSDL-Script
A.4 WSDL-Script (Forts.)
A.4 WSDL-Script (Forts.)
A.5 UDDI - Anmelden eines businessEntity-Elements bei der Re- gistry
A.6 Prozessformulierung mit BPEL
A.7 GET-Request in REST-Architektur
A.8 XML Encryption
A.9 XML Signature
A.10 Syntax einer SOAP Nachricht mit WS-Security
A.11 Authentifizierung mit SAML

ABKÜRZUNGSVERZEICHNIS

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Auf dem Weg zur Globalisierung bleiben IT-Systeme nicht unbeteiligt. Sie müssen äußerst flexibel sein, um sich den ständig neuen Gegebenheiten an- passen 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]

Aber auch in anderen Quellen lassen sich zahlreiche Veröffentlichungen finden:

„Software AG erweitert SOA-Suite Richtung EAM“ [Quack 2007]

„Web 2.0 und SOA: Vom Mitmach-Web zum Partizipations-Un- ternehmen“ [Müller 2007]

„SOA auf Basis von Open-Source leicht gemacht“ [Seidel 2006] „Deutsche sind Anfänger in Sachen SOA“ [Herrmann 2007a] „SOA bringt die Touristik auf Trab“ [Herrmann 2007b]

„A Little Known Company Charts the BPM-SOA Future“ [Greenbaum 2007]

„Auswahl und Betrieb einer Infrastruktur für SOA - Fundament für Dienste“ [Peters 2006]

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:

„Im Bereich Governance, Risk und Compliance wurde noch nicht viel getan.“ (Stephan Raschke, Enterprise SOA Security Architect, SAP AG)

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 ausge- tauscht 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 gibt, sind auch die Sicherheitslücken noch nicht oder nur teilweise erforscht. Aus diesem Grund ist es Aufgabe dieser Arbeit, mögliche Schwachstellen ei- ner 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 wer- den.

Um dieses Ziel zu erreichen, lässt sich vorliegende Arbeit in drei Schwer- punkte unterteilen. Im ersten Schwerpunkt soll eine einheitliche Wissensbasis geschaffen werden, indem mit Hilfe von Definitionen die Grundelemente er- läutert werden. Dabei wird eine konkrete Abgrenzung zwischen Web Services und SOA vorgenommen. Auf Grund des bisher sehr unscharfen Verständ- nisses 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 Interpreta- tionen, auch wenn es beide Ideen schon sehr lange gibt. Es herrscht Unei- nigkeit darüber, wie beide Technologien zusammenhängen und zusammen- wirken. Für einige sind Web Services nur sinnvoll innerhalb der Web Service 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 Forschungs- sachverhalte notwendigen Grundlagen erläutert und definiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Forschungsfragen und Aufbau der Arbeit

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 system- unabhängig funktionieren soll. Um sie jedoch in bestehende Systeme besser integrieren zu können, haben verschiedene Unternehmen ihre eigene spezi- fische 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 Pro- dukte 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 Enterpri- se 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

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.

Was sind Web Services und was macht eine SOA aus?

2 Forschungsgrundlagen

Nichts geschieht ohne Risiko. Aber ohne Risiko geschieht auch nichts!

Walter Scheel, Deutscher Bundespräsident 1974-1979

Oder wie der Volksmund sagt: No Risk, no fun! . Wie diese Zitate aus- sagen, 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.

2.1 Definitionen

2.1.1 Schutzbedürfnisse

Schutzbedürfnis Verlangte sicherheitsrelevante Eigenschaft eines Systems.

In der Literatur werden Schutzbedürfnisse meist als Schutzziele oder Sicher- heitsziele bezeichnet [vgl. Eckert 2005; Hansen und Neumann 2005; Klett und Kersten 2005]. Dabei wird davon ausgegangen, bestimmte sich auf die Sicher- heit von unternehmerischen Eigentums ((elektronische) Dokumente, Hard-, Software, . . . ) beziehende Ziele zu erreichen. Ein Ziel ist jedoch „etwas, wo- rauf 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 nach- stehenden Eigenschaften nicht gegeben. Erst folgende beispielhafte Formu- lierung würde zu einer Zielbeschreibung führen: „Die Verfügbarkeit des Pro- duktivsystems 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 des- sen Ü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 Risiko- analyse 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 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 Sys- tems.

Im Folgenden werden die wichtigsten Schutzbedürfnisse näher beschrie- ben.

Authentizität

Definition 2.2 - Authentizität:

Authentizität

Nachweisliche Identifikation.

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

Die Überprüfung dieser erfolgt mittels verschiedener Authentifizierungs- maßnahmen. Hierzu zählen z.B. Passwörter, Schlüssel, elektronische Zutritts- karten, 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 Vergabe von Zugriffsrechten aufgrund einer bestimmten Identität.

Autorisierung ( authorization ) ist die Vergabe von Zugriffsrechten für be- stimmte Informationen, Services oder Funktionen an eine Person, einen Com- puterprozess oder ein Gerät. Die Autorisierung erfolgt aufgrund der Identität einer Person, eines Computerprozesses oder Gerätes, die bei der Authentifi- zierung verifiziert wird. [SAP 2007a]

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

Vertraulichkeit

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

Definition 2.4 - Vertraulichkeit:

Vertraulichkeit Informationen bleiben Unbefugten unzugänglich.

Vertraulichkeit ( confidentiality ) bedeutet, dass Informationen unbefugten Drit- ten unzugänglich bleiben. [vgl. Eckert 2005; Hansen und Neumann 2005; Klett und Kersten 2005]

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

Integrität Modifikation von Daten durch Unbefugte oder auf unzulässige Weise ist nicht möglich. Verfügbarkeit Daten oder Systeme stehen Befugten bei Bedarf und in akzeptabler Zeit zur Verfügung.

Auch die Integrität setzt die Schutzbedürfnisse Authentizität und Autorisie- rung voraus. Nach Eckert [2005, S. 7] wird die (Daten-) Integrität gewährleis- tet, „wenn es Subjekten nicht möglich ist, die zu schützenden Daten unauto- risiert und unbemerkt zu manipulieren.“ Ähnlich beschreiben es auch Hansen 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- raum für Interpretationen. Daher wird die folgende Definition in Anlehnung an Klett und Kersten [2005, S. 44] übernommen, die am einfachsten und zutreffendsten erscheint:

Definition 2.6 - Verfügbarkeit:

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

Das bedeutet, dass authentifizierte und autorisierte Personen oder Ob- jekte in erlaubter Art und Weise auf die gewünschten Informationen oder Dienste zu jeder Zeit Zugriff erhalten. Hierbei wird eine meist zentral festge- legte Verzögerungszeit als normal und aktzeptiert angesehen. Ist die Nutzung nicht mehr möglich oder ist die Verzögerungszeit inakzeptabel, liegt womög- lich 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 Nicht-Abstreitbarkeit genannt. Ungeachtet dessen ist die Definition dieses Schutzbedürfnisses sehr ähnlich:

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. Eben- so wenig kann der Empfänger den Erhalt leugnen. Um solche Handlungen nachweisbar machen zu können, sind auch hier Authentifizierung und Auto- risierung notwendig.

Da, wie aus den vorherigen Erläuterungen ersichtlich wird, Authentizität und Autorisierung grundlegende Anforderungen sind, die erfüllt sein müs- sen, 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 nach- folgenden Betrachtungen werden nur noch den Schutzbedürfnissen Vertrau- lichkeit, Integrität, Verfügbarkeit und Rechtsverbindlichkeit unterworfen.

2.1.2 Risiko

Risiko Ein Ereignis mit einer bestimmten Eintritts- wahrscheinlichkeit und einem bestimmten Schadensausmaß.

In der Literatur wird zwischen den Begriffen Bedrohung und Risiko unter- 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- siko ergibt sich dabei aus der Wahrscheinlichkeit des Eintretens einer Bedro- hung und dem daraus resultierenden Schadensausmaß [vgl. Coester und Hein 2005; BSI 2005; Königs 2006; Eckert 2005]. Eine zweite häufige Definition des 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 eben- falls 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

Kontrolle Minimiert die Eintrittswahrschein- lichkeit und/ oder das Schadensausmaß eines Risikos.

Weitere Bezeichnungen sind Schutzmaßnahme [Pohlmann und Blumberg 2004], Sicherheitsmaßnahme [Klett und Kersten 2005] oder einfach nur Maßnahme [Hansen und Neumann 2005; Königs 2006; Lachnit und Müller 2006; Sei- bold 2006]. Solche, die erst nach Schadenseintritt aktiv werden, heißen auch 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 vermie- den wird. Sie können nach Seibold [2006, S. 31] in (1) aktive (ursachenbezo- gene) 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 bezeich- net. 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 nachgela- gerte, 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 Ein- trittswahrscheinlichkeit und Schadensausmaß, wirken also direkt darauf ein. Sie sind demnach präventiv. [vgl. Seibold 2006; MSIGroup]

Des Weiteren können Maßnahmen (1) organisatorisch, (2) administrativ 12 oder (3) technisch sein. Unter die organisatorischen Schutzmaßnahmen fal- len 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 ge- hört. Sie begleiten daher ständig den Betrieb der IT-Landschaft. Techni- sche Schutzmaßnahmen sind schließlich Hard- und Softwarekomponenten, die den gewünschten Grad an Sicherheit erzeugen. [vgl. Pohlmann und Blum- berg 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 Si- cherheit aller Beteiligten. Personelle Maßnahmen sind solche, die der Qua- lifizierung 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, Alarmsiche- rungen und weitere technische und bauliche Maßnahmen werden zu den in- frastrukturellen 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. Umfasst Kontrollen Hierbei wirken auf einzelne Stellen eine Reihe von einander abweichender zur Wahrung der für einen vollständigen Bedrohungen, deren Risiken gesondert durch Kontrollmaßnahmen reduziert Geschäftsprozess oder beseitigt werden. Jedoch sollen die Geschäftsprozesse im Ganzen, also End-to-End statt Point-to-Point, betrachtet werden, da sonst leicht Schwach- stellen an den Schnittstellen entstehen können. Mehrere eingesetzte Kontrol- len, welche die Einhaltung der Schutzbedürfnisse bewirken, können in einem Service zusammengefasst werden. Dieser wird als Sicherheitsservice bezeich- net. Als Definition bedeutet das:

Definition 2.10 - Sicherheitsservices: 13 definierten Schutzbedürfnisse.

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 zu- sammen?

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- zu-Maschine- Kommunikation unter Nutzung von auf XML-basierenden Standard-Protokollen.

Web services provide a standard means of interoperating be- tween different software applications, running on a variety of plat- forms and/or frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machine- processable descriptions thanks to the use of XML. They can be combined in a loosely coupled way in order to achieve complex operations. Programs providing simple services can interact with each other in order to deliver sophisticated added-value services. [W3C 2005]

Web services allow applications to communicate across plat- forms and programming languages using standard protocols based on XML. [OASIS 1993 - 2007a]

Zwei Definitionen von den Standardisierungsgremien W3C und Organiza- 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 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 Schnitt-stelle zu Anwendungsfunktionen, die mit Hilfe von Standardtechniken des Web realisiert wird.“ [Bengel 2004, S. 267]

Abbildung in dieser Leseprobe nicht enthalten

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

Laut des Online-Lexikons IT-Wissen gehören zu Web Services „alle Maßnahmen, die die Kommunikationshemmnisse zwischen verschiedenen E-Ser- vices 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 gu- tes 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 notwendig, darüber sind sich alle einig. So benötigen Web Services XML für den Funktionsaufruf, SOAP für den Datenaustausch (Austausch der Nach- richten) 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 Beschrei- bung der Schnittstellen (Input, Output) von Web Services und Universal De- scription, 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 Architek- tur 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 Choreogra- phy 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.

Abbildung in dieser Leseprobe nicht enthalten

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

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 problemlos mit Hilfe von BPEL & Co. abgebildet werden. Wozu wird dann aber eine SOA benötigt? Um dies zu klären, wird vor der eigentlichen Begriffsdefinition zunächst dargelegt, was solch eine Architektur überhaupt ist und welche Bestandteile sie hat.

Bestandteile

Innerhalb einer SOA stehen, und dies ist ein äußerst wichtiger Aspekt, Ge- schäftsprozesse im Vordergrund [vgl. Rausch 2004, S. 7 und Weigend 2006, S. 36]. Bei der alleinigen Nutzung von Web Services ist dies nicht stringent notwendig, mit ihnen können z.B. auch technische Elemente, wie Fax oder Drucker, als Services genutzt werden. Somit ist die Service Orientierte Archi- tektur nicht mit der WSA gleichzusetzen, auch wenn natürlich die elementa- ren Bestandteile und Funktionalitäten in der SOA implementiert sind. Besser ist es von einer Erweiterung der Web Service Architektur oder vergleichbarer Technologien zu sprechen.

Wie eben angedeutet, ist SOA nicht nur mit Web Services realisierbar [vgl. Thommes 2006; Rausch 2004; W3C 2004]. Dieser Sachverhalt wird in sehr vielen Schriften und somit bei der Diskussion von SOA häufig vergessen. Auch Technologien wie Distributed Component Object Model (DCOM), Windows Communication Foundation (WCF) oder Java (2) Platform, Enterprise Edi- tion (J(2)EE) können genutzt werden. Soll kein unternehmensübergreifender Einsatz erfolgen, wäre Common Object Request Broker Architecture (COR- BA) aufgrund der besseren Performanz und der Sprachunabhängigkeit sogar besser geeignet als die anderen Technologien [vgl. Rausch 2004, S. 11]. Doch die Service Oriented Architecture soll meist nicht nur intern, sondern vor allem global über mehrere Konzerne hinweg genutzt werden. Hierfür sind Web Services, welche eine konsequente Weiterentwicklung und Umsetzung der Ideen aus dem Middleware-Bereich (vor allem aus dem CORBA-Umfeld) darstellen, am Besten geeignet. Ihr Einsatz ist immer dann von Vorteil, wenn folgende Eigenschaften eintreten:

- Das System muss über das Internet agieren, so dass Zuverlässigkeit und Geschwindigkeit nicht garantiert werden können.
- Das System bietet keine Funktionalität, welche die Bereitstellung und Installation von Services so verwaltet, dass diese sowohl Anbieter als auch Konsument umgehend zur Verfügung stehen.
- Die Komponenten des verteilten Systems laufen auf verschiedenen Plattformen unterschiedlicher Produktanbieter.

[...]