Identity Governance: KI-gestützte Zugriffsprüfungen & minimale Rechte

Zugriffe sammeln sich an: Menschen wechseln Rollen, Projekte enden, Dienstkonten und Cloud-Rollen werden „auf Vorrat“ vergeben. Regelmäßige Zugriffsprüfungen sollen das rückgängig machen, doch die Prüfenden sehen Tausende Einzelposten, die sie nicht verstehen, und klicken „alle genehmigen“. KI vergleicht jede Identität mit ihrer Vergleichsgruppe, der Nutzung und den Richtlinien, ordnet nach Auffälligkeit oder Toxizität, empfiehlt Genehmigen oder Entziehen mit kurzer Begründung und schlägt sauberere Rollen vor. Ziel sind weniger durchgewunkene Kampagnen und ein messbarer Rückgang dauerhaft vergebener Privilegien.

Problem & Nutzen

• Heute: vierteljährliche oder jährliche Rezertifizierungskampagnen durch Vorgesetzte oder Anwendungsverantwortliche, Tabellen für ERP-/Altsysteme, Rollenmodelle aus Workshops, die innerhalb eines Jahres verfallen. Eintritts-, Wechsel- und Austrittsprozesse fügen Zugriffe hinzu, entfernen sie aber selten („Privilege Creep“). Nichtmenschliche Identitäten (Dienstkonten, API-Schlüssel, Workload-Identitäten, zunehmend KI-Agenten) haben oft keine Verantwortlichen.
• KI-Nutzen: (1) Prüfende sehen eine nach Risiko geordnete Liste mit Begründung statt einer flachen Liste; (2) risikoarme Posten mit hoher Konfidenz können automatisch zertifiziert oder gebündelt werden; (3) datengetriebenes Role Mining ersetzt Workshops; (4) ungenutzte Berechtigungen werden aus Nutzungsprotokollen gefunden und entfernt; (5) SoD-Konflikte werden vor der Genehmigung erkannt, nicht erst bei der Prüfung.
• Nachweis: Prüfer (ISO 27001, SOX, DORA, NIS2-Aufsicht) verlangen Belege für regelmäßige, wirksame Zugriffsprüfungen. Anbieter berichten von starken Aufwandssenkungen, doch veröffentlichte Zahlen sind Werbeaussagen; messen Sie Ihre eigene Ausgangslage.

Varianten

• KMU: Microsoft-365-/Entra-Prüfungen von Gruppen, Teams und Gastnutzern mit Eingrenzung nach Inaktivität; eine Handvoll SaaS-Anwendungen. Oft ist kein Role Mining nötig.
• Großunternehmen / reguliert (Banken, Versicherungen, öffentlicher Sektor): vollständige IGA-Suite mit SAP-/ERP-SoD, Anbindung privilegierter Zugriffe und Bestätigung auf Vorstandsebene.
• Cloud-Engineering-Teams: Right-Sizing im Stil von CIEM für AWS-/Azure-/GCP-Rollen anhand von Nutzungsdaten.
• Nichtmenschliche und Agenten-Identitäten: Prüfung von Verantwortlichkeit, Rotation und Umfang von Service Principals, Tokens und Zugangsdaten von KI-Agenten (siehe SEC-013).
• Öffentlicher Sektor: Einbindung von Personalrat und Datenschutzbeauftragten; Rezertifizierung von Zugriffen auf Systeme mit Bürgerdaten.

So funktioniert es

1. HR source + connectors (AD/Entra, SaaS, ERP, DB, cloud IAM)
2. identity & entitlement graph (who has what, via which group/role)
3. usage enrichment (last use, unused permissions, sign-in logs)
4. analytics: peer-group outliers, role mining, SoD/toxic rules, risk scoring
5. recommendation per item (approve / revoke / review) + LLM-written justification
6. campaign: reviewer decision (human)
7. provisioning/de-provisioning via connector or ticket
8. evidence store, feedback to models

• Vergleichsgruppen-Analyse: Clustering und Assoziationsregeln auf Identitäts-Berechtigungs-Matrizen (auch Graphverfahren) finden Berechtigungen, die nur wenige Vergleichspersonen derselben Abteilung oder desselben Stellencodes besitzen; die ML-Empfehlung von Entra nutzt zum Beispiel die aus der Berichtsstruktur abgeleitete Zugehörigkeit von Nutzern zu Gruppen und hängt von einem korrekten Vorgesetzten-Attribut ab [1].
• Role Mining: Bottom-up-Clustering von Berechtigungen zu Rollenkandidaten, danach menschliche Kuratierung durch Rollenverantwortliche; Top-down-Rollen aus Stellencodes. Das Ergebnis ist ein Vorschlag, niemals eine automatische Neuzuweisung.
• Nutzungssignale: inaktive Konten, ungenutzte Berechtigungen und Daten der letzten Anmeldung speisen Entzugsvorschläge.
• LLM-Schicht: fasst zusammen, warum ein Posten markiert ist, und beantwortet Fragen der Prüfenden; neuere „Review-Agenten“ verbinden einen deterministischen Bewertungsmechanismus mit einer vom LLM formulierten Begründung [2]. Entscheidungen deterministisch und erklärbar halten; das LLM nur für Sprache nutzen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Die prüfende Person (Vorgesetzte/Anwendungsverantwortliche) zeichnet die Entscheidung; Posten mit hohem Risiko und SoD-Posten werden nie automatisch genehmigt; der Entzug kritischer Zugriffe erfolgt gestaffelt und umkehrbar.

Datenaufbereitung

Identity Governance braucht saubere Identitätsdaten, und das ist der größte Teil des Projekts. Quellen: HR-Stammdaten (Abteilung, Vorgesetzte, Stellencode, Eintritts-/Wechsel-/Austrittsdaten), Active Directory/Entra, ERP- und Anwendungsrollentabellen, Cloud-IAM sowie Anmelde- oder Nutzungsprotokolle. Typische Lücken: HR-Daten sind veraltet oder ohne Vorgesetzte und Stellencodes, Berechtigungsnamen sind kryptische technische Zeichenfolgen ohne fachliche Beschreibung, es gibt verwaiste und gemeinsam genutzte Konten, keinen Verantwortlichen je Anwendung, und die Ergebnisse früherer Prüfungen liegen nur in E-Mails oder Excel vor.

Vorbereitungsschritte: 1. Anwendungen inventarisieren und je Berechtigungskatalog einen Verantwortlichen benennen (PREP-001, PREP-004). 2. Berechtigungen aus ERP- und SaaS-Systemen exportieren (PREP-005) und Excel-basierte Rollenlisten normalisieren (PREP-011). 3. Die Verknüpfung von HR zu Konto korrigieren, sodass jedes Konto einer Person oder einem verantworteten Dienstkonto zugeordnet ist. 4. Kritische Berechtigungen in verständlicher Sprache beschreiben (PREP-012, PREP-015). 5. Frühere Entscheidungen als Labels für Ausreißermodelle sammeln (PREP-020). 6. Exporte für externe Werkzeuge pseudonymisieren (PREP-022).

Werkzeuge: Verzeichnisexporte mit PowerShell oder Skripten, IGA-Konnektoren, Python. Rechnen Sie mit 50 Prozent oder mehr des Gesamtaufwands für die Datenaufbereitung; siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU — Weg A: die Zugriffsprüfungs- und Lebenszyklusfunktionen der bereits lizenzierten Identitätsplattform nutzen (z. B. Microsoft Entra), da eine eigenständige IGA-Suite selten nötig ist.
• Großunternehmen — Weg A: ausgereifte IGA-Produkte mit KI-Role-Mining und Empfehlungen sind verfügbar; die Zahl der Integrationen spricht für ein Produkt statt eines Eigenbaus.
• Öffentlicher Sektor — Weg B: eigener Workflow auf einer souveränen EU-Cloud mit API-Analytik, wenn IGA-Suiten Vergabe- oder Hostingregeln nicht erfüllen.
• Entwickler — Weg B: Cloud-IAM-Analysatoren plus ein LLM für Zusammenfassungen passen zu Teams, die Cloud-Rollen und Dienstkonten bedarfsgerecht zuschneiden.

Weg A — Kaufen (Standardsoftware) (empfohlen)

• IGA-Suiten: SailPoint (Identity Security Cloud, KI-gestützte Empfehlungen und Rollen-Einblicke), Saviynt, One Identity, Omada (Dänemark, EU), IBM Security Verify Governance, Microsoft Entra ID Governance (Zugriffsprüfungen, Berechtigungsverwaltung, Lebenszyklus-Workflows). Zu den EU-/deutschen Optionen zählen Omada und Evolveum midPoint (Slowakei, Open Core); auch deutsche/EU-Integratoren im Stil von matrix in Betracht ziehen.
• Identity-Security-Graph / Datensicherheitsplattformen: Veza (Zugriffsgraph über Anwendungen, Daten und nichtmenschliche Identitäten) sowie CIEM-Funktionen in Cloud-Sicherheitsplattformen (Wiz, Orca, Palo Alto Prisma Cloud, Microsoft Defender for Cloud).
• A wählen, wenn: mehr als ca. 500 Identitäten in mehreren Systemen oder eine Prüfungspflicht bestehen. Prüfen: EU-Datenstandort, Konnektorabdeckung für Ihre ERP-/Altsysteme, Erklärbarkeit der Empfehlungen, API für den Nachweis-Export, AVV und Unterauftragsverarbeiter.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Datenschicht: Berechtigungen über Microsoft Graph, SCIM und Cloud-APIs exportieren (Befunde zu ungenutztem Zugriff von AWS IAM Access Analyzer, Azure/Entra, GCP IAM Recommender) und in ein Data Warehouse laden.
• Analytik: Bewertung nach Vergleichsgruppen in Python/SQL; LLM (in einer EU-Region gehostetes Claude/GPT/Gemini oder Mistral) nur für Begründungstexte und Rückfragen der Prüfenden, wo möglich mit pseudonymisierten Identitäten.
• B wählen, wenn: Sie wenige Systeme, ein Datenteam und ein IGA-Produkt ohne KI-Funktionen haben.

Weg C — Selbst betreiben (Open Source)

• Identitätskern: Evolveum midPoint (IGA mit Role Mining und Zertifizierung), Keycloak für IAM, Open Policy Agent für SoD-Regeln als Policy-as-Code.
• Analytik: Clustering mit scikit-learn/pandas, Neo4j oder Apache AGE für den Berechtigungsgraphen, optional ein kleines Open-Weight-LLM (Qwen, Llama, Mistral-Klasse) für Begründungen; für die Analytik genügt die CPU, für das LLM HW1-HW2.
• Aufwand: Die Entwicklung der Konnektoren ist der Hauptkostenfaktor, nicht die Rechenleistung.

Weg D — Eigenes Training

Selten erforderlich. Überwachte Modelle, die auf früheren Zertifizierungsentscheidungen (genehmigen vs. entziehen) trainiert werden, können die Rangfolge verbessern, doch Vorsicht, dass sie die Tendenz zum Durchwinken lernen; erst nach Bereinigung der Labels und mit Prüfungen auf Fairness und Drift einsetzen.

Stand der Technik (2026)

• IGA-Anbieter haben KI-Empfehlungen, Role-Mining-Engines und Assistenten in natürlicher Sprache für Prüfende ergänzt; Microsoft führte 2023 ML-basierte Empfehlungen in Zugriffsprüfungen ein und später einen Agenten, der Entscheidungen mit Begründung vorschlägt [1][2].
• Die Grenze der Entwicklung sind nichtmenschliche und agentische Identitäten: Inventar, Verantwortlichkeit, kurzlebige Zugangsdaten und Just-in-Time-Zugriff für Dienstkonten und KI-Agenten, verknüpft mit AI-SPM (SEC-013).
• Zero Standing Privilege und Just-in-Time-Erhöhung senken den Prüfaufwand: weniger dauerhafter Zugriff bedeutet weniger zu zertifizierende Posten.
• Grenzen: Empfehlungen sind nur so gut wie die HR- und Verzeichnisdaten (falsche Vorgesetzte und veraltete Stellencodes ergeben falsche Vergleichsgruppen); die Vergleichsanalyse benachteiligt berechtigte Einzelrollen und belohnt durchgängig überprivilegierte Teams; automatische Zertifizierung kann systemische Überprovisionierung verdecken; LLM-Begründungen können flüssig, aber falsch sein, daher die zugrunde liegenden Signale zeigen. Role Mining auf bereits unordentlichen Zugriffen übernimmt die Unordnung.

Gemeinsame Bausteine & Kombinationen

• Berechtigungsgraph und Nutzungsprotokolle werden mit SEC-005 (UEBA: Laufzeitanomalien gegenüber vorbeugender Prüfung) und SEC-001 (die Triage kann einen Zugriffsentzug anfordern) geteilt.
• Nachweise speisen SEC-009 (Compliance-Automatisierung für ISO 27001 / NIS2 / DORA); die Datenklassifizierung aus SEC-017 priorisiert die Prüfung von Zugriffen auf sensible Daten; Identitäten von KI-Agenten überschneiden sich mit SEC-013 und SEC-022.
• Gleiche LLM-/Agenten-Infrastruktur wie bei anderen SEC- und AGENT-Anwendungsfällen; die Analytik ist klassisches ML und braucht wenig Hardware.

Aufwand, Kosten & Kennzahlen

• Weg A: 3-12 Monate für ein IGA-Programm (Konnektoren und Datenqualität dominieren); ein reines Entra-Prüfungs-Setup ist in Wochen machbar. Die Preise gelten typischerweise pro Identität und Jahr.
• Weg B/C: 3-6 Monate für einen fokussierten Umfang (Cloud-Rollen plus 3-5 Anwendungen).
• Kennzahlen: Abschlussquote und -dauer der Kampagnen, Anteil entzogener Posten, Durchwinkquote (Verhalten „alle genehmigen“), verwaiste und inaktive Konten, Anteil ungenutzter Berechtigungen, offene SoD-Verstöße, dauerhaft privilegierte Konten, nichtmenschliche Identitäten mit Verantwortlichen, Prüfungsfeststellungen.

Menschen & Veränderung

Die Geschäftsleitung ist Sponsor des Projekts, die Informationssicherheitsbeauftragte bzw. der Informationssicherheitsbeauftragte und die IT treiben es voran. Das Personalwesen muss verlässliche Stammdaten liefern und von Anfang an eingebunden sein; Anwendungsverantwortliche und Abteilungsleitungen werden zu den Prüfenden und müssen die KI-Empfehlungen verstehen. Die oder der Datenschutzbeauftragte prüft die Rechtsgrundlage, denn Identitäten und Nutzungsprotokolle sind personenbezogene Daten; eine DSFA ist wahrscheinlich, wenn Berechtigungsnutzungsprotokolle personenbezogen ausgewertet werden, und mit dem Anbieter ist ein AVV (Art. 28 DSGVO) nötig.

Betriebsrat: ja. Nutzungs- und Anmeldeprotokolle sind geeignet, Verhalten zu überwachen, daher gilt §87 Abs. 1 Nr. 6 BetrVG (BAG: objektive Eignung genügt); §90 Abs. 1 Nr. 3 verlangt frühzeitige Unterrichtung, und §80 Abs. 3 erlaubt einen KI-Sachverständigen. Vereinbaren Sie in einer Betriebsvereinbarung, dass die Ergebnisse dem Prinzip der minimalen Rechte und der Prüfung dienen, nicht der Leistungsbeurteilung. Öffentlicher Dienst: Personalrat.

KI-Kompetenz (Art. 4 KI-Verordnung): Unterstützen Sie die Prüfenden mit Schulungen dazu, wie Risikowerte zu lesen sind, warum „alle genehmigen“ nicht akzeptabel ist und dass Werte nur Empfehlungen sind. Pilotieren Sie mit einer Anwendung und einer Abteilung und vergleichen Sie die KI-Empfehlungen mit den manuellen Entscheidungen der Prüfenden. Typische Bedenken sind die Angst, Zugriffe zu verlieren, und vor Überwachung; begegnen Sie ihnen mit transparenten Kriterien und einem Beschwerdeweg. Über den Entzug entscheiden immer Menschen; die KI ordnet und erklärt nur. Siehe GUIDE-004, GUIDE-006 und GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko; das System verwaltet IT-Zugriffe, nicht Beschäftigungsentscheidungen. Es kann in die Nähe von Anhang III (Beschäftigung, Überwachung von Arbeitnehmern) geraten, wenn Werte zur Bewertung oder Disziplinierung von Beschäftigten genutzt werden; die Ergebnisse auf Zugriffsentscheidungen begrenzen [3]. Art. 4 KI-Kompetenz gilt für die Prüfenden.
• DSGVO: Berechtigungen, Nutzungs- und Anmeldeprotokolle sind personenbezogene Daten von Beschäftigten; nötig sind eine Rechtsgrundlage (berechtigtes Interesse/Art. 88 und nationales Recht wie § 26 BDSG), Zweckbindung (keine Leistungsüberwachung), eine DSFA, wo Nutzungsanalysen Profiling darstellen, in Deutschland eine Betriebsvereinbarung, Datenminimierung und kurze Aufbewahrung der Protokolle [4]. Art. 22 dürfte bei menschlicher Entscheidung nicht greifen, das ist aber zu dokumentieren.
• Sicherheits-/Finanzvorgaben: ISO/IEC 27001 Anhang A Zugriffskontrolle und -prüfung, NIS2 (Zugriffskontrolle und Identitätsmanagement, Art. 21), DORA IKT-Zugriffsmanagement für Finanzunternehmen, SOX/ITGC, MaRisk im deutschen Finanzsektor (BAIT weitgehend von DORA abgelöst) [5][6].
• Risiken und Gegenmaßnahmen: schlechte Daten (zuerst die HR-Quelle korrigieren), Ausfall durch automatischen Übermaß-Entzug (gestaffelter Entzug, Notfallzugang), Ermüdung der Prüfenden (nach Risiko geordnete Pakete), Modellverzerrung zugunsten von Mehrheitsmustern (SoD-Regeln bleiben deterministisch), Datenabfluss über das LLM (EU-Region, pseudonymisieren, kein Training mit Prompts).

Erste Schritte

1. Systeme und Identitäten inventarisieren; HR-Quelldaten (Vorgesetzte, Abteilung, Stellencode) korrigieren und jeder Anwendung und jedem Dienstkonto Verantwortliche zuweisen.
2. Eine Pilot-Zugriffsprüfung in Entra ID Governance oder Ihrer IGA für Gäste, privilegierte Gruppen und eine geschäftskritische Anwendung durchführen, mit Eingrenzung nach Inaktivität und Empfehlungen.
3. SoD- und Regeln für toxische Kombinationen für Finanzen/ERP und Admin-Rollen als Policy-as-Code definieren.
4. Rollen für eine Abteilung ermitteln, mit den Rollenverantwortlichen validieren, dann ausrollen.
5. Cloud-Right-Sizing (Befunde zu ungenutzten Berechtigungen) und die Verantwortlichkeit für nichtmenschliche Identitäten ergänzen; die Kennzahlen monatlich verfolgen.

Quellen

1. Microsoft Learn — Entra ID access reviews, machine-learning recommendations — https://learn.microsoft.com/en-us/entra/id-governance/review-recommendations-access-reviews
2. Petri — Microsoft Entra ID Gets AI-Powered Tool to Streamline Access Decisions — https://petri.com/microsoft-entra-id-access-review-agent/
3. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
5. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
6. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
7. Microsoft 365 for IT Pros — Entra ID Access Reviews Get Machine Learning Recommendations — https://office365itpros.com/2023/07/21/entra-id-access-review-ai/
8. Evolveum midPoint — https://github.com/Evolveum/midpoint