Identity & Access Management

Kurze Zusammenfassung

IAM ist eine Sammlung von Prozessen, Richtlinien und Tools, die sicherstellen, wer auf was zugreift, unter welchen Bedingungen und wie es kontrolliert wird. Ziele: Minimierung redundanter Rechte, Reduzierung der Angriffsfläche, Beschleunigung von Onboarding und Audit, Compliance (PCI DSS, DSGVO etc.) und messbare Zugriffssicherheit.

Grundlegende Konzepte

Identität: Person (Mitarbeiter, Auftragnehmer), Service/Anwendung, Gerät.
Authentifizierung (AuthN): Überprüfung des „Wer“ (Passwort → MFA → Parless FIDO2/Passkeys).
Autorisierung (AuthZ): Entscheidung „was erlaubt ist“ (RBAC/ABAC/ReBAC, Richtlinien).
Anmeldeinformationen (Credentials): Passwörter, Schlüssel, Token, Zertifikate (mTLS).
Secret Management: KMS/HSM/Vault, Rotationen, kurze TTLs, dynamische Geheimnisse.
Lebenszyklus: Joiner-Mover-Leaver (JML) - Erstellen, Rollen ändern, abrufen.

IAM-Zielarchitektur

Ebenen und Rollen:

IdP (Identitätsanbieter): SSO, MFA, Katalog, Verband (OIDC/SAML), Risikorichtlinien.
PDP/PEP: Decision/Enforcement - Policy Engine (OPA/Cedar) + Anwendungspunkte (API Gateways, Proxy, Service Mesh).
Kataloge/HR-System: Quelle der Wahrheit nach Mitarbeitern und Rollen.
Providing: SCIM/Automation zur Erstellung/Änderung/Rückruf von Zugriffen.
Audit: Zentrale Protokolle, UEBAs, Rollen- und Zugriffsberichte.

Zugriffsfluss (user→app):

SSO (+ MFA) → Token-Ausgabe (OIDC/JWT/SAML) → PEP überprüft Token/Kontext → PDP entscheidet über Richtlinie (Rolle/Attribute/Risiko) → Anwendung gewährt/verweigert Zugriff.

Authentifizierung: Von Passwörtern zu Passkeys

Passwörter: Nur mit Passwortmanagern, mindestens 12-14 Zeichen, keine Rotation „nach Kalender“, aber bei einem Vorfall obligatorisch.
Standard-MFA: TOTP/WebAuthn/Push; Vermeiden Sie SMS als Hauptfaktor.
Parless Login: FIDO2/passkeys für kritische Domains.
Adaptive AuthN: Berücksichtigen Sie das Risikosignal (Geo, ASN, Gerät, Anomalien) → erfordern Sie einen zusätzlichen Faktor/Block.

Zulassung: RBAC, ABAC, ReBAC

RBAC: Funktionsgerechte Rollen (Support, Finance, DevOps). Einfach und verständlich, aber „wächst“.
ABAC: Regeln nach Attributen (Abteilung, Risikostufe, Zeit, Zone, Ressourcenbeschriftungen). Skalierbar.
ReBAC: Beziehung „Wer bezieht sich auf was“ (Projektbesitzer, Teammitglieder). Praktisch für Multi-Tenant-Szenarien.

Best Practices:

Kombinieren Sie RBAC (Grundraster) + ABAC/ReBAC (Kontext/Grenzen).
JIT (Just-In-Time): Erteilung temporärer Privilegien durch Request/Approve, automatischer Widerruf.
JEA (Just-Enough Access): Minimal ausreichende Rechte für eine Operation.
PAM: isolierte „starke“ Zugriffe (DB/Cloud Admins) mit Session Broker, Screen/Command Recording und Short-Life Credits.

Verband und SSO

Protokolle: OIDC (JWT-Token), SAML 2. 0 (XML assertions) - für externe Anbieter/Partner.
SSO: Single Entry Point mit MFA, Phishing-Reduzierung, zentraler Rückruf.
B2B/B2C: Föderation mit Partnern, Bereichsbeschränkung, Domänenrichtlinien.
mTLS/m2m: Verwenden Sie für Dienste die kurzlebigen x.509 (SPIFFE/SVID) oder OAuth2 Client Credentials.

Lebenszyklus (JML) und Präsentation

Joiner: automatisches SCIM-Provisioning von Accounts und Basisrollen aus HR/Katalog.
Mover: Rollen ändern sich automatisch nach Attributen (Abteilung, Projekt, Standort).
Leaver: sofortiger Widerruf von SSOs, Schlüsseln, Tokens, Zugriffen auf Repositories/Clouds/CIs/CDs.
Prozesse: Zugriffsanfragen (ITSM), SoD-Matrix (Aufgabenteilung), periodische Zugriffsprüfung.

Geheimnisse, Schlüssel und Rotationen

KMS/HSM: Speichern Sie Root/Critical Keys, aktivieren Sie das Operations Audit.
Vault/Secrets-Manager: dynamische Credits (DBs, Clouds), Auto-Dröhnen beim Abschluss der TTL.
Rotationen: OAuth-Token, JWT-Signaturschlüssel, Dienstpasswörter - nach Zeitplan und bei Vorfällen.
mTLS: kurzlebige Zertifikate (Stunden/Tage), automatische Neuausstellung.

Richtlinien und Lösungsmotor

Deklarativität: Richtlinien in Git speichern; in CI (Policy-Tests) prüfen.
Kontext: Zeit/Ort/ASN/Risikostufe/Gerätestatus (MDM/EDR).

Beispiel (Rego, vereinfacht):

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

Überwachung, SLO und Audit

Metriken:

Erfolg AuthN/AuthZ (%), p95 Login-/Lösungszeit, Anteil MFA/No-Parol-Eingänge.
Anzahl der JIT/PAM-Eskalationen, durchschnittliche Dauer der Privilegien.
Abdeckung von Compliant-Geräten, Anteil von kurz lebenden Geheimnissen.

SLO (Beispiele):

Verfügbarkeit von SSO/IdP ≥ 99. 95% im Monat.
p95 AuthZ decision ≤ 50 мс.
100% Deaktivierung des Kontos ≤ 15 Minuten nach dem Offboarding.
Audit und UEBA: zentralisierte, unveränderliche Protokolle (Zugriffe, Rollenänderungen, fehlgeschlagene Eingaben, PDP-Lösungen), Verhaltensanalysen und Anomaliealarme.

Incident-respons im IAM

Kompromittierung von Token/Schlüsseln: sofortiger Widerruf, erzwungenes Logout, Rotation von Signaturschlüsseln, Re-Issue von kurz lebenden Geheimnissen.
Rechtsmissbrauch: Konto sperren, JIT/JEA sperren, Access Review auf benachbarte Entitäten durchführen.
IdP ist nicht verfügbar: Offline-Modi (temporäre Cache-Validierung von Token mit kurzer TTL), priorisierte Wiederherstellungsverfahren.
Phishing: obligatorische MFA, Risikoüberprüfungen von Sitzungen, Benachrichtigungen an Benutzer, Schulungen.

Wolken und Kubernetes (Muster)

Public Cloud IAM: Verwenden Sie native Rollen mit dem Prinzip des Least Privilege; anstelle von „ewigen“ Schlüsseln - Workloads mit einer OIDC-Verbindung zur Cloud (IRSA/Workload Identity).
Kubernetes: RBAC nach Nijmspaces/Rollen, begrenzen 'cluster-admin'; Geheimnisse - durch externe Manager; Service-Mesh + OPA für L7-Richtlinien; Admission-Controller (signierte Bilder, Verbot „: neueste“).
API-Gateways: JWT/mTLS-Validierung, Geschwindigkeitsbegrenzungen, Request Signing (HMAC) für empfindliche Endpunkte.

Praxis für iGaming/Fintech

Zugangsdomänen: Zahlungen, Fraud, PII, Content Provider - durch Rollen und Netzwerksegmente zu isolieren.
SoD: Verbot der Kombination widersprüchlicher Rollen (z. B. Erstellen einer Promo + Genehmigen von Zahlungen).
PAM und JIT: für den Zugriff auf PSP/Banken und Prod-DB - nur über den Session-Broker, mit Aufzeichnung und Auto-Recall.
Compliance: PCI DSS - MFA, Mindestprivilegien, Segmentierung der CHD-Zone; DSGVO - Prinzip der Datenminimierung und PII-Zugriffspunktprotokolle.
Partner und Anbieter von Inhalten: Verband und per-tenant Politik; kurzlebige Token und IP/ASN-allow-list.

Typische Fehler

„Ewige“ Schlüssel und Token: Es gibt keine Rotation und TTL → ein hohes Risiko von Lecks.
Manuelles Offboarding: Verzögerungen beim Widerruf von Rechten → „gespenstische“ Zugriffe.
Monolithische Rollen: eine „Superrolle“ anstelle von Komposition und Attributen.
MFA nur im Admin-Bereich: MFA muss für alle Eingänge und kritischen Operationen sein.
Logs „ins Nirgendwo“: keine Zentralisierung und UEBA → späte Erkennung von Vorfällen.

Roadmap für die IAM-Implementierung

1. Bestandsaufnahme der Benutzer/Dienste/Ressourcen; Daten- und Empfindlichkeitskarte.
2. SSO + MFA für alle, Phishing-Resistant Faktoren.
3. Rollenmodell: Basis-RBAC + -Attribute (ABAC) für den Kontext; SoD-Matrix.
4. SCIM Providing: automatische Erstellung/Änderung/Entzug von Rechten aus HR/Katalog; Bewerbungen und Upruvas im ITSM.
5. PAM und JIT/JEA: für privilegierte Zugänge; Aufzeichnung von Sitzungen, kurze TTL.
6. Secret Management: Ablehnung statischer Schlüssel; dynamische Geheimnisse, Rotationen, mTLS mit kurzen Zertifikaten.
7. Richtlinien in Git + CI: Regeltests, Änderungskontrolle, kanarische Richtlinienbereitstellungen.
8. Beobachtbarkeit und SLO: AuthN/AuthZ Dashboards, Alerts, regelmäßige Access Review.

Beispiele für Artefakte

AWS IAM Policy (mindestens S3-Berichte lesen)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (namespace-scoped developer)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: Genehmigungen für ABAC (Beispiel)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

Eine Richtlinie kann erfordern, dass' device _ compliant = true' und 'tenant' mit einer Ressource übereinstimmen.

🚨 check-list> Prüfliste

SSO ist für alle Anwendungen aktiviert; MFA Standard, passkeys Priorität.
RBAC ist definiert; ABAC/ReBAC fügen Kontext hinzu; JIT/JEA implementiert.
PAM schützt privilegierte Zugänge; Die Sitzungen werden aufgezeichnet.
SCIM-Providing von HR; offboarding ist vollautomatisch.
Geheimnisse sind dynamisch, mit kurzer TTL; Rotationen sind automatisiert.
Richtlinien werden in Git versioniert, in CI getestet; Es gibt Kanarienbilder.
Dashboards und SLOs nach AuthN/AuthZ; zentrale Protokolle und UEBA.
Regelmäßige Access Review und SoD-Prüfungen; Berichte für Compliance.

FAQ

Braucht jeder ReBAC?
Nein. Für einfache Umgebungen ist RBAC + ABAC ausreichend. ReBAC ist nützlich in einer komplexen Hierarchie von Ressourceneigentum und Multi-Tenant.

Kann ich lokale Konten hinterlassen?
Nur für Break-Glass und Offline-Szenarien, mit strengen Einschränkungen und periodischer Überprüfung.

Wie lässt sich die „Rollenexplosion“ reduzieren?
Erhöhen Sie die Granularität von Ressourcen, verwenden Sie AVAS/Templates, automatisieren Sie Revue und verzichten Sie auf ungenutzte Rollen.

Summe

Eine ausgereifte IAM-Architektur ist SSO + MFA, minimal erforderliche Rechte, automatisiertes JML, zentralisierte Richtlinien und Überwachbarkeit. Durch die Kombination von RBAC mit attributiven und relationalen Modellen, die Anwendung von JIT/JEA und PAM sowie die Automatisierung von Secret-Provisioning und Rotation erhalten Sie einen Managed, Validable und Scale-Up Access, der die Sicherheits- und Geschäftsanforderungen erfüllt.