Enterprise Application Integration

Teilleistung

Web-Service Security

Christoph Bhm Wintersemester 2010/2011

Inhaltsverzeichnis

Inhaltsverzeichnis
Abbildungsverzeichnis ........................................................................... II Abkrzungsverzeichnis .......................................................................... II 1 Einleitung .......................................................................................... 1 2 Grundlagen ........................................................................................ 1 2.1 Allgemeine Sicherheitsanforderungen an Webservices .........................1 2.2 Komponenten einer SOA-Sicherheitsarchitektur ..................................2 3 Konzepte fr Sicherheit in SOAs ........................................................ 3 3.1 Integritt und Vertraulichkeit ...........................................................3 3.2 Identittsmanagement ....................................................................4 3.3 Trust Management ..........................................................................5 3.4 Policy Management .........................................................................6 4 Fazit und Ausblick .............................................................................. 7 Literaturverzeichnis................................................................................ 8

Verzeichnisse

II

Abbildungsverzeichnis
Abbildung 1 - Web-Service Spezifikationen im berblick ..................................3 Abbildung 2 - Verschlsselung von SOAP-Nachrichten .....................................4 Abbildung 3 - WS-Policy Funktionsweise ........................................................6

Abkrzungsverzeichnis
BSI ........ Bundesamt fr Sicherheit in der Informationstechnik IT .......... Informationstechnik OASIS .... Organization for the Advancement of Structured Information Standards S. ......... Seite SAML ..... Security Assertion Markup Language SOA ....... Serviceorientierte Architektur SSO ....... Single Sign-on TLS ........ Transport Layer Security vgl. ....... vergleiche W3C ...... World Wide Web Consortium WS ........ Webservice WSDL ..... Web Services Description Language XML ....... Extensible Markup Language

Einleitung

Einleitung

Durch Service-orientierte Architekturen hlt ein neues Paradigma Einzug in Unternehmen aller Grenordnung (vgl. [KiRS2010, S. 1ff]). Der Bedarf, bestehende Verfahren auf Basis einer flexiblen und skalierbaren Architektur zu integrieren ist immanent (vgl. [EiMN2010, S. 1]). Dies uert sich seit Jahren in einem steigenden Interesse an SOA (vgl. [KiRS2010, S. 1ff]). Dabei ist dieser Paradigmenerfolg letztendlich auch auf dem Erfolg der Web Service-Technologie zurckzufhren (vgl. [Ort2005, S. 4]). Aus den Anforderungen an mit Web Services implementierten Geschftsprozessen ergeben sich jedoch auch steigende Anforderungen an die Verfgbarkeit, Integritt und Vertraulichkeit dieser Dienste und Daten (vgl. [EcSW2007, S. 9]). Als Folge dessen spielt das Thema Sicherheit bei Web Services eine herausragende Rolle und kann darber entscheiden, ob SOA in bestimmten Unternehmensbereichen eingesetzt wird oder nicht. Mit verschiedenen Standards versuchen deshalb die Normierungsgremien diesen Anforderungen aus der Praxis gerecht zu werden (vgl. [BeMP2010, S. 195]). Die vorliegende Arbeit erlutert zunchst die allgemeinen Sicherheitsanforderungen an SOA und gibt anschlieend eine bersicht ber die verschiedenen Standards. Zum Schluss wird ein Ausblick im Rahmen eines Fazits gegeben. Ziel der Arbeit ist es, einen berblick ber die grundlegende WebserviceSicherheitsarchitektur zu geben.

2
2.1

Grundlagen
Allgemeine Sicherheitsanforderungen an Webservices

Mit dem Einsatz von SOAs werden Unternehmensdaten, Geschftsanwendungen und ganze Geschftsprozesse ber offene Netze verfgbar gemacht. Dabei unterliegen auch Webservices und die verwalteten Daten den klassischen Sicherheitsanforderungen an IT-Systemen. Diese umfassen gem Eckert et al. Vertraulichkeit, Integritt, Authentizitt und die Nicht-Zurckweisbarkeit (vgl. [EcSW2007, S. 657; SAP2007, S. 11f]). Aufgrund der Charakteristika von SOAs ergeben sich jedoch zustzliche Anforderungen, welche ber die traditionellen Bestimmungen an IT-Systeme hinausgehen.

Grundlagen

So ist eine autorisierte Nutzung der Dienste domnenbergreifend zu gewhrleisten und nicht autorisierte Zugriffe zu verhindern. Dies erfordert eine verteilte Authentifizierung sowie ein Identitts- und Rechtemanagement, welches ber die jeweiligen administrativen Domnen hinaus wirksam ist. Anbieter und Nutzer besitzen unterschiedliche Sicherheitsbedrfnisse, die ber geeignete Sicherheitsregelwerke zu formulieren und bei einer Dienstnutzung in Einklang zu bringen sind (vgl. [EcSW2007, S. 657]). Weiterhin problematisch ist die Komposition von Webservices zur Durchfhrung komplexer Prozesse. Es ist sicherzustellen, dass auch in dem zusammengesetzten Diensten ein gefordertes Sicherheitsniveau garantiert werden kann, so dass beispielsweise sensitive Informationen nicht an unberechtigte weitergegeben werden (vgl. [EcSW2007, S. 657]). Zustzlich knnen die Teilnehmer in einer SOA unterschiedliche Basis-

Technologien nutzen (unter anderem Java, .Net, SAP). Um eine durchgehende plattformbergreifende Sicherheit zu gewhrleisten, muss eine Interoperabilitt und Standardisierung gegeben sein (vgl. [EcSW2007, S. 657]).

2.2

Komponenten einer SOA-Sicherheitsarchitektur

Auf Grundlage der oben genannten Sicherheitsanforderungen hat Krecher sowie in hnlicher Form das Bundesministerium fr Sicherheit in der Informationstechnik (kurz BSI) folgende vier Gebiete einer sicheren SOA identifiziert, auf welche im Rahmen dieser Seminararbeit weiter eingegangen wird (vgl. [Kre2008, S. 92; BSI2009, S. 187ff]): Integritt und Vertraulichkeit zur Sicherstellung der Identitt eines Nutzers sowie der Verschlsselung und Signatur auf Nachrichtenebene Identity Management zur Zuordnung von Nutzern zu Gruppen und Rollen Trust Management zur Abbildung von Vertrauensverhltnissen zwischen Komponenten einer SOA Policy Management zur Beschreibung von Sicherheitsrichtlinien, die beim Nutzen von Diensten eingehalten werden mssen Die Softwareindustrie hat mit Standards auf genau diese Anforderungen bereits Antworten entwickelt. Grundlage bildet ein 2002 von den Firmen IBM und Microsoft gemeinsam verffentlichtes Dokument mit dem Arbeitstitel Security in a Web Services World: A Proposed Architecture and Roadmap (vgl. [IBM2002, S. 1ff]). Ausgehend von bestehenden Sicherheitstechnologien (vgl. [BeMP2010, S.

Konzepte fr Sicherheit in SOAs

195]) definierten die Unternehmen ein Framework zur Sicherung von SOAs. Diese Spezifikation wurde spter zur Standardisierung bei OASIS sowie dem W3C eingereicht (vgl. [SAP2007, S. 33]) und stellt heute die wichtigste Grundlage der existierenden Security-Lsungen im SOA-Umfeld dar (vgl. [SAP2007, S. 33]). Stellt man die in dem Dokument erarbeiteten Sicherheitsstandards in das Gesamtbild der Spezifikationen um Webservices ergibt sich folgendes Bild:
Dienste beschreiben und auffinden
WS Policy WS-Policy Attachement WS-PolicyAssertions WS-Security Policy

Dienstkommunikation absichern
WS-Secure-Conversation OASIS WS-Federation WS-Trust OASIS WS-Security X.509 Certificate Token Kerberos Token

Dienste orchestrieren und choreographieren

BPEL WS-CDL WSFL ebXML

Standards fr Transaktionen
WS-Coordination

UDDI WS-Inspection WS-Discovery WS-Metadata Exchange WSDL SPML

Grundlegende Sicherheitsstandards
XKMS XML Encryption XACML SAML

WS-AtomicTransaction WS-BusinessActivity

XML Signature

Messaging Nachrichten zustellen

WS-Adressing WS-Eventing WS-Notification

Standards fr zuverlssige Zustellung von Nachrichten

WS-Reliability WS-ReliableMessaging

Grundlegende Webservice Standards

W3C XML Schema W3C XML 1.1 SOAP SwA MTOM W3C XPath

Abbildung 1 - Web-Service Spezifikationen im berblick Quelle: in Anlehnung an [BSI2009, S. 46]

Die in der Abbildung unter den Oberpunkten Grundlegenden Sicherheitsstandards sowie Dienstkommunikation absichern genannten Techniken thematisieren ausschlielich die Absicherung von Diensten. Je nach Anwendungsfall knnen weitere Verfahren hinzukommen, die sich an Sicherheitszielen wie Transaktionssicherheit, Ausfallsicherheit oder Verfgbarkeit orientieren (vgl. [BSI2009, S. 111f]), im Rahmen dieser Arbeit aber nicht weiter betrachtet werden.

3
3.1

Konzepte fr Sicherheit in SOAs

Integritt und Vertraulichkeit

Die auf XML basierende Nachrichtenkommunikation bei Webservices geht einher mit einer einfachen Lesbarkeit und bietet daher keinen Schutz vor unberechtigter Einsicht und Manipulation. Zur Wahrung der Integritt und Vertraulichkeit der ausgetauschten Informationen knnen Manahmen eingesetzt werden, welche direkt auf der Nachrichtenebene ansetzen (vgl. [BSI2009, S. 250]).

Konzepte fr Sicherheit in SOAs

So sorgt der Standard XML-Signature and Processing fr die Integritt von Nachrichten, indem diese komplett oder bei Bedarf Bestandteile, die im SOAP-Header als Security-Token gekennzeichnet sind, signiert werden (vgl. [W3C2008]). Eine eventuelle Manipulation kann damit vom Empfnger erkannt werden. Der Standard XML-Encryption sorgt hingegen fr die Vertraulichkeit von SOAP Nachrichten, indem mit Hilfe symmetrischer, asymmetrischer oder hybrider Verschlsselungstechniken die Nachricht oder Teile dieser verschlsselt werden (vgl. [W3C2002]). Das folgende Beispiel zeigt den Aufbau einer vollstndig verschlsselten SOAP-Nachricht:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 <S:Header> <wsse:Security> <xenc:EncryptedKey> <xenc:EncryptionMethodAlgorithm=.../> <ds:KeyInfo>...</ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReferenceURI=body/> </xenc:ReferenceList> </xenc:EncryptedKey> </wsse:Security> </S:Header> <S:Body> <xenc:EncryptedDataId=body> <xenc:CipherData> <xenc:CipherValue>...</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </S:Body>

Abbildung 2 - Verschlsselung von SOAP-Nachrichten

Wie dem Listing entnommen werden kann, wird im Header die Metainformationen, beispielsweise ber den verwendeten Verschlsselungsalgorithmus (EncryptionMethodAlgorithm) beschrieben. Die Daten, in S:Body spezifiziert, werden im Tag <xenc:CipherData/> verschlsselt versandt. Eine weitere einfache Mglichkeit ist der Einsatz einer Verschlsselung der Nachrichtenkommunikation auf TCP/IP-Transportebene, wie das beispielsweise mit dem TLS Protokoll mglich ist (vgl. [EcSW2007, S. 658]).

3.2

Identittsmanagement

Um Daten vor unerlaubtem Zugriff zu schtzen, muss der einzelne Webservice Informationen ber die Person erhalten, die den Zugriff anfordert. Erst basierend auf diesem Wissen kann das System eine Zugriffsentscheidung treffen. In einer

Konzepte fr Sicherheit in SOAs

SOA ist die Verwaltung derjenigen, die auf einen Dienst zugreifen, ungleich schwerer als in einer nicht-verteilten Anwendung. So muss der einzelne Konsument in einer SOA eine allgemein gltige Identitt besitzen und diese bei orchestrierten Diensten entsprechend weitergereicht werden. Als mglicher Standard fr die Einbindung eines dienstebergreifenden Identittsmanagements ist SAML zu nennen (vgl. [BeMP2010, S. 54; OAS2003]). Hierbei handelt es sich um eine umfangreiche Spezifikation zum Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen einem Anfrager und einem Aussteller von SAML-Asserts (vgl. [Kre2008, S. 92]). Das in der Spezifikation definierte Profil SOAP (vgl. [OAS2005, S. 26]) fgt der Nachrichtkommunikation ein zustzliches XML-Tag <saml:Assertion> hinzu, dass von den Nachrichtenempfnger fr den Identittsabgleich genutzt wird. Eine konkrete Implementierung des SAML-Standards ist JBOSS SSO (vgl. [Red2006, S. 8]). Der WS-Federation-Standard adressiert hnliche Aufgabenstellungen und hat den Anspruch komplette Identity-Management-Systeme abbilden zu knnen (vgl. [IBM2006, S. 1ff]). Weiterhin weist Krecher darauf hin, dass vor allem fr kleinere SOA-Lsungen auch eigens entwickelte Identittsmanagementmodule sinnvoll sein knnen (vgl. [Kre2008, S. 93]).

3.3

Trust Management

Dienste in einer SOA knnen unterschiedlichen administrativen und rechtlichen Organisationseinheiten angehren. Dies ist insbesondere der Fall, wenn Dienste zur Abwicklung sicherer Geschftsprozesse ber Unternehmensgrenzen hinweg choreographiert werden. Das Vertrauen zwischen den Teilnehmern einer SOA ist daher eine Grundvoraussetzung fr das Funktionieren einer solchen Architektur (vgl. [BSI2009, S. 209]). WS-Trust beschreibt ein Verfahren, in dem ein sogenannter Security-TokenService das Ausstellen, Erneuern, Besttigen und Verwerfen von SecurityToken durchfhrt. Das Ziel von WS-Trust ist es, zugesicherte Eigenschaften fr bestimmte Dienste innerhalb einer oder zwischen Domnen zu vermitteln. Token knnen bei Bedarf durch einen WS angefragt werden (vgl. [OAS2009]). Ein Dienst muss damit nicht mehr jedem einzelnen Aufrufer hinsichtlich der Glaubwrdigkeit der bermittelten Identittsinformationen direkt vertrauen, sondern er muss lediglich eine Vertrauensbeziehung zu einem oder mehreren Security Token Service etabliert haben. Dies ermglicht eine Vereinfachung des Aufbaus einer vertrauenswrdigen Web Service-Interaktion. WS-Trust ist von

Konzepte fr Sicherheit in SOAs

dem Typ des Tokens (beispielsweise SAML) unabhngig und stellt damit einen wichtigen Baustein des Standards WS-Federation dar (vgl. [BSI2009, S. 96]).

3.4

Policy Management

Die Anforderung der Wiederverwendbarkeit von Diensten ist ein wichtiger Aspekt, der die Umsetzung von Sicherheit von traditionellen Anstzen unterscheidet. Um einen Dienst in verschiedenen Kontexten wiederverwenden zu knnen, stellt das feste Einprogrammieren von Sicherheitsmechanismen keine Option dar. Vor diesem Hintergrund wurde der Standard WS-Policy (vgl. [W3C2007]) entwickelt, der Vielmehr einen deklarativer Ansatz verfolgt, um die Belange der Sicherheits- und Fachseite voneinander zu trennen und damit im Ergebnis einen hheren Grad an Wiederverwendbarkeit und Flexibilitt zu erzielen ([BSI2008, S. 192]). Neben der formalen Definition von Sicherheitsrichtlinien (so genannte Policies), zhlen auch das Verteilen, Aushandeln, Durchsetzen und berwachen von Policies zu den Aufgaben des Policy Managements. In Policies werden die notwendigen Sicherheitsrichtlinien formal beschrieben, die von den Diensten in einer SOA genutzt werden, um kontextabhngig die entsprechenden Sicherheitsmechanismen anzuwenden. Das heit es muss eine standardisierte Beschreibung in maschinenlesbarer Form erstellt werden, damit die Richtlinien z.B. durch einen Dienst korrekt interpretiert werden knnen und die gewnschten Sicherheitsmechanismen zum Tragen kommen (vgl. [BSI2008, S. 192]). Die folgende Darstellung verdeutlicht verkrzt das Verfahren der Policy Automation:

WS Request (bspw. SAML )

Web Service Policy Enforcement Point (PEP) 1. PEP erzeugt aus Ressourcen-Anfrage des Clients eine Autorisierungsanfrage ber SAML Client/Server Protokoll

Policy Decision Point (PDP)

2. PEP fragt bei PDP nach mit entsprechenden Daten

Policy Retrieval Point (PRP)

3. PDP: Prft Daten gegen die Policy (in PRP abgelegt), gibt die Entscheidung als Ergebnis zurck

Abbildung 3 - WS-Policy Funktionsweise Quelle: in Anlehnung an [Bh2005, S. 48]

Fazit und Ausblick

Fazit und Ausblick

Das Thema Sicherheit, welches in der ursprnglichen Webservicedefinition sicherlich nicht ausreichend betrachtet wurde, ist heute sehr zuverlssig zu garantieren (vgl. [Kre2008, S. 90]). Nahezu alle Industrieanforderungen knnen mit den verabschiedeten oder in Verabschiedung befindlichen Standards abgedeckt werden (vgl. [EcSW2007, S. 661]). Anstrengungen bedarf es hauptschlich, wie Eckert et al. feststellt, in der Entwicklung von Standards und Techniken fr eine sichere unternehmensbergreifende Kommunikation (vgl. [EcSW2007, S. 661]). Nicht in der Arbeit betrachtet, aber fr den Betrieb einer sicheren IT- und damit auch SOA-Infrastruktur genauso wichtig ist ein konsequentes SecurityManagement. Dieses ist fr die Planung, Umsetzung, Steuerung und Kontrolle der Sicherheit innerhalb einer Organisation verantwortlich ([BSI2009, S. 141]) und stellt damit einen Rahmen dar, in dem die verschiedenen vorgestellten Sicherheitsstandards einzusetzen sind. Dieser Themenbereich erffnet einen neuen Forschungsbereich, der aufgrund seiner Interdisziplinaritt groe Herausforderungen mit sich bringt.

Literaturverzeichnis

Literaturverzeichnis
BeMP2010 Bertino, Elisa; Paci, Federica; Martino, Lorenzo; Squicciarini, Anna: Security for Web Services and Service-Oriented Architectures. Berlin: Springer Verlag, Berlin 2010. Bhler, Ulrich: Web Services Sicherheit, 2005, URL: http://dev.hessen-it.de/mm/WS9_Buehler.pdf (Abruf am 2011-0104) Bundesamt fr Sicherheit in der Informationstechnik: SOASecurity-Kompendium, Version 2.0, 2009, URL: https://www.bsi. bund.de/cae/servlet/contentblob/486838/publicationFile/30662/SO A-Security-Kompendium_pdf.pdf (Abruf am 2011-01-04) Eckert, Claudia; Steinemann, Bjrn; Wahl, Tobias: SOA und Sicherheit, in: Datenschutz und Datensicherheit, Nr. 31, 2007, S. 656-661. Eicker, Stefan; Man, Christian; Nagel, Annett; Schuler, Peter: Service-Oriented Architecture, in S. Eicker: Enterprise Application Integration. Essen, Universitt Duisburg-Essen, Essen 2010. IBM Corporation: Web Services Federation Language, Version 1.1, 2006, URL: http://public.dhe.ibm.com/software/dw/specs/wsfed/WS-Federation-V1-1B.pdf (Abruf am 2011-01-04) IBM Corporation: Security in a Web Services World: A Proposed Architecture and Roadmap, Version 1.0, 2010, URL: http://public.dhe.ibm.com/software/dw/library/ws-secmap.pdf (Abruf am 2011-01-04) Kisker, Holger; Ried, Stefan; Shey, Heidi: The State Of Enterprise Software and Emerging Trends. Cambridge: Forrester Research Inc., Cambridge 2010. Krecher, Stefan: SOA Security, in: Java Magazin, Nr. 4, 2008, S. 90-96. OASIS: Profiles for the OASIS Security Assertion Markup Language, 2005, Version 2.0, URL: http://docs.oasis-open.org/security/saml/ v2.0/saml-profiles-2.0-os.pdf (Abruf am 2011-01-04) OASIS: WS-Trust, 2007, Version 1.3, URL: http://docs.oasisopen.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html (Abruf am 2011-01-04) OASIS: SAML Specifications SAML, 2009, Version 2.0, URL: http://saml.xml.org/saml-specifications/ (Abruf am 2011-01-04)

Bh2005

BSI2009

EcSW2007

EiMN2010

IBM2006

IBM2002

KiRS2010

Kre2008 OAS2005

OAS2007

OAS2009

Literaturverzeichnis

Ort2005

Ort, Ed: Service-Oriented Architecture and Web Services: Concepts, Technologies and Tools, 2005, URL: http://java.sun.com/ developer/technicalArticles/WebServices/soa2/soa2.pdf (Abruf am 2011-01-04) Red Hat: The JBoss Federated SSO Framework, 2006, URL: http://download.jboss.org/jbosssso/JBWB_SSO-final.pdf (Abruf am 2011-01-04) SAP AG: Web Service Security: Best Practice Guide, 2007, SecoLogic, URL: http://www.secologic.org/downloads/web/070209_ WebServiceSecurity_V1.pdf (Abruf am 2011-01-04) W3C: XML Encryption Syntax and Processing, 2002, URL: http://www.w3.org/TR/xmlenc-core/ (Abruf am 2011-01-04) W3C: Web Services Policy Framework, 2007, Version 1.5, URL: http://www.w3.org/TR/ws-policy/ (Abruf am 2011-01-04) W3C: XML Signature Syntax and Processing, 2008, URL: http://www.w3.org/TR/xmldsig-core/ (Abruf am 2011-01-04)

Red2006

SAP2007

W3C2002 W3C2007 W3C2008

Literaturverzeichnis

10

Ich versichere an Eides statt durch meine Unterschrift, dass ich die vorstehende Arbeit selbstndig und ohne fremde Hilfe angefertigt und alle Stellen, die ich wrtlich oder annhernd wrtlich aus Verffentlichungen entnommen habe, als solche kenntlich gemacht habe, mich auch keiner anderen als der angegebenen Literatur oder sonstiger Hilfsmittel bedient habe. Die Arbeit hat in dieser oder hnlicher Form noch keiner anderen Prfungsbehrde vorgelegen.

___________________________________ Ort, Datum, Unterschrift