ASI: sichere Anwendungen mit standardisierten Infrastrukturen

Ein seit einiger Zeit diskutiertes, viel zu selten umgesetztes Thema sind Anwendungssicherheits-infrastrukturen. Dahinter verbirgt sich das Ziel, Sicherheit aus dem Anwendungscode zu "externalisieren" und von außen einfach steuerbar zu realisieren.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 14 Min.
Von
  • Martin Kuppinger
  • Alexander Neumann
Inhaltsverzeichnis

Ein seit einiger Zeit diskutiertes, in der Praxis viel zu selten umgesetztes Thema sind Anwendungssicherheitsinfrastrukturen. Hinter dem sperrigen und ungenauen Begriff verbirgt sich das Ziel, Sicherheit aus dem Anwendungscode zu "externalisieren" und von außen einfach steuer- und nachvollziehbar zu realisieren.

Der Begriff Anwendungssicherheitsinfrastrukturen (Application Security Infrastructures; ASI) hat sich durchgesetzt, auch wenn in ihrem Mittelpunkt eine Serviceschicht für Governance, Identitäts- und Zugriffsmanagement und ergänzende Sicherheitsfunktionen steht. Dass diese Services von einer geeigneten Infrastruktur zu liefern sind, steht außer Frage, doch geht es im Kern nicht um die Infrastruktur, sondern um die Serviceschicht. Anwendungen können die Services nutzen, dafür grundlegende Funktionen wie die Authentifizierung oder eine Rollen-Autorisierung von Benutzern zu ersetzen.

Durch einen Service Layer zwischen Anwendungen und IT-Infrastruktur kann man mit standardisierten, wiederverwendbaren Sicherheitsdiensten arbeiten (Abb. 1).

Am einfachsten verdeutlicht ein Beispiel, das in vielen Unternehmen in dieser oder ähnlicher Weise immer wieder auftritt, das Konzept: Entwickelt man eine neue Anwendung im Auftrag eines Fachbereichs, ist es oft erforderlich, einige spezifische Informationen zu den Benutzern der Anwendung zu speichern. Das können bestimmte Funktionen im Job, zusätzliche Kontaktdaten oder, bei externen Benutzern, erweiterte Adresseninformationen sein. Die Informationen sind in einem für die primäre Netzauthentifizierung verwendeten Verzeichnisdienst wie Microsoft Active Directory oder Novell eDirectory oft nicht vorhanden und auch als entsprechende Attribute nicht vorgesehen.

Der naheliegende Ansatz wäre, das Schema (also das Datenmodell) des verwendeten Verzeichnisdienstes zu erweitern. Das stößt zunächst häufig auf Ablehnung bei den verantwortlichen Administratoren. Schema-Erweiterungen sind nicht trivial in ihrer Umsetzung und haben Einfluss auf die Performance und den benötigten Speicherplatz des Verzeichnisdienstes. Die Diskussionen darüber führen oft dazu, eine eigenständige Lösung für die Anwendung zu realisieren – falls es überhaupt zu einer solchen Diskussion kommt.

Das Resultat eigenständiger Lösungsansätze sind proprietäre Anwendungsverzeichnisse, in denen man die erforderlichen Benutzerinformationen speichert. Im besten Fall lässt sich dafür ein externes LDAP-Verzeichnis nutzen, oft handelt es sich aber nur um eine oder mehrere Datenbanktabellen. Solche Anwendungsverzeichnisse sind sowohl unter dem Aspekt der Administration als auch der Nachvollziehbarkeit problematisch – mehr dazu weiter unten.

Eine Alternative dazu wäre, für Anwendungsentwickler einen Satz von Diensten bereitzustellen, über die sie Attribute speichern, lesen und ändern können. Dafür sind einfache Standard-Schnittstellen wie LDAP (Lightweight Directory Access Protocol), DSML (Directory Service Markup Language, faktisch eine Webservices-Variante von LDAP) oder SQL zu verwenden, Letzteres mit dem Vorteil, dass es in der Softwareentwicklung verbreitet und einfach zu nutzen ist. Der Entwickler muss "nur" über eine Infrastruktur verfügen, die diese Dienste unterstützt.

Ein Beispiel für die Umsetzung sind Dienste für die Speicherung von Attributen in unterschiedlichen Verzeichnissen (Abb. 2).

In diesem Fall könnte das eine Kombination aus einem virtuellen Verzeichnisdienst (Virtual Directory Service), einem Provisioning-System und einem oder mehreren zentralen Verzeichnisdiensten sein. Ein virtueller Verzeichnisdienst kann virtuelle Verzeichnisse erzeugen. Aus Sicht der zugreifenden Anwendung handelt es sich um ein Verzeichnis. Dahinter können aber auch mehrere Verzeichnisse liegen, aus denen die Daten beim Zugriff zu holen und zusammenzusetzen sind. Damit kann man einfach für jede Anwendung eine individuelle Verzeichnisstruktur mit exakt den benötigten Informationen erzeugen, die beispielsweise teils im Active Directory, teils in einem zusätzlichen LDAP-Verzeichnis mit den ergänzenden, anwendungsspezifischen Attributen liegen.

Da virtuelle Verzeichnisdienste primär auf lesende Operationen ausgelegt sind, bietet sich für die Änderungsvorgänge die Verwendung eines (oft ohnehin schon vorhandenen) Provisioning-Systems an, das sie gezielt auf mehrere Verzeichnisse verteilt.

Mit einer solchen Kombination aus Diensten und darunter liegenden Infrastrukturelementen sowie den erforderlichen Prozessen für die Beschreibung und Anforderung eines Services durch einen Anwendungsentwickler erhält man eine vereinheitlichte Infrastruktur und macht es gleichzeitig den Entwicklern durch die Bereitstellung von einfach nutzbaren Diensten einfacher.