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:

Der Lebenszyklus verläuft in den Phasen: Anforderung → Genehmigung → Provisionierung → Nutzung → Review → Deprovisionierung. Drei Ereignistypen treiben den Zyklus an: der Joiner (neuer Mitarbeiter, löst Provisionierung aus), der Mover (Abteilungswechsel, löst Anpassung der Berechtigungen aus) und der Leaver (Mitarbeiter verlässt das Unternehmen, löst Deprovisionierung aus).

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.

Beispiel: Benutzer Hans erhält die Rolle "Buchhaltung". Diese Rolle beinhaltet Lese- und Schreibzugriff auf das ERP-Modul "Kreditoren" sowie Lesezugriff auf "Debitoren". Keinen Zugang hat Hans zum HR-System oder zur AD-Verwaltung.

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

Der moderne Ansatz: Jede Zugriffsanfrage wird gegen Policies geprüft, inklusive Gerätezustand. Die Policy Engine bewertet Identität (MFA bestanden?), Gerätecompliance (EDR aktiv, Patch-Level aktuell?), Netzwerkstandort (VPN, vertrauenswürdiges Netzwerk?), Verhaltensanomalien gegenüber dem Baseline sowie die Sensitivität der angefragten Ressource. Das Ergebnis ist Zugang gewähren, verweigern oder mit Step-up-Authentifizierung sichern.

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): Der Browser wird von der App zum Identity Provider (IdP) weitergeleitet, der Nutzer meldet sich an, der IdP stellt eine SAML Assertion aus, und die App vertraut dieser Aussage des IdP und gewährt Zugang.

OpenID Connect (OIDC) + OAuth 2.0 (JSON/JWT-basiert, moderne Web-/Mobile-Apps): Die App leitet zur Anmeldeseite von Google oder Microsoft weiter, der Nutzer gibt sein Consent, und erhält ein ID Token (JWT). Die App validiert das Token, extrahiert User-Informationen und erstellt eine Session.

FIDO2/Passkeys (passwordless): Der Nutzer authentifiziert sich per Fingerabdruck oder Face ID direkt auf dem Gerät. Der Browser sendet eine kryptographische Assertion an die 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

Im Normalzustand hat Hans keinerlei Admin-Rechte. Bei Bedarf beantragt er "Domain Admin"-Zugang für eine konkrete AD-Aufgabe, die IT-Leitung genehmigt per 4-Augen-Prinzip, und Hans erhält für genau zwei Stunden erhöhte Rechte. Nach Ablauf werden die Rechte automatisch entzogen und alle verwendeten Credentials rotiert.

Identity-Angriffe und Schutzmaßnahmen

Credential Stuffing

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

Der Ablauf: Eine Datenpanne bei Service A landet in Dumps auf haveibeenpwned.com. Der Angreifer kauft oder findet den Dump (user@example.com : Passwort123) und testet automatisiert gegen banking.de, paypal.de, amazon.de und linkedin.com. Der Angriff gelingt überall dort, wo der Nutzer dasselbe Passwort wiederverwendet hat.

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.

Der Ablauf: Eine Phishing-Mail führt den Nutzer zu einer gefälschten "Microsoft Login"-Seite, die tatsächlich ein Evilginx2-Proxy ist. Der Nutzer gibt sein Passwort ein - der Proxy leitet es an echtes Microsoft weiter. Microsoft sendet einen MFA-Push, der Nutzer bestätigt ohne Warnung, und der Proxy stiehlt den Session-Cookie. Der Angreifer hat nun vollen Zugang, ohne eigene Credentials eingegeben zu haben.

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 dem Endgerät extrahiert OAuth/OIDC-Tokens aus dem Browser-Storage und verwendet sie direkt für API-Calls - kein Login nötig, Token oft eine 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.