Geschäftsführer, OPTIMAbit GmbH. OPTIMA Business Information Technology GmbH ist eine Beratungsfirma, spezialisiert auf

Transkript

1 SOA Security Dr. Bruce Sams Geschäftsführer, OPTIMAbit GmbH Über OPTIMA OPTIMA Business Information Technology GmbH ist eine Beratungsfirma, spezialisiert auf Sicherheit für Anwendungen und Infrastrukturen Web Apps (J2EE &.NET) SOA (Web Services, ESB) Cryptography & PKI Single-Sign-On Die Integration von Sicherheit in der Entwicklung 1

2 SOA Sicherheit ist vielfältig SOA Sicherheit umfasst alle Aspekte der IT- Sicherheit. Providers Consumers Die Herausforderung von SOA Sicherheit Die große Herausforderung für Unternehmen ist es, umfassende Sicherheit für SOA mit einfacher Integration und Verwendung zu vereinen. Lösungen, die auf "traditionellen" Techniken (z.b. Firewalls, SSL) basieren, sind unzulänglich. Um erfolgreich zu sein, muss die Sicherheit auch als Service betrachtet werden. 2

3 Die Verteidigung von Web Services Web Services können durch dieselben Angriffe (z.b. SQL Injection, XSS, ) wie andere Web Anwendungen attackiert werden. SOAP Request/Response müssen "validiert" werden. Web Services können auch durch SOAP/XML Angriffe attackiert werden. XML bombs (expanding entities) XPATH injection SOAP attachments WS brauchen spezielle Sicherheit Das Model für Nachrichtenübertragung für Web Services ist nicht wie bei typischer HTTP: Client Endpoint 1 Endpoint 2 multiple Schritte Bestehende Sicherheitsinfrastrukturen für HTTP sind nicht ausreichend für Web Services. 3

4 SSL und Web Services SSL bietet keine Lösung für: Weiterleitung einer Nachricht Verschlüsselung der Nachricht SSL ist OK, wenn Sie keine Multi-Schritt Dienste haben und nicht Identitäten propagieren müssen. Nachrichtensicherheit ist besser: die Nachrichten selber sind verschlüsselt. Ein SOA braucht Nachrichtensicherheit, NICHT nur Transportsicherheit. Autorisierung Autorisierung unter Web Services wird stark vom "Multi-Stufen" Modell beeinflusst. Um die Identität des Ausrufers zu propagieren, muss sie in der Nachricht selbst eingebunden sein. Der Empfänger kann die Information nutzen, um Entscheidungen über Authentifizierung bzw. Autorisierung zu treffen. Die Security Assertion Markup Language (SAML) wird hier eine wichtige Rolle spielen. 4

5 Zwei Propagierungsszenarien Holder-of-Key (HK) (A B) Jeder Client zeigt seine Credentials zum nächsten Service. Sender-Vouches (SV) (BC) Benutzertokens werden extrahiert und weitergegeben. Security als Service: Wo und Wie? Die komplexe Sicherheit einer SOA kann in Sicherheitsdienste aufgeteilt werden. Wie geht das? (2 Schritte): 1. Erkennung der Stellen, wo Sicherheitsentscheidungen gemacht und durchgesetzt werden. 2. Festlegung, wann eine Sicherheitsentscheidung am besten durch ein Service oder durch Anwendungslogik zu implementieren ist. 5

6 Sicherheit als Service Eine "Entscheidung" verwendet die relevante Policy an einem Request. Die Anwendungslogik muss keine Sicherheitsfunktionalität bereitstellen. Das "Durchsetzen" ist eine Aktion, die auf der Entscheidung basiert. Kann Teil des Anwendungsdesign oder Teil der Infrastruktur sein. PDP und PEP Es existiert ein ISO Standard (ISO ) für Autorisierung, der folgende Konzepte definiert: Policy Decision Point (PDP) Ein PDP ist für Entscheidungen über Zugriffskontrolle verantwortlich. Policy Enforcement Point (PEP) Ein PEP ist für die Durchsetzung einer PDP-Entscheidung verantwortlich. 6

7 Sicherheitsprinzipien für SOA Sicherheitsschichten Schichten sollten benutzt werden: Eine Schicht wird durch die Art der Datenfluß definiert: 1) Transition, 2) Prozess, oder 3) Ruhen. 7

8 Daten: Transition, Prozess, Ruhen Transition: Verschlüsselung und MACs werden angewendet, um die Vertraulichkeit und die Integrität zu gewähren. Prozess: Digitale Signaturen werden angewendet, um die Authentizität des Requests und die Identität des Ausrufers zu gewähren. (Zugriffsrechte, Auditierung) Ruhen: Daten müssen gegen Veränderung, Verlust und Freigabe geschützt werden. Zugriffskontrolle Entscheidungen über die Zugriffskontrolle sollten stattfinden, wo die Daten von Zustand T => P wandeln. Konzept: Jedes Mal, dass ein Request tiefer in den Datenstrom gelangt, sollte es progressiv mehr Information geben, um eine detailliertere Entscheidung über Zugriffskontrollen zu machen. 8

9 Die Prinzipien angewandt So sieht eine Anwendung mit PDP und PEP aus. Zugriffskontrolle: grob => fein Eine Progression von groben zu feinen Entscheidungen hat einige Vorteile: Unautorisierte Requests können weit entfernt von den geschützten Ressourcen blockiert werden. Die Anzahl von unautorisierten Requests, die das Ziel erreichen, wird minimiert. Die Performanceeinbußen von Sicherheitslogik in der Anwendungsschicht werden minimiert. Das Kombinieren von Services in einer Kette wird vereinfacht. 9

10 Web Service Sicherheit Keine Sicherheit in der WS Standard Die Web Services Spezifikation kümmert sich um die Sicherheit überhaupt nicht. Weitere Standards vom W3C, OASIS, Microsoft, IBM und andere gehen spezifisch auf die Sicherheit. Web Service Security WS-Security WS-Policy WS-Federation WS-SecureConversation WS-SecurityPolicy WS-Trust XACML SAML General Security XML Signature XML Encryption XML Key Management XML Security 10

11 XML Signatur Wie XML Signatur funktioniert XML Signatur erlaubt die Signatur von jeglichem Inhalt: XML oder HTML Dokumente Binäre Daten Bilder Verwendet einen "Message Digest" Algorithmus (z.b DSA-SHA1 or RSA-SHA1). Das Hash wird in einem XML Element gespeichert. Das XML Element wird kryptografisch signiert. 11

12 XML Signature Elements <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI?> (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature> Drei Arten von XML Signature "Enveloped": Die XML Signatur ist innerhalb des ursprünglichen XML Inhalts eingebettet. "Enveloping": Informationsquellen: XML Signatures Scenarios FAQ: afts/prop-xmldsig-faq /Overview.html Der ursprüngliche XML Inhalt ist innerhalb der XML Signatur eingebettet. "Detached": Der ursprüngliche XML Inhalt ist getrennt von der Signatur und wird über eine URI identifiziert. 12

13 Example Enveloped Signature <myelement id="xd001"> <businesselement>...</ businesselement> <Signature>... <Reference URI="#xd001"/>... </Signature> </ myelement> Complete XML Signature Example Initial Dokument <PaymentInfo id="abcd54321"> <Name>John Smith<Name/> <CreditCard Limit="5000" Currency="EUR"> <Number> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>200504</Expiration> </CreditCard> </PaymentInfo> 13

14 Enveloped Signature Example (2) <PaymentInfo id="abcd54321"> <Name>John Smith</Name> <CreditCard Limit="5000" Currency="EUR"> <Number> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>200504</Expiration> </CreditCard> <Signature id="dhfgz7645ft" xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI="#ABCD54321"> <Transforms> <Transform Algorithm=" </Transform> </Transforms> <DigestMethod Algorithm=" <DigestValue>hfiddid45j43l34h3lkl34234===</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0E~LE=</SignatureValue>... Enveloped Signature Example (2)... <KeyInfo> <X509Data> <X509SubjectName>CN=BJS3,O=OPTIMABIT</X509SubjectName> <X509Certificate>XC56DG76HDGES...2AE==</X509Certificate> </X509Data> </KeyInfo> </Signature> </PaymentInfo> 14

15 XML Verschlüsselung Elemente für XML Verschlüsselung <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:keyinfo> <EncryptedKey>? <AgreementMethod>? <ds:keyname>? <ds:retrievalmethod>? <ds:*>? </ds:keyinfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData> 15

16 Unverschlüsseltes XML Ohne Verschlüsselung <PaymentInfo> <Name>John Smith</Name> <CreditCard Limit="5000" Currency="EUR"> <Number> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>200504</Expiration> </CreditCard> </PaymentInfo> Kompletter Inhalt verschlüsselt <EncryptedData xmlns=" Type=" <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> 16

17 Inhalt (außer Name) verschlüsselt <PaymentInfo> <Name>John Smith</Name> <EncryptedData Type=" xmlns=" <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo> Tielinhalt (CC Number) verschlüsselt <PaymentInfo> <Name>John Smith</Name> <CreditCard Limit="5000" Currency="EURO"> <Number> <EncryptedData xmlns=" Type=" <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>200504</Expiration> </CreditCard> </PaymentInfo> 17

18 OASIS WS-Security WS-Security ist ein "Schirm" Standard Der OASIS WS-Security Standard vereint verschiedene bestehende XML and WS Standards, unter einem "Schirm". Die WS-Security Spezifikation funktioniert mit SOAP Version

19 WS-Security definiert ein Format WS-Security definiert SOAP Header Elemente für Nachrichten Authentifizierung Nachrichten Integrität Nachrichten Vertraulichkeit Die Propagierung von Sicherheitstokens Es werden eine breite Palette von Tokens, Verschlüsselungen, Signatur usw. unterstützt, inklusive PKI und Kerberos. WS-Security Namespaces Die WS-Security 1.0 Spezifikation verlangt die Verwendung der folgenden zwei XML Namespaces. wsse für "WS-Security extensions" wsu für "global utility attributes". Prefix wsse wsu Namespace

20 SOAP Structure <wsse:security> Das <wsse:security> Element ist das Basiselement. Eine SOAP NAchricht darf ein oder mehrere <wsse:security> Headerelemente enthalten. optional: mustunderstand="true" Attribut. <wsse:security S:mustUnderstand="true">... </wsse:security> 20

21 <wsse:usernametoken> Das <wsse:username> Element bietet eine Möglichkeit, Information über den Username einzufügen. Beispiel: <wsse:security> <wsse:usernametoken> <wsse:username>hugo</wsse:username> </wsse:usernametoken> <wsse:binarysecuritytoken> Das <wsse:binarysecuritytoken > Element wird verwendet, um binäre Tokens einzufügen. X.509 Zertifikate Kerberos Tickets nicht-xml Format Sicherheitsinformation Beispiel: <wsse:binarysecuritytoken EncodingType="wsse:Base64Binary" ValueType="wsse:X509v3"/> DFERGDT...IUFTR== </wsse:binarysecuritytoken> 21

22 <saml:assertion> Das <saml:assertion> Element bindet SAML Strukturen ein. <wsse:security> <saml:assertion AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant=" T00:36:02Z" Issuer=" MajorVersion="1" MinorVersion="1"... </saml:assertion>... </wsse:security> XML Encryption Beispiel <SOAP:Envelope> <SOAP:Header> <wsse:security>... <wsse:binarysecuritytoken>...</ wsse:binarysecuritytoken> <ds:signature>...</ds:signature>... </wsse:security> </SOAP:Header> <SOAP:Body Id="Body">... <xenc:encrypteddata Id="myId" Type=" <xenc:encryptionmethod Algorithm="..." /> <ds:keyinfo> <KeyName>...</KeyName> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>...</ xenc:ciphervalue> </xenc:cipherdata> </xenc:encrypteddata> </SOAP:Body> </SOAP:Envelope> 22

23 WS-I Basic Security Profile WS-I Basic Security Profile Das WS-I Basic Security Profile v1.0 bietet Anforderungen und Empfehlungen, die zu hoher Interoperabilität führen soll. Basiert auf OASIS WS-Security 1.0 Standard mit HTTP über SSL/TLS als Protokoll. Reference: 23

24 Aspekte der WS-I Basic Security SOAP Nachrichtensicherheit Transport Layer Security (HTTP über SSL/TLS) Sicherheitstokens (Username Tokens, Binary security tokens and XML security tokens) Verwandt mit WS-I Basic Profile SOAP Attachment Sicherheit Verwendungsszenarien XML Signatur XML Verschlüsselung Algorithmen WS-Policy 24

25 Motivation für WS-Policy Die Sicherheitsanforderungen eines Web Service zu definieren. Zum Beispiel, wann braucht ein Web Service: WS-Security? Signierte Nachrichten? Verschlüsselung? Überblick über WS-Policy WS-Policy ist ein Standard, welcher eine flexible und erweiterbare Grammatik für folgende Themen bietet: Fähigkeiten Anforderungen Allgemeine Attribute WS-Policy definiert ein XML Model, um diese Aspekte als Policies auszudrucken. 25

26 WS-Policy Diagram Eine WS-Policy ist eine Anzahl von Behauptungen, die an einem Web Service "attached" (angebunden) wird. Das Attachment findet am WSDL oder UDDI statt, so dass der Service selbst nicht modifiziert werden muss. Es bietet eine flexible Konfiguration, z.b. der Server kann mehrere Optionen akzeptieren, hat aber eine Präferenz. Assertion Beispiel Beispiel Policy mit 2 Assertions: Ein Sicherheitstoken ist nötig Die Integrität der Nachricht muss gewährt sein <wsp:policy> <wsse:securitytoken wsp:usage="wsp:required"> <wsse:tokentype>wsse:kerberosv5st</wsse:tokentype> </wsse:securitytoken> <wsse:integrity wsp:usage="wsp:required"> <wsse:algorithm Type="wsse:AlgSignature" URI=" /> </wsse:integrity> </wsp:policy> 26

27 Zusammenfassung Danke für Ihre Aufmerksamkeit! Dr. Bruce Sams OPTIMA Business Information Technology 27