Identity Governance and Administration (IGA) - Wer darf was und warum?
Identity Governance and Administration (IGA) verwaltet digitale Identitäten, Zugriffsrechte und deren Lebenszyklen: Joiner/Mover/Leaver-Prozesse, Role-Based Access Control (RBAC), Access Reviews (regelmäßige Revalidierung von Berechtigungen), Segregation of Duties (SoD) - Vier-Augen-Prinzip auf Systemebene, Recertification-Kampagnen, Audit-Trail für Compliance. Produkte: SailPoint IdentityNow, Saviynt, One Identity, Microsoft Entra ID Governance.
Identity Governance beantwortet die kritischsten Fragen jedes Unternehmens: Wer hat Zugriff auf was? Warum hat diese Person diesen Zugriff? Und wird er noch benötigt? Ohne IGA entstehen “Berechtigungs-Geisterstände” - jahrelang akkumulierte Rechte, die niemand mehr prüft.
Joiner-Mover-Leaver-Prozess
Der Identitäts-Lifecycle deckt drei kritische Ereignisse ab:
Joiner (Neueintritt)
Wenn HR eine Neueinstellung meldet, wird automatisch ein IGA-Trigger ausgelöst. Template-basierte Rollenzuweisungen sorgen dafür, dass ein neuer „Vertrieb Auszubildender” am ersten Arbeitstag sofort die Standard-Rechte erhält: E-Mail, Teams, CRM-Leserecht und weitere rollenspezifische Zugriffe. Ein Genehmigungs-Workflow stellt sicher, dass der Manager den Zugriffsantrag bestätigt.
Mover (Versetzung/Rollenwechsel)
Bei einem Abteilungswechsel löst HR-Aktion erneut einen IGA-Trigger aus. Alte Rechte der vorherigen Rolle werden entzogen, neue Rechte der neuen Rolle vergeben. Ein kurzer Übergangspuffer von maximal einer bis zwei Wochen ist dabei vertretbar.
Häufiger Fehler - Privilege Creep: In der Praxis behält der Mover oft alle alten Rechte zusätzlich zu den neuen. Nach drei Versetzungen hat die Person die Rechte aller beteiligten Abteilungen angesammelt. Diese schleichende Rechte-Akkumulierung ist eines der häufigsten Sicherheitsprobleme in gewachsenen IT-Umgebungen.
Leaver (Austritt)
Bei Kündigung muss sofort ein IGA-Trigger ausgelöst werden. Am letzten Arbeitstag wird der Account deaktiviert - nicht gelöscht, da der Audit-Trail und archivierte E-Mails erhalten bleiben müssen. Nach 30, 60 oder 90 Tagen erfolgt die endgültige Löschung gemäß Policy.
Die Offboarding-Checkliste umfasst:
- AD-Account deaktiviert
- Exchange-Postfach auf Shared Mailbox umgestellt
- VPN-Zugriff gesperrt
- MFA-Token widerrufen
- SSH-Schlüssel entfernt
- PAM-Accounts deaktiviert
- Externe SaaS-Zugänge (Salesforce, GitHub usw.) entfernt
Role-Based Access Control (RBAC) und Role Mining
RBAC-Hierarchie
RBAC folgt dem Prinzip: Benutzer → Rolle → Berechtigung. Ein strukturiertes Beispiel für den Vertrieb:
Rolle „Vertrieb Junior”:
- CRM: Lesen und Schreiben (eigene Deals)
- ERP: Angebote erstellen
- E-Mail und Teams: Standard
Rolle „Vertrieb Senior”:
- Alles von Junior
- CRM: alle Deals lesen (nicht nur eigene)
- ERP: Rabatte bis 15% genehmigen
Rolle „Vertrieb Manager”:
- Alles von Senior
- CRM: Reports und Admin
- ERP: Rabatte bis 30%
- Personalakte lesen (eigene Mitarbeiter)
Role Mining
Role Mining analysiert bestehende Berechtigungen und leitet aus gemeinsamen Mustern neue Rollen ab. Ein IGA-Tool erkennt automatisch: „Diese 50 User haben alle dieselben 10 Rechte - das ist eine neue Rolle.” Role Mining ist der Ausgangspunkt für eine RBAC-Einführung in gewachsenen Umgebungen.
Segregation of Duties (SoD)
SoD verbietet kritische Berechtigungskombinationen die das Vier-Augen-Prinzip aushebeln würden:
| Falsch | Richtig |
|---|---|
| Gleicher User legt Bestellung an und genehmigt sie | Antrag (User A) → Genehmigung (User B) |
Typische SoD-Konflikte, die IGA automatisch erkennen und verhindern muss:
- Buchhaltung: Zahlung anlegen und Zahlung freigeben
- Einkauf: Lieferant anlegen und Bestellung genehmigen
- IT: Admin-Account erstellen und Sicherheit auditen
IGA erzwingt SoD automatisch: Ein erkannter Konflikt blockiert die zweite Berechtigung. Ein Override ist nur mit zusätzlicher Genehmigung und dokumentierter Begründung möglich.
Access Reviews (Revalidierung)
Warum Access Reviews?
- Privilege Creep kontinuierlich verhindern
- Compliance-Anforderungen erfüllen: ISO 27001 A-8.2, SOX, DSGVO, NIS2
- Least Privilege im laufenden Betrieb aufrechterhalten
Review-Typen
Manager Reviews (häufigste Form): Der Manager prüft die Zugriffsrechte aller direkten Mitarbeiter. Die zentrale Frage: „Braucht dieser Mitarbeiter noch dieses Recht?” Frequenz: halbjährlich, bei kritischen Systemen quartalsweise. Aktionen: bestätigen, entziehen oder delegieren.
Owner Reviews: Der Anwendungs-Owner prüft alle User seiner Anwendung. Die Frage: „Warum hat dieser User dieses Recht in meiner App?” Besonders geeignet für applikationsspezifische Prüfungen.
Role Reviews: Prüfung wer in einer privilegierten Gruppe ist (Domain Admins, Exchange-Admins usw.). Frequenz: monatlich für privilegierte Rollen.
Automated Reviews: Automatische Erkennung von gesperrten Usern die noch Rechte haben sowie von Usern im Leaver-Status.
Review-Prozess im IGA-Tool
- Campaign erstellt: „Q3 2026 Access Review”
- Reviewer erhält E-Mail: „Sie müssen 23 Zugriffsrechte prüfen”
- Self-Service Portal: bestätigen, entziehen oder kommentieren
- Eskalation: nach 7 Tagen ohne Aktion → automatische Erinnerung
- Nach 14 Tagen keine Aktion → Auto-Revoke (Fail-Safe!)
- Abschlussbericht: z.B. 98% der Rechte bestätigt, 23 entzogen
IGA-Produkte im Überblick
| Produkt | Positionierung | Stärken |
|---|---|---|
| SailPoint IdentityNow (Cloud) / IdentityIQ (On-Prem) | Marktführer (Gartner MQ), für 2.000+ Mitarbeiter | AI-basiertes Role Mining, sehr umfangreich |
| Saviynt Security Manager | Mid-Market und Enterprise | Cloud-native, kombiniert IGA und PAM, gute Application Governance |
| One Identity Manager | Microsoft-zentrierte Umgebungen | Deutsch (Frankfurt), DSGVO-nativ, starke AD/Azure AD Integration |
| Microsoft Entra ID Governance | Microsoft-Shops (im P2-Bundle) | Native in Azure AD/M365, kostengünstig, aber nur Azure/M365 |
Microsoft Entra ID Governance im Detail
Entra bietet nativ Access Packages (Entitlement Management), direkte Access Reviews in Entra ID, PIM (Privileged Identity Management) für Just-in-Time-Zugriff sowie Ablauffristen für Zugriffe:
Ein Beispiel-Access-Package „Finanz-Zugriff” bündelt SharePoint Finance-Site, Power BI Workspace und SAP Finance-App in einem Paket, das der Manager genehmigen muss. Nach 90 Tagen läuft der Zugriff automatisch ab und erfordert eine neue Anfrage.
Compliance-Nachweise mit IGA
IGA liefert für Audits konkrete, auditierbare Dokumente:
ISO 27001 A-8.2 (Privileged Access Rights):
- Nachweis wer privilegierte Rechte hat (IGA-Report)
- Access Reviews: Dokumentation der letzten vier Quartale
- SoD: welche Konflikte wurden verhindert oder gehandhabt?
SOX (für börsennotierte Unternehmen):
- Vollständiger Audit-Trail für Finanz-System-Zugriff
- Separation of Financial Duties lückenlos nachweisbar
- 100% prüfbar, null Ausnahmen ohne Dokumentation
DSGVO:
- Datenminimierung: nur nötige Rechte auf personenbezogene Daten
- Access Reviews zeigen Abbau überfluessiger Zugriffsrechte
- Nachweis: warum hat User X Zugriff auf Kundendaten?
NIS2 (Art. 21):
- Zugangsmanagement als Pflichtmaßnahme explizit genannt
- IGA-Dokumentation für sicherheitskritische Systeme und privilegierte Rechte
Typische Audit-Fragen und IGA-Antworten
Frage: „Wer hatte Zugriff auf Kundendaten im Januar 2026?” IGA-Antwort: Export aller Zugriffsrechte plus Nutzungsprotokoll für den Zeitraum.
Frage: „Haben ausgeschiedene Mitarbeiter noch aktive Konten?” IGA-Antwort: Bericht „Leaver mit aktivem Account” - leer bedeutet compliant.
Frage: „Wurden Rechte nach Abteilungswechsel entzogen?” IGA-Antwort: Mover-Protokoll: alte Rechte X entfernt, neue Rechte Y vergeben am Datum Y.
