Identity & Access Management: Zugriffe nachvollziehbar vergeben und entziehen

IAM organisiert, wie digitale Identitäten entstehen, sich anmelden, Rechte erhalten und diese wieder verlieren. Wichtig sind führende Datenquellen, befugte Genehmigungen und eine technische Umsetzung in den tatsächlich genutzten Anwendungen. Nutzen entsteht unter anderem durch nachvollziehbare Zugriffsentscheidungen und weniger unbemerkte Altberechtigungen. Ein zentrales Login allein erfüllt diese Aufgaben nicht.

Zu unterscheiden sind Identitätsdaten und ihr Lebenszyklus, Authentisierung, Autorisierung, technische Kontenversorgung sowie Governance und Reviews. Je nach Bedarf kommen privilegierte Zugriffe, externe Identitäten und weitere Kontrollen hinzu. Die Architektur beschreibt, welches System welche Aufgabe übernimmt und wie Änderungen zwischen ihnen abgeglichen werden. Nicht jede Aufgabe erfordert ein eigenes Produkt.

Häufig fehlen eindeutige Datenverantwortliche, belastbare Zuordnungen zwischen Personen und Konten oder Anwendungsverantwortliche mit Testkapazität. Sonderfälle wie externe Nutzer und lokale Administratorkonten werden leicht übersehen. Vor einer großen Migration hilft eine begrenzte Integration mit realistischen Lebenszyklus- und Fehlerfällen. So werden Abhängigkeiten sichtbar, bevor sie auf viele Anwendungen übertragen werden.

Beginnen Sie mit den wichtigsten Zugriffsrisiken und betroffenen Geschäftsprozessen. Erfassen Sie Identitätsarten, Anwendungen und verantwortliche Rollen. Daraus werden ein Zielbild und eine Reihenfolge abgeleitet, die Datenqualität, Integration und Betrieb berücksichtigt. Die Roadmap benennt Abschlusskriterien pro Schritt. Eine Produktauswahl vor der Klärung dieser Anforderungen kann lediglich bestehende Widersprüche in ein neues Werkzeug übertragen.

IAM kann beispielsweise Zugriffsbegrenzung, Entzug und regelmäßige Berechtigungsprüfungen unterstützen. Welche Pflichten tatsächlich gelten, hängt von Organisation, Tätigkeit und Regelwerk ab. Benötigt werden konkrete Kontrollen und überprüfbare Nachweise, keine pauschale Aussage zur vollständigen Erfüllung von DORA oder anderen Vorgaben. Ein freigegebenes Rollenmodell ist erst dann aussagekräftig, wenn seine Anwendung und Ausnahmen ebenfalls geprüft werden.

In Cloud-Umgebungen müssen unter anderem Mandanten, föderierte Anmeldungen, externe Identitäten und Administratorrechte abgegrenzt werden. Es ist zu klären, wer Konten provisioniert, wie Rechte in der Anwendung wirken und was bei Ausfall des Identitätsdienstes geschieht. Ein zentral gesperrtes Konto beendet nicht zwangsläufig jede bereits bestehende Anwendungssitzung. Dieses Verhalten gehört in die vereinbarten Entzugstests.

Rollen bündeln Berechtigungen für nachvollziehbare Aufgaben. Für jede Rolle sollten Zweck, Eigentümer, Genehmigung und enthaltene Rechte verständlich sein. Rollenwechsel brauchen eine Entscheidung über bisherige Rechte; bloßes Hinzufügen der neuen Rolle kann Berechtigungen ansammeln. Ausnahmen und konfliktträchtige Kombinationen werden gesondert geprüft. Ein umfangreicher Rollenkatalog ohne fachliche Verantwortlichkeit ist schwer zuverlässig zu pflegen.

Eine Wirtschaftlichkeitsbetrachtung braucht Ausgangswerte, etwa Aufwand für Kontenänderungen, Supportfälle oder Berechtigungsreviews. Gegenübergestellt werden Einführung, Lizenzen, Integration und laufender Betrieb. Risikoreduktion muss mit nachvollziehbaren Annahmen beschrieben werden und ist nicht ohne Weiteres eine garantierte Einsparung. Nach der Umsetzung sollten vergleichbare Fallzahlen und Zeiträume verwendet werden, um den tatsächlich erreichten Effekt zu prüfen.

Prüfenswert sind beispielsweise phishingresistente Anmeldeverfahren, der Lebenszyklus nichtmenschlicher Identitäten und besser nachvollziehbare Berechtigungsentscheidungen. Entscheidend ist jeweils der konkrete Bedarf: Welches Risiko oder Betriebsproblem wird gelöst, welche Systeme sind betroffen und wie wird der Erfolg geprüft? Ein Trend begründet keine allgemeine Beschaffungspflicht. Bestehende Lebenszykluslücken sollten durch neue Funktionen nicht aus dem Blick geraten.

Multi-Faktor-Authentisierung kombiniert unterschiedliche Faktorarten. Zwei Passwörter sind deshalb nicht automatisch zwei Faktoren. Nicht jedes MFA-Verfahren schützt in gleichem Maß gegen Phishing; Auswahl, Wiederherstellung und Ausnahmen müssen zum Risiko passen. Tests sollten auch verlorene Geräte, Ersatzverfahren und Administratorzugriffe einschließen. MFA verbessert die Anmeldung, entscheidet aber nicht darüber, ob die angemeldete Person eine bestimmte Transaktion ausführen darf.

Privileged Access Management behandelt besonders weitreichende Zugriffe, etwa Administration oder technische Dienstkonten. Zu klären sind Freigabe, zeitliche Begrenzung, Zugangsdatenverwaltung, Protokollierung und Notzugriff. Welche Funktionen benötigt werden, hängt vom System und Risiko ab. PAM ergänzt den allgemeinen Identitätslebenszyklus; ein privilegiertes Konto muss weiterhin einen nachvollziehbaren Eigentümer und einen geregelten Entzug haben.

Nach Umfang und Anforderungen werden eine begrenzte Integrationsgruppe und deren Abnahmekriterien festgelegt. Es folgen Konfiguration oder Entwicklung, Tests von Eintritt, Änderung und Entzug sowie Fehler- und Wiederholungsfällen. Erst nach geprüfter Übergabe sollte die Anbindung auf weitere Anwendungen ausgeweitet werden. Nicht migrierte Systeme und Übergangsverfahren bleiben im Register sichtbar und erhalten eine verantwortliche Rolle.

Ein Architekturentwurf zeigt führende Datenquellen, Identitätsdienste, Genehmigungsabläufe und Zielanwendungen mit ihren Vertrauensgrenzen. Anmeldung, Provisionierung und fachliche Rechteprüfung werden getrennt beschrieben. Zu berücksichtigen sind außerdem Ausfall, Rückmeldung fehlgeschlagener Änderungen und Änderungen am Datenmodell. Ein Produktdiagramm reicht nicht, wenn daraus nicht erkennbar wird, wer eine Änderung entscheidet und wie ihre Wirkung überprüft wird.

Eintritt, Wechsel und Austritt benötigen verbindliche Auslöser und eindeutige Zuordnungen zu den Zielkonten. Eine Änderung wird bis zur Anwendung zurückverfolgt; fehlgeschlagene oder verspätete Verarbeitung muss sichtbar werden. Technische Identitäten haben eigene Eigentümer und Zwecke und dürfen nicht ungeprüft mit dem Austritt einer Person gelöscht werden. Kontenabgleiche helfen, verwaiste oder außerhalb des Standardprozesses angelegte Zugänge zu erkennen.

CIAM richtet sich an Kundenidentitäten und deren Nutzung eines Angebots; internes IAM an Mitarbeitende und weitere betriebliche Identitäten. Registrierung, Einwilligungen, Wiederherstellung, Skalierung und Nutzererlebnis können deshalb andere Anforderungen haben. Gemeinsam sind nachvollziehbare Identitäten, sichere Anmeldung und passende Zugriffsentscheidungen. Beide Bereiche sollten nicht allein wegen ähnlicher Technik ohne Prüfung in ein identisches Rollen- und Betriebsmodell gezwungen werden.

Wichtige Fälle sind doppelte Personenkennungen, verzögerte Änderungen, ein nicht erreichbares Zielsystem und ein Rollenwechsel mit verbleibenden Altberechtigungen. Auch lokale Konten und bestehende Sitzungen müssen berücksichtigt werden. Ein erfolgreiches Provisionierungsprotokoll wird mit dem tatsächlichen Zustand der Anwendung verglichen. Abweichungen brauchen Zuständigkeit und Abschlussnachweis; sie dürfen nicht allein durch erneutes Ausführen des Standardfalls als behoben gelten.

SAML und OpenID Connect werden für föderierte Anmeldungen eingesetzt. OAuth behandelt delegierte Zugriffsberechtigungen und ist für sich genommen kein Anmeldeprotokoll. SCIM unterstützt die standardisierte Verwaltung von Identitätsressourcen. Welches Verfahren geeignet ist, hängt von den beteiligten Systemen und Anforderungen ab. Die Nennung eines Standards belegt weder eine korrekt konfigurierte Vertrauensbeziehung noch eine geprüfte Kontenlöschung.

Ein Anforderungskatalog sollte unterstützte Identitätsarten, Zielanwendungen, Integrationsverfahren, Genehmigungen, Nachweise und Betriebsbedarf enthalten. Anbieter werden anhand derselben relevanten Fälle bewertet, einschließlich Fehlerbehandlung und Entzug. Zu prüfen sind nachgewiesene Konnektorfunktionen, Lizenzmodell, Datenverarbeitung und Exitmöglichkeiten. Eine lange Funktionsliste oder ein nicht getesteter Standardkonnektor ersetzt keinen Nachweis im vorgesehenen Einsatz.

Hybridarbeit verändert Zugriffswege und kann zusätzliche Anforderungen an Geräte, Anmeldung und Sitzungen schaffen. Benötigt wird eine abgestimmte Entscheidung, welche Anwendungen unter welchen Bedingungen erreichbar sind und wie verlorene Geräte oder kompromittierte Konten behandelt werden. Technische Durchsetzung und Support müssen getestet werden. Allein ein VPN oder ein MFA-Schalter belegt noch kein durchgängiges Zugriffskonzept.

Governance verbindet fachliches Eigentum, Genehmigung, regelmäßige Prüfung und nachvollziehbare Ausnahmen. Reviews müssen zeigen, worüber entschieden wird und welche Rechte tatsächlich bestehen. Eine abgelehnte Berechtigung ist erst nach geprüftem Entzug bearbeitet. Verantwortliche, Prüfanlass und Eskalation werden festgelegt. Automatisch versandte Bestätigungslisten ohne verständliche Entscheidungsgrundlage liefern einen schwachen Nachweis tatsächlicher Kontrolle.