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

Abgrenzung der Begriffe:

IAM (Identity and Access Management):
  → Breitester Begriff: Authentifizierung + Autorisierung
  → Umfasst: SSO, MFA, Directory Services (AD, LDAP)
  → Fokus: "Wer bist du? Was darfst du?"
  → Tools: Azure AD/Entra ID, Okta, Ping Identity

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

IGA (Identity Governance and Administration):
  → Governance-Schicht über IAM
  → Fokus: "Wer DARF was? Ist das noch gültig? Wer hat genehmigt?"
  → Lebenszyklus-Management: Joiner → Mover → Leaver
  → Compliance: Zugriffszertifizierungen, SoD-Enforcement, Audit Trails
  → Tools: SailPoint, Saviynt, Microsoft Entra Identity Governance, One Identity

Zusammenspiel:
  HR-System → IGA (Joiner-Prozess) → IAM (Account anlegen) + PAM (Privileged Access)
  HR-System → IGA (Leaver-Prozess) → IAM + PAM (sofort deaktivieren!)

Joiner-Mover-Leaver Prozess

JML (Joiner-Mover-Leaver) - Kernprozess von IGA:

JOINER (Neuer Mitarbeiter):
  Trigger:  HR-System erstellt neuen Mitarbeiter-Datensatz
  Ablauf:
    1. IGA empfängt HR-Event (API, CSV, SCIM-Push)
    2. Identity wird erstellt: displayName, department, jobTitle, manager
    3. Role Assignment: basierend auf Rolle/Abteilung (Role Mining!)
       Beispiel: "Junior Developer, IT" → Standardzugang:
         □ Azure AD Account
         □ E-Mail-Account (Exchange)
         □ Jira (Developer-Berechtigung)
         □ GitHub Org (ausgewählte Repos)
         □ VPN-Zugang
    4. Genehmigungsworkflow: Manager bestätigt (für nicht-Standard-Zugänge)
    5. Account-Erstellung in Zielsystemen (via Connector/SCIM)
    6. Willkommens-E-Mail mit Credentials
    7. Audit: alle Aktionen mit Zeitstempel protokolliert

  Automatisierungsgrad:
    Standard-Zugang:   Vollautomatisch (kein manueller Schritt)
    Sonder-Zugang:     Genehmigungsworkflow (Manager → System Owner)
    Privileged Access: PAM-Prozess (separate Genehmigung!)

MOVER (Versetzung, Beförderung, Abteilungswechsel):
  Trigger:  HR-Update: Abteilung, Jobtitel, Vorgesetzter ändert sich
  Ablauf:
    1. IGA empfängt HR-Änderungs-Event
    2. Neue Role Assignment berechnen
    3. Delta-Analyse: was kommt dazu? Was muss weg?
    4. Neue Berechtigungen: automatisch oder via Workflow
    5. KRITISCH: Alte Berechtigungen entziehen (SoD-Check!)
       → Mitarbeiter sollte NUR neue Rolle haben, NICHT alte!
    6. Transition Period: ggf. 30-Tage-Überlappung (Business-Entscheidung)
    7. Audit Trail: alle Änderungen dokumentiert

  Typisches Problem ohne IGA:
    Person wechselt von Finanz nach IT:
    → Behält Finanz-Zugang (nicht entzogen)
    → Erhält IT-Zugang (neu)
    → Nach 3 Jahren: 5 Rollenwechsel = 5 Sätze akkumulierte Berechtigungen
    → "Permission Creep" oder "Privilege Creep" - hochgefährlich!

LEAVER (Kündigung, Austritt):
  Trigger:  HR-Event: Termination Date oder sofort bei Kündigung
  Ablauf (kritisch - schnell!):
    T-30 Tage:  Vorbereitung (Asset-Liste, Knowledge Transfer)
    T-0 (letzter Arbeitstag):
      □ Account-Deaktivierung (ALLE Systeme!): < 1 Stunde nach Trennung
      □ Passwort-Reset aller bekannten Konten
      □ MFA-Tokens entfernen
      □ Active Sessions terminieren (SSO-Session-Invalidierung!)
      □ VPN-Zertifikate widerrufen
      □ API-Keys und Service-Accounts deaktivieren
      □ Shared-Accounts Passwort wechseln (falls Zugang)
    T+7 Tage:   Account archivieren (nicht löschen! Audit!)
    T+90 Tage:  Account final löschen (nach Aufbewahrungsfrist)

  Sofortiger Leaver (fristlose Kündigung, Sicherheitsvorfall):
    → Notfall-Deaktivierung in < 15 Minuten
    → IGA-Workflow: "Emergency Termination" mit Bestätigung durch CISO/HR
    → Parallel: alle Sessions forcieren + alle Tokens widerrufen

  SLAs für Leaver:
    Standard:           < 24 Stunden (nächster Werktag)
    Hochrisikoposition: < 1 Stunde (sofort nach HR-Bestätigung)
    Security Incident:  < 15 Minuten (manueller Trigger durch CISO)

Role Management und Role Mining

Rollenkonzept in IGA:

Business Roles (Was macht der Mensch?):
  → "Junior Developer", "HR Manager", "Finance Director"
  → Abstrakte Geschäftsfunktionen (kein technisches Detail)
  → Durch HR definiert und gepflegt
  → Beispiel: "Sales Manager DACH"

IT Roles / Technical Roles (Was braucht er dafür?):
  → "CRM Power User", "AD Domain User", "SharePoint Contributor"
  → Technische Berechtigungen die der Business Role entsprechen
  → Durch IT gepflegt
  → Mapping: 1 Business Role = mehrere IT Roles

Entitlement (Technische Berechtigung):
  → Konkrete Berechtigung in einem System
  → "Jira Gruppe: developers-backend"
  → "AD Gruppe: SG-FILE-SHARE-Marketing-RW"
  → "Salesforce Profil: Standard User"

Role Mining - automatische Rollenerkennung:
  Problem: Unternehmen haben oft keine strukturierten Rollen → historisch gewachsen
  Lösung: Analyse bestehender Berechtigungen → ähnliche User = gleiche Rolle

  # SailPoint Role Mining (konzeptuell):
  1. Export: alle User + ihre Entitlements
  2. Clustering: Ähnlichkeitsanalyse (k-Means, Hierarchical)
  3. Kandidaten-Rollen: "75% der Developer haben genau diese 12 Entitlements"
  4. Review: IT + HR validiert Rolle
  5. Import: Rolle in IGA angelegt und Mitglieder assigned

  Typische Rollenhierarchie:
  Basisrolle (alle):     E-Mail, SharePoint Read, VPN-Basic
  IT-Abteilung:          +AWS Console Read, +Confluence, +Jira
  Developer-Backend:     +GitHub Teams-Backend, +k8s Namespace Dev
  Senior Developer:      +AWS Console Write (DEV only), +Code Review Approval
  Tech Lead:             +Production ReadOnly, +Architecture Confluence
  IT-Admin:              +AD-Admin Tier 1, +ITSM Full, +Cloud Management

Segregation of Duties (SoD)

SoD - Trennung von Aufgaben zur Betrugsprävention:

Warum SoD?
  → Vier-Augen-Prinzip in IT-Systemen
  → Niemand darf Zahlung anlegen UND genehmigen (Finanzrisiko)
  → Niemand darf Account anlegen UND Audit durchführen (Kontrollrisiko)
  → SOX, ISO 27001, NIS2: alle fordern SoD für kritische Prozesse

SoD-Konflikt-Beispiele:
  KRITISCH:
    "Buchhalter kann Kreditoren anlegen" + "Buchhalter kann Zahlungen freigeben"
    → Betrugsrisiko: falsche Rechnungen an eigene Firma!

    "IT-Admin kann AD-Accounts anlegen" + "IT-Admin ist sein eigener Auditor"
    → Kontrolllücke: kann Spuren verwischen

  MITTEL:
    "Einkäufer kann Bestellungen anlegen" + "Einkäufer kann Bestellungen genehmigen"
    → Einkäufer kann eigene Bestellungen ohne Kontrolle freigeben

  NIEDRIG:
    "Entwickler kann Code schreiben" + "Entwickler kann Code in Prod deployen"
    → Change Management umgehbar (nur riskant ohne andere Kontrollen)

SoD-Rule-Set erstellen:
  Format: "Berechtigung A" KONFLIKT-MIT "Berechtigung B"

  IGA-Konfiguration (YAML-Konzept):
  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:
  Präventiv: IGA verhindert Zuweisung wenn Konflikt entsteht
  Detektiv:  Periodischer SoD-Report für bestehende Konflikte
  Kompensierend: Mitigating Control dokumentieren (wenn Konflikt unvermeidbar)

Vorgehen:
  1. Rollenmatrix aufbauen (alle Rollen × alle Rollen)
  2. Kritische Prozesse identifizieren (Finance, IT-Admin, HR)
  3. Konfliktregeln definieren (mit Business-Input!)
  4. Bestehende Verletzungen: remediate oder mitigating control
  5. Laufende Durchsetzung: präventiv im Workflow

Zugriffszertifizierung (Access Review)

Periodischer Review aller Berechtigungen - ISO 27001 A.9.2.5 + SOX:

Was wird reviewt?
  Regelmäßig (quartalsweise/jährlich):
    □ Alle Benutzer und ihre aktuellen Berechtigungen
    □ Privilegierte Accounts (Admin, Service Accounts): quartalsweise
    □ Normaler Mitarbeiter: jährlich
    □ Externe (Contractor): bei Vertragsende + jährlich

Review-Prozess:
  1. IGA generiert Kampagne ("Q1 2026 Access Review")
  2. Manager/Certifier erhält Liste seiner direkt unterstellten Mitarbeiter
  3. Pro Mitarbeiter: Liste aller Berechtigungen
  4. Zertifizierer entscheidet: APPROVE / REVOKE / DELEGATE
  5. Widerspruch: Revoke ausgelöst → Berechtigung entzogen
  6. Non-Response: Erinnerungen → Eskalation → Auto-Revoke
  7. Bericht: Zertifizierungsrate, revokte Entitlements, Dauer

Best Practices:
  → Kampagne nicht zu groß (Ermüdungseffekt → alle klicken "Approve")
  → Risikobasiert: High-Risk-Zugang häufiger reviewen
  → Context anzeigen: "Diese Person hatte diesen Zugang seit 847 Tagen
     und hat ihn zuletzt vor 450 Tagen genutzt" → fundierte Entscheidung
  → Automated Recommendations: IGA empfiehlt "Revoke" bei Inaktivität

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

Audit-Trail (ISO 27001):
  Jede Entscheidung wird gespeichert:
  "2026-03-01T10:30:00Z | certifier=john.doe | user=jane.smith |
   entitlement=SAP-MM-Admin | decision=REVOKE | reason=Left department"

IGA-Produkte im Vergleich

Marktübersicht (Stand 2026):

SailPoint Identity Security Cloud:
  → Marktführer (Gartner Magic Quadrant Leader seit 2015)
  → KI-basiertes Role Mining und Anomalie-Erkennung
  → IdentityNow (SaaS) oder IdentityIQ (on-premise)
  → Stärken: umfangsreichste Connector-Bibliothek (250+ Apps)
  → Schwächen: Komplex, teuer (Enterprise-Preise)
  → Geeignet: Enterprise 1000+ Mitarbeiter

Saviynt Enterprise Identity Cloud:
  → Kombination IGA + PAM + CIEM (Cloud IGA)
  → Cloud-nativ, gute Azure/AWS-Integration
  → CIEM: Cloud Infrastructure Entitlement Management
  → Geeignet: Cloud-first Unternehmen

Microsoft Entra Identity Governance:
  → Bestandteil von Microsoft 365 E5 / Entra ID P2
  → Access Reviews, Entitlement Management, Lifecycle Workflows
  → Stärken: nativ in M365-Ökosystem integriert (kein extra Connector)
  → Schwächen: begrenzt auf Microsoft-zentrierte Umgebungen
  → Geeignet: Microsoft-heavy Unternehmen

One Identity (Quest):
  → Stärke: Active Directory-Integration
  → Manager (on-premise AD), Starling (SaaS), Safeguard (PAM)
  → Geeignet: Windows-lastige Umgebungen, Mittelstand

Omada Identity:
  → Europäischer Anbieter (dänisch), DSGVO-konform
  → Stärke: Komplianzmanagement und SoD-Enforcement
  → Geeignet: Compliance-intensive Branchen (Finance, Health)

Build vs. Buy:
  DIY (AD + PowerShell):  Nur für kleinste Umgebungen (<100 User)
  Entra Identity Gov:     100-5000 User, Microsoft-Umgebung
  One Identity / Omada:   500-5000 User, Mittelstand
  SailPoint / Saviynt:    5000+ User, Enterprise

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

IGA und Compliance

Regulatorische Anforderungen die IGA adressiert:

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 Audit-Trail für alle Entscheidungen

SOX (Sarbanes-Oxley) - finanzrelevante Systeme:
  → SoD-Enforcement für Finanzprozesse Pflicht
  → Periodische Access Reviews dokumentiert
  → Quarterly User Access Review als SOX-Kontrolle

DSGVO Art. 25 (Privacy by Design):
  → Minimale Berechtigungen = Datenschutz-Grundsatz
  → IGA erzwingt Least Privilege
  → Verarbeitungsverzeichnis: Wer hat Zugang zu personenbezogenen Daten?
  → Access Review beantwortet: "Haben alle diese Zugriffsberechtigung?"

NIS2 Art. 21 (Technische Maßnahmen):
  → "Zugangskontrolle und Benutzerverwaltung" explizit genannt
  → IGA als Nachweis strukturierter Zugriffskontrolle

BSI IT-Grundschutz ORP.4:
  → Identitäts- und Berechtigungsmanagement als eigener Baustein
  → Anforderungen: vollständige JML-Dokumentation, regelmäßige Reviews