https://cdn.openpublishing.com/images/brand/9/logo.gif
Warenkorb 0 Artikel | US$ 0,00
https://cdn.openpublishing.com/images/brand/9/grin_twitter.png
https://cdn.openpublishing.com/images/brand/9/grin_fb.png
Homepage >  Katalog >  Informatik - Wirtschaftsinformatik

Veröffentlichen auch Sie Ihre Arbeiten - es ist ganz einfach!

Mehr Infos
Blick ins Buch
Titel: XML und IT-Security

XML und IT-Security

Konzeption einer sicheren Web Services-Infrastruktur

Diplomarbeit, 2002, 188 Seiten

Informatik - Wirtschaftsinformatik

Autor

Autor: Thorsten Merz

Leseprobe


ID 6233
Merz, Thorsten: XML und IT - Security - Konzeption einer sicheren Web Services-
Infrastruktur
Hamburg: Diplomica GmbH, 2002
Zugl.: Frankfurt am Main, Universität, Diplomarbeit, 2002
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
I
Inhaltsverzeichnis
INHALTSVERZEICHNIS
...I
ABBILDUNGSVERZEICHNIS
... IV
SOURCE ­ CODE VERZEICHNIS
... VI
TABELLENVERZEICHNIS
... VIII
ABKÜRZUNGSVERZEICHNIS
... IX
1.
EINLEITUNG...1
2.
WEB SERVICES ...2
2.1 Einführung... 2
2.2 Definition... 2
2.3 Eigenschaften, Anforderungen und Nutzenpotentiale für EAI ... 3
2.4 Implementierung und Aufruf von Web Services ... 6
3.
DAS BEISPIEL ­ SZENARIO...7
4.
INTERNET ­ SICHERHEIT...11
4.1 Einführung... 11
4.2 Definition... 12
4.3 Sicherheitseigenschaften... 13
4.4 Internet ­ Protokollfamilie ... 16
4.4.1 Das ISO / OSI ­ Referenzmodell... 16
4.4.2 Das TCP / IP ­ Referenzmodell ... 18
4.4.3 TCP / IP... 20
4.4.3.1 Das Internet Protokoll IP... 20
4.4.3.2 Das Transportprotokoll TCP ... 21
4.5 Sicherheitsprobleme... 22
4.5.1 Sicherheitsprobleme von IP... 22
4.5.2 Sicherheitsprobleme von TCP... 23
4.6 Absicherung der Internet ­ und Transportprotokolle ... 24
4.6.1 SSL / TLS ... 24
II
4.6.2 IPsec... 25
4.7 Schlußfolgerung... 26
5.
XML ­ SECURITY...29
5.1 Einführung... 29
5.2 Grundlagen der Kryptographie... 32
5.2.1 Kryptographische Verfahren ... 32
5.2.1.1 Symmetrische Verschlüsselungsverfahren... 32
5.2.1.2 Asymmetrische Verschlüsselungsverfahren ... 35
5.2.2 Hashfunktionen und digitale Signaturen ... 38
5.2.2.1 Einführung... 38
5.2.2.2 Hashfunktionen ... 38
5.2.2.3 Digitale Signaturen... 40
5.2.3 Schlüsselmanagement ... 42
5.2.4 Authentizität und Autorisation... 46
5.3 XML ­basierte Sicherheitsstandards und Spezifikationen ... 48
5.3.1 Einführung... 48
5.3.2 XML Encryption ... 53
5.3.2.1 Granulare Verschlüsselung ... 53
5.3.2.2 Der XML Encryption - Syntax... 54
5.3.2.3 Die XML Encryption Processing Rules ... 60
5.3.2.4 Sicherheitserwägungen... 64
5.3.3 XML Signature... 65
5.3.3.1 Der XML Signature - Syntax ... 66
5.3.3.2 Die XML Signature Processing Rules ... 73
5.3.3.3 Sicherheitserwägungen... 76
5.3.4 XKMS (XML Key Management Specification)... 78
5.3.4.1 X-KISS : Das Tier ­ basierte Service ­ Modell ... 79
5.3.4.2 Der X-KISS Syntax... 82
5.3.4.3 X-KRSS : Der Registration Service... 87
5.3.4.4 Der X-KRSS Syntax... 88
5.3.4.5 Sicherheitserwägungen... 92
5.3.5 XML ­ basierte Authentizität und Autorisation ... 93
5.3.5.1 SAML ( Security Assertion Markup Language) ... 93
5.3.5.2 XACML (eXtensible Access Control Markup Language)... 112
5.4 Schlußfolgerung... 121
6.
SOAP - SECURITY EXTENSIONS ...129
6.1 Einführung... 129
6.2 WS - Security (Web Services Security) ... 130
6.2.1 Einführung... 130
6.2.2 Der WS ­ Security Syntax ... 130
6.2.3 Integration des XML Signature Syntax ... 133
6.2.4 Integration des XML Encryption Syntax ... 133
6.2.5 Sicherheitserwägungen ... 135
III
6.3 Schlußfolgerung... 136
7.
ZUSAMMENFASSUNG UND AUSBLICK ...137
ANHANG
... XII
RESSOURCENVERZEICHNIS
... XXXVI
LITERATURVERZEICHNIS
... XXXVII
IV
Abbildungsverzeichnis
Abbildung 1: XML ­ basierte Internet ­ Komponenten sprechen miteinander.
[Quelle : Stal 2001, S.16] ... 6
Abbildung 2: Das Beispiel ­ Szenario : Die IT ­ Infrastruktur der Firma IQ ­ Technology
[Quelle : Thomas 1999, S.4] ... 8
Abbildung 3: Das Beispiel ­ Szenario : Business Partner Connectivity ... 9
Abbildung 4: Elemente von Sicherheit [Quelle : Rannenberg 2000, S.490] ... 13
Abbildung 5: Wechselwirkungen zwischen den Sicherheitsforderungen für Webdienste ... 15
Abbildung 6: Das ISO / OSI ­ Referenzmodell [Quelle : Nusser 1998, S.10]... 16
Abbildung 7: Vergleich OSI und TCP / IP Protokollstack [Quelle : Bernert 1999, S.21]... 19
Abbildung 8: Der TCP / IP Protokollstack [Quelle : Fuhrberg 1998, S.10]... 20
Abbildung 9: Das Beispiel ­ Szenario : Einbeziehung von SSL in die Business Partner Connectivity... 27
Abbildung 10: CBC ­ Modus bei Blockalgorithmen [Quelle : Fuhrberg 1998, S.80] ... 33
Abbildung 11: Triple ­ DES Operationen [Quelle : Dournaee 2002, S.9] ... 34
Abbildung 12: Die digitale Signatur [Quelle : Fuhrberg 1998, S.93]... 41
Abbildung 13: Hierarchische Struktur der Zertifizierungsstellen [Quelle : Fuhrberg 1998, S.96]... 44
Abbildung 14: HTTP ­ Authentizitätsmechanismen [Quelle : Kirtland 2002, S.3]... 46
Abbildung 15: Das Beispiel ­ Szenario : Darstellung der Sicherheitsspanne und Transaktionsspanne... 48
Abbildung 16: Das Web Services Trust Framework von Entrust [Quelle : Entrust 2002, S.4]... 51
Abbildung 17: XML Encryption : Der Encryptor - Prozeßablauf [Quelle : Dournaee 2002, S.267] ... 62
Abbildung 18: XML Encryption : Der Decryptor - Prozeßablauf [Quelle : Dournaee 2002, S.270] ... 64
Abbildung 19: XML Signature : Die Reference - und Signature Generation... 74
Abbildung 20: XML Signature : Die Reference - und Signature Validation ... 76
Abbildung 21: XKMS : Minimierung der PKI ­ Komplexität... 78
Abbildung 22: XKMS : ,,XML Signature Verification and Trust" [Quelle : Dournaee 2002, S.334] ... 79
Abbildung 23: XKMS : Der Locate Service [Quelle : Dournaee 2002, S.338]... 80
Abbildung 24: XKMS : Der Validate Service [Quelle : Dournaee 2002, S.341]... 81
Abbildung 25: XKMS : Schlüsselgenerierung und Registration Request ... 89
Abbildung 26: SAML : Das SAML ­ Domain Modell [Quelle : Maler; Hallam ­ Baker, 2002, S.7]... 94
Abbildung 27: XACML : Das Data ­ Flow Modell [Quelle : Godik; Moses 2002, S.16] ... 112
Abbildung 28: XACML : Das Policy - Laguage Modell [Quelle : Godik; Moses 2002, S.18]... 115
Abbildung 29: Das Beispiel ­ Szenario : Die Grundlagen einer sicheren Web Services ­ Infrastruktur . 122
Abbildung 30: Das Beispiel ­ Szenario : Die Trust Context ­ Komponente
[Quelle : Netegrity 2002, S.2] ... 123
Abbildung 31: Das Beispiel ­ Szenario : Implementierung der Trust Context -, Trust Service ­ und
Trusted XML Messaging ­ Komponente ... 128
Abbildung 32: Der XML Encryption ­ Syntax : Darstellung der wichtigsten Elemente und Attribute .. XVI
Abbildung 33: Der XML Signature ­ Syntax : Darstellung der wichtigsten Elemente und Attribute ...XVII
Abbildung 34: Der X-KISS ­ Syntax : Darstellung der wichtigsten Elemente und Attribute... XVIII
Abbildung 35: Der X-KRSS ­ Syntax : Darstellung der wichtigsten Elemente und Attribute ... XIX
V
Abbildung 36: Der SAML ­ Syntax (I) : Darstellung der wichtigsten Elemente und Attribute ... XX
Abbildung 37: Der SAML ­ Syntax (II) : Darstellung der wichtigsten Elemente und Attribute ... XXI
Abbildung 38: Der XACML ­ Syntax (I) : Darstellung der wichtigsten Elemente und Attribute ...XXII
Abbildung 39: Der XACML ­ Syntax (II) : Darstellung der wichtigsten Elemente und Attribute... XXIII
VI
Source ­ Code Verzeichnis
Source Code 1: XML Encryption : Das <EncrytedType> Element ... 55
Source Code 2: XML Encryption : Das <EncryptionMethod> Element
[Quelle : Dournaee 2002, S.236]... 55
Source Code 3: XML Encryption : Das <Transforms> Element [Quelle : Dournaee 2002, S.239]... 56
Source Code 4: XML Encryption : Das <EncryptionProperties> Element ... 57
Source Code 5 : XML Encryption : Das <ds :RetrievalMethod> Element ... 57
Source Code 6: XML Encryption : Das <EncryptedKey> Element... 59
Source Code 7: XML Encryption : Das <AgreementMethod> Element... 60
Source Code 8: XML Signature : ,,Enveloped, enveloping and detached XML Signature"
[Quelle : Dournaee 2002, S.120]... 65
Source Code 9: XML Signature : Das <Signature> Element ... 66
Source Code 10: XML Signature : Das <SignatureValue> Element... 66
Source Code 11: XML Signature : Das <CanonicalizationMethod> Element
[Quelle : Dournaee 2002, S.123]... 67
Source Code 12: XML Signature : Das <SignatureMethod> Element [Quelle : Dournaee 2002, S.123].. 67
Source Code 13: XML Signature : Das Type ­ Attribut des <Reference> Elements... 69
Source Code 14: XML Signature : Das <Reference> Element [Quelle : Dournaee 2002, S.149] ... 69
Source Code 15: XML Signature : Das <KeyInfo> Element ... 70
Source Code 16: XML Signature : Das <Object> Element... 71
Source Code 17: XML Signature : Das <Signature> Element in Verbindung mit dem
<Manifest> Element [Quelle : Dournaee 2002, S.142] ... 72
Source Code 18: XML Signature : Das <SignatureProperties> Element... 73
Source Code 19: XKMS : Der Locate Service : Der Syntax der Request ­ und
Response ­ Nachrichten ... 83
Source Code 20: XKMS : Der Validate Service : Der Syntax der Request ­ und
Response ­ Nachrichten ... 86
Source Code 21: XKMS : Das <AuthServerInfo> - und <AuthUserInfo> Element ... 88
Source Code 22: XKMS : Der Registration Service (I):: Der Syntax der Request ­ und
Response ­ Nachrichten ... 89
Source Code 23: XKMS : Der Registration Service (II): Der Syntax der Request ­ und
Response ­ Nachrichten ... 90
Source Code 24: XKMS : Der Registration Service (III): Der Syntax der Request ­ und
Response ­ Nachrichten ... 90
Source Code 25: SAML : Das <Conditions> Element... 97
Source Code 26: SAML : Das <SubjectStatement> Element ... 98
Source Code 27: SAML : Das <AuthenticationStatement> Element... 99
Source Code 28: SAML : Das <AuthorizationDecisionStatement> Element ... 100
Source Code 29: SAML : Das <AttributeStatement> Element ... 100
Source Code 30: SAML : Das <Assertion> Element ... 101
VII
Source Code 31 : SAML : Das <Request> Element ... 102
Source Code 32: SAML : Das <Response> Element ... 104
Source Code 33: XACML : Das <Rule> Element ... 116
Source Code 34: XACML : Das <PolicyStatement> Element... 118
Source Code 35 : XACML : Das <PolicySetStatement> Element... 119
Source Code 36: WS ­ Security : Das <UsernameToken> Element... 131
Source Code 37: WS ­ Security : Das <BinarySecurityToken> Element... 132
Source Code 38: WS ­ Security : Das <SecurityTokenReference> Element... 132
Source Code 39: Das Beispiel ­ Szenario : Das DTD ­ Schema ,,schema.dtd"...XII
Source Code 40: Das Beispiel ­ Szenario : Das XML ­ Dokument ,,transfer.xml"... XIV
Source Code 41: Das Beispiel ­ Szenario : Das modifizierte XML ­ Dokument ,,transfer.xml" (I) ..XXVII
Source Code 42: Das Beispiel ­ Szenario : Der Locate ­ und Validate Service der
Trust Services ­ Komponente (I) ... XXIX
Source Code 43: Das Beispiel ­ Szenario : Das modifizierte XML ­ Dokument ,,transfer.xml" (II).XXXII
Source Code 44: Das Beispiel ­ Szenario : Der Locate ­ und Validate Service der
Trust Services ­ Komponente (II) ... XXXIV
Source Code 45: Das Beispiel ­ Szenario : Die Übermittlung von Authentifizierungsdaten an die
Trust Context ­ Komponente ...XXXV
VIII
Tabellenverzeichnis
Tabelle 1: SAML : Die Gültigkeit einer Assertion in Abhängigkeit vom <Conditions> Element... 97
Tabelle 2: SAML : Das <StatusCode> Element und die möglichen Ausprägungen des
Value ­ Attributes ... 104
Tabelle 3: SAML : Eine Unterscheidung zwischen der dienstgebunden ­ und der
informationsgebundenen Sicherheit ... 105
Tabelle 4: SAML : Sicherheitserwägungen für die SAML ­ Protocol Bindings ... 109
Tabelle 5: SAML : Sicherheitserwägungen für die SAML ­ Protocol Profiles ... 111
Tabelle 6: XACML : Die ,,Rule truth table" [Quelle : Godik, Simon; Moses, Tim 2002, S.19]... 117
Tabelle 7: Das Beispiel ­ Szenario : Die Bedeutung der einzelnen Symbole ... 124
Tabelle 8: Das Beispiel ­ Szenario : Die Web Services ­ gesteuerten Prozesse innerhalb der
einzelnen Transaktionsschritte ... 127
Tabelle 9: WS ­ Security : Das Konzept der Security Token [Quelle : Atkinson; Hada 2002, S.7
]
... 131
Tabelle 10: WS ­ Security : Das Type ­ Attribut des <Password> Elements [Quelle
: Atkinson; Hada 2002, S.11
]
... 132
Tabelle 11: WS ­ Security : Einordnung der XML Signature und Encryption ­ Elemente in die
SOAP - Elementenstruktur... 134
Tabelle 12: Das DTD ­Schema : Die inhaltliche Bedeutung der einzelnen Elemente... XV
Tabelle 13: Ein Überblick über die verwendeten Namespaces ... XXIV
IX
Abkürzungsverzeichnis
ACL Access
Control
List
AES
Advanced Encryption Standard
AH
IP Authentification - Header
BPEL
Business Process Execution Language
BPMI
Business Process Management Initiative
bspw. beispielsweise
BTP
Business Transactions Protocol
bzgl. bezüglich
CBC
Cipher Block Chaining
DES
Data Encryption Standard
DOS
Denial of Service
DSA
Digital Signature Algorithm
DTD
Document Type Declaration
EAI Enterprise
Application
Integration
ebXML Electronic
Business
XML
engl. englisch
ESP
IP Encapsulation Security Payload
FTP
File Transfer Protocol
geg. gegebenenfalls
HTML
Hyper Text Markup Language
HTTP
Hypertext Transfer Protocol
HTTPR reliable
HTTP
i.S.v.
im Sinne von
IETF
Internet Engineering Task Force
IIS
Microsoft Internet Information Server
insbes. insbesondere
IP Internet
Protocol
IV Initialisierungsvektor
J2EE
Java 2 Platform, Enterprise Edition
L Lieferant
LDL Logistikdienstleister
MAC
Message Authenticate Code
X
MIME
Multipurpose Internet Mail Extensions
OAEP
Optimal Asymmetric Encryption Padding
OASIS
Organisation for the Advancement of Structured Information
Standards
PAP
Policy Administration Point
PDP
Policy Decision Point
PEP
Policy Enforcement Point
PGP
Pretty Good Privacy
PIP Policy
Information
Point
PKCS
Public Key Cryptography Standards
PKI
Public Key Infrastructure
PKIX
Public - Key Infrastructure (X.509)
POP
Proof of Possession
PRP
Policy Retrieval Point
ROI Return
on
Investment
RPC
Remote Procedure Call
SA Security
Association
SHA
Secure Hash Algorithm
SigG Deutsches
Signaturgesetz
SMTP
Simple Mail Transfer Protocol
SOAP
Simple Object Access Protocol
SPKI Simple
PKI
SSH Secure
Shell
SSL Secure
Socket
Layer
TCP
Transmission Control Protocol
TLS Transport
Layer
Security
u.a. unter
anderem
u.U. unter
Umständen
UDDI
Universal Description, Discovery and Integration
UDP
User Datagram Protocol
URI Uniform
Resource
Identifier
URL Uniform
Resource
Location
W3C
World Wide Web Consortium
WS - Routing
Web Services Routing Protocol
XI
WS ­ Security
Web Services Security
WSDL
Web Services Description Language
WSFL
Web Services Flow Language
WS-I
Web Services Interoperability Organization
XAML
Transaction Authority Markup Language
X-KISS
XML Key Information Service Specification
XKMS
XML Key Management Specification
X-KRSS
XML Key Registration Service Specification
XML eXtended
Markup
Language
XTASS
XML Trust Assertion Service Specification
z.B. zum
Beispiel
ZS Zertifizierungsstelle
1. Einleitung
1
1. Einleitung
Der Siegeszug des Internets in den vergangenen 10 Jahren hatte auch erhebliche
Auswirkungen auf die Art und Weise, wie Unternehmensanwendungen heute entwickelt
werden. Diese Revolution in der Softwareentwicklung wurde mitbegründet durch die
von der Internet Engineering Task Force (IETF) auf den Weg gebrachten Standards.
Dazu zählen u.a. HTML, HTTP und XML, ein Internet ­ Standard zum Austausch von
strukturierten Dokumenten.
1
Web Services machen gerade durch die Nutzung von SOAP einen intensiven Gebrauch
von diesen Internet ­ Standards. Ein Web Service stellt eine Komponente dar, in der
spezifische Geschäftsfunktionalitäten gekapselt sind. Diese Funktionalitäten werden
über ein Netzwerk, wie dem Internet, anderen Anwendungen oder Komponenten zur
Verfügung gestellt, wodurch Transaktionen über Unternehmensgrenzen hinweg
abgebildet werden können.
,,The evolution of business on the Internet is putting enterprise functionality
near the fringes of the company firewall"
Damit ergeben sich aber auch ganz neue Sicherheitsherausforderungen für die
Unternehmen. Web Services basieren zwar auf bestehenden Internet ­ Technologien,
erfordern aber im Vergleich zur Sicherung von Web Sites eine ganz andere
Herangehensweise. Trotz dieser unterschiedlichen Herangehensweise können eine
Vielzahl von Tools und Technologien, die zur Sicherung von Web Sites verwendet
werden, auch für Web Services eingesetzt werden.
2
Die Klärung und Lösung dieser sicherheitsrelevanten Problemstellungen ist von
entscheidender Bedeutung für den erfolgreichen Einsatz von Web Services im EAI ­
Umfeld.
Ausgehend von Kapitel 2, in dem eine kurze Einführung in die Funktionsweise von
Web Services gegeben wird, soll in Kapitel 3 ein konkretes Beispiel ­ Szenario
aufgebaut werden, das durch die sukzessive Lösung von Sicherheitsanforderungen und
der Implementierung geeigneter Protokolle und Standards in den nachfolgenden
Kapiteln erweitert werden soll.
In Kapitel 4 werden Grundlagen der Internet ­ Sicherheit dargestellt. Insbesondere
werden dabei Sicherheitseigenschaften für Web Services und die Eigenschaften der
Internet ­ Protokollfamilie erarbeitet. Die sich daraus ergebenden Sicherheitsprobleme
1
Vgl. Sun Microsystems, Inc. 1999, S.10
2
Vgl. Sundsted 2002, S.1
2. Web Services
2
der Internet ­ Protokollfamilie sowie deren mögliche Lösung stehen schließlich am
Ende der Betrachtung.
In dem Kapitel 5 erfolgt zunächst eine allgemeine Einführung in kryptographische
Verfahren, Hashfunktionen und digitale Signaturen. Das Schlüsselmanagement und
Fragen der Authentizität und Autorisation bilden den Schlußpunkt dieser Betrachtung.
Im Anschluß daran werden XML ­ basierte Sicherheitsstandards und Spezifikationen
dargestellt und mit den zuvor beschriebenen Sicherheitskonzepten in Verbindung
gebracht.
Die SOAP ­ Security Extensions werden in Kapitel 6 vorgestellt und bilden den
Abschluß dieser Arbeit.
2. Web Services
2.1 Einführung
Web Services stellen ein Framework bereit, welches eine dynamische Integration von
Applikationen und Unternehmen über das Internet ermöglicht.
Zukünftig können Web Services für den Wachstum der IT ­ Branche von
entscheidender Bedeutung sein. Insbesondere die Stagnation im EAI ­ Bereich könnte
damit überwunden werden.
Dem stehen jedoch auch sicherheitsrelevante Fragestellungen gegenüber, die es zu lösen
gilt. Das Kapitel 2 soll einen Einblick über die Funktionsweise von Web Services
geben, um darauf aufbauend ein Beispiel ­ Szenario entwickeln zu können, das durch
sukzessives Lösen der aufgeworfenen Sicherheitsanforderungen erweitert werden soll.
2.2 Definition
Innerhalb dieses Kapitels ist eine Abgrenzung zwischen Enterprise Application
Integration (EAI) und Web Services erforderlich.
Web Services können folgendermaßen definiert werden:
3
,,A collection of functions that are packaged as a single entity and published to the
network for use by other programs. Web services are building blocks for creating
open distributed systems, and allow companies and individuals to quickly and
cheaply make their digital assets available worldwide"
3
Vawter; Roman 2001, S.3
2. Web Services
3
Auf der anderen Seite muß noch der Begriff EAI erläutert werden :
4
,,Enterprise Application Integration combines the technologies and processes that
enable custom ­ built and / or packaged business applications to exchange business
­ level information in format and contexts that each understands"
Letztendlich stellen Web Services aus technologischer Sicht keine grundlegende
Neuerung im Bereich der verteilten Anwendungsentwicklung dar. Vielmehr können sie
als natürliche Weiterentwicklung bestehender XML ­ basierter Lösungen verstanden
werden, deren Aufgabe in der strukturierten Darstellung sowie dem Austausch und der
Weiterverarbeitung von Geschäftsdaten bestand.
2.3 Eigenschaften, Anforderungen und Nutzenpotentiale für EAI
Durch EAI sollen gerade systemübergreifende Geschäftsprozesse mit Hilfe geeigneter
Technik derart abgebildet werden, daß alle am Geschäftsprozeß beteiligten Systeme die
prozeßrelevanten Daten miteinander in geeigneter Form austauschen können und
insbesondere bezüglich der Daten ein gleiches Verständnis haben.
5
Bis zur Entwicklung
von Web Services waren eben diese Integrationstätigkeiten, aufgrund der Heterogenität
der innerhalb der Unternehmen verwendeten Programmiersprachen und Middleware,
sehr schwierig. Durch die Nutzung von Web Services ist eine schnelle und
kostengünstige Integration von Internet / Intranet ­ fähigen Anwendungen ohne
Probleme möglich. Als Basis dient SOAP, das Internet ­ Standards, wie beispielsweise
XML, für den Austausch von Geschäftsdaten und deren Übermittlung durch HTTP
verwendet. Diese Standards werden von allen Programmiersprachen, Middleware - und
Plattformanbietern unterstützt.
Aus technologischer Sicht stellen sie also weiterhin XML ­ basierte Verbindungen zu
Unternehmen, Anwendungen und Systemdiensten dar.
6
Web Services können zum
einen als Integrationssoftware für unternehmensinterne Anwendungen, zum anderen
aber auch als eine auf dem Internet ­ Standard XML basierende Middleware verstanden
werden, die eine direkte Kommunikation zwischen Applikationen über das Internet
ermöglicht. Für eine vollständige Integration ist jedoch ein umfassendes Framework
erforderlich.
7
4
Sailer 2001, S.208
5
Vgl. Sailer 2001, S. 208 ff.
6
Vgl. Vawter; Roman 2001, S.4 ff.
7
Vgl. Stal 2001, S.16
2. Web Services
4
Sämtliche von einem Web Service benötigten Daten bzw. Informationen zur
Durchführung seiner angebotenen Dienste sind entweder direkt Teil des SOAP ­
Requests oder Informationen, die innerhalb einer Datenbank verwaltet werden und
durch den SOAP ­ Request dem Web Service verfügbar gemacht werden. Web Services
sind also stets zustandslos (engl. Stateless). Weiterhin enthält ein Web Service alle für
einen Prozeß relevanten Funktionalitäten und Methoden, um diesen eigenständig in
konsistenter Weise durchführen zu können. Web Services sind folglich atomar (engl.
Atomic).
8
Daraus ergeben sich besondere Erfordernisse an die Sicherheit bzgl. der Übertragung
und der Informationssicherheit der auszutauschenden XML ­ Dokumente.
Eine Web Services - Infrastruktur bezieht eine Vielzahl von heterogenen und verteilten
Systemen bei der Integration von Geschäftsprozessen ein und kann durch folgende
Charakteristika beschrieben werden :
Dezentralisierte Architektur und Administration
Heterogenität bzgl. der Implementationstechnologien
Verbindung zu einer Vielzahl von unterschiedlichen Abteilungen und Unternehmen
Peer ­ basierte Architektur
,,Offenheit" der Infrastruktur
Alle genannten Charakteristika stellen erhebliche Sicherheitsanforderungen und
Herausforderungen an das gesamte System.
9
So muß insbesondere bei der Verwendung von Web Services darauf geachtet werden,
daß bei jeder Form der Integration von Geschäftsprozessen über das Internet bzgl. des
verwendeten Messaging - Protokolls gewisse Anforderungen zu stellen sind.
Insbesondere muß auch SOAP einen konsistenten und zuverlässigen
Kommunikationsmechanismus zwischen den am Datenaustausch beteiligten Parteien
ermöglichen.
8
Vgl. Microsoft Corporation 2002b, S.2
9
Vgl. Posts 2002, S.1
2. Web Services
5
Für einen voll funktions - und leistungsfähigen Datenaustausch über das Internet sind
eine Vielzahl von Mechanismen und Diensten erforderlich, die im einzelnen folgende
Aspekte betreffen :
Authentifikation and Authorization
Signatures and Encryption
Interest ­ based routing (publish / subscribe)
Message correlation
Business process orchestration (workflow)
Message content transformation
Attachements and MIME encapsulation (packaging)
Die Servicequalität (engl. Quality of Service) zeichnet sich gerade auch dadurch aus,
den Sender und Empfänger ­ Service authentifizieren zu können. Der Ursprung einer
Nachricht muß genauso nachvollziehbar sein wie die Tatsache, daß jede gesandte
Nachricht nur einmal empfangen werden kann. Eine fehlerhafte Übertragung muß
beiden Parteien bekannt gegeben werden können und Nachrichten müssen in der
gleichen Reihenfolge beim Empfänger eintreffen, wie sie vom Sender verschickt
wurden.
10
Inwieweit die bis dahin genannten Sicherheitsanforderungen durch ein geeignetes
Protokoll ­ Design erfüllt werden können, wird Gegenstand des Kapitels 4 sein. Dort
wird dann besonders auf die von SOAP verwendeten Protokolle der Internet ­ und
Transportschicht Bezug genommen.
Bei der Entwicklung von Web Services muß weiterhin darauf geachtet werden, daß
diese gewisse Kriterien erfüllen, welche sich grundsätzlich nicht sehr von denen
unterscheiden, die andere Unternehmensanwendungen erfüllen müssen. Dazu zählen
Fehlertoleranz, Skalierbarkeit und Zuverlässigkeit. Sowohl bei J2EE als auch bei .NET
laufen Web Services innerhalb von Containern ab, welche die Interaktion mit anderen
Diensten, Anwendungen und Unternehmen regeln und steuern. Damit können sich
Unternehmen bei der Entwicklung von Web Services auf ihr Spezialwissen
konzentrieren und müssen sich nicht um die Integration ihrer Lösung innerhalb einer
gegebenen Systemlandschaft kümmern. Die Vision geht letztendlich dahin, daß Web
10
Vgl. Brown 2002, S.1 ff.
2. Web Services
6
Services sich vollständig selbst beschreiben und bei Bedarf dynamisch miteinander
interagieren können.
11
2.4 Implementierung und Aufruf von Web Services
Bei der Implementierung von Web Services sind XML ­ basierte Komponenten
erforderlich, die über das SOAP ­ Protokoll automatisiert Daten austauschen.
Insbesondere sind Unternehmen und Entwickler via SOAP in der Lage auf Web
Services zuzugreifen. Für den Aufruf und die Verwendung von Web Services sind
WDSL und UDDI, zwei spezielle XML - basierte Standards, von Bedeutung.
Abbildung 1: XML ­ basierte Internet ­ Komponenten sprechen miteinander. [Quelle : Stal 2001, S.16]
Der Web Service wird zunächst durch den Anbieter in der WDSL beschrieben. Diese
Detailinformationen werden durch Festschreibung in der UDDI ­ Registry
übernommen. Damit ist der Web Service für Anwendungen verfügbar. Wenn nun eine
Anwendung über das Internet Informationen abfragen will, erfolgt der Datenaustausch
und die Einbindung des Web Service unter Verwendung des SOAP ­ Protokolls. Ein
SOAP ­ Client, der mit der anfragenden Anwendung verbunden ist, sucht unter
Verwendung der UDDI ­ Registry nach einem geeigneten Web Service. Die UDDI ­
11
Vgl. Vawter; Roman 2001, S.4 ff.
SOAP - Client
SOAP - Server
Integrierte
Applikation, etwa
Abrechnungssoftware
Integrierte
Applikation,
etwa
Datenbank
UDDI - Registry
3. Das Beispiel ­ Szenario
7
Registry zeigt nun wie dieser Web Service aufgerufen werden kann. Anschließend
erfolgt der Aufruf des SOAP ­ Client an den vorgeschlagenen SOAP ­ Server.
12
3. Das Beispiel ­ Szenario
Innerhalb dieses Kapitels soll ein Beispiel ­ Szenario für eine Web Services -
Infrastruktur aufgebaut werden. Dabei stehen lediglich die für das Thema unmittelbar
relevanten Inhalte im Mittelpunkt der Betrachtung. In diesem Zusammenhang werden
folgende Annahmen implizit unterstellt :
1.) Sicherheitsrelevante Problemstellungen, die unmittelbar den Intranet ­ Bereich der
beteiligten Geschäftspartner betreffen, werden ausgeblendet. Es wird demzufolge
unterstellt, daß alle Geschäftspartner eine voll funktionsfähige Sicherheitspolitik
adaptiert haben. Dies betrifft insbesondere die Konfiguration der Firewall, die
lokalen Authentizitäts - und Autorisationsroutinen und die sichere Aufbewahrung
von sensitiven Benutzerdaten.
2.) Die Web Server sind unter sicherheitskritischen Gesichtspunkten konfiguriert. Dies
schließt vor allem eine fehlerfreie Konfiguration von Netzdiensten, wie etwa dem
Domain Name Service (DNS), ein. Nicht benötigte Netzdienste sind deinstalliert,
um keine unnötigen Angriffspunkte zu liefern.
Abbildung 2 zeigt eine vereinfachte Darstellung der IT ­ Infrastruktur der Firma IQ ­
Technology. In der Middle Tier wird sowohl von der Implementierung eines konkreten
Frameworks, wie J2EE oder .NET, als auch von der genauen Verarbeitungsweise
innerhalb des Web Service - Containers abstrahiert.
12
Vgl. Stal 2001, S.16
3. Das Beispiel ­ Szenario
8
Abbildung 2: Das Beispiel ­ Szenario : Die IT ­ Infrastruktur der Firma IQ ­ Technology
[Quelle : Thomas 1999, S.4]
Innerhalb dieser Infrastruktur wird ein Web Service angeboten, der für die noch zu
formulierende Aufgabenstellung des Beispiel ­ Szenarios die benötigte Funktionalität
bereitstellt. Der Geschäftsprozeß, der durch den Web Service abgebildet wird, enthält
die gesamten Funktionen, die für die Bestellabwicklung zwischen den beteiligten
Parteien erforderlich sind.
Abbildung 3 zeigt alle an dem Geschäftsprozeß beteiligten Parteien. Aus den zuvor
gemachten Annahmen wird sofort ersichtlich, daß lediglich die durch die Pfeile
dargestellten Informationsflüsse Gegenstand sicherheitsrelevanter Überlegungen sein
können. Dies betrifft gerade die Verbindung zwischen den beteiligten
Kommunikationspartnern und die in den auszutauschenden Geschäftsdokumenten
enthaltenen Informationen.
Firewall
Client Tier
Middle Tier
Data Tier
Client
Client
Client
Client
Client
Web Server
HTML
XML
Application Server
EIS
Systems
RDBMS
Legacy
ERP
Web ­
Service
Container
3. Das Beispiel ­ Szenario
9
Abbildung 3: Das Beispiel ­ Szenario : Business Partner Connectivity
Genau hier findet der Aufruf und die Einbindung des Web Services durch den
entsprechenden Client sowie der Austausch von Geschäftsdaten mittels SOAP statt.
Gemäß dem Kapitel 2 impliziert dies aber wiederum die Nutzung von XML, für den
Austausch von Geschäftsdaten, und deren Übermittlung durch HTTP. Diese beiden
Teilgebiete sind dann letztendlich Gegenstand von Sicherheitsüberlegungen. Während
in Kapitel 4 Vorschläge für eine Absicherung der Internet ­ und Transportprotokolle
gemacht werden, setzen sich Kapitel 5 und 6 mit neueren Standards und Spezifikationen
zur Absicherung von XML ­ Dokumenten und den sogenannten SOAP Security -
Extensions auseinander.
Web Server
HTML
XML
Web ­
Service
Container
Firma IQ - Technology
Firewall
Logistikdienstleister
(LDL)
E - Logistic
Zulieferer (L)
Firma Hansen
Firewall
Firewall
Client
Client
Client
SOAP ­ Request via HTTP
SOAP ­ Response via HTTP
HTTP HTTP
HTTP
HTTP
HTTP
HTTP
2.
1.
2. 5.
2.
5.
3.
4.
3. 4.
5.
Web ­ Service
Container
Web ­ Service
Container
3. Das Beispiel ­ Szenario
10
Der durch den Web Service dargestellte Geschäftsprozeß setzt sich aus folgenden
aufeinander aufbauenden Transaktionen zusammen :
13
1. Transaktionsschritt :
Bedarfsermittlung durch dynamische Lagerbestandsplanung innerhalb des ERP ­
Systems der Firma IQ ­ Technology.
2. Transaktionsschritt :
Automatische Bestellung und Übermittlung der relevanten Daten an den
entsprechenden Lieferanten und den Logistikdienstleister.
3. Transaktionsschritt :
Durchführung der Bestellung sofern der entsprechende Lieferant in der Lage ist die
Bestellung auszuführen, d.h. Durchführung einer Verfügbarkeitsprüfung der Ware
beim entsprechenden Lieferanten.
4. Transaktionsschritt :
Bestellfortschrittskontrolle und gegenwärtiger Ort / Status der verschickten Ware
beim Logistikdienstleister.
5. Transaktionsschritt :
Automatische Bestandsaktualisierung bei Eintreffen der Ware innerhalb des ERP ­
Systems der Firma IQ ­ Technology.
Automatische Buchung / Verrechnung des zu zahlenden Betrags innerhalb des ERP
­ Systems der Firma IQ ­ Technology sowie deren Transaktionspartner.
Das XML ­ Dokument ,,transfer.xml" beinhaltet alle für den vorliegenden
Geschäftsprozeß relevanten Daten, wobei der Dokumentenstruktur ein gültiges DTD ­
Schema ,,schema.dtd" zugrundegelegt sei. Beide Dokumente sind zusammen mit der
konkreten Ausprägung und Erklärung der einzelnen Elemente und Attribute im Anhang
dargestellt.
13
Diese einzelnen Transaktionsschritte sind in Abbildung 3 durch eine entsprechende Nummerierung der
Pfeilendungen hervorgehoben.
4. Internet ­ Sicherheit
11
4. Internet ­ Sicherheit
4.1 Einführung
Eine der einfachsten Methoden XML ­ basierte Web Services sicher zu gestalten, ist die
Möglichkeit, die Verbindung zwischen SOAP - Client und SOAP ­ Server abzusichern.
Dafür stehen eine Vielzahl von Technologien bereit, die von Firewall ­ basierten Rollen
über Secure Sockets Layer (SSL) bis zu Virtual Private Networks (VPN) reichen.
14
Durch die Verwendung von Web Services und den damit verbundenen Austausch von
sensitiven Daten über das Internet, ergeben sich eine Vielzahl von
Sicherheitsbedrohungen. Diese betreffen, neben dem unautorisierten Lesen und
Verändern von Daten, auch das Maskieren und Vortäuschen einer falschen
Absenderidentität. Aus diesem Grund beschäftigt sich das Kapitel 4 mit
Sicherheitsfragen im Zusammenhang mit den für das Internet festgelegten
Kommunikationsprotokollen der Internet ­ Protokollfamilie.
15
Hierbei ist es hilfreich, sich mit den Aufgaben und Funktionen, die für die Übertragung
von Daten zwischen zwei Computern notwendig sind, vertraut zu machen. Diese
werden in der Regel in Schichten organisiert, wobei jede Schicht für die jeweils
übergeordnete Schicht spezifische Dienste zu leisten hat.
Die Regeln zur Steuerung dieser Kommunikation werden unter dem Begriff des
Protokolls zusammengefaßt. Wenn nun ein Computer mit einem anderen Computer
Daten austauschen möchte, erfolgt diese Kommunikation derart, daß die jeweils n-te
Schicht des einen Computers mit der n ­ ten Schicht des anderen Computers
kommuniziert. Das dafür verwendete Protokoll wird dann allgemein als Schicht ­ n ­
Protokoll bezeichnet. Dabei werden die Daten von der höchsten Schicht an die nächst
niedrigere Schicht übergeben, bis die unterste Schicht erreicht ist, die als physikalisches
Übertragungsmedium bezeichnet wird. Dabei werden die Daten eingekapselt, indem
von jeder Schicht spezifische Steuerinformationen zu den eigentlichen Nutzdaten
hinzugefügt werden.
16
Angefangen mit der allgemeinen Definition eines IT ­ Systems und dessen
unterschiedlichen Ausprägungen, beschäftigt sich Kapitel 4.3 mit der Formulierung von
Sicherheitseigenschaften, die von der sukzessiv zu entwickelnden Web Services ­
Infrastruktur zu erfüllen sind.
14
Vgl. Microsoft Corporation 2002a, S.2
15
Vgl. Eckert 2001, S.39
16
Vgl. Fuhrberg 1998, S.5
4. Internet ­ Sicherheit
12
Kapitel 4.4 gibt einen kurzen Einblick in die Internet ­ Protokollfamilie. Es wird das
ISO / OSI ­ und das TCP / IP ­ Referenzmodell vorgestellt, wobei der spätere Focus auf
die Internet ­ und Transportschicht gelegt wird. Auf der Internetschicht wird das
Internet Protocol IP und auf der Transportschicht das Transmission Controll Protocol
TCP in deren grundlegendsten Eigenschaften und Funktionsweisen behandelt. Dort
werden dann auch mögliche Sicherheitsprobleme aufgezeigt und zugleich
Lösungsmöglichkeiten vorgeschlagen.
4.2 Definition
Für die nachfolgende Betrachtung ist es erforderlich grundlegende Begriffe der IT ­
Sicherheit zu definieren. Dabei soll auf die Definition eines IT ­ Systems im
allgemeinen und auf den Unterschied zwischen geschlossenen und offenen Systemen
eingegangen werden.
Ein IT ­ System kann folgendermaßen definiert werden :
17
,,Ein IT ­ System ist ein geschlossenes oder offenes, dynamisches und
technisches System mit der Fähigkeit zur Speicherung und Verarbeitung von
Informationen"
Geschlossene Systeme bauen dabei auf der Technologie eines Herstellers auf, sind zu
Konkurrenzprodukten inkompatibel und deren Verbreitung ist auf ein bestimmtes
räumliches Gebiet und einen bestimmten Teilnehmerkreis beschränkt. Sie werden in
aller Regel zentral verwaltet und sind homogen. Offene Systeme stellen im Gegensatz
dazu vernetzte, physisch verteilte Systeme dar, die sich an Standards zum
Informationsaustausch mit anderen Systemen orientieren. Sie sind also offen in der
Kommunikation mit anderen Systemen und insbesondere darin gekennzeichnet, daß sie
dezentral verwaltet werden und sich aus heterogener Hard ­ und Software
zusammensetzen.
18
Innerhalb unserer Betrachtung gehen wir von offenen Systemen aus, die unter
Verwendung des in dem Beispiel ­ Szenario beschriebenen Web Service miteinander
kommunizieren und Daten über das Internet austauschen.
17
Eckert 2001, S. 1
18
Vgl. Eckert 2001, S.1 ff
4. Internet ­ Sicherheit
13
4.3 Sicherheitseigenschaften
Der Begriff Sicherheit soll im Sinne von Sicherheit von Information und
Kommunikation verwendet werden und sich dabei vorwiegend auf immaterielle
Schutzgüter und den Schutz vor beabsichtigten Angriffen beziehen. Der so definierte
Begriff der Sicherheit soll dabei mit dem Begriff Security gleichgesetzt werden.
Insbesondere stellt dieser Begriff dann auch die Basis für die Sicherheit IT ­ gestützter
Geschäftsprozesse, insbesondere von XML ­ basierten Web Services, dar.
19
Informationen bzw. Daten sind die zu schützenden Güter von informationssicheren bzw.
datensicheren Systemen. Unter anderem darf der Zugriff nur durch autorisierte Subjekte
erfolgen, was durch die Sicherheitseigenschaft der Authentizität zu erreichen ist.
20
Die Erreichung von Sicherheitszielen birgt jedoch auch einen menschlichen Zwiespalt,
der in Abbildung 4 dargestellt wird.
Abbildung 4: Elemente von Sicherheit [Quelle : Rannenberg 2000, S.490]
19
Vgl. Rannenberg 2000, S.489 ff.
20
Vgl. Eckert 2001, S. 4 ff.
Ein sehr menschlicher
Zwiespalt
Privatheit
Die eigene Sphäre und die
eigenen Güter schützen
Verbindlichkeit
Vertrauen (bei Partnern)
gewinnen
Eine eher technische
Gliederung
Vertraulichkeit
Informationen nicht an die
Falschen
Integrität
Keine Verfälschung von
Informationen
Verfügbarkeit
Kein Ausfall von Ressourcen
Zurechenbarkeit
Keine unerwarteten Aktionen
Sicherheit
4. Internet ­ Sicherheit
14
Bei der Darstellung dieser Sicherheitsziele beziehe ich mich im folgenden auf Brandt;
Bonte 2002, S.1 ff. in Verbindung mit Röhrig; Knorr; Noser 2000, S.500 :
Verfügbarkeit
Daten und Funktionen müssen für den autorisierten Benutzer bei Bedarf bzw. in
angemessener Zeit verfügbar sein.
Die Verfügbarkeit kann nicht durch die in Kapitel 5 dargestellten
Sicherheitsverfahren ermöglicht werden, und stellt daher auch keine Anforderung an
die noch einzuführenden XML ­ basierten Sicherheitsstandards und Spezifikationen
dar.
Integrität
Die Integritätsforderung zielt darauf ab, daß Daten weder absichtlich noch
versehentlich unbefugt geändert werden können. Sie garantiert damit die Korrektheit
und Vollständigkeit der auszutauschenden Daten. Kryptographische Verfahren, wie
beispielsweise Hashfunktionen, stellen eine perfekte Möglichkeit dar, Änderungen
an der Ursprungsnachricht aufzudecken. Dieser Sachverhalt wird in Kapitel 5.2.2.2
näher dargestellt. Somit sind XML ­ basierte Sicherheitsstandards und
Spezifikationen, wie die XML Signature - Empfehlung oder der XML Encryption -
Entwurf, in der Lage die Integrität von Daten zu gewährleisten.
Vertraulichkeit
Vertraulichkeit schützt Daten vor unbefugter Kenntnisnahme durch Personen,
Prozesse o.ä.. Wie wir noch sehen werden verfügen XML ­ basierte
Sicherheitsstandards und Spezifikationen über ausgezeichnete Möglichkeiten, die
Vertraulichkeit sensitiver Daten zu ermöglichen.
Zurechenbarkeit
Diese Sicherheitseigenschaft soll gewährleisten, daß Handlungen den betreffenden
Individuen zugerechnet werden können. Dies ist indirekt durch die Public ­ Private
Key Beziehung bei der Verschlüsselung von sensitiven Daten möglich und auch ein
wichtiger Einsatzbereich des Schlüsselmanagements, wie der XKMS ­
Spezifikation.
Die Zurechenbarkeitsforderung macht es dem Sender einer Nachricht unmöglich, im
nachhinein das Senden seiner Nachricht abzustreiten. Man spricht in diesem
Zusammenhang von der Unabstreitbarkeitsforderung (engl. Nonrepudiation). Der
Sender einer Nachricht muß also zweifelsfrei nachweisen können, daß er auch
wirklich die Person ist, die er vorzugeben scheint.
4. Internet ­ Sicherheit
15
Erfüllt wird die Authentizitätsforderung durch die XML Signature - Empfehlung. In
diesem Zusammenhang spielt auch die Überprüfbarkeit des Nachrichtenursprungs
(engl. Proof of Origin) eine wichtige Rolle. Es muß gewährleistet sein, daß die
Nachricht von einem zweifelsfrei identifizierten Absender stammt, und nicht eine
Wiedereinspielung einer zuvor übertragenen Nachricht ist.
21
Somit sollen
sogenannte Replay ­ Attacken vermieden werden.
22
Abschließend sei darauf hingewiesen, daß zwischen einigen dieser
Sicherheitseigenschaften gewisse Wechselwirkungen und Abhängigkeiten bestehen, die
in Abbildung 5 kurz dargestellt werden. Diese Sachverhalte ergeben sich unmittelbar
aus den zuvor beschriebenen Sicherheitseigenschaften.
Abbildung 5: Wechselwirkungen zwischen den Sicherheitsforderungen für Webdienste
[Quelle : Leung; Nadalin; Rich 2002, S.3]
In Abbildung 5 wird zur Veranschaulichung der Wechselwirkung bzw. der
Abhängigkeit zwischen der Nonrepudiation ­ und der Proof of Origin ­ Forderung
bereits auf die Verwendung einer Hashfunktion zur Überprüfung eines ausgetauschten
Dokuments auf dessen authentischen Ursprung hingewiesen, ein sogenannter Message
21
Vgl. Leung; Nadalin; Rich 2002, S.3
22
Dieser Sachverhalt wird in Kapitel 5.2 noch einmal aufgegriffen und näher erläutert. Zum jetzigen
Zeitpunkt ist ein genaues Verständnis dieser Sicherheitsforderung noch nicht erforderlich.
Nonrepudiation
Proof of Origin
Data Integrity
impliziert
Die
Integritätsforderung
schützt nicht vor
Replay ­ Attacken, da
sie die Daten einer
Nachricht nur auf
Vollständigkeit und
Korrektheit überprüft.
Ein HMAC ist
für die Proof of
Origin ­
Forderung, nicht
jedoch für die
Nonrepudiation ­
Forderung
ausreichend.
4. Internet ­ Sicherheit
16
Authentification Code (MAC) bzw. HMAC.
23
Dieses Konzept wird jedoch erst in
Kapitel 5.2.2 näher betrachtet, und ist für das jetzige Verständnis noch nicht
erforderlich.
4.4 Internet ­ Protokollfamilie
4.4.1 Das ISO / OSI ­ Referenzmodell
Das Open System Interconnection (OSI) ­Referenzmodell wurde Ende der siebziger
Jahre durch die International Standardization Organization (ISO) geschaffen, um eine
Vereinheitlichung, der vielen verschiedenen bis dahin entstandenen Protokolle und
Techniken zur Vernetzung von Computern, zu ermöglichen. Das Ziel dieser
Vereinheitlichung bestand also darin, durch eine Verwendung von einheitlichen
Schnittstellen eine Möglichkeit zu schaffen, unterschiedliche Netz ­ Komponenten von
verschiedenen Herstellern zusammen einsetzen zu können. Bei der Übertragung von
Daten durchlaufen diese sieben Schichten, die auf beiden Computern implementiert sein
müssen.
24
Abbildung 6 zeigt den genauen Aufbau der Schichten im ISO / OSI ­ Referenzmodell.
Abbildung 6: Das ISO / OSI ­ Referenzmodell [Quelle : Nusser 1998, S.10]
23
Vgl. Eckert 2001, S.245
24
Vgl. Fuhrberg 1998, S.7
Anwendungsschicht
Präsentationsschicht
Sitzungsschicht
Transportschicht
Netzwerkschicht
Datensicherungsschicht
Bitübertragungsschicht
Anwendungs -
system
Transport ­
system
Dienste
(Dateitransfer, Mail)
Transformation von
Daten
Management virtueller
Verbindungen
Transportadressen, Ende
­ zu ­ Ende- Verbindung
Wegewahl, Prioritäten
Zugang, Fehlerkorrektur
Übertragungsmedium,
Schnittstellen
4. Internet ­ Sicherheit
17
Das ISO / OSI ­ Referenzmodell besteht also aus sieben Schichten, deren Funktionen
nachfolgend kurz erläutert werden sollen. Dabei folge ich den Ausführungen von
Bernert 1999, S16 ff. und Nusser 1998, S.9 ff..
Die Bitübertragungsschicht (engl. Physical Layer) stellt die hardwarenächste Schicht
dar und regelt die physikalische Verbindung auf dem Medium. Sie legt also die
Eigenschaften des physikalischen Übertragungsmediums und der benötigten
Steckverbindungen fest.
Die Datensicherungsschicht (engl. Data Link Layer) nutzt die Dienste der
Bitübertragungsschicht, um die Bits zu logischen Einheiten, den sogenannten Frames
oder Rahmen, zusammenzufassen und zu übertragen. Es beinhaltet also all diejenigen
Standards, die für die Übertragung von Daten über ein bestimmtes physisches Teilnetz
benötigt werden.
Die Vermittlungs, - bzw. Netzwerkschicht (engl. Network Layer) besitzt als
Hauptaufgabe die Vermittlung der Pakete zwischen einzelnen Netzwerken, auch
Routing genannt. Dafür standardisiert sie die Adressierung und die automatische
Weiterleitung der Pakete über unterschiedliche physikalische Teilnetze hinweg. Darüber
hinaus regelt sie den Datenfluß auf dem Netzwerk und führt Aufgaben zur
Überlastungsüberwachung durch. Das Internet Protokoll (IP) gehört zu dieser Kategorie
der Vermittlungsschicht - Protokolle.
Die Transportschicht (engl. Transport Layer) sorgt für eine korrekte Verbindung
zwischen zwei Computern, und stellt somit den darüberliegenden Schichten eine
verläßliche Verbindung zur Verfügung. Sie sorgt für eine Korrektur von
Übertragungsfehlern auf den unteren Schichten und legt Adressen auf Transportebene
fest. Innerhalb der Internet Protocol Suite (IPS) werden diese Leistungen durch das
Transmission Control Protocol (TCP) erbracht.
Die Sitzungsschicht (engl. Session Layer) verwaltet virtuelle Verbindungen zwischen
zwei Anwendungen, und ist im TCP / IP ­ Stack nicht implementiert. Die in diesem
Bereich enthaltenen Standards üben hauptsächlich Ordnungsfunktionen aus, wie den
Aufbau und Abbau solcher Verbindungen, den automatischen Abbau einer Verbindung
nach längerer Inaktivität, oder die Wiederherstellung von Verbindungen nach einer
Unterbrechung auf einer der unteren Ebenen durch das Setzen von sogenannten
Synchronisationspunkten.
Die Präsentationsschicht (engl. Presentation Layer) standardisiert das Format der
auszutauschenden Daten auf oberster Ebene. Auf dieser Ebene sollte auch die
4. Internet ­ Sicherheit
18
Verschlüsselung der Daten stattfinden, wenngleich solche Sicherheitsaspekte in der
Praxis häufig auf der Anwendungs ­ oder der Vermittlungsschicht, wie z.B. bei IPv6,
implementiert werden. Weiterhin soll innerhalb dieser Schicht, gemäß der ISO
Konvention, eine international gültige Repräsentation von nationalen Zeichensätzen
angesiedelt sein.
Die Anwendungsschicht (engl. Application Layer) beinhaltet anwendungsspezifische
Funktionen. Sie enthält typischerweise diejenigen Netzwerkfunktionalitäten mit denen
der Benutzer direkt konfrontiert ist.
4.4.2 Das TCP / IP ­ Referenzmodell
Wie der Begriff TCP / IP ­ Referenzmodell veranschaulicht, spielen TCP und IP eine
zentrale Rolle innerhalb dieses Referenzmodells. Der Großteil der Internet ­ Dienste
nutzt diese beiden Netzwerkprotokolle als Grundlage. Die darauf aufbauenden
Protokolle der Anwendungsebene werden in diesem Zusammenhang oft auch als
Protokollfamilie TCP / IP oder TCP / IP Protokollsuite bezeichnet.
Bei der Entwicklung des TCP / IP ­ Stacks wurde das Ziel verfolgt, Computer
unterschiedlicher, paketorientierter Netzwerke miteinander zu verbinden.
25
Daraus resultierten die wichtigsten Charakteristika der Protokollfamilie TCP / IP :
26
Die Protokollfamilie TCP / IP zeichnet sich durch eine Unabhängigkeit vom
physischen Übertragungsmedium und dem eingesetzten Protokoll auf
Sicherungsebene aus.
Offene Standards, die unabhängig von einer speziellen Hardware oder einem
bestimmten Betriebssystems entwickelt wurde, stellen die Grundlage der Internet -
Protokolle dar.
Wichtiger Bestandteil der Internet ­ Protokolle ist ein weltweit einheitlicher
Adressierungsmechanismus, der eine Rechner - Kommunikation über das
Netzwerk, mit jedem Rechner der über einen Internet ­ Anschluß verfügt,
ermöglicht.
Die Protokollfamilie TCP / IP besteht aus zahlreichen Protokollstandards der
Anwendungsebene, welche eine konsistente Grundlage für die gängigsten Internet
­ Dienste, wie beispielsweise FTP für den elektronischen Dateitransfer oder
SMTP für den E ­ Mail Versand, bereitstellen.
25
Vgl. Nusser 1998, S.11 ff.
26
Nusser 1998, S.12 ff.
4. Internet ­ Sicherheit
19
Abbildung 7: Vergleich OSI und TCP / IP Protokollstack [Quelle : Bernert 1999, S.21]
Der konzeptionelle Unterschied der beiden in der Abbildung 7 dargestellten Modelle
besteht letztendlich darin, daß das OSI ­ Modell aus Schichten und das TCP / IP ­
,,Modell" aus Protokollen besteht. Damit kann mit dem TCP / IP ­ ,,Modell" kein
anderer Protokollstapel als der eigene beschrieben werden.
27
Dadurch, daß im TCP / IP ­ ,,Modell" die Anwendungsschicht direkt auf der
Transportschicht aufsetzt, also keine ausgleichende Zwischenschicht vorhanden ist,
wirken sich damit Sicherheitsprobleme der TCP / IP ­ Protokolle unmittelbar auf die
Anwendungsprotokolle aus.
28
Dieser Sachverhalt wird abschließend in Abbildung 8
graphisch dargestellt. Graphisch hervorgehobene Protokolle sind für die Verwendung
des im Beispiel ­ Szenario beschriebenen XML ­ basierten Web Services von
besonderer Bedeutung, und werden daher in den Kapiteln 4.4.3 und 4.4.4 näher
beschrieben. Dabei sollen zunächst die Eigenschaften und Funktionsweisen dieser
Protokolle dargestellt werden, um darauf aufbauend Sicherheitsprobleme identifizieren
zu können. Diese Sicherheitsprobleme werden im Anschluß daran, durch eine
Absicherung eben dieser Protokolle, eliminiert.
27
Vgl. Bernert 1999, S.21 ff.
28
Vgl. Eckert 2001, S.44
Anwendungsschicht
Präsentationsschicht
Sitzungsschicht
Netzwerkschicht
Datensicherungsschicht
Bitübertragungsschicht
OSI ­ 7 - Schichtenmodell
Anwendungsschicht
Internetschicht
Transportschicht
Linkschicht
TCP / IP - Stack
Transportschicht
4. Internet ­ Sicherheit
20
Abbildung 8: Der TCP / IP Protokollstack [Quelle : Fuhrberg 1998, S.10]
4.4.3 TCP / IP
4.4.3.1 Das Internet Protokoll IP
Das Internet Protokoll stellt die unterste einheitliche Schicht einer jeden
Kommunikation über das Internet dar. Wie in Abbildung 7 zu sehen ist, übernimmt es
die Aufgaben der Netzwerkschicht und bietet für diese einen paketvermittelnden,
verbindungslosen Dienst an, der auch als unzuverlässiger Dienst bezeichnet wird, da er
den Erhalt von Datenpaketen nicht bestätigt. Jedes Datenpaket kann bei der
Übertragung an das Zielsystem eine Vielzahl von Vermittlungsrechnern durchlaufen
(engl. Routing).
Es enthält jedoch weder Maßnahmen zur Gewährleistung der Vollständigkeit der
gesendeten Pakte bzw. Fragmente noch Mechanismen, die überprüfen können, ob die
Datenpakete in der gesendeten Reihenfolge oder überhaupt beim Empfänger
angekommen sind.
29
29
Vgl. Eckert 2001, S.45 ff.
TCP
UDP
X.25
Ethernet
IP
HTTP
Telnet
SMTP
FTP
DNS
Anwendungs ­
schicht
Transport ­
schicht
Internetschicht
Linkschicht
4. Internet ­ Sicherheit
21
Gerade durch die verbindungslose Natur des Internet Protokolls fehlen jegliche
Spezifikationen zum Verbindungsaufbau (engl. Handshake) oder zur Fehlerkontrolle.
Eben diese Funktionalitäten werden durch das TCP - Protokoll auf der Transportschicht
zur Verfügung gestellt, woraus sich gerade der Name der Protokollfamilie TCP / IP
ergibt.
Für sicherheitsrelevante Überlegungen sind, wie wir in Kapitel 4.5 noch sehen werden,
zwei Aspekte von herausragender Bedeutung. Diese betreffen zum einen den genauen
Aufbau eines IP ­ Datagramms, insbesondere des IP ­ Headers, zum anderen aber auch
den Vorgang der Routenwahl.
30
4.4.3.2 Das Transportprotokoll TCP
Das Transportprotokoll TCP setzt auf dem IP ­ Protokoll auf und stellt ein
verbindungsorientiertes Protokoll dar, das immer dann angewendet wird, wenn
Empfänger und / oder Absender eine zuverlässige Übertragung möchten. Dabei nimmt
TCP eine Verbindung mit dem Empfänger auf, überprüft ob dieser für den
Datenempfang bereit ist, überträgt daraufhin die Daten, korrigiert evtl. Fehler in der
Übertragung, wie z.B. fehlende oder defekte Pakete, falsche Reihenfolge usw., und
beendet die Verbindung gesichert.
31
Diese Aufgaben stellen gerade die sicherheitskritischen Methoden dar, die in Kapitel
4.5 näher dargestellt werden sollen.
Das TCP ­ Protokoll ist jedoch nicht nur in der Lage eine Ende ­ zu ­ Ende ­
Verbindung zwischen zwei Endsystemen, sondern auch zwischen einzelnen Prozessen
und Diensten herzustellen. Zur Identifikation dieser Dienste bzw.
Kommunikationsendpunkte wird das Port ­ Konzept verwendet, das unter Verwendung
von Portmappern auf der Anwendungsebene die Zuteilung von Port ­ Adressen zu den
jeweiligen Netzdiensten realisiert. Dabei besitzt jeder allgemein bekannte Netzdienst
eine eindeutige, ihm zugeordnete Port ­ Nummer. Der für unsere Betrachtung relevante
HTTP ­ Dienst besitzt die Port ­ Adresse 80, über welche die Verbindung zwischen
Endsystemen aufgebaut wird.
32
30
Vgl. Nusser 1998, S.15 ff.
31
Vgl. Bernert 1999, S.59
32
Vgl. Eckert 2001, S.48
4. Internet ­ Sicherheit
22
4.5 Sicherheitsprobleme
4.5.1 Sicherheitsprobleme von IP
Für das IP ­ Protokoll ergeben sich bzgl. der in Kapitel 4.3 eingeführten
Sicherheitseigenschaften sicherheitsrelevante Problemstellungen. Routing ­ Angriffe
können insbesondere die Vertraulichkeit, Integrität und Verfügbarkeit des IP ­
Protokolls gefährden.
33
Authentizität
Das IP ­ Protokoll vertraut den Angaben in den Adresseinträgen der Pakete. Weder
Absender noch Empfänger werden authentifiziert, obgleich diese Adressen gefälscht
werden können, sodaß ein Angreifer in der Lage ist, seine eigenen IP ­ Pakete
einzuschleusen. Einer der häufigsten Angriffe im Internet, das sogenannte Address
Spoofing nutzt eben diese Schwachstelle, indem sich ein Angreifer maskiert und
dem Kommunikationspartner eine gefälschte Identität vortäuscht. Darauf aufbauend
werden häufig Denial ­ of ­ Service Angriffe gestartet, die einen fremden Rechner
solange mit ,,künstlich" erzeugten Datenpaketen beschicken, bis dieser aufgrund der
enormen Last zusammenbricht. Für einen solchen Angriff werden meist
ungeschützte Ports verwendet, also solche die bespielsweise nicht durch Firewalls
blockiert sind. Wie wir in Kapitel 6 noch sehen werden kommt diesem Problem
unter Verwendung von SOAP eine besondere Bedeutung zu. SOAP nutzt HTTP zur
Übermittlung von Geschäftsdaten, so daß SOAP ­ Nachrichten als HTTP ­ Pakete
getarnt die Firewall ungeprüft durchlaufen können.
34
Vertraulichkeit
Die Nutz ­ und Verwendungsdaten (IP ­ Headerdaten) eines IP ­ Pakets werden
unverschlüsselt übertragen, so daß auf allen Kommunikationsverbindungen sowie in
allen Vermittlungsstellen diese mitunter sehr sensitiven Daten im Klartext vorliegen.
Somit ist ein Angreifer durch eine Verkehrsflußanalyse in der Lage, Zugriffs ­ und
Kommunikationsprofile zu erstellen, wodurch die Anonymität der
Kommunikationspartner nicht mehr gewährleistet sein kann.
33
Vgl. Eckert 2001, S.50 ff.
34
Vgl. Computer Zeitung 2002a, S.13
4. Internet ­ Sicherheit
23
Integrität
Hashfunktion oder MAC's, zur Überprüfung der Integrität der übertragenden
Nutzdaten sind kein Bestandteil des Internet ­ Protokolls IP. Damit ist es für den
Empfänger eines Nachrichtenpakets nicht möglich unautorisierte Modifikationen zu
erkennen und geeignete Maßnahmen zur Abwehr der sich daraus ergebenden
Angriffe zu ergreifen.
Verbindlichkeit
IP ­ basierte Aktionen sind nicht verbindlich, da die Identifikation des
Kommunikationspartners nur durch die in den IP ­ Paketen enthaltene, nicht
fälschungssichere IP ­ Adresse erfolgt. Digitale Signaturen bleiben
unberücksichtigt.
Es sei jedoch darauf hingewiesen, daß die aktuelle IP ­ Protokollversion IPv6 um
spezielle Mechanismen zur Sicherstellung von Vertraulichkeit und Authentizität auf der
Internetschicht erweitert wurde. Deren Berücksichtigung erfolgt durch Implementierung
der IPsec ­ Spezifikation, die für IPv6 verpflichtend ist und in Kapitel 4.6.2 kurz
betrachtet werden soll.
35
4.5.2 Sicherheitsprobleme von TCP
Wie wir im vorherigen Kapitel gesehen haben, bietet TCP auf der Transportschicht ein
geeignetes Medium, um Sicherheitsmaßnahmen, die auf der Internetschicht aufbauen,
zu realisieren. So bietet das TCP ­ Protokoll gewisse Sicherheitsmaßnahmen zur
Identifikation und Authentizität der Kommunikationspartner an, die über die
fälschbaren IP ­ Adressen hinausgehen. Sequenzierung, Fehlerkorrektur und
Flußkontrolle stellen Sicherheitsmaßnahmen für höherliegende Schichten dar und
sorgen für eine verläßliche Übertragung. Leider reichen diese Maßnahmen jedoch nicht
aus, um den Ansprüchen des kommerziellen Internet ­ Einsatzes und damit auch der
Nutzung von XML ­ basierten Web Services gerecht werden zu können.
36
Sequenznummerangriffe unter TCP können die Grundlage für Maskeraden sein durch
die ein Angreifer dem Empfänger eine falsche Identität vortäuschen kann.
35
Vgl. Fuhrberg 1998, S. 18 ff.
36
Vgl. Nusser 1998, S.34
4. Internet ­ Sicherheit
24
Sofern der Angreifer Kenntnis über den aktuellen Zählerstand der Sequenznummer
besitzt, ist es ihm möglich, die Sequenznummer, die ein System für den nächsten
Verbindungsaufbau benutzt, mit hoher Wahrscheinlichkeit korrekt zu bestimmen. Dies
ist nur dadurch möglich, daß die Sequenznummern in aller Regel nicht zufällig generiert
werden, also keinen Zufallsgenerator verwenden, sondern einen einfachen 32 ­ Bit
Zähler.
Weiterhin kann ein Angreifer versuchen, eine bestehende Verbindung zwischen Server
und Client zu übernehmen, in dem die ursprünglichen Kommunikationspartner
desynchronisiert werden. Durch einen anschließenden Maskerade ­ Angriff kann er nun
die Stelle einer der beiden Partner übernehmen und ist dadurch in der Lage eigene
Pakete einzuschleusen. Damit sind Protokolle erforderlich, die den gesamten
Nachrichtentransport absichern.
37
4.6 Absicherung der Internet ­ und Transportprotokolle
4.6.1 SSL / TLS
Durch die Erweiterung der Transportschicht um Sicherheitsaspekte kann diese der
Internetschicht Mechanismen bereitstellen, auf welche die Internetschicht aufbauen
kann. Solche Erweiterungen der Protokollfamilie können damit gerade auch die
Voraussetzung für sichere Anwendungsprotokolle wie HTTP sein.
38
Sicherheitsprotokolle auf dieser Schicht bieten eine Ende ­ zu ­ Ende Verschlüsselung
zwischen zwei Kommunikationspartnern, die Daten liegen an den Endrechnern also in
unverschlüsselter Form vor. Sie stellen anwendungsunabhängige Sicherheitsdienste zur
Verfügung und können daher beliebige Anwendungsprotokolle um Dienste zur
Gewährleistung der Kommunikationsvertraulichkeit, der Datenintegrität und der
Authentizität von Kommunikationspartnern erweitern. Dabei ist jedoch zu beachten,
dass es sich innerhalb unseres Beispiel - Szenarios eigentlich um Punkt ­ zu ­ Punkt
Sicherheitsprotokolle handelt, da diese jeweils nur eine sichere Verbindung zwischen
zwei bestimmte Transaktionsknoten innerhalb der Wertschöpfungskette jedoch nicht
direkt zwischen dem Start ­ und Zielknoten herstellen können.
37
Vgl.Eckert 2001, S.58 ff.
38
Vgl. Nusser 1998, S.34
4. Internet ­ Sicherheit
25
Bespiele für sichere Protokolle der Transportschicht sind neben Secure Socket Layer
(SSL) auch Transport Layer Security (TLS). Das TLS - Protokoll, eine
Weiterentwicklung des SSL ­ Protokolls, das insbesondere um das HMAC ­ Verfahren
erweitert wurde, bildet einen de facto Standard für die sichere HTTP ­ Kommunikation.
Für SSL ­ basiertes HTTP (HTTPS) wird dafür die Portadresse 443 reserviert.
Das SSL - Protokoll ermöglicht zum einen die Authentizität der
Kommunikationspartner unter Verwendung von asymmetrischen
Verschlüsselungsverfahren und Zertifikaten, zum anderen aber auch eine vertrauliche
Datenübertragung unter Verwendung eines gemeinsamen Sitzungsschlüssels und die
Sicherung der Nachrichtenintegrität unter Nutzung von MAC's. Dabei stellen das
Aushandeln der verwendeten Verfahren sowie der Austausch der benötigten Schlüssel
einen integralen Bestandteil des SSL ­ Protokolls dar.
Die Sicherheit des Protokolls hängt dabei ganz entscheidend von den ausgehandelten
kryptographischen Verfahren ab.
Da die zu übertragenden Daten nicht signiert werden, ermöglicht SSL keine
Gewährleistung der Verbindlichkeit von Aktionen.
39
4.6.2 IPsec
IPsec erweitert den IP ­ Header um zwei wichtige Einträge. Der IP Authentification ­
Header (AH) ermöglicht eine Sicherung des Datenverkehrs bzgl. Integrität und
Authentizität auf IP ­ Ebene. Daten können nicht ohne Verletzung deren Integrität
unerkannt verändert werden. Weiterhin ermöglicht der IP Authentification ­ Header
einen eindeutigen Nachweis über den Absender des IP ­ Pakets. Die zweite wichtige
Erweiterung stellt der IP Encapsulation Security Payload (ESP) ­ Header dar. Dieser
Header ermöglicht die Übertragung von Daten, ohne daß deren Vertraulichkeit
unerkannt verloren oder deren Integrität unerkannt verändert werden kann. Weiterhin
ermöglicht dieser Header einen eindeutigen Nachweis über den Absender eines IP ­
Pakets. Die zu schützenden Daten werden dabei gekapselt und darauf
Verschlüsselungsverfahren zur Gewährleistung der Vertraulichkeit und zusätzlich
kryptographische Prüfsummen zur Sicherstellung der Integrität angewendet.
39
Vgl. Eckert 2001, S.476 ff.
4. Internet ­ Sicherheit
26
Grundlage dieser Sicherheitserweiterungen ist das Konzept der Security Association
(SA), auf das jedoch nicht weiter eingegangen werden soll.
40
Man kann sich eine IPsec Security Association als ein Abkommen zwischen zwei oder
mehr Kommunikationspartnern vorstellen, das unter anderem Informationen bzgl. der
verwendeten Authentizitätsverfahren, Modi und Schlüssel für das AH ­ Protokoll und
die verwendeten Authentizitätsverfahren, Modi und Schlüssel für das ESP ­ Protokoll
enthält.
41
Fragen zur Zugriffskontrolle und zur Verbindlichkeit bleiben jedoch offen.
4.7 Schlußfolgerung
Die Absicherung der Internet ­ und Transportschicht sind von entscheidender
Bedeutung für eine sichere Übertragung von sensitiven Daten. Dies ist insbesondere
auch für XML ­ basierte Web Services von Bedeutung, da diese sensitive Daten als
SOAP ­ Nachrichten empfangen, verarbeiten und an die entsprechenden
Geschäftspartner unter Nutzung von HTTP weiterleiten. Wie in Abbildung 8 dargestellt
ist HTTP ein Dienst auf der Anwendungsschicht, der unmittelbar auf den vorgestellten
Protokollen der Internet ­ und Transportschicht aufsetzt. Diese Protokolle liefern den
Diensten der Anwendungsschicht, insbesondere HTTP, anwendungsübergreifende
Sicherheitsfunktionalitäten.
Durch Anwendung der in Kapitel 4.6 vorgeschlagenen Protokolle, zur Absicherung der
Internet ­ und Transportschicht auf unser Beispiel ­ Szenario, erhalten wir folgende
Modifikationen für die Abbildung 3 :
40
Vgl. Fuhrberg 1998, S. 18 ff.
41
Eckert 2001, S.481 ff.
4. Internet ­ Sicherheit
27
Abbildung 9: Das Beispiel ­ Szenario : Einbeziehung von SSL in die Business Partner Connectivity
Die Protokolle der Transportschicht sind lediglich in der Lage die Verbindung zwischen
zwei Geschäftspartnern abzusichern, d.h. die Daten liegen an den beiden Endknoten
ungeschützt als Klartext vor. Das SSL Protokoll gehört zu den Ende ­ zu ­ Ende
Sicherheitsprotokollen und stellt dabei ein CPU ­ intensiver Prozeß dar. Eine SSL ­
Verbindung besteht jeweils nur für zwei bestimmte Geschäftspartner, die sich zuvor
bzgl. der verwendeten Verfahren verständigt, und die individuellen Schlüssel des
jeweiligen Partners ausgetauscht haben. Einer dieser Geschäftspartner kann diese
Verbindung also nicht ohne weiteres für eine sichere Kommunikation mit einem
anderen Geschäftspartner nutzen.
Dies erscheint gerade innerhalb des EAI ­ Umfeldes wenig praktikabel. Durch den in
einem Web Service gekapselten Geschäftsprozeß sollen gerade alle an diesem Prozeß
beteiligten Geschäftspartner und geg. adhoc neue Kommunikationspartner eingebunden
werden, wobei einige dieser Transaktionsknoten lediglich Intermediäre darstellen
können, die die erhaltenen Dokumente an andere Knoten weiterleiten. Am Beispiel
eines Automobilkonzerns wird deutlich, daß die Anzahl der Geschäftspartner sehr
schnell eine Vielzahl von Zulieferern, Speditionen usw. annehmen kann. Verbunden mit
den Schwächen dieser Ansätze erscheint eine andere bzw. ergänzende
Herangehensweise erforderlich.
SOAP ­ Response via HTTPS
Web Server
HTML
XML
Web ­
Service
Container
Firma IQ - Technology
Firewall
Logistikdienstleister
(LDL)
E - Logistic
Zulieferer (L)
Firma Hansen
Firewall
Firewall
Client
Client
Client
SOAP ­ Request via HTTPS
HTTPS HTTPS
HTTPS
HTTPS
HTTP
HTTP
2.
1.
2. 5.
2.
5.
3.
4.
3. 4.
5.
Web ­ Service
Container
Web ­ Service
Container
Ende der Leseprobe aus 188 Seiten  - nach oben

Details

Titel
XML und IT-Security
Untertitel
Konzeption einer sicheren Web Services-Infrastruktur
Autor
Erscheinungsjahr
2002
Seiten
188
Katalognummer
V221680
ISBN (eBook)
9783832462338
ISBN (Buch)
9783838662336
Dateigröße
1074 KB
Sprache
Deutsch
Schlagworte
soap saml xums xml-signature xml-encryption
Produktsicherheit
Diplom.de
Arbeit zitieren
, 2002, XML und IT-Security, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/221680

Kommentare

  • Noch keine Kommentare.
Uniturm.de

Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!  
Uniturm.de

Ihre Vorteile als Autor

Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.

Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.

Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.

Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.

Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.

Jetzt Autor werden!
Allgemein
Autoren
Leser & Käufer
  • Copyright
  • © Bedey & Thoms
    Media GmbH
  • seit 1997
  • Alle Inhalte urheberrechtlich geschützt. Kopieren und verbreiten untersagt.
    Diplom.de steht seit 1996 für die professionelle und hochwertige Veröffentlichung akademischer Abschlussarbeiten im Original als eBook und Buch.
    Bachelorarbeiten, Masterarbeiten, Diplomarbeiten, Magisterarbeiten, Dissertationen und andere Abschlussarbeiten aus allen Fachbereichen und Hochschulen können Sie bei uns als eBook sofort per Download beziehen oder sich als Buch zusenden lassen.