Vielfalt der Identitäten

Es ist heute für den IT-Verantwortlichen sehr wichtig, dass er zum einen die laufenden Systeme gut betreut. Doch fast genauso wichtig ist der Blick nach vorne. Die Identity-Infrastruktur im Unternehmen muss alle Vorteile dieser neuen Technologien nutzen können – wo immer es für das eigene Geschäft als sinnvoll erscheint.

Dabei sind aber in der Regel mehrere Faktoren zu beachten: Die Informationssicherheit und die Einsparungen in verschiedenen Bereichen gelten dabei als wichtige Parameter. Eine zentrale Rolle fällt dabei dem Active Directory zu, das mittlerweile auch mit den Claims-basierten Konzepten gut zusammenspielt.

Wer sich im Unternehmen mit professionellen Identity-Systemen auseinandersetzen muss, der steht in der Regel vor einer großen Herausforderung: Es ist meistens nicht nur ein einziges Identity-System, wie etwa das Active Directory (AD), im Einsatz. Überlicherweise gilt es ein ganzes Sammelsurium innerhalb eines Unternehmens zu betreuen. Und oftmals gehört es dann zu den dringlichsten Aufgaben, all diese Systeme so zusammenzubinden, dass sie für alle Applikationen kohärent ihre Dienste erbringen.

Noch komplexer wird diese Angelegenheit, wenn modern Lösungen nach dem Motto Software as a Service (SaaS) mit einzubeziehen sind. Die Akzeptanz dieser Lösungen stellt die internen Bereich der IT vor weitere Herausforderungen, den der sichere Zugriff auf diese SaaS-Anwendungen muss mit dem bestehenden Identity-Konzept zusammenpassen. Wer da erfolgreich sein möchte, der muss mehrere SaaS-Provider – mit ihren unterschiedlichen Typen von Diensten oder Anwendungen – in die bestehende Identity-Umgebung integrieren können und dabei sozusagen noch eine “verwobene Identity-Umgebung” bereitstellen. Ist eine derart verwobene Umgebung erst einmal erstellt, muss der “Fluss der Identitäten“ in diesem Konstrukt funktionieren.

In diesem Beitrag geht es zunächst um die wichtigsten Knoten in diesem Konstrukt. Vor allem die Verbindungspunkte der einzelnen Systeme sind dabei sehr interessant. Selbst wenn man in seiner eigenen Umgebung nicht alle hier aufgeführten Bestandteile zu berücksichtigen hat, wird man doch mit den meisten davon umgehen können müssen. Denn es kann ja auch in der Zukunft dazu kommen, dass es weitere Komponenten einzubauen gilt.

In der Abbildung  sind die einzelnen Komponenten und der Datenfluss zwischen ihnen zu sehen. Dabei ist dieses Bild nicht dazu gedacht, eine typische Produktivumgebung wiederzugeben. Zum Beispiel würde der Identity Provider Federation Service  keinen Input von einem VDS (Virtual Directory Service) und dem AD bekommen. Denn die wichtigste Aufgabe eines VDS ist das Minimieren von Identity-Verbindungen. Es geht hier eher darum, dass man alle Knoten sich ansehen kann und erkennen kann, welchen typischen Input und Output es dabei gibt.

Kernkomponente Active Directory

Das AD stellt bei den meisten Unternehmen das Fundament für ihre Identity-Infrastruktur dar. Es ist eine universelle Identity-Quelle in einem Unternehmen. Weltweit gesehen ist das AD bei 75 Prozent aller Unternehmen mit mehr als 500 Mitarbeitern installiert beziehungsweise es arbeitet als das zentrale Verzeichnis. Zudem wird es weiterentwickelt, um die Anforderungen von modernen Applikationen oder Diensten zu erfüllen. Beim Windows Server 2012 wird zum Beispiel die Virtualisierung ohne irgendwelche Einschränkungen unterstützt. Zudem kommt die Unterstützung von Claims mit dazu.

Somit ist das AD eine Anwendung, mit der jede IAM-Applikation (Identity and Access Management) umgehen können muss. Denn es wurde enorm viel in das AD aber auch in die AD-integrierten Anwendungen sowie in die zugehörige Hardwareausrüstung, die Zusatzsoftware aber auch die internen Prozesse im Zusammenhang mit dem AD investiert. Ein weiterer Grund für ein AD, das im eigenen Unternehmen installiert ist, ist die Einstellung:

Der Kern einer Identity-Lösung sollte im eigenen Unternehmen liegen. Diese Leitlinie wird sich auch in der nächsten Zeit nicht so schnell ändern. Das AD ist in größeren Unternehmen die Informationsquelle für einzelne Identitäten im Unternehmenskontext. Dazu gehören zum Beispiel die Computerkonten oder die Sicherheitsgruppen. Doch andere Objekte – wie etwa die Benutzerkennungen und zugehörige Attribute wie die Mitarbeiternummern, stammen in der Regel von einem übergeordneten HR-System (Human Resources).

Bei den HR-Systemen handelt es sich um dringend erforderliche Anwendungen in Unternehmen, um alle Informationen zu einem Mitarbeiter zu bündeln. Daraus resultiert auch ein höherer Sicherheits- und Vertraulichkeitsanspruch – diese Systeme gelten daher als sehr sensibel. Das ist auch der Grund, warum sie üblicherweise auch keine Aktualisierungen aus anderen Systemen – wie etwa dem AD – zulassen. Andere Anwendungen wie Datenbanken, die für die physische Sicherheit zuständig sind (und die zum Beispiel für das Ausstellen von Zutrittsausweisen – Badges – für Besucher in einem Unternehmen herangezogen werden), verfügen mitunter über ihre eigenen einzigartigen Identitäten – und haben daher unterschiedliche Anforderungen an den Grad der Kommunikation mit dem AD.

Metadirectory Services

Der Einsatz von Metadirectory Services hat sich als ein guter Weg herauskristallisiert, Objekte und Attribute au seiner Vielzahl von Identity-Quellen in ein umfassendes Metadirectory zusammenzuführen. Von dieser Stelle aus werden dann die einzelnen Informationsquellen wieder aktualisiert und auch die anderen Applikationen mit den daten gefüttert, die sie im Identity-Umfeld benötigen.

Der Vorteil eines Metadirectory liegt auf der Hand: Damit lassen sich quasi alle Attribute von einer Identity-Informationsquelle zu allen anderen oder zu den Applikationen durchreichen. Doch das ist nicht einfach zu erreichen: Aufgrund des Aufwands für die Implementierung und den laufenden Betrieb (inklusive des Supports) für den Metadirectory Service kommen diese Systeme meist nur in großen Unternehmen zum Einsatz.

Aber sie passen in der bereits skizzierten Identity-Infrastruktur (dem “verwobenen Identity-Konstrukt”, siehe Abbildung) gut in das Zentrum – denn sie binden sowohl die Informationsquellen im Bereich der Identity als auch die Informationskonsumenten (also die Applikationen) zusammen.

Virtual Directory Server liefern abstrahierte Sicht

Ein anderer Weg, eine aggregierte Sicht von Objekten und Attributen aus verschiedenen Identity-Informationsquellen zu bieten, ist der Einsatz von VDS (Virtual Directory Servers). Anstelle die Informationen zum Bereich Identity in regelmäßigen Abständen aus allen Quellen in einem Metadirectory zusammenzufassen und danach die Daten an die betreffenden Stellen zu verteilen, erzeugt ein VDS einen “Einblick” in diese Identity-Informationsquellen.

Bei diesem “Blick” handelt es sich eigentlich um eine Abstraktion – sie erscheint für die betreffende Applikation als ein einziges Verzeichnis. Gibt eine Applikation eine Anfrage an dieses Interface heraus, erstellt der VDS in Echtzeit Anfragen an die betreffenden Identity-Quellen – nutzt dabei eventuell auch noch spezielle Caching-Techniken – und gibt dann die gewünschten Daten an die Applikation.

Da der VDS eine gewisse Abstraktionsschicht einzieht, benötigt die Applikation keine spezielle Logik, um herauszufinden, welche Informationsquelle für die gewünschten Attribute zuständig ist. Die VDS-basierten Lösungen erweisen sich in der Praxis als einfacher und vor allem auch als billiger als der Einsatz von Metadirectory Services und haben daher auch mehr Anhänger. Sie passen ebenfalls sehr gut in das Zentrum eines “verwobenen Identity-Konstrukt”.

Web Access Management einbeziehen

Viele Unternehmen haben seit längerem WAM-Systeme (Web Access Management) im Einsatz, mit denen neue Identity-Lösungen zu integrieren sind. Die WAM-Lösungen bietet Authentifizierung und Authorisierung aus einer oder mehreren Identity-Informationsquellen – sowohl für nach innen als auch nach außen gerichtete Webservices. Der meistgenutzte Fall dieser Lösungen ist die Zugriffsberechtigung auf externe Webservices – diese Funktionalität liegt meistens auf der Unternehmens-Firewall. Diese in Haus eingesetzten Systeme sind sehr eng mit vielen Identity-Informationsquellen verknüpft, nutzen aber normalerweise keine der neuen Techniken (wie etwa einen VDS), um diese Integrationsaufgaben zu vereinfachen.

Spezielle Dienste für das Synchronisieren von Verzeichnissen gelten als eine gute Lösung, wenn man Identity-Daten duplizieren muss – etwa wenn diese Informationen aus einem Unternehmen auch bei einem Cloud Service Provider vorliegen müssen.

Ein Ableger der Synchronisierungsfunktion eines Metadirectory-Servers, also ein Verzeichnissynchronisationsdienst, ist ein schlanker Prozess, der auf einem Server installiert ist. Damit wird ein Speicher für die Identity-Informationen, wie etwa das AD, überwacht und dabei Änderungen herausgefiltert. Dann werden diese Modifikationen sofort repliziert und dann an den zugehörigen Cloud-Dienst übertragen.

Einweg-Synchronisation in die Cloud

Dabei handelt es sich um eine Einweg-Synchronisation: Der Identity-Speicher in der Cloud spiegelt die Inhalte des Identity-Speichers im Unternehmens – oder aber eine definierte Untermenge (wie etwa eine Organisationseinheit – OU, Organizational Unit oder eine Sicherheitsgruppe). Diese Art der Verzeichnissynchronisation wird von SaaS-Lösungen wie Microsofts Office 365 oder Google Apps genutzt. Aber auch “Identity as a Service” Provider (IDaaS) verwenden diesen Ansatz, um ihren Identity-Speicher zu füllen. Kennwörter dürfen dabei mit den Inhalten im Identity-Speicher in der Cloud synchronisiert werden – oder man kann diese Funktion auch ausschließen. Das ist abhängig vom jeweiligen Anbieter und von der gewünschten Konfiguration.

Das Prinzip der Federation

Ein weiterer wichtiger Punkt der Identity-Infrastruktur im eigenen Haus ist der Federation Service. Dieser Dienst agiert als eine Brücke zwischen Sicherheitsprotokollen wie Kerberos (wie es beim AD eingesetzt wird) und den Claims-basierten Protokollen (wie etwa dem SAML, der Security Assertion Markup Language, die bei den Applikationen zum Einsatz kommt, die mit Claims zusammenspielen).

Ein Federation-Dienst überführt die Token zwischen den verschiedenen Sicherheitsdomänen und gilt somit als ein wichtiger Bestandteil, wenn es um die Verbindung mit Applikationen aus der Cloud geht. Im Bereich der Identity-Infrastruktur sind die Federation-Dienste mit einer oder mehreren Identity-Quellen verbunden. Dabei stellen sie Token für die Claims-basierten Anwendungen bereit, die sich entweder bei einem Service Provider in der Cloud oder auch im eigenen Haus befinden können.

Doch ein Unternehmen muss den Federation-Dienst nicht im eigenen Haus betreiben. Es gibt auch Anbieter, die „IDaaS Provider“, die diese Aufgabe in einem Outsourcing-Modell übernehmen. Damit hat man eine zusätzliche Stelle im Einsatz, die sich um die Themen Autentifizierung und Authorisierung für eine Vielzahl von SaaS-Anwendungen kümmern kann. Die meisten Dienste bieten dazu auch ein SSO (Single Sign-On) für Service Provider an, die keine Federation-Dienste für ihre eigenen proprietären Methoden zur Verfügung stellen.

Ob man nun als Identity Provider oder als Service Provider agiert, hängt vom jeweiligen Blickwinkel ab. Die meisten werden zwar interne IT-Systeme zu unterstützen haben. Doch ein Service Provider mit seinem eigenen Identity-Speicher für die Anwender seines Dienstes (wenn zum Beispiel eigene Konten am Standort des Service Providers erzeugt werden müssen), ist auch ein Identity Provider. Und ein Identity Provider im Unternehmen, der eine Anwendung für seine Geschäftspartner – in einem B2B-Modell – bereitstellt, der hat auch die Rolle eines Service Providers. Diese Möglichkeiten machen die generelle Aufgabe noch komplexer.

Zudem kommen noch weitere Identity Provider ins Spiel: Viele Anwender nutzen Facebook, Google, Twitter und ähnliches, um ein SSO bereitzustellen. Zukünftig wird man diese Provider auch in den Unternehmensumgebungen einziehen sehen – etwa wenn man SSO für Kundendienst-Portale aufzubauen hat.

Sean Deuby