Identity and Access Management (IAM) umfasst Regeln, Prozesse und technische Systeme, mit denen digitale Identitäten verwaltet und Zugriffe gesteuert werden. IAM beantwortet über den gesamten Lebenszyklus vier Fragen: Wer ist die Identität, wie weist sie sich aus, worauf darf sie zugreifen und wie wird dieser Zugriff nachvollziehbar geändert oder beendet?
Welche Bestandteile gehören zu IAM?
| Baustein | Aufgabe |
|---|---|
| Identitätsquelle | Benutzer, Geräte, Anwendungen und technische Konten mit eindeutiger Verantwortlichkeit verwalten. |
| Authentifizierung | Identität mit Passwort, Zertifikat, MFA oder Passkey nachweisen. |
| Autorisierung | Rollen, Gruppen, Attribute und Richtlinien in konkrete Zugriffsentscheidungen übersetzen. |
| Provisionierung | Zugänge bei Eintritt, Rollenwechsel und Austritt erstellen, anpassen und entfernen. |
| Föderation und SSO | Identitäten über Organisations- und Anwendungsgrenzen mit SAML oder OpenID Connect verwenden. |
| Governance | Berechtigungen genehmigen, regelmäßig überprüfen, protokollieren und Verantwortlichen zuordnen. |
| Privileged Access | Administrative und besonders wirkungsvolle Rechte getrennt, zeitlich begrenzt und überwacht vergeben. |
Authentifizierung ist nicht Autorisierung
Eine erfolgreiche Anmeldung bestätigt nur die Identität. Sie sagt nicht, welche Daten oder Funktionen verwendet werden dürfen. Autorisierung muss deshalb an jeder relevanten Aktion durchgesetzt werden. Eine Anwendung mit sicherem Login kann weiterhin Broken Access Control enthalten. Ebenso ersetzt 2FA keine minimalen Rechte, saubere Rollentrennung oder sichere Sitzungen.
Wie unterscheiden sich AD, Entra ID und IAM?
IAM ist das übergeordnete Konzept. Active Directory verwaltet vor allem Windows-Domänen, Geräte und Kerberos-/LDAP-basierte Zugriffe. Microsoft Entra ID steuert Cloud-Identitäten, SaaS- und API-Zugriffe. Beide können Bestandteile einer IAM-Architektur sein. Für anwendungsübergreifendes Single Sign-on werden häufig SAML oder OpenID Connect eingesetzt.
Welche IAM-Risiken treten häufig auf?
- Überprivilegierung:
Rollen wachsen über Jahre, Ausnahmen werden nicht entfernt und technische Konten besitzen unnötige Rechte. - Verwaiste Identitäten:
Konten ehemaliger Mitarbeiter, alter Anwendungen oder externer Partner bleiben aktiv. - Unsichere Wiederherstellung:
Passwort-Reset und Helpdesk-Prozesse umgehen starke Anmeldung oder ermöglichen Account Enumeration. - Föderationsfehler:
Aussteller, Zielgruppe, Signatur oder Antwortbezug von SAML- und OIDC-Nachrichten werden falsch geprüft. - Gestohlene Sitzungen und Tokens:
Ein sicherer Login schützt nicht, wenn anschließend ein langlebiges Token übernommen wird. - Fehlende Kontrolle technischer Identitäten:
API-Schlüssel, Service Principals und CI/CD-Konten werden nicht inventarisiert oder rotiert.
Wie wird IAM sinnvoll umgesetzt?
- Eine maßgebliche Identitätsquelle, Eigentümer und eindeutige Joiner-Mover-Leaver-Prozesse festlegen.
- Rollen klein halten, privilegierte Rechte separat behandeln und zeitlich begrenzten Zugriff bevorzugen.
- Phishing-resistente Anmeldung mit Passkeys beziehungsweise WebAuthn dort einsetzen, wo das Risiko sie rechtfertigt.
- Zugriffsentscheidungen, Rollenänderungen, neue Anwendungen und fehlgeschlagene Anmeldungen nachvollziehbar protokollieren.
- Berechtigungen regelmäßig durch fachlich Verantwortliche bestätigen und ungenutzte Identitäten automatisch deaktivieren.
- Anmeldung, Tokenprüfung und Session Management gemeinsam testen.
Vielen Dank für dein Feedback! Wir werden es prüfen und unseren Artikel anpassen.