Cloud Security Iam: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Cloud IAM ist nicht nur Benutzerverwaltung. In realen Umgebungen steuert IAM, welche menschlichen Benutzer, Workloads, Services, APIs, Automatisierungen und Fremdsysteme auf welche Ressourcen zugreifen dürfen, unter welchen Bedingungen dieser Zugriff erfolgt und wie sich dieser Zugriff nachvollziehen lässt. Wer IAM nur als Sammlung von Rollen und Policies betrachtet, übersieht die eigentliche Angriffsfläche: Vertrauensbeziehungen, temporäre Tokens, föderierte Identitäten, Service Principals, Maschinenidentitäten, Berechtigungsvererbung und implizite Rechte durch Plattformfunktionen.

Der Kern von IAM besteht aus drei Ebenen. Erstens Identitäten: Benutzer, Gruppen, Rollen, Service Accounts, Managed Identities und externe Föderationsobjekte. Zweitens Autorisierung: Policies, Role Assignments, Conditions, Scopes, Resource Policies und Ausnahmen. Drittens Vertrauenskette: Wer darf eine Rolle annehmen, wer darf Tokens ausstellen, welche Claims werden akzeptiert und welche Systeme dürfen im Namen anderer Systeme handeln. Genau an dieser dritten Ebene scheitern viele Umgebungen. Technisch saubere Rollenmodelle helfen wenig, wenn eine Build-Pipeline unkontrolliert hochprivilegierte Rollen übernehmen darf.

In der Praxis muss IAM immer zusammen mit Cloud Security Identity und Cloud Security Access Control betrachtet werden. Identität ohne Zugriffskontrolle ist wertlos, Zugriffskontrolle ohne belastbare Identitätsquelle ist unsicher. Dazu kommt die Cloud-spezifische Dynamik: Ressourcen entstehen und verschwinden automatisiert, Container und Serverless-Funktionen leben nur kurz, CI/CD-Systeme erzeugen laufend neue Berechtigungsbedarfe. Ein statisches Rollenmodell aus klassischen Rechenzentrumsumgebungen passt hier nicht mehr.

Ein weiterer Punkt ist die Trennung zwischen Authentisierung und Autorisierung. MFA, SSO und starke Identitätsprüfung lösen nur den ersten Teil. Viele Vorfälle entstehen nicht durch schwache Anmeldung, sondern durch übermäßige Berechtigungen nach erfolgreicher Anmeldung. Ein kompromittierter Entwickleraccount mit globalen Leserechten auf Secrets, Storage und Logging ist oft gefährlicher als ein schlecht geschützter Standardaccount ohne Reichweite. Deshalb muss IAM immer entlang der Frage bewertet werden: Was kann nach erfolgreichem Login tatsächlich getan werden?

Aus Pentest-Sicht ist IAM häufig der schnellste Weg zu kritischen Auswirkungen. Ein einzelnes Recht wie das Erstellen neuer Access Keys, das Anhängen einer Policy an eine Rolle oder das PassRole-Äquivalent in einer Plattform kann aus einem scheinbar harmlosen Konto einen administrativen Zugriff machen. Viele dieser Eskalationen sind keine klassischen Software-Schwachstellen, sondern Designfehler in Berechtigungsmodellen. Genau deshalb gehört IAM zu den wichtigsten Themen in Pentesting Cloud und zu den häufigsten Ursachen für Cloud Security Angriffe.

Wer Cloud IAM sauber aufbauen will, braucht ein präzises Verständnis von Scope, Vererbung, expliziten Deny-Mechanismen, Default-Rechten, Service-zu-Service-Authentisierung und Token-Lebenszyklen. Ohne dieses Fundament entstehen Rollenmodelle, die auf dem Papier restriktiv wirken, in der Realität aber seitliche Bewegungen, Datenabfluss oder Privilege Escalation ermöglichen.

Die Begriffe unterscheiden sich je nach Plattform, die Muster bleiben ähnlich. In Cloud Security Aws arbeiten Teams mit Users, Groups, Roles, Policies, Trust Policies, Permission Boundaries, SCPs und Resource Policies. In Cloud Security Azure stehen Entra ID, Service Principals, Managed Identities, Role Definitions, Role Assignments, Management Groups und Conditional Access im Vordergrund. In beiden Welten gilt: Rechte entstehen nicht nur an einer Stelle. Effektive Berechtigungen sind das Ergebnis mehrerer Ebenen.

Ein häufiger Denkfehler ist die Annahme, dass eine Rolle nur das kann, was in ihrer Hauptpolicy steht. In Wirklichkeit wirken zusätzliche Mechanismen mit: Ressourcenseitige Freigaben, Delegationsrechte, Gruppenmitgliedschaften, Subscription- oder Account-weite Vorgaben, Organisationsrichtlinien und Sonderrechte für Plattformdienste. Wer Berechtigungen prüft, muss immer die effektive Summe betrachten. Genau hier entstehen Fehleinschätzungen in Audits, wenn nur einzelne Policies gelesen werden, ohne die gesamte Auswertungskette zu analysieren.

Besonders kritisch sind Maschinenidentitäten. Anwendungen, Container, Build-Agenten, Serverless-Funktionen und Automatisierungsjobs benötigen Zugriff auf APIs, Storage, Datenbanken und Secrets. Werden diese Identitäten zu breit berechtigt, entsteht eine stille Hochrisikozone. Ein kompromittierter Container mit Schreibrechten auf Artefakt-Repositories, Secret Stores und Deployment-APIs kann die gesamte Lieferkette beeinflussen. Die Verbindung zu Cloud Security Container, Cloud Security Kubernetes und Cloud Security Devsecops ist deshalb direkt.

In hybriden Umgebungen kommt Föderation hinzu. Benutzer authentisieren sich gegen ein zentrales Identity-System und erhalten daraus Cloud-Zugriff. Das reduziert Passwortinseln, erhöht aber die Bedeutung der Vertrauenskette. Wenn Claims falsch gemappt werden, Gruppenmitgliedschaften unkontrolliert synchronisiert sind oder Legacy-Protokolle weiter aktiv bleiben, entstehen Rechte, die in der Cloud selbst gar nicht sichtbar geplant wurden. Ein IAM-Review muss daher immer auch die vorgelagerte Identitätsquelle prüfen.

• Welche Identitäten existieren tatsächlich: Menschen, Services, externe Partner, CI/CD-Systeme, Break-Glass-Konten?
• Welche Rollen dürfen von welchen Identitäten übernommen werden und unter welchen Bedingungen?
• Welche Rechte sind dauerhaft, welche temporär und welche entstehen nur durch Delegation oder Ressourcenkonfiguration?

Ein belastbares Modell trennt klar zwischen Human Access und Workload Access. Menschen arbeiten idealerweise über SSO, MFA, kurzlebige Sessions und klar definierte Rollen. Workloads nutzen verwaltete Identitäten oder kurzlebige Tokens statt statischer Schlüssel. Externe Integrationen erhalten eng begrenzte Rechte mit klaren Bedingungen. Sobald diese Trennung fehlt, vermischen sich Betriebszugriffe, Automatisierung und Notfallrechte. Das führt fast immer zu überprivilegierten Konten und schlechter Nachvollziehbarkeit.

Saubere IAM-Architektur ist damit ein Teil von It Security Sicherheitsarchitektur und kein isoliertes Administrationsdetail. Wer Plattformen skaliert, ohne IAM-Strukturen mitzudenken, baut technische Schulden auf, die später nur mit hohem Aufwand korrigiert werden können.

Least Privilege klingt einfach: Jede Identität bekommt nur die Rechte, die sie wirklich braucht. In produktiven Cloud-Umgebungen ist die Umsetzung deutlich komplexer. Anwendungen ändern sich, Teams deployen neue Komponenten, APIs benötigen Zusatzrechte, Incident-Teams brauchen kurzfristig Einblick, und Plattformdienste erzeugen implizite Abhängigkeiten. Deshalb scheitert Least Privilege oft nicht an fehlendem Willen, sondern an unklaren Prozessen und fehlender Transparenz über tatsächliche Nutzung.

Ein typisches Muster: Ein Team startet mit Administratorrechten, um schnell produktiv zu werden. Später sollen die Rechte reduziert werden. Da aber niemand exakt weiß, welche API-Aktionen wirklich benötigt werden, bleiben die breiten Rechte bestehen. Aus Sicht eines Angreifers ist das ideal. Ein kompromittiertes Build-System, ein gestohlener Entwickler-Token oder eine SSRF-Schwachstelle in einer Cloud-nativen Anwendung kann dann auf weit mehr Ressourcen zugreifen als fachlich notwendig wäre. Die Verbindung zu Websecurity Ssrf ist real, weil SSRF in Cloud-Umgebungen oft Metadaten- oder Token-Zugriffe ermöglicht.

Least Privilege funktioniert nur, wenn Berechtigungen aus beobachteter Nutzung und klaren Rollenprofilen abgeleitet werden. Das bedeutet: Logs auswerten, tatsächlich genutzte Aktionen identifizieren, unnötige Rechte entfernen, Änderungen testen und Ausnahmen zeitlich begrenzen. Ohne Logging bleibt jede Rechteoptimierung spekulativ. Deshalb gehören Cloud Security Logging und Cloud Security Monitoring direkt in den IAM-Lebenszyklus.

Ein zweites Problem ist Scope. Eine Rolle kann funktional korrekt sein und trotzdem zu breit wirken, wenn sie auf Subscription-, Account- oder Organisationsebene zugewiesen wird. Viele Vorfälle entstehen nicht durch falsche Aktionen, sondern durch falschen Geltungsbereich. Leserechte auf alle Storage-Ressourcen, alle Secrets oder alle Audit-Logs sind in vielen Unternehmen bereits kritisch genug, um Datenschutz-, Compliance- und Incident-Risiken auszulösen. Gerade bei Cloud Security Daten ist Leseberechtigung oft gleichbedeutend mit vollständigem Datenabfluss.

Least Privilege muss außerdem zwischen direkten und indirekten Rechten unterscheiden. Ein Konto braucht vielleicht kein direktes Recht auf Secrets, kann aber eine Funktion neu deployen, die beim Start Secrets liest. Oder ein Benutzer darf keine virtuellen Maschinen administrieren, kann aber eine Rolle an eine VM hängen, die dann weitergehende Rechte besitzt. Solche indirekten Pfade sind in Reviews oft unsichtbar, wenn nur offensichtliche API-Rechte betrachtet werden.

Ein praxistauglicher Ansatz ist rollenbasierte Standardisierung mit enger Zweckbindung. Statt generischer Rollen wie Developer-Admin oder Ops-FullAccess werden Rollen entlang konkreter Aufgaben gebaut: ReadOnly-Observability, Deployment-to-Staging, Secret-Rotation-for-Service-X, Incident-Read-for-Logs, Storage-Backup-Operator. Je präziser der Zweck, desto leichter lassen sich Rechte prüfen, dokumentieren und wieder entziehen.

Least Privilege ist kein einmaliges Projekt, sondern ein Betriebsprozess. Neue Services, neue Regionen, neue Plattformfeatures und neue Integrationen verändern den Rechtebedarf laufend. Wer keine regelmäßige Rezertifizierung und keine technische Validierung der effektiven Rechte etabliert, verliert die Kontrolle schleichend.

Die meisten kritischen IAM-Probleme sind keine exotischen Spezialfälle. Es sind wiederkehrende Muster, die in Audits, Red-Team-Übungen und echten Vorfällen ständig auftauchen. Dazu gehören überprivilegierte Standardrollen, ungenutzte Altkonten, statische Access Keys ohne Rotation, fehlende Trennung zwischen Produktions- und Entwicklungsrechten, unkontrollierte Cross-Account- oder Cross-Tenant-Vertrauensstellungen und unzureichend geschützte Break-Glass-Konten.

Besonders gefährlich sind Rechtekombinationen. Ein einzelnes Recht wirkt oft harmlos, mehrere zusammen ermöglichen Eskalation. Beispiele sind das Erstellen neuer Rollen plus das Anhängen von Policies, das Übergeben privilegierter Rollen an Compute-Dienste, das Ändern von Netzwerk- oder Storage-Konfigurationen in Kombination mit Leserechten auf sensible Daten oder das Verändern von Logging-Einstellungen, um Spuren zu verwischen. Solche Ketten sind aus Angreifersicht wertvoller als ein offensichtlicher Administratorzugang, weil sie in vielen Umgebungen weniger überwacht werden.

Ein weiterer Klassiker ist die Vermischung von Benutzer- und Servicezugriff. Entwickler erhalten dauerhafte API-Schlüssel für Automatisierung, Build-Server nutzen persönliche Konten, Skripte laufen mit menschlichen Identitäten, und Notfallkonten werden für Routineaufgaben verwendet. Das zerstört Verantwortlichkeit und erschwert forensische Zuordnung. Wenn später verdächtige Aktionen auftauchen, ist oft nicht mehr sauber nachvollziehbar, ob ein Mensch, ein Job oder ein kompromittiertes System gehandelt hat.

Auch Ressourcenseitige Freigaben werden regelmäßig unterschätzt. Ein Storage-Bucket, ein Key Vault, ein Secret Store oder eine Queue kann zusätzliche Zugriffe erlauben, die im zentralen Rollenmodell nicht sichtbar sind. In Kombination mit schwachen Netzwerkgrenzen oder öffentlich erreichbaren Diensten entstehen dann Pfade, die klassische IAM-Reviews übersehen. Deshalb müssen IAM-Prüfungen immer mit Konfigurationsanalysen aus Cloud Security Misconfigurations verbunden werden.

• Dauerhafte Hochprivilegien für Menschen statt kurzlebiger, genehmigter Admin-Sessions
• Statische Schlüssel in Repositories, CI/CD-Variablen oder Container-Images
• Rollen mit Wildcards, globalem Scope oder unklaren Delegationsrechten

Ein oft übersehener Fehler ist fehlender Schutz der Kontrollinstanzen selbst. Wer IAM verwaltet, muss besonders abgesichert sein. Admin-Portale ohne starke MFA, fehlende Conditional Access Regeln, unzureichende Session-Kontrollen oder ungeschützte Self-Service-Funktionen öffnen direkte Wege zur Übernahme der gesamten Cloud-Umgebung. In vielen Fällen beginnt ein schwerer Vorfall nicht mit einem Exploit gegen eine Anwendung, sondern mit einem kompromittierten Identitätskonto und anschließendem Missbrauch legitimer Verwaltungsfunktionen.

Aus Sicht von It Security Typische Fehler ist IAM deshalb ein Bereich, in dem kleine Designfehler unverhältnismäßig große Auswirkungen haben. Ein falsch gesetztes Trust-Statement oder eine zu breite Rollenzuweisung kann mehr Schaden verursachen als mehrere ungepatchte Einzelserver.

Privilege Escalation in der Cloud funktioniert selten wie auf klassischen Hosts über Kernel-Lücken oder lokale Fehlkonfigurationen. Stattdessen erfolgt die Eskalation meist über legitime Verwaltungsrechte, Delegationsmechanismen und Vertrauensbeziehungen. Ein Angreifer sucht nicht primär nach einem Exploit, sondern nach einer Berechtigungskombination, mit der sich zusätzliche Rechte erzeugen, übernehmen oder indirekt missbrauchen lassen.

Ein typischer Pfad in AWS ist das Recht, eine Rolle an einen Compute-Dienst zu binden oder eine Funktion mit privilegierter Ausführungsrolle zu starten. In Azure sind es häufig Rechte auf Role Assignments, Managed Identities, Automation Accounts oder App Registrations. In beiden Fällen gilt: Wer eine Identität kontrolliert, die andere privilegierte Identitäten erzeugen oder nutzen darf, besitzt faktisch einen Eskalationspfad. Das ist der Grund, warum reine Listen von erlaubten API-Aktionen nicht ausreichen. Entscheidend ist die Frage, welche Folgeaktionen diese Rechte ermöglichen.

Ein weiterer realistischer Pfad ist die Manipulation von Deployment-Prozessen. Wenn ein Build-System Artefakte veröffentlichen, Infrastruktur ausrollen und gleichzeitig Secrets lesen darf, reicht oft schon die Übernahme eines Pipeline-Tokens. Danach können neue Ressourcen mit privilegierten Rollen erstellt, bestehende Policies verändert oder Daten aus produktiven Diensten abgegriffen werden. IAM und Supply-Chain-Sicherheit sind deshalb eng verknüpft. Besonders in containerisierten Plattformen mit Cloud Security Docker oder Kubernetes-basierten Deployments muss geprüft werden, welche Rollen Pods, Runner und Controller tatsächlich besitzen.

Auch Leserechte können zur Eskalation beitragen. Wer Konfigurationen, Logs, Parameter Stores oder Secret-Referenzen lesen darf, findet oft Zugangsdaten, interne Endpunkte, Rollennamen, Trust-Beziehungen oder Hinweise auf schwach geschützte Notfallkonten. In vielen Umgebungen ist Informationsgewinnung der erste Schritt zur späteren Rechteausweitung. Deshalb ist ReadOnly nicht automatisch ungefährlich. ReadOnly auf IAM, Secrets, Storage und Monitoring kann für einen Angreifer operativ extrem wertvoll sein.

Ein häufiger Denkfehler in Reviews lautet: Diese Rolle hat keine Admin-Rechte, also ist sie unkritisch. Korrekt wäre: Diese Rolle hat keine direkten Admin-Rechte, aber möglicherweise Rechte zur Vorbereitung, Delegation oder Umgehung. Genau diese indirekten Pfade müssen modelliert werden. Das entspricht dem Denken aus It Security Threat Modeling und It Security Attack Surface: Nicht nur offensichtliche Privilegien zählen, sondern alle Wege, die zu ihnen führen.

Beispielhafte Eskalationslogik:

1. Konto A darf neue Serverless-Funktion deployen
2. Konto A darf Rolle B als Ausführungsrolle zuweisen
3. Rolle B darf Secrets lesen und Storage exportieren
4. Ergebnis: Konto A kann indirekt auf Daten zugreifen, obwohl kein direktes Secret-Read-Recht besteht

In Pentests wird genau nach solchen Ketten gesucht. Die technische Herausforderung liegt weniger im Finden einzelner Rechte als im Verstehen ihrer Wechselwirkung. Wer IAM sicher betreiben will, muss deshalb nicht nur Policies schreiben, sondern Eskalationspfade aktiv modellieren, testen und überwachen.

Viele IAM-Probleme entstehen nicht durch fehlende Technik, sondern durch schlechte Betriebsabläufe. Ein sauberes Rollenmodell verliert schnell an Wert, wenn Benutzerwechsel, Teamwechsel, Projektenden, Dienstleisterzugänge und Notfallprozesse unkontrolliert ablaufen. IAM muss deshalb als Lebenszyklus organisiert werden. Jede Identität braucht einen definierten Zweck, einen Eigentümer, einen Genehmigungsweg, ein Ablaufdatum oder zumindest eine regelmäßige Rezertifizierung.

Joiner-Mover-Leaver-Prozesse sind in der Cloud besonders wichtig, weil Rechte oft über mehrere Systeme verteilt sind: zentrales Identity-System, Cloud-Rollen, Projektgruppen, CI/CD-Plattformen, Secret Stores, Kubernetes-Zugänge und externe SaaS-Integrationen. Wenn ein Mitarbeiter das Team wechselt, reicht es nicht, nur die Gruppenmitgliedschaft im Verzeichnisdienst anzupassen. Auch temporäre Rollen, API-Tokens, lokale Servicekonten, gespeicherte CLI-Profile und Zugriff auf Build-Systeme müssen entzogen oder neu bewertet werden.

Break-Glass-Konten verdienen Sonderbehandlung. Sie sind notwendig, aber hochriskant. Solche Konten dürfen nicht für Routinearbeiten genutzt werden, müssen stark geschützt, überwacht und regelmäßig getestet werden. In vielen Umgebungen existieren Notfallkonten zwar formal, sind aber technisch veraltet, besitzen unklare Passworthinterlegung oder werden nie auf Funktionsfähigkeit geprüft. Im Ernstfall führt das zu Chaos. Noch schlimmer ist der umgekehrte Fall: Break-Glass-Konten funktionieren, werden aber im Alltag bequem mitbenutzt und tauchen dadurch in normalen Logmustern auf.

Automatisierung braucht ebenfalls eigene Regeln. CI/CD-Systeme, Terraform-Runner, Deployment-Bots und Integrationsdienste dürfen nur die minimalen Rechte für ihren konkreten Zweck erhalten. Besonders wichtig ist die Trennung nach Umgebung. Ein Pipeline-Token für Development darf nicht automatisch Produktionsrollen übernehmen können. Wer Infrastruktur als Code nutzt, sollte IAM-Änderungen wie Code behandeln: versioniert, reviewt, getestet und nachvollziehbar ausgerollt. Das ist ein Kernprinzip aus It Security Secure Development und It Security Devsecops.

Ein praxistauglicher Workflow definiert nicht nur Genehmigungen, sondern auch technische Leitplanken. Dazu gehören verpflichtende Tags oder Namenskonventionen für Rollen, maximale Laufzeiten für temporäre Berechtigungen, automatische Deaktivierung ungenutzter Konten, Rezertifizierungszyklen für privilegierte Rollen und Alarmierung bei Änderungen an Trust Policies oder Rollenzuweisungen. Ohne solche Leitplanken wird IAM mit wachsender Cloud-Nutzung unübersichtlich und fehleranfällig.

Gute Workflows reduzieren nicht nur Risiko, sondern beschleunigen auch den Betrieb. Wenn Standardrollen, Genehmigungspfade und Rezertifizierungen klar definiert sind, müssen Teams weniger improvisieren. Genau diese operative Reife trennt stabile Cloud-Umgebungen von Plattformen, die nur so lange sicher wirken, bis der erste größere Incident eintritt.

IAM ist nur dann beherrschbar, wenn Änderungen und Nutzung lückenlos sichtbar sind. Dazu gehören erfolgreiche und fehlgeschlagene Anmeldungen, Token-Ausstellungen, Rollenübernahmen, Policy-Änderungen, neue Schlüssel, Löschvorgänge, Änderungen an Föderationskonfigurationen und Zugriffe auf besonders sensible Ressourcen. Ohne diese Daten bleibt unklar, ob eine Berechtigung nur existiert oder bereits missbraucht wurde.

Detection im IAM-Kontext muss verhaltensorientiert sein. Ein einzelner Login ist selten verdächtig. Kritisch werden Muster wie erstmalige Nutzung einer privilegierten Rolle, Rollenübernahme aus ungewohnten Regionen, Erstellung neuer Access Keys kurz nach erfolgreicher Anmeldung, Deaktivierung von Logging, Massenabfragen von Storage-Objekten oder Änderungen an Vertrauensbeziehungen außerhalb definierter Change-Fenster. Solche Use Cases gehören in Cloud Security Detection und in zentrale Überwachung aus Security Monitoring Siem.

Ein häufiger Fehler ist die Konzentration auf Authentisierungsereignisse, während Autorisierungsänderungen zu wenig beachtet werden. In vielen Vorfällen ist nicht der Login selbst das Problem, sondern die Minuten danach: neue Rollen, neue Schlüssel, neue Ausführungsidentitäten, geänderte Policies, geänderte Netzwerkpfade. Detection muss deshalb den gesamten Missbrauchszyklus abdecken. Wer nur Login-Anomalien überwacht, verpasst oft die eigentlichen Schadenshandlungen.

• Alarm auf Erstellung oder Reaktivierung privilegierter Zugangsschlüssel
• Alarm auf Änderungen an Trust Policies, Role Assignments und Conditional Access
• Alarm auf Deaktivierung, Umleitung oder Manipulation von Audit- und Sicherheitslogs

Für die Forensik ist Kontext entscheidend. Ein Event allein reicht selten. Benötigt werden Session-Informationen, Quell-IP, User-Agent, Token-Typ, korrelierte API-Aufrufe, betroffene Ressourcen, vorherige Rollenwechsel und idealerweise die Zuordnung zu Change-Tickets oder Deployments. Nur so lässt sich unterscheiden, ob eine Aktion legitim, fehlerhaft oder bösartig war. Diese Arbeitsweise überschneidet sich mit Forensik Log Analyse und Cloud Security Response.

Wichtig ist auch die Unveränderbarkeit der Protokolle. Wenn dieselben privilegierten Konten, die produktive Ressourcen verwalten, auch Audit-Logs löschen oder umkonfigurieren können, fehlt eine belastbare Beweiskette. Logs müssen getrennt gespeichert, gegen Manipulation geschützt und mit klaren Aufbewahrungsregeln versehen werden. In reifen Umgebungen werden besonders kritische IAM-Ereignisse zusätzlich in unabhängige Systeme repliziert.

Detection für IAM ist keine reine Compliance-Aufgabe. Sie ist operativ notwendig, weil Cloud-Angriffe oft mit legitimen APIs durchgeführt werden. Ohne gute Telemetrie sieht ein Angriff dann aus wie normale Administration.

In vielen Cloud-Umgebungen sind nicht menschliche Benutzer das größte IAM-Risiko, sondern Maschinenidentitäten. Anwendungen, Container, Jobs, Serverless-Funktionen, Integrationsplattformen und Agenten kommunizieren permanent mit Cloud-APIs. Wenn diese Zugriffe über statische Secrets, langlebige Tokens oder schlecht geschützte Konfigurationsdateien laufen, entsteht eine riesige Angriffsfläche. Ein kompromittierter Build-Runner oder ein auslesbarer Container kann dann sofort produktive Rechte missbrauchen.

Der sichere Standard sind kurzlebige, automatisch rotierte Identitäten mit enger Bindung an Workload, Umgebung und Zweck. Managed Identities, Workload Identity Federation und temporäre Rollen sind statischen Schlüsseln fast immer überlegen. Sie reduzieren das Risiko von Secret-Leaks in Repositories, Images, Logs oder Debug-Ausgaben. Trotzdem werden in der Praxis noch häufig Access Keys in CI/CD-Systemen, Umgebungsvariablen oder lokalen Entwicklerprofilen hinterlegt. Das ist bequem, aber hochriskant.

Secret Management und IAM gehören zusammen. Ein Secret Store ist nur so sicher wie seine Zugriffsregeln. Wenn breite Leserechte auf Parameter, Zertifikate oder API-Schlüssel vergeben werden, ist der Secret Store kein Schutz, sondern nur ein zentraler Sammelpunkt für attraktive Ziele. Die Verbindung zu It Security Secret Management und It Security Key Management ist unmittelbar.

Containerisierte Umgebungen verschärfen das Problem. Ein Pod oder Container erhält oft automatisch eine Identität, die auf Cloud-Ressourcen zugreifen darf. Wenn Namespace-Grenzen, Service Accounts oder Metadatenzugriffe unsauber konfiguriert sind, kann ein Angreifer aus einer Anwendung in die Cloud-Ebene springen. Das ist einer der Gründe, warum IAM nicht getrennt von Cloud Security Kubernetes und Cloud Security Docker betrachtet werden darf.

Schlechtes Muster:
- Statischer API-Key in CI/CD-Variable
- Key hat Schreibrechte auf Produktion
- Mehrere Pipelines teilen denselben Key
- Keine Rotation, keine Zweckbindung, keine saubere Attribution

Besseres Muster:
- Kurzlebiger Token pro Pipeline-Run
- Rollenübernahme nur für konkretes Projekt und konkrete Umgebung
- Enge Laufzeitbegrenzung
- Vollständige Protokollierung der Token-Nutzung

Maschinenidentitäten brauchen denselben Governance-Grad wie Benutzerkonten: Eigentümer, Zweck, Scope, Ablauf, Monitoring und Rezertifizierung. Alles andere führt dazu, dass alte Integrationen jahrelang mit unnötig hohen Rechten weiterlaufen. In Incident-Untersuchungen zeigt sich regelmäßig, dass vergessene Servicekonten oder Alt-Tokens der eigentliche Einstiegspunkt waren.

IAM-Hardening beginnt mit Reduktion. Weniger Identitäten, weniger Ausnahmen, weniger dauerhafte Privilegien, weniger statische Schlüssel. Jede zusätzliche Rolle, jede Sonderfreigabe und jede manuelle Ausnahme erhöht die Komplexität und damit das Fehlerrisiko. Ziel ist nicht maximale Flexibilität, sondern kontrollierbare Berechtigungsstrukturen mit klaren Verantwortlichkeiten.

Ein robuster Hardening-Ansatz startet bei privilegierten Konten. Administrative Zugriffe sollten nur über starke Authentisierung, definierte Geräteanforderungen, begrenzte Session-Dauer und möglichst Just-in-Time-Freigaben erfolgen. Dauerhafte Global-Admins oder Account-Admins sind in modernen Cloud-Umgebungen kaum vertretbar. Stattdessen werden privilegierte Rollen nur bei Bedarf aktiviert, protokolliert und nach kurzer Zeit automatisch entzogen.

Danach folgt die technische Begrenzung von Delegation. Rechte zum Erstellen, Ändern oder Zuweisen von Rollen müssen extrem restriktiv vergeben werden. Gleiches gilt für Trust Policies, Föderationskonfigurationen und Service Principals. Wer diese Ebenen kontrolliert, kontrolliert indirekt die gesamte Berechtigungslandschaft. Deshalb sollten Änderungen an solchen Objekten immer besonders überwacht und idealerweise an Review- oder Freigabeprozesse gekoppelt sein.

Auch organisatorische Trennung ist wichtig. Entwicklung, Betrieb, Security und Incident Response brauchen unterschiedliche Rollenprofile. Produktionszugriffe dürfen nicht automatisch aus Entwicklungsrollen folgen. Leserechte für Security-Analysen sollten von Änderungsrechten getrennt sein. Notfallzugriffe müssen technisch und prozessual isoliert werden. Diese Trennung entspricht grundlegenden Prinzipien aus It Security Prinzipien und Defense Zero Trust.

Ein weiterer Hardening-Baustein ist Policy-Hygiene. Wildcards, globale Scopes, veraltete Rollen, ungenutzte Gruppen und doppelte Berechtigungswege müssen regelmäßig bereinigt werden. In vielen Umgebungen wächst IAM über Jahre organisch. Ohne Cleanup entstehen Schattenrechte, die niemand mehr fachlich begründen kann. Genau diese Altlasten werden in Audits und Angriffen ausgenutzt.

Schließlich gehört auch Testbarkeit zum Hardening. Rollen und Policies sollten nicht nur dokumentiert, sondern aktiv validiert werden. Kann eine Rolle wirklich nur das, was vorgesehen ist? Gibt es unerwartete Seiteneffekte? Lassen sich Eskalationspfade nachstellen? Solche Prüfungen sind Teil von Pentesting Best Practices und sollten regelmäßig in technische Reviews einfließen.

IAM-Hardening ist erfolgreich, wenn ein kompromittiertes Konto nur begrenzten Schaden anrichten kann, wenn Missbrauch schnell sichtbar wird und wenn privilegierte Änderungen nicht still und unbemerkt erfolgen können.

Ein brauchbarer IAM-Review besteht nicht aus dem Lesen einiger Policies. Er beginnt mit einer vollständigen Inventarisierung aller Identitäten und ihrer Beziehungen. Dazu gehören Benutzer, Gruppen, Rollen, Servicekonten, Managed Identities, externe Föderationen, Break-Glass-Konten, CI/CD-Identitäten und Drittanbieterintegrationen. Danach wird nicht nur dokumentiert, welche Rechte existieren, sondern welche Rechte effektiv wirksam werden und welche Eskalationspfade daraus entstehen.

Der nächste Schritt ist die Priorisierung nach Risiko. Hochrelevant sind Identitäten mit Zugriff auf IAM selbst, auf Secrets, auf produktive Daten, auf Logging, auf Netzwerksteuerung und auf Deployment-Prozesse. Ebenfalls kritisch sind Identitäten mit breitem Leserecht, weil sie oft die Grundlage für spätere Eskalation bilden. Ein gutes Audit fragt nicht nur nach Admin-Rechten, sondern nach allen Rechten, die Kontrolle, Unsichtbarkeit oder Datenabfluss ermöglichen.

Danach folgt die Validierung gegen reale Nutzung. Welche Rollen wurden in den letzten 30, 60 oder 90 Tagen tatsächlich verwendet? Welche Aktionen wurden ausgeführt? Welche Rechte sind ungenutzt? Welche Konten sind inaktiv? Welche Schlüssel sind alt? Welche Rollen werden außerhalb definierter Zeitfenster genutzt? Diese Fragen trennen theoretische Berechtigungen von operativer Realität. Ohne diesen Abgleich bleibt jedes Audit unvollständig.

Wichtig ist auch die Prüfung der Governance. Gibt es Eigentümer pro Rolle? Gibt es Rezertifizierungen? Werden Notfallkonten getestet? Sind IAM-Änderungen versioniert? Gibt es Freigabeprozesse für privilegierte Rollen? Werden Drittanbieterzugriffe regelmäßig überprüft? Technische Sicherheit ohne Governance hält selten lange, weil Berechtigungen im Tagesgeschäft sonst wieder ausufern.

Ein belastbares Review endet mit konkreten Maßnahmen statt abstrakten Empfehlungen. Rollen mit Wildcards werden zerlegt, ungenutzte Konten deaktiviert, statische Schlüssel ersetzt, Trust-Beziehungen eingeschränkt, Logging-Härtung umgesetzt und Detection-Regeln ergänzt. Genau diese operative Umsetzbarkeit macht den Unterschied zwischen Papier-Assessment und echter Sicherheitsverbesserung.

Prüfreihenfolge in der Praxis:

1. Identitäten inventarisieren
2. Effektive Rechte und Scope ermitteln
3. Eskalationspfade modellieren
4. Nutzung gegen Logs validieren
5. Kritische Altlasten priorisiert abbauen
6. Detection und Rezertifizierung nachziehen

Wer IAM so prüft, erkennt nicht nur offensichtliche Fehlkonfigurationen, sondern auch strukturelle Schwächen im Betriebsmodell. Genau dort liegen meist die Ursachen für wiederkehrende Cloud-Sicherheitsprobleme.