Eine große Organisation hat Tausende von Benutzern, Hunderte von Systemen und Zehntausende von Zugriffsberechtigungen. Ein Mitarbeiter, der vor fünf Jahren in der Kreditabteilung war und heute im Marketing arbeitet, besitzt wahrscheinlich noch die alten Berechtigungen. Ein Dienstleister, dessen Projekt beendet ist, hat womöglich noch ein aktives Konto. Servicekonten, die für eine vorübergehende Integration angelegt wurden, bestehen jahrelang mit unverändertem Passwort. Nichts davon ist für sich genommen eine Katastrophe, doch zusammen entsteht ein Risikoniveau, das kein Prüfer übersieht und kein Sicherheitsteam manuell beherrschen kann.
Entscheidend ist hier die Trennung zweier Konzepte. Identitäts- und Zugriffsmanagement (IAM) beantwortet die Frage, ob diese Person die ist, für die sie sich ausgibt, und ob sie das jetzt tun darf: Authentifizierung, Single Sign-on, Multi-Faktor-Verifizierung und Token-Ausgabe. Identity Governance and Administration (IGA) behandelt eine tiefere Frage: ob diese Person diesen Zugriff überhaupt haben sollte, wer ihn genehmigt hat und wann er überprüft werden muss. Organisationen, die nur IAM haben, verschließen die Haustür zuverlässig, wissen aber nicht, wem sie einen Schlüssel gegeben haben.
Die bevorzugte Architektur gestaltet beide als sich ergänzende Schichten über einer gemeinsamen Identitätsquelle. Im Zentrum steht ein Identitätsverzeichnis, das vom HR-System und den Partner-Stammdaten gespeist wird und jede Identität durch ihren Lebenszyklus vom Eintritt bis zum Austritt begleitet. Die IAM-Schicht, aufgebaut auf offenen Standards wie OpenID Connect und SAML, übernimmt Authentifizierung und Token-Ausgabe für jede Anwendung, jede API und jeden Agenten. Die IGA-Schicht verwaltet Rollen, Richtlinien, Antrags- und Genehmigungsworkflows, regelmäßige Zugriffsüberprüfungen und Funktionstrennung und provisioniert das Ergebnis als konkrete Berechtigungen in die Zielsysteme.
Die erste praktische Überlegung betrifft das Design des Rollenmodells. Rollen müssen aus der tatsächlichen Struktur der Organisation und aus Stellenbeschreibungen abgeleitet werden, nicht aus bestehenden Zugriffen; andernfalls werden alle über Jahre angesammelten Überberechtigungen als Rollen festgeschrieben. Ein praktikabler Ansatz kombiniert Basisrollen, die nach Einheit und Position vergeben werden, mit individuell beantragten Berechtigungen. So erhält jeder Filialmitarbeitende automatisch die Basisrolle der Filiale, doch die Befugnis, Kredite oberhalb eines festgelegten Schwellenwerts zu genehmigen, erfordert einen Antrag, die Freigabe einer Führungskraft und ein Ablaufdatum.
Die zweite Überlegung betrifft die Automatisierung des Lebenszyklus. Die wirksamste Sicherheitskontrolle ist der rechtzeitige Entzug von Zugriffen, und das ist nur verlässlich, wenn er an HR-Ereignisse gekoppelt ist. Wechselt der Datensatz eines Mitarbeitenden in den Status „ausgeschieden“, müssen in diesem Moment Konten deaktiviert, Tokens widerrufen und Berechtigungen entzogen werden. Ein Wechsel zwischen Einheiten muss die alte Rolle entfernen und die neue vergeben, statt die neue lediglich hinzuzufügen. Diese ereignisgesteuerte Kopplung verlagert die Arbeit des Sicherheitsteams von manueller Überprüfung hin zur Überwachung von Ausnahmen.
Die dritte Überlegung betrifft nicht-menschliche Identitäten. Services, geplante Jobs, IoT-Geräte und zunehmend auch KI-Agenten brauchen alle eine Identität, einen Satz an Berechtigungen und einen benannten Verantwortlichen. Diese Identitäten müssen denselben Lebenszyklus und dieselbe regelmäßige Überprüfung durchlaufen wie menschliche Benutzer. Ein Agent, der im Namen eines Benutzers handelt, sollte einen Token mit engem Geltungsbereich und kurzer Lebensdauer halten, und jede seiner Aktionen sollte beiden Identitäten zugeordnet werden, dem Agenten und dem Benutzer, damit der Audit-Trail keine von beiden verliert.
Die Fallstricke in diesem Bereich sind zahlreich. Erstens: mit einem Werkzeug statt mit dem Datenmodell und dem Prozess zu beginnen; kein Produkt kann Rollen definieren, die niemand definiert hat. Zweitens: zeremonielle Zugriffsüberprüfungen, bei denen Führungskräfte alles ungelesen genehmigen; Abhilfe schafft es, Kontext anzuzeigen, etwa wann eine Berechtigung zuletzt genutzt wurde, und jede Überprüfung kurz zu halten. Drittens: Altsysteme ohne Standardschnittstellen zu ignorieren, die noch über Dateien und direkten Datenbankzugriff verwaltet werden. Viertens: IAM und IGA in einem riesigen Projekt zu bündeln, das an Glaubwürdigkeit verliert, bevor es seinen ersten Nutzen liefert.
Bei Niadad stellt die Plattform Shanasa die Identitäts- und Zugriffsschicht auf Basis offener Standards bereit: zentrale Authentifizierung, Single Sign-on, Multi-Faktor-Verifizierung und Token-Ausgabe für Benutzer, Services und Agenten. Die Plattform Parsa übernimmt die Richtlinien- und Governance-Schicht: Definition von Rollen und Zugriffsrichtlinien, Antrags- und Genehmigungsworkflows, regelmäßige Überprüfungen und Funktionstrennung. Im Banking-Programm von Niadad stehen beide neben den Partner-Stammdaten Ashna und dem API-Gateway, sodass Identität als eine durchgängige Kette von der Quelle bis zum Durchsetzungspunkt verwaltet wird.
Unternehmenssicherheit läuft letztlich auf eine einfache Frage hinaus: Können Sie jederzeit sagen, wer worauf Zugriff hat und warum? IAM beantwortet das Wer, IGA das Warum. Eine Organisation, die über beides verfügt, besteht nicht nur ihre Audits, sondern kann ihre Systeme auch souverän für neue Benutzer, Partner und Agenten öffnen, ohne die Kontrolle zu verlieren. Diese Arbeit ist nie abgeschlossen, denn Organisationen verändern sich ständig; mit der richtigen Architektur wird das Schritthalten jedoch zur Routine statt zum regelmäßigen Notfall.