Sichere Web Services- Standards und architektonische Bausteine

Web Services bilden ein fundamentales Element der elektronischen Geschäftsausübung – entsprechend hohes Gewicht liegt auf der adäquaten Sicherung dieser Services. Nachfolgend werden potentielle Schwachstellen von Web Services sowie die entsprechenden Sicherheitselemente – Standards und Lösungskomponenten – beleuchtet.

Der Trend zu Service-orientierten Architekturen

Service-orientierte Architekturen und Web Services als deren potentiell am weitesten verbreitete Ausprägung sind derzeit «in Mode» – die Gründe liegen vor allem im Potential zur vereinfachten Verknüpfung verteilter Dienste und zur Vermeidung kostenintensiver Integrationsarbeiten. Die «Versuchung» ist gross – für jeden Franken, der derzeit für Software-Beschaffung ausgegeben wird, müssen weitere 3 bis 5 Franken für Integrationsaufwände budgetiert werden, und bereits heute werden bis zu 70% firmenweiter IT-Budgets für Integrationsarbeiten aufgewendet. Web Services haben aufgrund ihrer einfachen und bereits weit ausgebreiteten Basistechnologien das Potential, diese hohen «top down» Integrationen (A) durch einen einfachen, skalierbaren «bottom up» Ansatz (B) zu ersetzen.

Die potentiellen Vorteile einer entsprechend stringent durchgesetzten Software-Architektur sind erheblich. Die vereinfachte Integration hilft, Kosten zu senken, die dynamische Verbindung mit neuen Services erlaubt es dem Unternehmen, schnell auf neue Marktgegebenheiten zu reagieren, und die Nutzung bereits vorhandener Komponenten und Legacy-Systeme innerhalb einer service-orientierten Architektur schützt bereits getätigte Investitionen.

Potentielle Risiken und Schwachstellen

Auf der Negativ-Seite schlagen zwei Faktoren zu Buche, die beim Umstieg auf Service-orientierte Architekturen im allgemeinen und auf Web Services im Besonderen zu beachten und durch geeignete Gegenmassnahmen abzumildern sind. Die ggf. unkontrollierte Verbreitung von dynamisch verwendeten internen und externen Web Services erhöht den Betriebs- und Überwachungsaufwand und erschwert die Suche nach Fehlern – die End-zu-End Funktionalität muss zudem durch komplexe Service Level Agreements sichergestellt werden, die Komponenten weit ausserhalb der eigenen Kontrolle beinhalten. Beide Faktoren erhöhen also die Gesamtkomplexität und verursachen damit potentielle Zusatzkosten und –aufwände.

Darüber hinaus ist ein nicht zentral gesteuerter und geplanter Service Ansatz anfällig für «lokale» System-Fehler und Sicherheits-Schwachstellen, deren Auswirkung dann erst spät erkannt wird und potentiell alle Web-basierten Systeme und Dienste betreffen kann – zudem bewirken «denial of service» Angriffe auf Teilkomponenten zuvor nicht erkennbare Schäden in der Gesamt-Dienstleistung. Dieses erhöhte Risikopotential muss ebenfalls durch entsprechende Erkennungs- und Gegenmassnahmen auf ein akzeptables Mass reduziert und laufend überwacht werden. Auch in rein technischer Hinsicht weist eine Service-orientierte Architektur eine Vielzahl von potentiellen Schwachstellen auf – die Service-Registratur, die Registration oder Deregistrierung von Services, die Suche nach Services sowie die Verbindungsaufnahme und Kommunikation zwischen Services sind lohnenswerte Objekte für einen Angreifer, der hier die ganze Palette von Angriffen von der einfachen Dienstunterbrechung bis hin zur Datenverfälschung, Datenverzögerung, Datenlöschung oder Datenerzeugung bzw. zum Mitlesen ggf. sensitiver Daten nutzen kann.

Schliesslich ist zu beachten, dass in einer Service-orientierten, verteilten Architektur nicht nur die Sicherheitsprobleme der bereits nicht trivialen vertikalen Integration zwischen den Schichten der lokalen Software-Architektur zu lösen sind (z.B. die gemeinsame Definition und Verwendung von Identitäten, Rollen und Rechten über die verschiedenen Software-Komponenten hinweg), sondern dass neu komplexe Service-Prozessketten entstehen, welche nicht mehr unter einer einheitlichen Verwaltung und Kontrolle stehen, und dennoch über eine Kette von Intermediären zwischen den beteiligten End-zu-End-Parteien einen genügend guten Sicherheitskontext aufrechterhalten müssen.

Eine entsprechende Sicherheitsarchitektur muss demzufolge sowohl die lokalen Sicherheitsbedürfnisse und lokal geltenden Sicherheitsregeln unterstützen, als auch föderierte, geschäftlich und vertraglich verbundene Einheiten so miteinander integrierbar machen, dass unter Beibehaltung aller lokalen Sicherheitsanforderungen auch die nötige End-zu-End-Sicherheit (z.B. die selektive Weitergabe von Identitätsmerkmalen und der zugehören Zweckbindung) gewährleistet wird.

Eine Web-Service Sicherheitsarchitektur

Die sicherheitsspezifischen Anforderungen an Web Services unterscheiden sich zunächst nicht grundsätzlich von den Sicherheitsanforderungen für traditionelle «Silo»-Anwendungen. Gefordert werden:

• Vertraulichkeit, Integritätsschutz, Verfügbarkeit, Verbindlichkeit, Skalierbarkeit

• Starke Identifikation, Authentisierung und Autorisierung zwischen Benutzer, aber auch zwischen Software-Komponenten

• Betriebs- und Systemüberwachung, Event Management und Event Korrelation, und revisionssichere Aufbewahrung und -Auswertung

• Transparente, nachvollziehbare Kosten/Nutzen Analysen bezüglich Bedrohungen und Gegenmassnahmen

• Ein klar definiertes Änderungs- und Konfigurations-­Management
Eine Sicherheitsarchitektur für Web Services muss darüber hinaus zwei weitere Voraussetzungen erfüllen. Einerseits muss sie föderative Methoden des Identitäts- und Zugangs-Managements unterstützen – ggf. integriert in ein ebenfalls föderatives Management der physisch und logisch verteilten Web-Services und den darunter nötigen Infrastruktur-Elementen. Andererseits muss sie in der Lage sein, über die Unterstützung und Interpretation entsprechender Standards offene Schnittstellen für den Daten- und Kontrollfluss anzubieten und zu bewirtschaften.
Der Schlüssel für die Bereitstellung dieser Eigenschaften liegt in der Verwendung breit akzeptierter und angewandter Standards für das Sicherheits-Management in föderativen Umgebungen.

Standards für die Sicherheit von Web Services

Eine Reihe von Organisationen und Hersteller-Verbunden beschäftigt sich derzeit mit der Entwicklung, Ausbreitung und Pflege von Standards und «best practices» für die Sicherheit Web-basierter Dienste. Jedoch muss festgestellt werden, dass diese Standardisierungsbemühungen zumindest teilweise von partikulären Interessen der Beteiligten getrieben werden und entsprechende Inkompatibilitäten vorhanden sind und ggf. bleiben werden. Wesentliche Standards für föderative Sicherheit in Web Service Umgebungen sind derzeit:

• Security Assertion Markup Language (SAML) ermöglicht den Austausch von Sicherheitsinformation zur Identifikation und Authentisierung zwischen Sicherheits-Diensten.

• XML Key Management (XKMS) beschreibt wie Schlüssel, Zertifikate, Sicherheits-Token etc von einem Sicherheitsdienst oder einem Web Dienst bezogen werden können.

• eXtensible Access Control Markup Language (XACML) dient der Definition und dem Austausch von Sicherheits-Policies in XML und kann zum Abgleich von Sicherheits-Policies in föderativen Umgebungen verwendet werden.

• Service Provisioning Markup Language (SPML) ermöglicht Sicherheits- oder Applikationsumgebungen, die nötigen Sicherheits-Elemente zu konfigurieren und zu kontrollieren.
Insbesondere SAML stellt in diesem Zusammenhang ein Schlüsselelement der Standardisierung dar. Der Standard definiert eine offene Umgebung für die Bereitstellung und den Abgleich von Sicherheitsinformation im Internet mittels XML Dokumenten. Das Management und die Weiterentwicklung von SAML sind dabei herstellerunabhängig und obliegt der Vereinigung OASIS (siehe http://www.oasis-open.org). SAML wurde ursprünglich entworfen zur Verbesserung der Web Sicherheit – insbesondere beinhaltet SAML ein standardisiertes Verfahren, um »cookies” zwischen verschiedenen Internet Umgebungen sicher zu transferieren, und um proprietäre Single sign-on (SSO) Lösungen im Web durch ein standardisiertes Verfahren abzulösen, um SSO innerhalb oder zwischen Internet Umgebungen zu definieren und zu betreiben.
Daneben beschäftigt sich die Liberty Alliance (ein Konsortium auf Initiative von Sun Microsystems, siehe: http://www.projectliberty.org/) mit föderativen Ansätzen des Managements digitaler Identitäten, insbesondere im Kontext von Web-Services). Liberty beinhaltet ein 3 Phasen – Modell:

• Phase 1: Identity Federation Framework (ID-FF): Föderative, netzwerk-basierte Dienste, insbes. Sign-In/-Out, Opt-In, Verknüpfung von Benutzer-Berechtigungen, Privatsphärenschutz.

• Phase 2: Identity Web Services Federation (ID-WSF): Ein Framework für interoperable, föderative, netzwerk-basierte Identitätsdienste, insbes. Definition relevanter Identitätsdaten, Suche nach Identitätsdiensten, Nutzung fremder Identitätsdienste, gemeinsamen Nutzung von Sicherheits-Attributen, Definition von Diensten, Protokollen und Sicherheitsprofilen.

• Phase 3: Identity Services Interface Specification (ID-SIS): Definition interoperabler Identitätsdienste zur Implementation von ID-WSF Definitionen in spezifischen Web-Diensten (z.B. Identitätsprofile von Benutzern, Mitarbeitern etc.
Wiederum parallel dazu definiert der von Microsoft und IBM unterstützte WS-Security* Framework über eine Reihe von Standards einen Träger für Identitäten und andere sicherheitsrelevante Information für Interaktionen mit Web Diensten. Relevante Teilstandards sind dabei:

• WS-Trust: Ein Protokoll für den sicheren Bezug und Umgang mit Sicherheits-Token

• WS-SecureConversation: Erstellung und gemeinsame Nutzung von Sicherheits-Kontexten zwischen Kommunikationspartnern mittels «Security Context Token» sowie Regeln für die Verwendung von digitalen Schlüsseln für das Chiffrieren und Signieren von Nachrichten.

• WS-Policy: Sprache und Regeln für die formale Definition von Sicherheits-Fähigkeiten und Anforderungen
(Policy Assertation) von Web Services, basierend auf entsprechenden weiteren Standards (insbes. WS-Policy­Attachment)

• WS-Federation: basiert auf den Modellen aus WS-Security, WS-Trust, and WS-Policy und erlaubt die selektive Weitergabe von Vertrauensbeziehungen und Sicherheits-Token sowie den Schutz der Privatsphäre durch entsprechende Identitäts-Schutzmechanismen
Wie bereits dargelegt sind diese Standardisierungsbemühungen nicht völlig widerspruchsfrei und teilweise motiviert durch gegensätzliche Marktbemühungen der involvierten Hersteller (so konkurrieren beispielsweise WS-Federation und Liberty Alliance ID-WSF). Zwar ist mittelfristig damit zu rechnen, dass zumindest die Interoperabilität zwischen den unterschiedlichen Ansätzen gewährleistet wird, dem interessierten Anwender bzw. Entwickler oder Integrator kann jedoch auf absehbare Zeit nicht erspart werden, die entsprechenden Standards und Frameworks für den jeweiligen Anwendungsfall zu prüfen und ggf. selektiv auszuwählen, welche Standards und darauf basierenden Produkte zum Einsatz kommen.

Zusammenfassung

Ein Gesamtkontext für die Erstellung, den Betrieb und die Überwachung föderativer Web Services muss auf einer Vielzahl von «Bausteinen» und den entsprechenden funktionalen und technischen Verbindungen bestehen. Hierbei ist insbesondere die Integration in bereits jeweils lokal bestehende Abläufe (z.B. Benutzer-Identifikation und

• Provisionierung oder die sicherheitsspezifische Betriebsüberwachung) von Bedeutung für die resultierenden Projekt- und Betriebsaufwände.
Für die Service-orientierte Kommunikation zwischen Endbenutzer und der web-basierten Applikationskette gelten dabei die folgenden Anforderungen:

• EINE zentralisierte Benutzerverwaltung/-provisionierung für ALLE Web Applikationen.

• Reduktion der administrativen Aufwände durch weitestgehende Automation der Abläufe.

• Einbezug existierender PKI und/oder SSO Umgebungen, inklusive Beachtung der Anforderungen aus dem Schutz der Privatsphäre bei föderativen Prozessketten.

• Einbezug sicherer und stark genug ausgebildeter primärer Identifikations- und Authentisierungsmechanismen, auf denen der Rest der Prozesskette aufbauen kann.

• Standardisierte Bausteine für Applikationen, Datenbanken und Middleware-Komponenten.


Für die Kommunikation zwischen Web-basierten Anwendungselementen ergeben sich hingegen die folgenden Anforderungen:

• Zentralisierte Zugangskontrolle für Transaktionen zwischen föderativen Applikationen.

• Schutz der Vertraulichkeit der übermittelten Nutz- und Kontrolldaten durch Chiffrierung.

• Schutz der Integrität der übermittelten Nutz- und Kontrolldaten durch digitale Signaturen.

• Sicherung der End-zu-End Verfügbarkeit durch Service Level und deren Überwachung.

• Verbindlichkeit verteilter Transaktionen durch Anlage/Aufbewahrung von Log-Daten.