Identity Governance and Administration (IGA): Joiner-Mover-Leaver und Zugriffszertifizierung

Identity Governance and Administration (IGA) löst ein fundamentales Problem: Berechtigungen akkumulieren sich über Zeit. Mitarbeiter erhalten Zugänge, wechseln Rollen, verlassen das Unternehmen - aber Berechtigungen werden selten systematisch entzogen. Das Ergebnis: Mitarbeiter haben Zugriff auf Systeme die sie längst nicht mehr brauchen. IGA automatisiert den Berechtigungslebenszyklus und erzwingt das Least-Privilege-Prinzip.

IGA vs. IAM vs. PAM

IAM (Identity and Access Management) ist der breiteste Begriff und umfasst Authentifizierung, Autorisierung, SSO, MFA und Directory Services (AD, LDAP). Die zentrale Frage: "Wer bist du? Was darfst du?" Tools: Azure AD/Entra ID, Okta, Ping Identity.

PAM (Privileged Access Management) fokussiert auf privilegierte Accounts (Admin, Root, Service Accounts) mit Password Vaults, Session Recording und Just-in-Time Access. Tools: CyberArk, BeyondTrust, Delinea.

IGA (Identity Governance and Administration) ist die Governance-Schicht über IAM. Die zentrale Frage: "Wer darf was? Ist das noch gültig? Wer hat genehmigt?" IGA deckt Lebenszyklus-Management (Joiner → Mover → Leaver), Compliance (Zugriffszertifizierungen, SoD-Enforcement, Audit Trails) ab. Tools: SailPoint, Saviynt, Microsoft Entra Identity Governance, One Identity.

Das Zusammenspiel: Das HR-System triggert den IGA-Joiner-Prozess, dieser löst in IAM die Account-Anlage und in PAM die Privileged-Access-Einrichtung aus. Beim Leaver-Prozess deaktivieren IAM und PAM sofort alle Zugänge.

Joiner-Mover-Leaver Prozess

JOINER (Neuer Mitarbeiter): Trigger ist die Anlage eines neuen Mitarbeiter-Datensatzes im HR-System. Die IGA empfängt das HR-Event (API, CSV, SCIM-Push), erstellt die Identity (displayName, department, jobTitle, manager) und berechnet das Role Assignment basierend auf Rolle und Abteilung. Beispiel "Junior Developer, IT": automatisch erhält die Person Azure AD Account, E-Mail, Jira (Developer), GitHub Org und VPN-Zugang. Ein Genehmigungsworkflow wird nur für nicht-Standard-Zugänge ausgelöst (Manager → System Owner), Privileged Access läuft durch den PAM-Prozess mit separater Genehmigung. Alle Aktionen werden mit Zeitstempel auditiert.

MOVER (Versetzung, Beförderung, Abteilungswechsel): Trigger ist ein HR-Update von Abteilung, Jobtitel oder Vorgesetztem. Die IGA berechnet die neue Role Assignment, führt eine Delta-Analyse durch und entzieht kritisch die alten Berechtigungen (SoD-Check!). Der Mitarbeiter soll nur die neue Rolle haben, nicht die alte. Ohne IGA entsteht "Permission Creep": Nach drei Jahren und fünf Rollenwechseln hat die Person fünf akkumulierte Berechtigungssätze - ein hochgefährliches Sicherheitsproblem.

LEAVER (Kündigung, Austritt): Der kritischste Prozess - Geschwindigkeit ist entscheidend. 30 Tage vor dem letzten Arbeitstag: Vorbereitung (Asset-Liste, Knowledge Transfer). Am letzten Arbeitstag (T-0): Account-Deaktivierung aller Systeme innerhalb einer Stunde nach Trennung, Passwort-Reset, MFA-Tokens entfernen, Active Sessions terminieren (SSO-Session-Invalidierung!), VPN-Zertifikate widerrufen, API-Keys und Service-Accounts deaktivieren, Shared-Account-Passwörter wechseln. Nach sieben Tagen: Account archivieren (nicht löschen - Audit!). Nach 90 Tagen: Account final löschen.

Bei sofortigem Leaver (fristlose Kündigung, Sicherheitsvorfall): Notfall-Deaktivierung in unter 15 Minuten über den "Emergency Termination"-Workflow mit CISO/HR-Bestätigung.

SLAs für Leaver: Standard unter 24 Stunden; Hochrisikoposition unter 1 Stunde; Security Incident unter 15 Minuten (manueller Trigger durch CISO).

Role Management und Role Mining

Das IGA-Rollenkonzept besteht aus drei Ebenen:

Business Roles beschreiben, was eine Person tut: "Junior Developer", "HR Manager", "Finance Director". Diese abstrakten Geschäftsfunktionen werden durch HR definiert und gepflegt.

IT Roles / Technical Roles beschreiben, was dafür technisch benötigt wird: "CRM Power User", "AD Domain User", "SharePoint Contributor". Eine Business Role mappt auf mehrere IT Roles.

Entitlements sind konkrete Berechtigungen in einem System: "Jira Gruppe: developers-backend", "AD Gruppe: SG-FILE-SHARE-Marketing-RW", "Salesforce Profil: Standard User".

Role Mining löst das Problem historisch gewachsener Berechtigungsstrukturen: IGA-Tools wie SailPoint exportieren alle User und ihre Entitlements, führen eine Ähnlichkeitsanalyse durch (k-Means-Clustering) und identifizieren Kandidaten-Rollen ("75% der Developer haben genau diese 12 Entitlements"). IT und HR validieren die vorgeschlagenen Rollen, die dann in die IGA importiert werden.

Eine typische Rollenhierarchie: Alle Mitarbeiter erhalten E-Mail, SharePoint Read und VPN-Basic. IT-Mitarbeiter kommen AWS Console Read, Confluence und Jira hinzu. Developer-Backend erhalten zusätzlich GitHub Teams und Kubernetes Namespace Dev. Senior Developer erhalten AWS Console Write (DEV only) und Code-Review-Genehmigung. Tech Leads erhalten Production ReadOnly. IT-Admins erhalten AD-Admin Tier 1, ITSM Full und Cloud Management.

Segregation of Duties (SoD)

SoD setzt das Vier-Augen-Prinzip in IT-Systemen durch: Niemand darf Zahlungen anlegen und genehmigen (Finanzrisiko), niemand darf Accounts anlegen und gleichzeitig sein eigener Auditor sein (Kontrollrisiko). SOX, ISO 27001 und NIS2 fordern SoD für kritische Prozesse.

Typische SoD-Konflikte nach Kritikalität:

Kritisch: "Buchhalter kann Kreditoren anlegen" + "Buchhalter kann Zahlungen freigeben" → Betrugsrisiko durch falsche Rechnungen an eigene Firma. Oder: "IT-Admin kann AD-Accounts anlegen" + "IT-Admin ist sein eigener Auditor" → kann Spuren verwischen.
Mittel: "Einkäufer kann Bestellungen anlegen" + "Einkäufer kann Bestellungen genehmigen" → unkontrollierte Eigenfreigabe.
Niedrig: "Entwickler kann Code schreiben" + "Entwickler kann Code in Prod deployen" → Change Management umgehbar (nur riskant ohne andere Kontrollen).

Das SoD-Rule-Set definiert Konflikte im Format "Berechtigung A KONFLIKT-MIT Berechtigung B" mit Schweregrad und optionaler Mitigating Control:

sod_rules:
  - id: "SOD-001"
    name: "Finance: Anlage und Freigabe"
    severity: critical
    conflicting_entitlements:
      - "SAP-FI-Kreditoren-Anlage"
      - "SAP-FI-Zahlungsfreigabe"
    mitigating_control: "4-Augen durch Finance Manager"
  - id: "SOD-002"
    name: "IT: Account-Anlage und Audit"
    severity: high
    conflicting_entitlements:
      - "AD-User-Administration"
      - "SIEM-Audit-Log-Access"

SoD-Enforcement erfolgt auf drei Wegen: präventiv (IGA verhindert die Zuweisung wenn ein Konflikt entsteht), detektiv (periodischer SoD-Report für bestehende Konflikte) und kompensierend (Mitigating Control dokumentieren wenn der Konflikt unvermeidbar ist). Das Vorgehen beginnt mit dem Aufbau einer Rollenmatrix, der Identifikation kritischer Prozesse (Finance, IT-Admin, HR), der Definition von Konfliktregeln mit Business-Input, der Remediation bestehender Verletzungen und der laufenden präventiven Durchsetzung im Workflow.

Zugriffszertifizierung (Access Review)

Der periodische Review aller Berechtigungen ist durch ISO 27001 A.9.2.5 und SOX gefordert. Privilegierte Accounts (Admin, Service Accounts) werden quartalsweise reviewt, normale Mitarbeiter jährlich, externe Contractor bei Vertragsende und jährlich.

Der Review-Prozess: Die IGA generiert eine Kampagne ("Q1 2026 Access Review"). Jeder Manager/Certifier erhält eine Liste seiner direkt unterstellten Mitarbeiter mit allen aktuellen Berechtigungen und entscheidet pro Eintrag: APPROVE, REVOKE oder DELEGATE. Widersprüche lösen automatisch einen Revoke aus. Non-Response führt zu Erinnerungen, Eskalation und schließlich Auto-Revoke. Der Abschlussbericht zeigt Zertifizierungsrate, revokte Entitlements und Kampagnendauer.

Best Practices für effektive Reviews: Kampagnengröße begrenzen (zu viele Einträge erzeugen einen Ermüdungseffekt - alle klicken "Approve"). Risikobasiert priorisieren: High-Risk-Zugang häufiger reviewen. Kontext anzeigen ("Diese Person hatte diesen Zugang seit 847 Tagen und hat ihn zuletzt vor 450 Tagen genutzt") für fundierte Entscheidungen. Automatisierte Empfehlungen ("Revoke" bei Inaktivität) nutzen.

Certifier-Typen: Manager-Review (Vorgesetzter zertifiziert direkte Mitarbeiter), Application Owner Review (System-Owner zertifiziert alle User seines Systems), Role Owner Review (Rolleninhaber prüft alle Mitglieder) sowie Self-Certification (schwächste Form, User bestätigt eigene Berechtigungen).

IGA-Produkte im Vergleich

Produkt	Stärken	Geeignet für
SailPoint Identity Security Cloud	Marktführer (Gartner seit 2015), KI-basiertes Role Mining, 250+ Connectors	Enterprise 1000+ Mitarbeiter
Saviynt Enterprise Identity Cloud	IGA + PAM + CIEM kombiniert, Cloud-nativ, gute Azure/AWS-Integration	Cloud-first Unternehmen
Microsoft Entra Identity Governance	Nativ in M365 integriert, Access Reviews, Lifecycle Workflows, in E5 enthalten	Microsoft-heavy Umgebungen
One Identity (Quest)	Starke AD-Integration, Manager (on-premise), Starling (SaaS), Safeguard (PAM)	Windows-lastige Umgebungen, Mittelstand
Omada Identity	Europäischer Anbieter (DSGVO-konform), starkes SoD-Enforcement	Compliance-intensive Branchen (Finance, Health)

Orientierung für die Auswahl: DIY mit AD und PowerShell ist nur für kleinste Umgebungen unter 100 Usern geeignet. Entra Identity Governance eignet sich für 100-5.000 User in Microsoft-Umgebungen. One Identity und Omada decken 500-5.000 User im Mittelstand ab. SailPoint und Saviynt sind für Enterprises ab 5.000 Usern ausgelegt.

IGA-Implementierungsdauer: Phase 1 (Foundation, Connectors, Basis-Prozesse): 3-4 Monate; Phase 2 (Automation, JML-Automatisierung, Rollen): 4-6 Monate; Phase 3 (Governance, Zertifizierungen, SoD, Reporting): 6-12 Monate. Typisch: 12-18 Monate bis vollständige IGA-Reife.

IGA und Compliance

ISO 27001:2022: A.5.18 (Zugangsrechte: Provisioning + Revocation), A.8.2 (Privilegierte Zugangsrechte, Review quartalsweise), A.5.19 (Zugang von Lieferanten/Dritten). IGA liefert den Audit-Trail für alle Entscheidungen.

SOX (Sarbanes-Oxley): SoD-Enforcement für Finanzprozesse ist Pflicht. Periodische Access Reviews müssen dokumentiert sein. Quarterly User Access Review ist eine typische SOX-Kontrolle.

DSGVO Art. 25 (Privacy by Design): Minimale Berechtigungen sind ein Datenschutz-Grundsatz. IGA erzwingt Least Privilege und beantwortet die Frage: "Wer hat aktuell Zugang zu personenbezogenen Daten, und ist das noch begründet?"

NIS2 Art. 21 (Technische Maßnahmen): "Zugangskontrolle und Benutzerverwaltung" ist explizit als technische Maßnahme genannt. IGA liefert den Nachweis strukturierter Zugriffskontrolle.

BSI IT-Grundschutz ORP.4: Identitäts- und Berechtigungsmanagement ist ein eigener Baustein mit den Anforderungen vollständiger JML-Dokumentation und regelmäßiger Reviews.