Safety first in Service-orientierten Architekturen

Die Bedeutung Service-orientierter Architekturen (SOA) wächst. So geht der Marktforscher Gartner davon aus, dass in drei Jahren SOA-Implementierungen weltweit in mehr als 60 Prozent aller Unternehmen zu finden sein werden. Forrester Research erwartet eine Senkung der IT-Kosten von mindestens 30 Prozent, wenn Services die Hauptrolle spielen. Doch derzeit planen die meisten Unternehmen erst ihren Stapellauf. An die Absicherung denkt kaum jemand. Das ist ein Fehler. Security gehört immer an Bord, ist dennoch nicht per se im Service enthalten.

Wer nach Security in SOAs fragt, bekommt ein Spektrum an Antworten, das von “Hier ist alles anders” reicht bis “Es bleibt alles, wie es ist” rangiert. Bei “Security” denken die einen an Virenabwehr, die nächsten an ein ‘Two-Phase Commit’, andere wiederum an Verschlüsselung und weitere an den Datenschutz. Das alles ist weder ganz falsch noch ganz richtig und tangiert die Architekturfrage. SOA selbst ist kein klar umrissener Begriff.

“Im Wesentlichen ist SOA eine Software-Architektur, die in eine Topologie von Interfaces mündet, Schnittstellen-Implementierungen und Interface-Aufrufen”, definiert etwa Gartner-Analyst David McCoy. SOA basiere auf Beziehungen zwischen Service-Anbietern und Service-Nehmern, wobei die Softwaremodule jeweils groß genug seien, um komplette Geschäftsfunktionen abzubilden. Security muss somit sowohl die Sicherung der Wege betreffen als auch die der Inhalte, die ausgetauscht werden. Darüber hinaus muss gewährleistet sein, dass der richtige Service die passende Nachricht überbringt und einschleusen darf.

Keine Chance für Wegelagerer

Außerdem siedelt sich Security in keiner von mehreren aufeinander folgenden Stufen in der Software-Entwicklung an, sondern begleitet die Konzeption von Anfang an. “In einer Service-orientierten Architektur ist Security nicht mehr von Service trennbar”, sagt etwa Bruno Quint, Geschäftsführer der Darmstädter Besecure GmbH. Das Zehn-Mann-Unternehmen bietet mit “Business Security Framework” eine konfigurierbare Sicherheitsplattform an, unter anderem speziell für SOAs und SAPs Netweaver. “Wer eine SOA modelliert”, sagt er, “muss gleichzeitig Security konfigurieren”. Als Beispiel nennt er Bestimmungen der US-Behörde Food and Drug Administration (FDA), deren Aufgabe unter anderem darin besteht, die Sicherheit und Wirksamkeit von Arzneimitteln für Tier und Mensch zu kontrollieren, die in den USA hergestellt oder importiert werden. Sie schreibt etwa vor, welche Strecken in einem Geschäftsprozess nur verschlüsselt passiert werden können.

Auch Helmuth Trautmann, in Branchenkreisen bestens bekannter Entwickler bei Hewlett-Packard, rät dazu, Security-Fragen gleich beim Zuschnitt der Services mit zu bedenken. Er führt aus: Ein Service könne sowohl Provider als auch Konsument sein. Somit müssten sich die Dienste erst bekannt machen und mitteilen, was sie von einander wollten.

Das wäre in einer uniformen Umgebung einfach. Doch in SOAs müssen die Architekten und Entwickler erst einmal festlegen, auf welcher Basis sich die Services austauschen können; sie müssen ein Art Vertragswerk aufsetzen, ‘Policies’. Für die Definition der Datenkontrakte stellen Web-Service-Standards die Möglichkeit einer XML Schema Definition (XSD) bereit. Das ermöglicht ein korrektes Format der XML-Nachrichten, die über das Web-Service-Protokoll Soap (Simple Object Access Protocol) verschickt werden. Mit Hilfe der Beschreibungssprache Web Service Description Language (WSDL) lassen sich XSD-Messages für die auszuführenden Operationen spezifizieren. Der Fokus liegt dabei auf Sequenzierung, Austausch-Mustern und Transport-Details.

Laut Trautmann und Aaron Skonnard, Autor und Geschäftsführer des Schulungshauses Pluralsight, sollten solche Abkommen vor jeglicher Implementierung von Code entstehen. Die Methode nennt sich ‘Contract First’. Der Ansatz sieht unter anderem vor, dass sich der Code für den zu implementierenden Service generieren lässt, zum Beispiel Java- oder C#-Code. Doch der direkte Umgang mit WSDL etwa scheint unbequem, komfortable Tools entstehen erst. Das Vorgehen bleibt in der Diskussion.

Erst verhandeln, dann codieren

Solche Verträge bilden neue Module, auch ‘Building Blocks’ genannt. Sie enthalten nicht nur Security-Klauseln, sondern auch Bestimmungen über die Zusammensetzung, die Integrationsmöglichkeiten und Nutzung. Letztlich ermöglicht nur ein Vertragswerk eine Föderation von Services, die über verschiedene Plattformen, Betriebssystemen, Applikationen, Programmiersprachen und Komponententechniken hinweg verteilt zusammenarbeiten sollen.

Somit gehören Policies, laut Trautmann, nicht in die Services selbst, sondern in die Verwaltungs- und Integrationsmechanismen eines Enterprise Service Bus (ESB). Denn Services ähneln zwar durchaus verteilten Komponenten, doch im Gegensatz zu bisher üblichen Mechanismen können Policy-Änderungen auch in Echtzeit greifen. ESBs bilden die Prozesslogik ab und ermöglichen zentral die Orchestrierung und Verteilung der Services. “Deshalb”, so stimmt auch Quintec-Geschäftsführer Quint und Anbieter eines Security-Layers zu, “gehören Security-Regeln in oder auf den ESB.” Das beinhaltet sowohl Regeln wie ein Vier-Augen-Prinzip, als auch die Erteilung von Zertifikaten, XML-Signaturen, Signle Sign-on und die Sicherung des Nachrichtentransports. So unterstützt etwa sein Framework unter anderem das Netzprotokoll SSL (Secure Socket Layer), SAML (Security Assertion Markup Language) sowie die Spezifikationen von WS-Security.