Identitäts- und Zugriffsmanagement (IAM) ist einer der kritischsten Sicherheitsbereiche in Cloud-Umgebungen. In diesem Abschnitt behandeln wir die wichtigsten IAM-Konzepte und -Technologien.
Federated Identity
Federated Identity ist ein Kommunikationsmodell, bei dem mehrere Organisationen oder Systeme ein gemeinsames Authentifizierungsmechanismus verwenden. Dies ermöglichten die Schaffung und weitere Verwendung einer einzigen digitalen Identität zur Authentifizierung an diesen Systemen oder Organisationen. Im Mittelpunkt dieses Kommunikationsmodells steht der Identity Provider (IdP), dem alle anderen Teilnehmer vertrauen.
Der Einsatz von Federated Identity bringt mehrere Vorteile mit sich: eine einheitliche Benutzeridentität (kein Bedarf, mehrere Konten zu pflegen), geringerer Administrationsaufwand und zentralisierte Zugriffskontrolle.
Aus Security-Sicht ist Federated Identity ein Single Point of Failure, da ein kompromittierter Benutzeraccount den Zugriff auf alle verbundenen Systeme ermöglicht.
Identity Providers (IdP)
Ein Identity Provider (IdP) ist eine zentrale Komponente der Federated Identity. IdP ist für die Verwaltung digitaler Identitäten und die Authentifizierung von Benutzern zuständig.
Aufgabe eines IdPs:
Benutzer-Authentifizierung – es wird bestätigt, dass der User derjenige ist, für den er sich ausgibt.
Token-Generierung – nach erfolgreicher Authentifizierung stellt der IdP einen Sicherheits-Token aus, der die Identität und Attribute des Benutzers bestätigt/bescheinigt (z. B. SAML-Assertion, OAuth Access Token, OIDC ID-Token).
Attributverwaltung – der IdP verwaltet Benutzerattribute wie Name, Rolle und Berechtigungen. Auch die Konfiguration der Access Policies findet ebenfalls hier statt.
Kommunikation mit der Relying Party (RP). Die Relying Party ist der Service oder die Anwendung, die den Token empfängt und den Zugriff gewährt. Je nach Protokoll wird diese Komponente auch Service Provider (SP) genannt. Beide Begriffe beschreiben dasselbe, SP in SAML- und RP in OAuth/OIDC-Terminologie.
Federated Identity Flow:
- Zugriffsanfrage. Der Benutzer versucht, auf eine Anwendung (RP/SP) zuzugreifen.
- Weiterleitung. Die Anwendung leitet die Anfrage zum IdP.
- Authentifizierung. Der IdP prüft die Identität des Benutzers (z.B. Passwort, MFA).
- Token-Ausstellung. Der IdP erstellt einen Token oder eine Assertion (SAML-Assertion, OAuth Access Token oder OIDC ID-Token).
- Zugriffsgewährung. Die Relying Party empfängt den Token, validiert ihn mithilfe eines Zertifikats und gewährt dem Benutzer den Zugriff.
Typen von IdPs
Es gibt zwei Arten von Identity Providers: Cloud-native IdPs (z. B. AWS Identity and Access Management, Microsoft Entra ID, Google IAM) und IdPs von Drittanbietern in Form von Identity as a Service (IDaaS) (z.B. Okta, Ping Identity).
Der IdP ist ein High-Value-Target, wird er kompromittiert, ist der Zugriff auf alle verbundenen Systeme offen.
Single Sign-On (SSO)
SSO ist die praktische Anwendung von Federated Identity aus Benutzerperspektive. Single Sign-On (SSO) ermöglicht es Benutzern, sich einmal anzumelden und danach auf mehrere Anwendungen / Systeme zuzugreifen. Technisch basiert SSO auf dem im vorherigen Abschnitt beschriebenen Federation-Mechanismus mit IdP.
Die Vorteile sind sowohl aus Benutzersicht als auch aus IT-Sicht deutlich erkennbar: Benutzer müssen sich nur ein einziges, starkes Passwort merken, die IT hingegen profitiert von weniger Passwort-Resets und einer zentralisierten Sicherheitsüberwachung.
Multi-Factor-Authentication (MFA)
MFA ist ein klassisches Beispiel für eine mehrschichtige Sicherheitsstrategie. Ein Benutzer muss mehrere voneinander unabhängige Identitätsnachweise erbringen, bevor ihm Zugriff gewährt wird.
Im Cloud-Kontext ist MFA besonders kritisch, da Cloud-Dienste öffentlich erreichbar sind. Somit reicht ein kompromittiertes Passwort allein für einen erfolgreichen Angriff aus.
Authentifizierungsfaktoren
MFA kombiniert immer mehrere der folgenden Faktoren. Es ist fast immer als zusätzliche Schutzschicht zur klassischen Passwortanmeldung:
- Etwas, das man weiß – Passwort, PIN, Sicherheitsfrage
- Etwas, das man hat – Hardware-Token, Smartcard, Smartphone
- Etwas, das man ist – Fingerabdruck, Gesichtserkennung, Retina-Scan
Moderne Systeme setzen zunehmend auf adaptives MFA, die bei verdächtigen Zugriffen aktiviert werden. Es wäre der vierte Faktor:
- Etwas in der Anfrage – Standort, Gerätetyp, Uhrzeit
Cloud Access Security Broker (CASB)
Die grundlegende Funktion eines CASB wurde bereits in Abschnitt 3.4 erläutert. Ergänzend hierzu folgt ein Überblick über die Kernfunktionen und Betriebsmodi.
Kernfunktionen
- Überwachung – analysiert Cloud-Nutzung und erkennt verdächtige Aktivitäten.
- Sicherheitsrichtlinien – erzwingt Zugriffskontrollen, Verschlüsselung und DLP-Regeln.
- Erkennung von Shadow IT – identifiziert nicht genehmigte Cloud-Apps.
- Bedrohungsschutz – erkennt Malware oder unautorisierte Datenübertragungen.
- Compliance-Unterstützung – hilft bei der Einhaltung von DSGVO, HIPAA, PCI DSS usw.
Betriebsmodi
- API-basiert – direkter Zugriff auf Cloud-Dienste über deren APIs, kein Eingriff in den Datenverkehr.
- Forward Proxy – Datenverkehr wird vor der Cloud durch den CASB geleitet.
- Reverse Proxy – Datenverkehr wird nach der Cloud durch den CASB geleitet.
- Log-basiert – Analyse von Firewall- und Proxy-Logs zur nachträglichen Erkennung von Shadow IT.
Weitere Informationen auf der Seiten der führenden Anbieter:
Secrets Management
Das Thema „Secrets Management“, also die Verwaltung nicht-menschlicher Anmeldeinformationen, wurde in diesem Modul bereits mehrfach angesprochen.
Zur Kategorie „Secrets” zählen:
- API-Schlüssel
- Zertifikate
- SSH-Schlüssel
- Tokens
Diese Secrets müssen auf Basis starker Zufallswerte erstellt, sicher und zentralisiert gespeichert sowie regelmäßig rotiert werden. Zugriffskontrollen nach dem Least-Privilege-Prinzip und lückenloses Audit & Logging sind weitere Grundpfeiler im sicheren Umgang mit Secrets.