Suchen

SOA Layer Model hilft bei der Kontrolle von Webservices Klarer Fokus sichert erfolgreiche Lösungsstrategie

Autor / Redakteur: Lothar Lochmaier / Peter Schmitz

Der Wildwuchs an Webservices und Web 2.0-Tools läßt sich heute strategisch im Unternehmen kaum noch bewältigen. Einige praktische Ratschläge zeigen, wie sich allzu große Turbulenzen vermeiden lassen. Als Kernelement gilt das SOA Layer Model, mit dessen Hilfe Unternehmen eine möglichst klare und strikte Trennung zwischen Geschäfts- und Applikationsdiensten bewerkstelligen.

Firmen zum Thema

Bei der Kontrolle von Webservices kann das SOA-Konzept Komplexität reduzieren, die Sicherheit darf dabei aber nicht außen vor bleiben.
Bei der Kontrolle von Webservices kann das SOA-Konzept Komplexität reduzieren, die Sicherheit darf dabei aber nicht außen vor bleiben.
( Archiv: Vogel Business Media )

Im Rahmen einer Service-orientierten Architektur sind die Spezialisten mit der konkreten Ausgestaltung von geschäftsorientierten Diensten mehr als gefordert, oftmals auch überfordert. Denn diese Services sind abhängig von den jeweiligen Geschäftsprozessen individuell gestaltet und haben damit meistens einen geringen Wiederverwendungsgrad. „Entsprechend resultiert daraus eine hohe Anzahl an Webservices (WS)in den einzelnen Unternehmen“, betont Detlef Sturm, Senior Manager Product Technology Beta Systems Software AG.

Und dieser oft ausufernde Wildwuchs, indem sich IT- und Fachabteilungen häufig in die Quere kommen, weil sie gelegentlich den Überblick verlieren, gelingt es mit einem klaren Lösungskonzept ins Visier zu nehmen. Zwar kümmern sich Tools wie Service Registries und Repositories um die unternehmensweite Verwaltung der zahlreichen Webservices und bieten mit Governance-Vorgaben auch konkrete Möglichkeiten, das ungebremste Chaos einzudämmen, noch bevor es sich wie eine Krake auf viele Bereiche ausdehnen kann.

Bildergalerie
Bildergalerie mit 5 Bildern

„Der Ansatz generische und applikationsorientierte Webservices zu entwickeln, wird dabei aber oftmals vernachlässigt“, gibt Sturm zu bedenken. Damit ließen sich nach Auffassung des Experten aber genau jene häufig wieder verwendbare Webservices bereitstellen, wodurch sich die Anzahl der Webservices stark reduziere.

Fokussieren auf die zentralen Bedrohungen

Bevor dieses komplexe Unterfangen jedoch erfolgreich justiert werden kann, muss sich das jeweilige Unternehmen erst einmal auf die zentralen Bedrohungen fokussieren, die mit den zahlreichen unverbundenen Webinseln einher gehen. Eine hohe Anzahl an eigenständigen Webservices bedeute auch eine hohe Anzahl an (neuralgischen) Stellen, in denen Security zu realisieren und zu überprüfen sei, so der Experte von Beta Systems Software weiter.

Mit den sensiblen Nahtstellen gemeint sind so genannte Policy Enforcement Points. Dabei benötigen Service-übergreifende Geschäftsprozesse ebenfalls eine Service-übergreifende Security. Entsprechend sei ein konsistentes Verhalten mit Blick auf die Sicherheitsanforderungen dringend nötig, führt der Experte weiter aus.

„Das heißt aber auch, bei einer hohen Anzahl an Webservices erhöht sich der Aufwand diese einheitlich zu konfigurieren und hier gilt: die Kette ist so schwach wie das schwächste Glied“, gibt Detlef Sturm die Marschrichtung vor. Wie also müsste eine entsprechend leistungsfähige „Informationsarchitektur“ aufgestellt sein? Erstens: Entscheidende Dienste wie Authentifizierung und Zugriffskontrolle müssen zentral bereitgestellt werden bzw. zentral gesteuert werden können.

Anstelle von Anwendungs-spezifischen Security-Implementierungen sollten hier eher Ansätze wie Security-as-Infrastructure oder Security-as-a-Service verwendet werden. Ein typischer Vertreter ist der OASIS-Standard XACML (Extended Access Control Markup Language), der sowohl eine Architektur als auch ein Processing-Modell für die Auslagerung der Zugriffskontrollentscheidungen vorgibt.

Seite 2: Ohne Security keine SOA in geschäftskritischen Bereichen!

Ohne Security keine SOA in geschäftskritischen Bereichen

Doch damit allein ist die Arbeit längst noch nicht getan. Wo liegen die Herausforderung bei der Klammer zwischen SOA und Security? Auch die Service-orientierten Architekturen werden von traditionellen Security-Themen wie Authentifizierung, Zugriffskontrolle, Nachrichtenschutz, Auditing oder Key-Management bestimmt. „Diese Themen unterliegen aber aufgrund der SOA-spezifischen Merkmale besonderen Herausforderungen“, räumt der Experte von Beta Systems Software ein.

Eine dieser spezifischen Hürden ist etwa der hohe Grad der Verteilung von verschiedenen Komponenten (Distribution). Des Weiteren ist die große Heterogenität aufgrund des Zusammenspiels von unterschiedlichen Produkten, Herstellern und Systemen zu nennen. Dies erfordere wiederum ein hohes Maß an Standardisierung, um eine Interoperabilität zu gewährleisten. Zudem erfolge die Integration (Composition) der einzelnen Komponenten erst auf Kundenseite und lasse sich daher nicht - wie sonst bei monolithischen Anwendungen der Fall - vorab ausreichend im Entwicklungslabor testen.

Das Zusammenspiel von unterschiedlichen Anwendungs- und Security-Domänen erfordert also neue „föderierte Lösungen“, wie die Experten dies im Fachjargon bezeichnen. Dies bedeute, dass ohne Security eine SOA in geschäftskritischen Bereichen nicht betrieben werden könne, betont Sturm. Dabei sei der Aspekt IT-Sicherheit nicht nur als reine technologische Domäne zu verstehen, sondern zunehmend auch als geschäftskritisches Element zu betrachten. „Composition und Federation sind dabei Key-Treiber in einer SOA und somit im Security-Kontext zu unterstützen“, so der Experte.

Welche Lösungsansätze bereit stehen, um die komplexe Thematik sowohl technisch als auch organisatorisch bis hin zur Sensibilisierung und Bewusstseinsbildung (Awareness) zu dominieren, auch für diesen „Link“ kann Sturm eine klare Zielrichtung vorgeben. Technische Optionen gilt es zunächst unter einem besonderen Blickwinkel zu evaluieren. Mittlerweile gibt es am Markt bereits eine große Anzahl an Spezifikationen, die die besonderen Facetten der SOA-Security behandeln und entsprechende interoperable Lösungsvarianten vorgeben.

In vielen Fällen ist nach Auffassung von Detlef Sturm der Reifegrad für einen Praxiseinsatz ausreichend. „Leider fehlt im organisatorischen Umfeld nach wie vor das Verständnis für die SOA-spezifische Security.“ Die gute Nachricht lautet aber: Diesen latenten Missstand haben mittlerweile auch die großen Hersteller von SOA-Plattformen bereits erkannt. Sie stellen neben ihren Anwendungen zusätzlich umfangreiche Best Practices bereit, mit Blick auf das jeweils präferierte Vorgehensmodell.

Seite 3: Noch viel Arbeit für die Spezialisten

Noch viel Arbeit für die Spezialisten

Trotz dieser graduellen Fortschritte wartet aber auf die Spezialisten immer noch viel Arbeit. Denn vieles hängt auch mit der Wahrnehmung von neuen Themen im Umfeld der SOA-Security ab. „Die Entwickler von Webservices müssen das Outsourcing von nichtfunktionalen Eigenschaften aus ihrem Code akzeptieren und dafür neue Schnittstellen bereitstellen bzw. nutzen“, bilanziert Sturm. Um zentrale, föderierte Ansätze in der IT-Infrastruktur zu adressieren, gebe es noch viel Aufklärungsarbeit zu leisten, um ein konsistentes Grundverständnis in dieser komplexen Thematik herzustellen.

Praktikable Referenzmodelle und Standards, mit deren Hilfe sich die Verschmelzung zwischen SOA und Security besser bewältigen lässt, können dabei weiter helfen. Immerhin stellen die wichtigen großen Spieler auf dem Markt für SOA-Lösungen bereits jeweils eigene SOA-Security-Referenzmodelle bereit. Standardmäßig kann aber auch die ISO 7498-3 „Information Security Architecture“ herangezogen werden.

Weiterhin definieren einige WS-Standards bereits eigene Architekturlösungen. Viele SOA-Security-Referenzmodelle sind in die Blöcke „Business-orientierte Security-Services“ bzw. „IT-orientierte Security-Services“ unterteilt. „Die Brücke zwischen den beiden Blöcken wird durch ein Policy-Management realisiert“, so Sturm weiter.

Der Trend, die Geschäftsprozesse mit Hilfe einer „Business Technology“ und einer modularen Modellierung auf Service-orientierten IT-Komponenten (Web Services) abzubilden, bestimme auch das Security-Umfeld. Hierbei nehme das Policy-Management eine maßgebende Rolle ein.

Rolle des CISO im Spagat zwischen Geschäft und Serviceorientierung

Was also müssen die Security-Verantwortlichen (CISOs) zur Orchestrierung der Web Service Security beachten, denn eine Schwalbe macht ja bekanntlich noch keinen Sommer. „Webservices müssen auf Basis von WS-Security abgesichert werden“, bringt Detlef Sturm auf den Punkt. Die Richtlinien (Policies) bezüglich Nachrichtenschutz, Authentifizierung und Zugriffskontrolle sollten demnach vom Unternehmen zentral verwaltet oder zumindest steuerbar sein.

„Ein zentrales Logging ist dabei essenziell“, so Sturm weiter. Dabei müsse die Möglichkeit bestehen, die Log-In-Informationen der verschiedenen Quellen zu korrelieren. Üblicherweise ergebe etwa die Orchestrierung von Webservices - z.B. durch Business Process Execution Language (BPEL) - wiederum einen neuen Webservice. Es sei dabei sicherzustellen, dass dieser neue Webservice den gleichen Security-Anforderungen unterliege wie seine „angezapften“ Datenquellen.

Seite 4: Fazit: SaaS die Lösung für SOA?

Fazit: SaaS eine mögliche Lösung für SOA

Wie kann man also die einzelnen Bausteine zu einem schlüssigen lösungsorientierten Gesamtkonzept verschmelzen, nach dem Motto weder zu wenig noch zu viel Sicherheit, in der fatalen Überzeugung „Security driven by Overdesign?“ Detlef Sturm vom Lösungsspezialisten Beta Systems Software AG plädiert dazu für das generelle Auslagern der Security-Implementierung mit Hilfe von Ansätzen wie „Security-as-Infrastructure“ oder „Security-as-a-Service“.

Das Auslagern verringere die Gesamtkomplexität des Systems stark und sorge für eine Verschmelzung der einzelnen Bausteine zu gegenseitigen Unterstützung. Die Interaktion zwischen den einzelnen Komponenten erfolge über standardisierte Schnittstellen und Protokolle. „Policy-Management und Federated Identity and Access Management sind die Bausteine einer zukünftigen Steuerungszentrale“, fasst der Experte zusammen.

Wie sorgt das Unternehmen aber dafür, dass die auf dem Papier einmal festgelegten Policies auch sowohl von den Führungskräften als auch den Mitarbeitern umgesetzt bzw. eingehalten werden? Als zentrale Koordinierungsstelle für die Policies kommt hier kaum ein Unternehmen um geeignete „Governance-Maßnahmen“ herum. Diese gilt es jedoch zwingend, fortlaufend zu kommunizieren und zu überprüfen. Ansonsten besteht die Gefahr, im Unternehmen einen zahnlosen Papiertiger zu etablieren.

Zudem ist es nach Auffassung von Detlef Sturm wichtig, dass bereits bei der Webservice-Entwicklung ein „Design-Time-Governance“ zur Anwendung kommt. Sprich, die Verwaltung von Service-Artefakten wie Schnittstellendefinition, Deployment und SLA-Eigenschaften wäre zu adressieren. „Das operative Umfeld erfordert leistungsfähige Lösungen für das Monitoring, die entsprechend den jeweiligen Compliance-Anforderungen ein geeignetes Reporting anbieten“, sagt Detlef Sturm.

(ID:2020685)