Seite 4: Anbieter

Inhaltsverzeichnis

Anbieter

Eine grundlegende Frage ist, ob man eine solche Anwendungssicherheitsinfrastruktur selbst definiert oder ob man auf Ansätze von Anbietern setzt. Es gibt im Markt derzeit vier große Gruppen von Herstellerlösungen.

Das beginnt bei Grundfunktionen und Erweiterungen zu Anwendungsinfrastrukturen, wie sie bei IBM WebSphere und anderen Anwendungsservern zu finden sind. Diese Gruppe ist allerdings zunehmend weniger zu trennen von den Ansätzen anderer IT-Anbieter, die oftmals um diese Anwendungsplattformen herum Konzepte für die Externalisierung der Sicherheit und damit von Anwendungssicherheitsinfrastrukturen definieren.

Oracle hat die Service-oriented Security (SOS) definiert, die unterschiedliche Module wie den von BEA übernommenen Entitlements Server enthält. SAP setzt auf die NetWeaver Identity Services. CA hat ein eigenes Produkt für das Management von Entitlements, und Microsoft erweitert die Funktionen in seinem .Net-Framework unter anderem im Rahmen des Geneva-Ansatzes.

Daneben gibt es etliche spezialisierte Anbieter. Einige Provisioning-Hersteller wie Beta Systems und iSM haben eigene APIs, die im Rahmen solcher Anwendungssicherheitsinfrastrukturen zu verwenden sind. Spezialisten wie Engiweb und Bitkoo bieten Engines für die Externalisierung der Autorisierung (und anderer Funktionen) an.

Schließlich gibt es Produkte für das Web Access Management, die solche Funktionen für Webanwendungen und oft auch für Enterprise-Java-Anwendungen bereitstellen und die Authentifizierung ebenso wie die Autorisierung auslagern können. Die Idee ist keineswegs neu: IBM hat schon 1976 mit RACF (Resource Access Control Facility) eine Lösung für IBM-Mainframes eingeführt, die auf die Externalisierung von Authentifizierung und Autorisierung zielt. Klar ist aber, dass derzeit praktisch kein Anbieter – wenn man vielleicht von Oracles recht weit gediehenem Konzept der SOS absieht – alle Bereiche abdeckt, die eine Anwendungssicherheitsinfrastruktur umfassen sollte.

Risiko "Vendor Lock-in"

Das offensichtliche Risiko all dieser Ansätze ist die Abhängigkeit von Anbietern. Das gilt umso mehr, weil es um Anwendungen geht. Wenn man im Code der Anwendungen spezifische Anpassungen für die Dienste einzelner Anbieter durchführt, dann gestaltet sich der Wechsel auf andere Anwendungsplattformen oder andere externe Lösungen für die Anwendungssicherheit immer schwieriger. Wenn man dafür Änderungen im Code von womöglich dutzenden oder gar hunderten Anwendungen vornehmen muss, ist das kaum noch zu realisieren.

Es spricht daher viel dafür, eine eigene Schicht zu definieren und darüber gegebenenfalls auf proprietäre Ansätze der Hersteller zuzugreifen. Damit erhält man sich die nötige Flexibilität. Natürlich ist der konzeptionelle Aufwand in diesem Fall höher als bei der Nutzung eines Herstellerkonzepts, und eine Zwischenschicht erfordert immer zusätzlichen Aufwand. Dafür erhält man sich gerade in einem Themenfeld, in dem einerseits die Probleme der Herstellerabhängigkeit besonders groß sind und das andererseits noch lange nicht ausgereift ist, die erforderliche Flexibilität. Zudem geht es nicht nur darum, Anwendungen flexibel zu halten, sondern auch die Infrastruktur optimal gestalten zu können. Hier sollte man sich möglichst wenig an einzelne Anbieter binden.

Anwendungssicherheitsinfrastrukturen – ein Muss

Trotz aller Herausforderungen lässt sich festhalten: ASI sind ein Muss. Man sollte sich aus vielen Gründen mit dem Thema auseinander setzen. Letztlich ist die Realisierung einer ASI ein zwingendes Element in jedem Konzept für IT-Governance. Und gerade der Trend hin zu serviceorientierten Architekturen gestaltet die Nutzung solcher Modelle immer einfacher.

Martin Kuppinger
ist Gründer und Senior Analyst bei Kuppinger Cole, einem auf IAM, GRC, Cloud Computing und verwandten Themen spezialisierten Analystenunternehmen. Er hat langjährige Erfahrung auch in der Softwarearchitektur.