ohne Standard keine Sicherheit

Dr. Bruno Quint ist einer der Gründer und Geschäftsführer der Corisecio GmbH, die sich auf Security-Lösungen für SOA-Produkte spezialisiert hat

Die Idee, Funktionalitäten und Aufgaben als lose gekoppelte, unabhängige und austauschbare Dienste über standardisierte Schnittstellen anzubieten, trifft den Nerv der Zeit. Dieses «Baukasten-Prinzip» erlaubt es den Unternehmen, flexibler auf sich ändernde Geschäftsprozesse zu reagieren - und das ist heute gefragter denn je. Viele der bereits im Zuge des SOA-Hypes diskutierten Herausforderungen gelten dabei auch für Cloud Computing. Kein Wunder, bedenkt man, dass SOA ein Managementkonzept von IT-Systemen und Applikationen beschreibt, das Voraussetzung jedes Cloud-basierten Geschäftsmodells ist. Nicht wenige «lessons learned» aus serviceorientierten IT-Projekten können daher für die Cloud übernommen werden. Für Sicherheitsmechanismen gilt das in besonderem Masse, denn die Realisierung neuer Cloud-Geschäftsmodelle hängt stark von den verfügbaren Sicherheitsmethoden ab. Das Management und die Absicherung dienstorientierter Infrastrukturen sind aber um ein Vielfaches komplexer als herkömmliche (monolithische) Applikationen. Beherrschbar werden SOA-Geschäftsprozesse, bestehend aus lose gekoppelten Services, erst durch entsprechende Managementwerkzeuge, die für eine zentrale Verwaltung und Steuerung sorgen.

Neben dieser Orchestrierung spielt die Modellierung von Prozessen eine wichtige Rolle. Oft durch grafische Werkzeuge unterstützt, können Architekten und Systemdesigner komplette Geschäftsprozesse aus einzelnen Services modellieren und konfigurieren. Zur Beschreibung und Ausführung werden Standards wie BPEL (Business Process Execution Language) verwendet. Gerade im SOA-Umfeld sind Standards unumgänglich, um die Interoperabilität systemweit zu gewährleisten. Für Sicherheitsmethoden fehlen solche Werkzeuge. Analog zu den Geschäftsprozessen muss die Security-Implementierung aber mit demselben Grad an Flexibilität erfolgen. Daraus folgt sowohl die Forderung nach Modellierungswerkzeugen als auch nach Standards, die in der Lage sind, Security-Prozesse abzubilden. Es müssen die gleichen Aufgaben - von Design und Modellierung bis zu Deployment und Enforcement - abgedeckt werden können.

Die Anforderungen an eine Beschreibungssprache für Security lassen sich zunächst aus den Einsatzszenarien in SOA- und Cloud-Umgebungen ableiten. Insbesondere vor dem Hintergrund der losen Servicekopplung mit mehreren Teilnehmern und den daraus resultierenden Enforcement Points, müssen Security-Methoden an zahlreichen Stellen in der Gesamtinfrastruktur verfügbar sein. Daher liegt es nahe, Sicherheitsmethoden selbst als Service «in der Cloud» zu etablieren. Analog zu Application Services können Security-Dienste so flexibel mit Prozessen kombiniert und genutzt werden.

Neben Standardservices, wie Authentisierungs- und Autorisierungsdiensten, werden in Cloud-Projekten zudem Sicherheitsservices benötigt, die Themen wie Datenschutz, Delegation und Schlüsselmanagement abdecken. Dies setzt neben Management und Orchestrierung die Modellierbarkeit von Security-Prozessen voraus. Nun können vorhandene Standards (wie BPEL) aufgrund der technischen Anforderungen von Sicherheitsprozessen nicht einfach übernommen werden. Ein Beispiel dafür ist die Parametrisierung. So werden bereits zur Ausführung eines einfachen Verschlüsselungsservices (auf Basis von XML-Encryption) dynamische Parameter benötigt, die beispielsweise das Zertifikat des Empfängers sowie die Angabe der Adressierung der zu verschlüsselnden Elemente (z.B. via X-Path) enthalten. Die Processing Engine muss in der Lage sein, den modellierten Service zur Laufzeit um solche dynamischen Informationen zu ergänzen und entsprechend auszuführen. Es werden daher Elemente benötigt, die bislang in keinem Standard abgebildet sind. Eine proprietäre bzw. herstellergebundene Implementierung ist insbesondere im SOA- und Cloud-Umfeld nicht praktikabel. Um Inkompatibilitäten und aufwendige Integrationen zu vermeiden, sollte - dem SOA-Gedanken folgend - auch für die Modellierung auf Standards gesetzt werden.
Eine nahe liegende Lösung besteht darin, den Sprachumfang vorhandener Standards entsprechend zu erweitern. Benötigt wird eine Anpassung des Sprachumfangs an die Erfordernisse von Sicherheitsmethoden bei gleichzeitiger Bewahrung vorhandener Syntax und Semantik. Dadurch kann die Interoperabilität zwischen Business- und Security-Design einfach hergestellt werden.

Vielfach existieren Überlappungen zwischen Business- und Security-Prozessen, die durch die integrierte Beschreibungssprache bereits in der Designphase berücksichtigt werden können. Auf Basis einer gemeinsamen Prozessbeschreibung lassen sich grafische Modellierungswerkzeuge um Securitytern, sodass der Geschäftsprozess an zentraler Stelle vollständig definiert werden kann.

Als Beispiel sei ein klassisches Vier-Augen-Prinzip zur Freigabe von Aufträgen genannt. In erster Linie ein Businessprozess, benötigt der Betrieb trotzdem zur Umsetzung zahlreiche Sicherheitsmethoden. So muss der Auftrag nach der Geschäftsprozesslogik bei Übertretung eines definierten Auftragsvolumens vom zuständigen Vorgesetzten signiert werden. Dies setzt die Integration eines Signaturservices in den Geschäftsprozess ebenso voraus wie den integrierten Zugriff auf das Rollen- und Rechtekonzept, in dem Zuständigkeiten und Kompetenzen abgebildet sind. Dies muss in der Modellierung berücksichtigt werden, sodass entsprechende Signaturen von zuständigen Personen erstellt und im Anschluss auch auf Gültigkeit (und Zuständigkeit) geprüft werden können.

Angesichts realer Anforderungen wie Änderungen in Zuständigkeiten, Versetzungen, Umstrukturierungen oder einfach nur Ferienvertretungen, wird die Notwendigkeit von dynamischen Modellen bzw. Parametern auf den ersten Blick deutlich.

Derzeit wird die Umsetzung von Cloud- und SOA-basierten Geschäftsmodellen durch fehlende Sicherheitskonzepte gehemmt. In der Realität werden viele Pilotprojekte gänzlich ohne Security durchgeführt, steht doch die Abbildung der Geschäftsprozesse erst einmal im Vordergrund. Spätestens bei der Planung des Go-Live fällt dann aber auf, dass der Security-Aspekt noch nicht abgedeckt ist. In Ermangelung standardisierter SOA-adäquater Lösungen wird dann vielfach auf herkömmliche Massnahmen (bspw. SSL) zurückgegriffen. Das Resultat ist oft eine starre Implementierung, welche die Flexibilität stark einschränkt und zudem nicht die Sicherheitsanforderungen dienstorientierter Systeme (beispielsweise Sicherheit auf Nachrichtenebene) erfüllt.

Die Standardisierung der Beschreibungssprache kann Abhilfe schaffen. Durch eine gemeinsame Modellierung kann Security bereits in der Designphase berücksichtigt werden. Insbesondere die Integration in vorhandene Modellierungswerkzeuge wird durch einen Standard erst ermöglicht. Gleiches gilt für die Umsetzung. Processing Engines wären in der Lage, Security-Anweisungen zu verstehen und entsprechende Services aufzurufen. Damit wäre dann auch die sichere Umsetzung neuer Cloud- und SOA-basierter Geschäftsmodelle möglich.

SET 5.-6. Mai 2009

Aktuelle Trends in der Software-Entwicklung sind auch Thema der diesjährigen «Software Engineering Today (SET 2009)». Computerworld begleitet die Konferenz als Medienpartner.
Programm und Anmeldung unter: www.set-conference.com