Sicherheit in SOA Was kommt auf Entwickler zu? Sebastian Weber

Sicherheit in SOA Sebastian Weber Developer Platform & Strategy Group Microsoft Deutschland GmbH Sebastian.Weber@microsoft.com

SOA der Hype „IT-Dienstleister können mit SOA abkassieren“ Quelle: www.cio.de, 10.04.06 „2006 wird das SOA-Jahr“ Quelle: www.cio.de, 03.12.05 „SOA treibt das intelligente Unternehmen“ Quelle: www.computerwoche.de, 13.04.06 „In Architekturfragen zeigen die Unternehmen ein zunehmendes Interesse an der Serviceorientiertung. Im Jahr 2003 noch kaum genannt, liegen SOA-Projekt mittlerweile im Trend.“ Quelle: www.computerwoche.de, „Agilität – Stand der Praxis“, 26.04.06

SOA – was ist ein Dienst?* Web Service Nachrichten == Daten Logik („Code“) *Serviervorschlag

SOA – ein Schaubild UDDI Service A Service B

SOA und die Sicherheit (I) UDDI Jeder Web Service bietet Zugang zum System Service A Service B

SOA und die Sicherheit (II) UDDI Dokumente werden über das (Inter-)net versendet Service A Service B

SOA und die Sicherheit (III) UDDI Services müssen „als Ganzes“ geschützt sein Service A Service B

SOA Security – Es gibt viel zu tun! UDDI Service A Service B

Agenda SOA und Sicherheit SOA Security Pattern Servicezugang schützen Nachrichten schützen Servicegrenzen sichern Implementierungsstrategien

Servicezugang schützen Authentifizierung Authorisierung

Direkte Authentifizierung (I) Service verlangt Authentifizierung des Clients Service fungiert als Autentifizierungsdienst Client und Server haben ein gemeinsames Geheimnis Client Service Aufruf inkl. Credentials

Direkte Authentifizierung (II) Pro Contra Keine weitere Infrastruktur benötigt Geht das Geheimnis verloren, ist „nur“ diese Verbindung gefährdet Kein SSO möglich Aufwendiger Abgleich der Credentials bei mehreren Diensten Pro-Request Authent. kostet Zeit und Ressourcen

Broker Authentifizierung (I) Service verlangt Authentifizierung des Clients Client authentifiziert sich beim Broker Service und Client haben kein gemeinsamens Geheimnis Authentifizierungsbroker Authentifi- zierungs- anfrage Authentifizierungs- anfrage Token Client Service

Broker Authentifizierung (II) Pro Contra Zentrale Vertrauensstellung Client und Service müssen sich nicht kennen Zentrale Verwaltung aller Credentials (möglich) Single point of failure Broker darf niemals in die falschen Hände gelangen

Direkt oder via Broker? Mal wieder: keine pauschale Antwort Direkte Authentifizierung ist schnell implementiert und bedarf keine weitere Infrastruktur Broker-basierte Authentifizierung ist aufwendiger, dafür in vielen Szenarien flexibler

Agenda SOA und Sicherheit SOA Security Pattern Servicezugang schützen Nachrichten schützen Servicegrenzen sichern Implementierungsstrategien

Nachrichten schützen? Oliver Sebastian Spesenabrechnung von Sebastian

Nachrichten schützen! Nicht Sebastian 

Was genau ist zu schützen? Ist die Nachricht wirklich von B? Hat A wirklich X gemeint? Authentizität der Herkunft Integrität der Daten Geheimhaltung Service A Service B Das sollte C lieber nie erfahren ...

Das Prinzip VIA Vertraulichkeit Daten der Nachricht dürfen nicht von Dritten eingesehen werden Integrität & Authentizität der Herkunft Überprüfbarkeit, ob der Inhalt unverändert übermittelt wurde Überprüfbarkeit, ob der Inhalt wirklich vom Abesender stammt

Vertraulichkeit - Symmetrisch Sender Empfänger Verschlüsseln Entschlüsseln Gemeinsamer Schlüssel

Vertraulichkeit - Asymmetrisch Sender Empfänger Verschlüsseln Entschlüsseln Öffentlicher Schlüssel vom Empfänger Privater Schlüssel vom Empfänger

Integrität & Authentizität der Herkunft – Symmetrisch Sender Empfänger Signieren Signatur prüfen Gemeinsamer Schlüssel

Integrität & Authentizität der Herkunft – Asymmetrisch Sender Empfänger Empfänger Signieren Signatur prüfen Privater Schlüssel vom Sender Öffentlicher Schlüssel vom Sender

Nachrichten schützen Vertraulichkeit Verschlüsseln der Nachrichten Symmetrisch / Asymmetrisch Integrität & Authentizität der Herkunft Signieren der Nachrichten

Agenda SOA und Sicherheit SOA Security Pattern Servicezugang schützen Nachrichten schützen Servicegrenzen sichern Implementierungsstrategien

Servicegrenzen sichern Wirklich sicher?

Servicegrenzen sichern Replay Attack? DOS? Zugang zu Internas? Injection?

Servicegrenzen sichern Schutz vor Injections Steht etwas „Böses“ in den Nachrichten? Schutz vor Replay Attacks / DOS „2-mal die gleiche Nachricht?“ „Wirklich 1.000.000.000 Nachrichten von X?“ Schutz vor Spionage Exception Shielding Nie wieder: „Fehler in SQL Statement: SELECT * FROM KennwortTabelle WHERE User = ‘Ernie‘ AND Pass = ‘geheim!‘“

Schutz vor Injections Client-seitige Überprüfung nicht ausreichend AJAX (!!!!!!!!!!) Ist die Nachricht formal korrekt? Länge, Schema, ... Entsprechen die Daten der erwarteten Datentypen? Eingabevalidierung, Eingabevalidierung, Eingabevalidierung, Eingab...

Schutz vor RAs / DOS Sender Empfänger Replay Cache Prüfen, ob bekannt

Schutz vor Spionage Ein sehr häufiges Problem: Exeptions Lösungsansatz Angreifer erzwingt eine Exception Service gibt interne Informationen in der Fehlermeldung preis Lösungsansatz Jeder Exception muss vom Service behandelt werden Erstellung explizierter Exceptions ohne interne Informationen

Agenda SOA und Sicherheit SOA Security Pattern Servicezugang schützen Nachrichten schützen Servicegrenzen sichern Implementierungsstrategien

Message vs Transport Layer Absicherund der Kommunikation kann auf zwei unterschiedlichen Ebenen stattfinden Message Layer Bestandteil der Nachrichten Transport Layer Die Netzwerkverbindung wird pauschal gesichert

Technologien X.509 Zertifikate Kerberos Security Token Service (STS) SSL IPSec Diverse Web Service Spezikationen WS-Security, WS-Trust, WS-Federation, ... ...

SOA Security Implementierung .NET Framework 2.0 Verschlüsselung, Signierung, Zertifikate, ... Web Service Enhancements 3.0 (WSE) Zusätzliche WS-* Implementierungen Windows Communication Foundation (WCF) Next Generation Secure by Default „Eine Frage der Konfiguration“

WCF Security Übersicht <Vortragstitel> WCF Security Übersicht Einheitlich Designed für On-Machine, Cross-Machine, und Cross-Internet Szenarien Einheitliches Programmiermodell Interoperabel Basiert auf WS-* Spezifikationen Kompatibel mit existierenden Security Mechanismen (Windows, Kerberos, X.509, HTTPS) Secure by default Alle Standard-Bindings sind per Default sicher BasicHttpBinding ist eine Ausnahme Standardabsicherung ist Verschlüsseln und Signieren TechNet Roadshow zum Windows Server System: Migration, Deployment und Sicherheit

Mehr zu Web Service Security Web Service Security ISBN: 0735623147 Online und als Download (PDF) kostenfrei erhältlich http://msdn.com/practices

Agenda SOA und Sicherheit SOA Security Pattern Servicezugang schützen Nachrichten schützen Servicegrenzen sichern Implementierungsstrategien

Sicherheit in SOA Ein umfassendes Thema Automatisierung macht den Angriff einfach Auch hier: keine nachträgliche Sicherheit WSE 3.0 und WCF erleichtern die Arbeit

Vielen Dank! Fragen und Antworten Sebastian Weber Sebastian.Weber@microsoft.com http://sebastianweber.org

Mehr Informationen MSDN Security Center TechNet Security Center http://microsoft.com/germany/msdn/security http://msdn.microsoft.com/security TechNet Security Center http://www.microsoft.com/germany/technet/sicherheit http://www.microsoft.com/technet/Security Codezone.de http://codezone.de

Ihr Potenzial. Unser Antrieb.