Identity- und Access-Management (IAM) bezeichnet die Dienste zum Verwalten digitaler Identitäten und die Zugriffssteuerung auf Ressourcen. Die deutsche Übersetzung "Benutzer- und Berechtigungsmanagement" ist dabei deutlich zu eng, weil sie nur Teilaspekte von IAM abdeckt und in erster Linie auf die Verwaltung von Benutzerkonten und Berechtigungen von Mitarbeitern ausgerichtet ist. IAM umfasst beispielsweise auch das Management von Kunden und Partnern ebenso wie von Identitäten von Geräten, vernetzten Dingen und Diensten. Auf der funktionalen Ebene geht es nicht nur um die Benutzerverwaltung und das Berechtigungsmanagement, sondern auch um die Zugriffssteuerung beispielsweise mit starker, kennwortloser Authentifizierung oder um das Management privilegierter Zugriffe.

IAM hat sich in den letzten beiden Jahrzehnten stark verändert und weiterentwickelt. Diese Veränderung ist einerseits funktional mit vielen neuen und erweiterten Diensten, andererseits durch die viel größere Zahl an Identitätstypen geprägt. Mit dezentralen Identitäten und ihrem Zusammenspiel mit IAM wird diese Entwicklung auch künftig weitergehen. Besonders deutlich zeigte sich die Veränderung vor gut zehn Jahren, als das Thema CIAM (Consumer/Customer IAM) aufkam und separate Lösungen für eine neue Gruppe von Identitäten umsetzte. In letzter Zeit rückten dann auch die B2B-Identitäten entlang der Wertschöpfungskette (Supply Chain) in den Fokus. Mit weiteren Identitätstypen und wachsenden funktionalen Anforderungen und Möglichkeiten zeigte sich, dass es nicht zielführend ist, die verschiedenen Anforderungen und Teilbereiche isoliert anzugehen.

Erschwerend kommt hinzu, dass mit dieser Entwicklung oft auch getrennte organisatorische Zuständigkeiten verbunden sind. Das gilt für Workforce IAM (Mitarbeiter) und CIAM (Kunden, Konsumenten), aber teilweise auch immer noch für Identitäts- (Identity) versus Zugriffsmanagement (Access). Auch PAM (Privileged Access Management) für hochprivilegierte Zugriffe ist in manchen Organisationen noch in einer anderen Zuständigkeit, vom Berechtigungsmanagement für Geschäftsanwendungen wie zum Beispiel SAP-Systemen ganz zu schweigen. Sehr häufig ist auch das Microsoft Active Directory nicht in der Zuständigkeit des IAM-Bereichs, sondern beispielsweise der IT-Infrastruktur oder des Workplace-Managements, obwohl es in erster Linie ein System für das Verwalten von Benutzern und Berechtigungen ist. Selbst Microsoft Entra ID ist nicht immer dem IAM-Bereich zugeordnet, obwohl es – im Gegensatz zum AD, das auch Infrastruktur- und Endpoint-Management-Funktionen wie Gruppenrichtlinien integriert – ausschließlich ein System zur Verwaltung von Identitäten und ihrer Authentifizierung ist.

Diese häufig vorzufindenden organisatorischen Trennungen oder nicht (mehr) sinnvollen Zuordnungen von bestimmten Funktionen erschweren eine zielgerichtete Integration und Weiterentwicklung von IAM, erzeugen hohe organisatorische Aufwände und teilweise auch Mehrfachinvestitionen, führen zu erhöhten Integrationskosten und stellen insbesondere auch ein Sicherheitsrisiko dar.

IAM ist ein Kernbaustein jedes Cybersicherheitskonzepts. Sicherheit beginnt bei der digitalen Identität, egal welcher Art diese ist, und diese gilt es zu verwalten. Berechtigungen sind zu steuern, Zugriffe bedürfen der Authentifizierung und Analyse, um Bedrohungen zu erkennen, und sie müssen zudem nachvollziehbar sein. Cybersicherheit braucht ein modernes, leistungsfähiges und integriertes IAM, das auch die Grundvoraussetzung für die Umsetzung jedes Zero-Trust-Konzepts ist. Die Identity Fabric liefert ein Modell für ein solches IAM-Gesamtkonzept.

Das vor mehreren Jahren von KuppingerCole-Analysten vorgestellte Konzept der Identity Fabric hat inzwischen breite Akzeptanz gefunden und wird von vielen Anwenderunternehmen, Herstellern, Beratern und Analysten genutzt. Die Basis für das Modell war die Frage, was IAM eigentlich leisten muss. Die Antwort ist letztlich einfach: IAM soll dafür sorgen, dass jeder Nutzer und jedes Gerät reibungslosen, aber sicheren und nachvollziehbaren Zugriff auf jeden digitalen Dienst erhält. Hinter dieser einfachen und kurzen Antwort stehen viele spezifische Anforderungen, die klassische IAM-Umsetzungen oft nicht oder nur unzureichend abdecken. Es gilt also einerseits, die Dienste für Identitäten und ihre Zugriffe bereitzustellen und andererseits die Integration von verschiedenen IAM-Diensten. Die Identity Fabric leistet beides: Sie integriert IAM-Funktionen und stellt die erforderlichen IAM-Dienste bereit.

Die Gesamtsicht über alle IAM-Funktionen, alle Identitäten und alle Zielsysteme, auf die ein Zugriff erfolgt, ist ein zentrales Merkmal einer Identity Fabric. Es lassen sich innerhalb einer solchen dann durchaus auch Ausschnitte betrachten, also beispielsweise die Funktionen für Kundenidentitäten. Es gibt aber keine "Consumer Identity Fabric", weil ein wesentliches Merkmal der Identity Fabric eben ist, dass sie alle Arten von Identitäten unterstützt. Betrachten lassen sich aber durchaus "Control Planes" für verschiedene Anforderungen wie das Management von Identitäten, die Authentifizierung und Autorisierung von Zugriffen oder die Verwaltung von Richtlinien und Regeln für die Zugriffssteuerung innerhalb einer Identity Fabric. Damit gelangen wir aus der generischen Sichtweise zu konkreten Aufgabenstellungen und Funktionen.

Ganz wichtig ist, dass die Identity Fabric ein Konzept für eine Gesamtsicht auf IAM ist, aber nicht determiniert, ob die verschiedenen Funktionen von wenigen oder vielen technischen Produkten erbracht werden. Wesentlich ist die Fähigkeit zur Integration und Orchestrierung verschiedener technischer Komponenten. Eine Identity Fabric lässt sich aber ebenso gut auf Basis einer weitgehend integrierten IAM-Suite oder durch die Kombination von Best-of-Breed-Werkzeugen für verschiedene Teilfunktionen umsetzen – hier gibt es nicht den einen richtigen Ansatz. In den allerwenigsten Fällen basiert eine Identity Fabric aber nur auf einem Tool eines Herstellers, schon weil spezialisierte Dienste oder innovative Funktionen häufig von anderen Anbietern geliefert werden.

Die Ausgestaltung der konkreten Identity Fabric differenziert sich auch zwischen Unternehmen. Das liegt schon daran, dass sich die Identitätstypen zwischen endkundenorientierten Unternehmen und solchen, die im B2B-Business tätig sind, ebenso unterscheiden wie zwischen produzierenden Firmen oder solchen aus der Dienstleistungsbranche. Auch die Größenordnung von Organisationen und die spezifischen Anforderungen und Prioritäten an das IAM sind in diesem Zusammenhang wichtige Faktoren.

Eine Identity Fabric ist auch nicht statisch, sondern entwickelt sich kontinuierlich weiter, indem sie beispielsweise weitere Dienste erhält, ältere Funktionen tilgt, wenn nicht mehr benötigt, oder Dienste ersetzt. Der Rahmen dafür bleibt aber konstant: Es geht immer darum, die Services in integrierter Form zu liefern, die jeder Identität den Zugriff auf jeden Dienst ermöglichen. Die Umsetzung einer eigenen Identity Fabric startet beim gleichen Grundkonzept, erfordert dann aber die spezifische Anpassung an die Anforderungen der jeweiligen Organisation.

Die Unterstützung aller Identitätstypen ist ein wesentliches Merkmal einer Identity Fabric. Neben Identitäten von Menschen wächst dabei insbesondere auch die Zahl von "Silicon Identities", also Geräte, Dinge, Dienste et cetera. Auch für diese Identitäten muss es definierte Prozesse der Erstellung, der Berechtigungszuordnung, der Überwachung und Analyse geben. Immer wichtiger wird zudem der Umgang mit Beziehungen zwischen verschiedenen Arten von Identitäten wie etwa Kunden und von diesen genutzten Diensten, Geräten und Dingen – ein Beispiel sind Fitnesstracker und die entsprechenden Apps.

Die komplexen Beziehungen sind in einem Gesamtkonzept wie der Identity Fabric wesentlich einfacher zu beherrschen als beim Versuch, verschiedene Identitätssilos mit unterschiedlicher organisatorischer Zuständigkeit miteinander zu verknüpfen. Anders formuliert: Um erfolgreich digitale Dienste und vernetzte Geräte und Dinge im digitalen Business zu vermarkten, braucht es eine Identity Fabric statt isolierter Lösungen.

Gleichzeitig sind auch der kontrollierte und sichere Zugriff auf alle Arten von Diensten zu unterstützen, von modernen SaaS-Anwendungen über Applikationen, die im B2B-Umfeld bei Geschäftspartnern laufen, bis hin zu Legacy-Anwendungen im unternehmensinternen Rechenzentrum, Steuerungssystemen für IoT-Geräte im Konsumentenumfeld oder OT-Systemen (Operational Technology, Steuerungssysteme in der Produktion). Die Vernetzung all dieser Komponenten erfordert auch eine übergreifende Steuerung und Sicherheit, die mit den unterschiedlichen Identitäten und ihren Zugriffsberechtigungen sowie der Authentifizierung und Autorisierung beginnt.

Eine Identity Fabric ist dabei nicht nur eine Ansammlung von Techniken wie IGA (Identity Governance & Administration, also das eigentliche Benutzer- und Berechtigungsmanagement für Mitarbeiter), CIAM, PAM oder Zugriffsmanagementsystemen für die starke, kennwortlose Authentifizierung. Die Integration der verschiedenen Systeme ist ein Kernmerkmal, um Wiederverwendung und durchgängige Prozesse ebenso wie eine hohe Sicherheit zu ermöglichen. Deshalb ist die Unterstützung einer flexiblen "Identity Orchestration", also der Prozessverknüpfung verschiedener Komponenten eine Kernfunktion, die eine Identity Fabric liefern muss. Dazu zählt auch die Verbindung zu Umsystemen wie beispielsweise ITSM (IT Service Management), die sich für das Ausführen manueller Provisionierungsschritte oder als Anforderungssystem für verschiedene IAM-Aufgaben nutzen lassen.

Eine moderne Identity Fabric muss auch einen As-a-service-Betrieb als Ziel haben. Das lässt sich in den meisten Fällen nicht sofort erreichen, weil eine Identity Fabric selten auf der grünen Wiese entsteht, sondern als Weiterentwicklung der bestehenden IAM-Systeme hin zu einer modernen, integrierten Umgebung. Bei der Modernisierung und Ergänzung von Komponenten muss aber zumindest die Fähigkeit zu einem As-a-service-Betrieb gegeben sein. Eine Grundvoraussetzung dabei ist auch eine moderne, modulare Architektur, die auf Microservices basieren sollte und entweder als mandantenfähiger Dienst in der Public Cloud oder mit effizient verwalteten, kundenspezifischen Instanzen in einem As-a-service-Modell laufen. Aufgrund der Sensitivität von Identitäts- und Berechtigungsinformationen sind viele IT-Verantwortliche bezüglich eines mandantenfähigen Deployments aus der Public Cloud zögerlich. Soweit eine hohe Elastizität und Skalierbarkeit sowie Automatisierung von Bereitstellung, Patches, Updates und Betrieb durch den Dienstanbieter gegeben ist, sind aber auch spezifische Bereitstellungsmodelle (Single Tenant) ein valider Ansatz.

Eine Identity Fabric stellt im Vergleich zu klassischen IAM-Ansätzen auch einen Paradigmenwechsel dar. Althergebrachte Werkzeuge sind auf das Verwalten von Zielsystemen ausgerichtet, arbeiten also "inside-out". Eine Identity Fabric muss aber zusätzlich auch einen "outside-in"-Ansatz unterstützen, der Identitätsdienste bereitstellt und den Anwendungen nutzen können, sei es für die Anforderung, ein Benutzerkonto anzulegen oder für eine Autorisierungsanforderung, mit der zur Laufzeit darüber entschieden wird, ob eine bestimmte Identität über mit ihr verknüpfte Benutzerkonten Zugriff erhält.

Dazu ist ein konsistenter Identity-API-Layer erforderlich, der in definierter und standardisierter Form APIs bereitstellt, die Anwendungen und ihre Entwickler einsetzen, um auf Funktionen der Identity Fabric zuzugreifen. Idealerweise wird ein solcher Layer unabhängig von den technischen Bausteinen der Identity Fabric definiert, um diese ohne Auswirkungen auf die nutzenden Anwendungen austauschen zu können. Dazu sollte der layer einerseits Standards unterstützen, andererseits aber auch proprietäre APIs von IAM-Systemen kapseln.

Damit verbessert sich gleichzeitig auch die Anpassbarkeit der IAM-Infrastruktur. Viele bestehende IAM-Umgebungen leiden darunter, dass über viele Jahre individuelle Konfigurationen erfolgt sind, deren Pflege oft nicht mehr beherrschbar ist und die zudem bei Produkt-Updates regelmäßig Probleme und hohe Anpassungsaufwände verursachen oder diese sogar verhindern. In der Architektur einer Identity Fabric kommen solche Anpassungen entweder durch Konfiguration in den genutzten technischen Komponenten oder durch das Erstellen eigener Microservices unter Nutzung des Identity-API-Layers zustande. Damit sind sie von den darunter liegenden Produkten und Diensten isoliert und lassen sich leichter pflegen und erweitern, machen aber insbesondere von Updates weitgehend unabhängig und erleichtern auch den Austausch von Komponenten innerhalb der Identity Fabric, soweit die APIs stabil bleiben.

Die meisten Organisationen starten ihren Weg zur Identity Fabric mit einer mehr oder weniger vollständigen IAM-Infrastruktur, die sich in vielen Fällen über Jahrzehnte entwickelt hat und oft auch Bausteine enthält, die schon seit mehr als zehn Jahren in Betrieb sind. Andererseits unterstützen diese Legacy-IAM-Komponenten oft auch die Einbindung von Legacy-Anwendungen, die oft komplex und schwierig zu ersetzen ist. Eine Identity Fabric entsteht daher üblicherweise schrittweise mit drei wesentlichen Bausteinen:

- Die weitere Nutzung und schrittweise Modernisierung von IAM-Komponenten, die wichtige Funktionen in einer Identity Fabric liefern.

- Das Ergänzen weiterer funktionaler Komponenten mit moderner Architektur und As-a-service-Betriebsmodell, um weitere Anforderungen abzudecken.

- Die Integration mit Legacy-IAM-Komponenten für eine Übergangszeit, um bestimmte Dienste und Schnittstellen weiterzunutzen, bis diese Bausteine ersetzt wurden.

Das ermöglicht einen schrittweisen Übergang in der vom Unternehmen gewünschten Geschwindigkeit. Insbesondere ältere IGA-Produkte, die mit speziellen und schwierig anbindbaren oder ohnehin mittelfristig vor der Ablösung stehenden Zielsystemen integriert sind, lassen sich in einer Übergangszeit von neuen Bausteinen der Identity Fabric als Zwischensystem versorgen, um die komplexe Anwendungsintegration entweder schrittweise durchführen zu können oder abzuwarten, bis die Zielsysteme abgelöst sind.

Das Konzept der Identity Fabric beschreibt einen modularen Ansatz für ein modernes IAM, der auf Produktfähigkeiten (Capabilities) basiert, diese zu Diensten bündelt und dann definiert, welche technischen Komponenten wie beispielsweise Clouddienste diese bereitstellen. Der Einstieg beginnt dabei einerseits damit, ein Zielbild zu definieren, indem IT-Verantwortliche Identitätstypen, Zielsysteme und die erforderlichen Capabilities analysieren. Letztere sind auf Vollständigkeit hin zu prüfen, insbesondere auch mit Blick auf zukünftige Anforderungen. Hier können Referenzarchitekturen eine wichtige Hilfestellung leisten, weil sich über diese analysieren lässt, welche Funktionsblöcke vorhanden sind, wo es Lücken gibt, welche fehlen und ob und wie wichtig das Schließen solcher funktionaler Lücken ist. Auf diese Weise lässt sich auch ermitteln, welche technischen Komponenten bereits in ausreichend moderner Form vorhanden sind, welche modernisiert werden müssen, welche fehlen oder ersetzt werden müssen und welche überflüssig sind. Dazu gehört auch zu prüfen, wo mögliche Redundanzen bestehen.

Eine Identity Fabric ist dabei nicht statisch. Es empfiehlt sich, regelmäßig zu überprüfen, wo das Projekt steht, welche neuen Anforderungen es gibt und auch, ob die Roadmap angepasst werden muss. Eine jährliche Bestandsaufnahme hat sich dabei bewährt. Die Identity Fabric ist durch ihre generische Struktur und die spezifische Anpassbarkeit auch sehr gut geeignet, um neue Anforderungen zu integrieren – das Grundkonzept verändert sich nicht. Aspekte wie die Integration mit Legacy-IAM, die Verbindung zu Zielsystemen und der Identity-API-Layer sind immer Teil der Umgebung. Die unterstützten Funktionen, ihre Integration zu Diensten und die Umsetzung durch konkrete Produkte verändern sich mit der Zeit. Neue Anforderungen, neue Techniken und der Ersatz von Bausteinen in der Identity Fabric führen zu Anpassungen.

Bei der Weiterentwicklung sollten IT-Verantwortliche den Fokus auf Funktionen legen, die IAM-Werkzeuge in der Identity Fabric integrieren und für unterschiedlichste Identitäten nutzbar sind oder die Bereitstellung von IAM-Diensten über den Identity-API-Layer unterstützen. Dazu zählen Orchestrierungsdienste, um Prozesse abzubilden und IAM-Dienste untereinander und mit externen Applikationen zu integrieren.

Darunter findet sich die Unterstützung von dezentralen Identitäten (DCI, Decentralized Identity) als neues Paradigma, das viele neue Möglichkeiten für den Umgang sowohl mit externen als auch internen Identitäten bietet. Auch PBAM (Policy Based Access Management), um richtlinienbasiert Autorisierungsentscheidungen zur Laufzeit zu treffen, statt mit statischen Berechtigungen in Zielsystemen zu arbeiten, lässt sich mit einer Identity Fabric integrieren, ohne dass sich das Grundmodell verändert.

Der Identity-Fabric-Ansatz lässt sich jederzeit umsetzen und die meisten Organisationen beginnen damit, wenn größere Investitionen in IAM anstehen. Statt weiterzumachen wie bisher, kommt die Identity Fabric ins Spiel, um IAM auf ein neues Niveau zu heben. Der wichtigste Schritt ist die Schaffung eines gemeinsamen Verständnisses über Anforderungen, Status und Prioritäten über alle Beteiligten hinweg. Das setzt die Unterstützung des Managements voraus, auch weil die Gesamtsicht in vielen Organisationen mitunter Anpassungen der Organisationsstruktur erfordert. Auch über das Betriebsmodell müssen IT-Verantwortliche entsprechend nachdenken.

Mit einer Identity Fabric erfolgen Investitionen aber zielgerichtet und priorisiert und Redundanzen lassen sich vermeiden, während ein deutlich höheres Niveau in der IAM-Serviceerbringung ebenso wie eine größere Flexibilität erreicht werden. Gleichzeitig bietet das Konzept ausreichend Spielraum, um sowohl den Status als auch die spezifische Situation von Organisationen zu berücksichtigen. Identity Fabrics sind damit ein zentrales Gestaltungselement innerhalb jedes IAM-Programms.