Identity & Access Management (IAM): Identitäten sicher verwalten

Identitäten sind das neue Perimeter. In einer Welt ohne feste Netzwerkgrenzen - Cloud, Remote Work, BYOD - ist die Frage “Wer bist du?” wichtiger als “Von wo kommst du?”. Identity & Access Management (IAM) umfasst alle Prozesse und Technologien zur sicheren Verwaltung digitaler Identitäten und ihrer Zugriffsrechte.

Der Identity Lifecycle

Jede Identität durchläuft einen Lebenszyklus - unvollständiges Management in jeder Phase schafft Sicherheitslücken:

Anforderung → Genehmigung → Provisionierung → Nutzung → Review → Deprovisionierung
     ↑                                           ↓
  Joiner                                      Mover
  (neuer Mitarbeiter)                    (Abteilungswechsel)
                                                ↓
                                             Leaver
                                       (Mitarbeiter verlässt)

Häufige Lifecycle-Fehler

Joiner: Konto angelegt, aber Standard-Passwort nicht geändert; zu breite Rechte vergeben (“erstmal alles aktivieren, dann schauen”).

Mover: Mitarbeiter wechselt Abteilung, alte Rechte bleiben aktiv (Rechteakkumulation). Nach 5 Jahren: User hat Rechte aus 4 verschiedenen Abteilungen.

Leaver: Mitarbeiterkündigung → IT bekommt es eine Woche später mit → Account war 7 Tage aktiv ohne legitimen Nutzer. Insider Threat Risiko.

Lösung: HR-Integration - IAM-System wird automatisch beim HR-Event getriggert.

Zugriffsmodelle: RBAC vs. ABAC vs. PBAC

RBAC - Role-Based Access Control

Der Standard in den meisten Unternehmen. Benutzer erhalten Rollen, Rollen haben Berechtigungen.

Benutzer Hans → Rolle: "Buchhaltung"
Rolle "Buchhaltung" → Berechtigungen:
  ✓ ERP Modul "Kreditoren" (Lesen + Schreiben)
  ✓ ERP Modul "Debitoren" (Lesen)
  ✗ HR-System (kein Zugang)
  ✗ AD Verwaltung (kein Zugang)

Stärken: Einfach zu verstehen und zu verwalten. Schwäche: Role Explosion (zu viele Rollen), Context-unabhängig.

ABAC - Attribute-Based Access Control

Zugriffsentscheidungen basieren auf Attributen des Users, der Ressource und des Kontexts.

# Beispiel: Arzt darf Patientenakte nur lesen wenn:
# - User.Rolle = "Arzt"
# - User.Abteilung = Patientenakte.Abteilung
# - Patientenakte.Status ≠ "Archiviert"
# - Aktuelles Datum liegt im Behandlungszeitraum

def can_access(user, resource, context):
    return (
        user.role == "doctor" and
        user.department == resource.department and
        resource.status != "archived" and
        context.date in resource.treatment_period
    )

Stärken: Sehr feingranular, kontextsensitiv. Schwäche: Komplex zu implementieren und zu debuggen.

Zero-Trust PBAC - Policy-Based Access Control

Moderner Ansatz: Jede Zugriffsanfrage wird gegen Policies geprüft, inkl. Gerätezustand:

User Anfrage → Policy Engine prüft:
  ✓ Identität (MFA bestanden?)
  ✓ Gerätecompliance (EDR aktiv, Patch-Level aktuell?)
  ✓ Netzwerklocation (VPN? Vertrauenswürdiges Netzwerk?)
  ✓ Verhalten (Anomalie zum Baseline?)
  ✓ Ressource-Sensitivität (Klassifizierung?)
  → Zugang gewährt / verweigert / mit Step-up-Auth

Single Sign-On (SSO) und Föderierte Identität

SSO ermöglicht einen Login für viele Anwendungen - ohne separate Passwörter.

Protokolle

SAML 2.0 (XML-basiert, Enterprise-Standard):

Browser → App → "Wer bist du?" → Identity Provider (IdP)
Browser → IdP → Login → SAML Assertion → App
App vertraut IdP-Aussage → Zugang gewährt

OpenID Connect (OIDC) + OAuth 2.0 (JSON/JWT-basiert, moderne Web-/Mobile-Apps):

App → "Login mit Google/Microsoft"
User → Google → Consent → ID Token (JWT)
App → Token validieren → User-Info extrahieren → Session

FIDO2/Passkeys (passwordless):

User → Browser → Fingerabdruck auf Gerät
Browser → Cryptographic Assertion an App
App → Kein Passwort mehr nötig

Identity Provider im Enterprise

IdP	Stärke
Microsoft Entra ID (Azure AD)	M365-Integration, Conditional Access
Okta	Multi-App, SCIM-Integration, Neutraler
Google Workspace	Google-Ökosystem
Keycloak	Open Source, Self-hosted, DSGVO-freundlich
Active Directory + ADFS	On-Premises, ältere Umgebungen

Privileged Access Management (PAM)

PAM ist IAM für besonders kritische Konten - Administratoren, Service Accounts, Notfallzugänge.

Vault-Konzept

Szenario: Admin benötigt Root-Zugang zu Produktionsdatenbank:

1. Öffnet PAM-Portal (mit MFA)
2. Beantragt Zugang (Ticketnummer, Begründung, Zeitraum)
3. PAM checkt Passwort aus verschlüsseltem Vault aus
4. Admin erhält temporäres Einmal-Credential (4h gültig)
5. Session wird vollständig aufgezeichnet (Video + Keylog)
6. Nach 4h: Credential automatisch rotiert
7. Admin kann Credential nicht “behalten” oder weitergeben

Just-in-Time (JIT) Privilegien

Normal:     Hans = Standard-User, KEIN Admin-Recht

Bei Bedarf: Hans beantragt "Domain Admin" für AD-Aufgabe
Genehmigt:  Ticket von IT-Leitung (4-Augen-Prinzip)
Aktiv:      Hans = Domain Admin für genau 2 Stunden
Danach:     Automatischer Entzug, Rotierung aller verwendeten Credentials

Identity-Angriffe und Schutzmaßnahmen

Credential Stuffing

Angreifer testet Milliarden gestohlene Login-Daten (aus Datenpannen) gegen verschiedene Dienste.

Datenpanne bei Service A → Credentials bei "haveibeenpwned.com"
Angreifer kauft/findet Dump: user@example.com : Passwort123
Testet gegen: banking.de, paypal.de, amazon.de, linkedin.com
Erfolg wenn: User hat dasselbe Passwort auf mehreren Diensten

Schutz:

• Multi-Faktor-Authentifizierung (bricht Credential Stuffing komplett)
• Breached Password Detection (API zu HIBP oder PwnedPasswords)
• Rate Limiting + CAPTCHA auf Login-Endpoints
• Anomalie-Erkennung: Login aus ungewöhnlichem Land/Zeit

Adversary-in-the-Middle (AiTM) Phishing

Überwindet TOTP-basierte MFA durch Session-Cookie-Diebstahl in Echtzeit.

Phishing-Mail → User öffnet Link → "Microsoft Login" (Evilginx2-Proxy)
User gibt Passwort ein → Proxy leitet an echtes Microsoft weiter
Microsoft schickt MFA-Push → User bestätigt (keine Warnung)
Proxy stiehlt Session-Cookie → Angreifer hat Zugang ohne eigene Credentials

Einziger wirksamer Schutz: FIDO2/Passkeys oder phishing-resistente MFA (FIDO2 ist domain-gebunden - funktioniert auf Phishing-Domain NICHT).

Pass-the-Token / Token Theft

Malware auf Endgerät extrahiert OAuth/OIDC Tokens aus Browser-Storage
→ Angreifer nutzt Token direkt für API-Calls (kein Login nötig)
→ Token oft 1 Stunde oder länger gültig

Schutz: Continuous Access Evaluation (CAE) - Token-Invalidierung bei Anomalie-Erkennung in Echtzeit.

Kerberoasting (Active Directory)

Service Accounts mit SPNs: deren Tickets können offline geknackt werden.

Schutz: Managed Service Accounts (gMSA) mit automatisch rotierten 240-Zeichen-Passwörtern.

Identity-Sicherheits-Roadmap

Sofort (0-30 Tage)

1. MFA für alle Mitarbeiter aktivieren (Authenticator-App, kein SMS)
2. Passwort-Manager einführen (keine shared Credentials mehr)
3. Privilegierte Accounts inventarisieren (wie viele Domain Admins gibt es wirklich?)

Kurzfristig (1-3 Monate)

4. SSO einführen (ein Login, volle Sichtbarkeit)
5. Conditional Access Policies (Device Compliance + MFA)
6. Alle Service Accounts auf gMSA migrieren

Mittelfristig (3-12 Monate)

7. PAM-Lösung einführen (CyberArk/BeyondTrust für Enterprise, Azure AD PIM für Microsoft)
8. JIT-Privilegien für alle Admin-Tätigkeiten
9. Identity Governance: regelmäßige Access Reviews
10. FIDO2/Passkeys für High-Value-Accounts

Compliance-Anforderungen

NIS2 Art. 21: MFA für privilegierte Zugänge und alle Remote-Zugriffe explizit gefordert.

ISO 27001 A.5.15-A.5.18: Zugangskontrolle, Benutzerauthentifizierung, Rechte von privilegierten Accounts, geheime Authentifizierungsinformationen.

BSI ORP.4: Identitäts- und Berechtigungsmanagement - Lifecycle, Rollen, Privilegien.

PCI DSS 8.2-8.6: Starke Authentifizierung, Account-Management, Privilegien-Kontrolle.