SOA ohne IAM: Geht nicht!

Die Idee von SOA (Service-oriented Architecture) ist zwar nicht ganz neu, hat aber in den letzten beiden Jahren durch die Standardisierung im Bereich der Web Services stark an Bedeutung gewonnen. Mit SOA werden Anwendungen bezeichnet, bei denen (verteilte) Dienste zu neuen Applikationen kombiniert oder, wie es die Hersteller nennen, «orchestriert» werden.
Identity Management, oft auch als Identity and Access Management (IAM) bezeichnet, umfasst dagegen Technologien, mit denen man Identitäten verwaltet, die Authentifizierung und Autorisierung durchführt und Identitätsinformationen zwischen verschiedenen Systemen austauschen kann. Auch dieser Teil des IT-Markts erlebt derzeit einen Boom, weil die Herausforderungen unter anderem durch steigende Compliance-Anforderungen immer grösser werden.
Zwischen beiden Themenfeldern gibt es aber enge Verknüpfungen, wie ohnehin das Identity Management eine wichtige Basis nicht nur für service-orientierte Architekturen, sondern für moderne, flexible IT-Architekturen generell darstellt.

SOA und Federation

Die Umsetzung von service-orientierten Architekturen führt zu Anwendungen, die man als «lose gekoppelt» bezeichnen kann, weil man nicht mehr eine lokale Anwendung hat, sondern ein System, mit dem verschiedene verteilte Dienste verbunden werden. Diese lose Kopplung führt zu einigen Herausforderungen, wie man an den Initiativen der Systemmanagement-Hersteller in diesem Bereich gut erkennen kann. Sie führt aber auch zu Herausforderungen im Bereich der Sicherheit.
Wenn man Geschäftsprozesse nicht nur abbilden, sondern dies auch in sicherer Weise bewerkstelligen möchte, braucht man eine IAM-Infrastruktur. Denn die Zielsetzung muss sein, den Benutzern der neuen, dem SOA-Gedanken folgenden Anwendung sicheren Zugriff auf die Informationen über alle Dienste hinweg zu geben, so dass sie genau die Informationen sehen und bearbeiten können, die sie auch benötigen.

Dafür gibt es nun verschiedene Ansätze. Ein häufig zu findender Weg ist der, ein Sicherheitsmodell auf der Ebene der integrierenden Anwendung zu realisieren. Von dieser aus wird mit umfassenden Berechtigungen auf Dienste zugegriffen. Im Code der neuen SOA-Anwendung wird festgelegt, welcher Benutzer welchen Ausschnitt der so zu erreichenden Informationen zu sehen bekommt.
Das ist nicht neu. Solche unsicheren Lösungen finden sich zuhauf bei 3- und n-Tier-Architekturen. Applikationen, bei denen sich der Benutzer lokal authentifizieren muss und die Benutzer mehr schlecht als recht, oft auch noch mit unverschlüsselt abgelegten Kennwörtern, verwalten, sind leider keine Ausnahme. Und Anwendungen, bei denen beispielsweise auf Datenbanken mit vollen Zugriffsberechtigungen statt einer Pass-Through-Authentifizierung des Benutzers zugegriffen wird, sind eher die Regel. Das führt dazu, dass es unzählige Anwendungen mit eigenem
Sicherheits-«Konzept» gibt, die
in Wirklichkeit genau dieses vermissen lassen.

Die Gründe dafür sind vielfältig. Gerade in grossen Unternehmen werden Anwendungen oft von Fachbereichen in Auftrag gegeben, die zwar ihr konkretes Problem, aber nicht die Anforderungen der IT-Infrastruktur insgesamt im Blick haben. Ein zweites Problem sind Entwickler, die im Sicherheitsbereich nicht erfahren genug sind und die einfache Lösung wählen, statt nach zentralisierten und standardisierten Ansätzen zu suchen. Gerade von Entwicklern ist oft auch Widerstand gegen – auf Gesamtebene – bessere Lösungen zu erleben, weil das zu Einarbeitungsaufwand und vielleicht auch Mehrarbeit zumindest bei der ersten Umsetzung führen würde. Schliesslich liegt das Problem oft aber auch darin, dass es schlicht keine ausreichenden strategischen und operativen Vorgaben für die Umsetzung von Sicherheit bei eigenen Anwendungen gibt.
Im Übrigen muss die Sicherheitsintegration auch ein Auswahlkriterium für Anwendungen sein. Ein eigenes Benutzermanagement von Anwendungen ist eigentlich ein KO-Kriterium für die Auswahl.

Solche Ansätze führen zu erheblichen Problemen vor allem in Bezug auf die Erfüllung von Compliance-Anforderungen und damit generell auch im Bereich der Sicherheit. Man hat keine Kontrolle über die tatsächlichen Zugriffsberechtigungen von Benutzern und kann nicht nachvollziehen, wer genau nun auf welche Informationen in den Endsystemen wie beispielsweise Datenbanken zugreift. Und man kann die oftmals fest codierte Sicherheit der Anwendungen nicht von aussen steuern – was ginge, wenn man mit nach aussen exponierten Rollenmodellen arbeiten würde.
Dabei gibt es etliche Ansätze, das Problem zu lösen. Das Spektrum reicht von der Verwendung eines zentralen Verzeichnisdienstes bis hin zur Identity Federation. Vor allem letztere bietet sich im Zusammenhang mit service-orientierten Architekturen an, weil sie Web Services nutzt, standardisiert ist und letztlich zu einer losen Kopplung von Identitätsinformationen führt. Sie ist also das Gegenstück aus dem IAM-Bereich zu SOA und letztlich sogar in deren Folge bei der Weiterentwicklung der ersten Web-Service-Standards entstanden.

Identity Federation arbeitet im Kern mit der Trennung zwischen einem Identity Provider, bei dem die Identitätsverwaltung und die Authentifizierung erfolgen, und einem oder mehreren Service-Providern, die die Autorisierung für Zugriffe durchführen. Bezogen auf SOAs heisst das, dass die genutzten Dienste als Service Provider fungieren, während der Identity Provider beispielsweise ein zentrales unternehmensinternes System ist. Es erfolgt eine Authentifizierung. Auf die einzelnen Dienste wird aber im Kontext eines definierten Benutzers zugegriffen. Ergänzende Informationen wie die Rollenzugehörigkeiten lassen sich über die Federation-Protokolle flexibel austauschen. Genauso, wie die Dienste lose zusammengefügt werden, gibt es damit einen flexiblen Mechanismus für den Austausch aller im Zusammenhang mit Authentifizierung und Autorisierung relevanten Informationen.

Anwendungsverzeichnisse als Infrastruktur-Element

Über die Thematik der SOA hat IAM aber auch eine generelle strategische Bedeutung. Wie oben schon angesprochen, arbeiten viele Anwendungen heute mit eigenen Anwendungs-«verzeichnissen». Manchmal sind das wirklich Verzeichnisdienste, manchmal werden nur Benutzernamen und ein paar ergänzende Informationen in einer Datenbank gespeichert.

Das über längere Zeit von vielen Anbietern propagierte Ideal des einen zentralen Verzeichnisdienstes ist inzwischen gescheitert. Solche zentralen Strukturen werden zu komplex, um praktisch nutzbar zu sein. Selbst Microsoft hat sich mit der Ankündigung von ADAM als ergänzender Technologie für Anwendungsverzeichnisse von diesem Ansatz verabschiedet.
Um aber nun einen Wildwuchs zu verhindern, bei dem verschiedene Anwendungen unterschiedlichste Technologien nutzen, die später in der Administration und beim Sicherheitsmanagement nicht mehr beherrschbar sind, braucht man eine Strategie für Anwendungsverzeichnisse. Das heisst konkret, dass man einen einheitlichen Weg für den Zugriff definieren muss, wofür sich LDAP als bekanntester Mechanismus oder DSML als Web Service- und XML-basierende Variante anbieten.

Dahinter muss eine Infrastruktur von Verzeichnissen stehen, die zentral betrieben werden und die von Anwendungen genutzt werden können. Dabei sollte mit einem einheitlichen Verzeichnisdienst gearbeitet werden, der eine wichtige Anforderung erfüllen muss: Er muss in vielen kleinen Instanzen parallel auf einem Server ausgeführt werden können und entsprechend schlank sein. Um den Anwendungen einen einheitlichen Zugriff auf das spezielle Anwendungsverzeichnis und einen eventuellen weiteren Verzeichnisdienst wie das Active Directory oder eDirectory, der für die Authentifizierung verwendet wird, zu geben, muss darüber ein virtueller Verzeichnisdienst liegen, der aus Sicht der Anwendungen für einen einheitlichen Zugriff sorgt.

Infrastrukturen für die Anwendungssicherheit

Damit erhält man im Ergebnis ein Kernelement einer Anwendungssicherheitsinfrastruktur. Anwendungen können standardisiert Benutzer und erweiterte Objekte und Attribute in Verzeichnissen verwalten. Und sie können bei der Authentifizierung und Autorisierung flexibel über Federation-Mechanismen mit anderen Systemen zusammenarbeiten, auch ausserhalb des Unternehmens.

Ohne eine solche Anwendungssicherheitsinfrastruktur, für die in diesem Artikel Kernelemente skizziert wurden, ist jede Investition, die man heute in die Entwicklung eigener Anwendungen tätigt, eine Fehlinvestition. Man muss sich heute intensiv mit solchen Infrastrukturen auseinandersetzen und dabei insbesondere über neue technische Möglichkeiten – und hier konkret virtuelle Verzeichnisdienste und die Identity Federation – nachdenken. Dass dabei Auseinandersetzungen mit Fachbereichen, die Investitionen in Anwendungen tragen und die vermeintlich höheren Kosten scheuen, unvermeidbar sind, ist klar. Auf Unternehmensebene sind die Kosten aber durch die grössere Sicherheit, die besseren Administrationsmöglichkeiten und die Chance, auch neue und komplexe Compliance-Anforderungen erfüllen zu können, aber mittelfristig deutlich niedriger als ohne Anwendungssicherheitsinfrastruktur.

Kurz gesagt: Wer keine geeignete IAM-Infrastruktur und keine klare IAM-Strategie hat und diese nicht mit seiner Strategie für die Anwendungsentwicklung in Übereinstimmung bringt, wird im besten Fall unsichere und kaum zu administrierende Anwendungen bekommen, im schlimmsten Fall aber nicht kontrollierbare Sicherheitslücken und Fehlinvestitionen zu verzeichnen haben. Hier liegt heute eine der Kernaufgaben für CIOs, die es zu lösen gilt.





Prozessübergreifendes Identity Management