Warum IAM zentral für die Cloud ist

2026-07-27

In einer traditionellen Rechenzentrumsumgebung ist der Zugriff auf Systeme physisch begrenzt: Man braucht Zugang zum Gebäude, zum Rack, zum Netzwerk. In der Cloud fällt diese physische Barriere komplett weg. Jede einzelne Ressource, von der VM über den Storage-Bucket bis zur Datenbank, ist über das Internet erreichbar und wird ausschließlich durch Identity and Access Management (IAM) geschützt. Damit wird IAM von einem administrativen Detail zur zentralen Sicherheitsgrenze der gesamten Cloud-Infrastruktur.

IAM ist der neue Perimeter

Der klassische Sicherheitsperimeter, die Firewall am Netzwerkrand, verliert in der Cloud an Bedeutung. Stattdessen gilt zunehmend das Prinzip “Identity is the new perimeter”: Nicht mehr die Frage “Bist du im richtigen Netzwerk?”, sondern “Bist du die richtige Identität mit den richtigen Berechtigungen?” entscheidet über Zugriff.

Das hat weitreichende Konsequenzen für das Design einer Cloud-Plattform:

• Jeder API-Call muss authentifiziert und autorisiert werden, nicht nur der Zugriff auf das Netzwerk
• Es gibt keinen “vertrauenswürdigen internen Bereich” mehr, jede Komponente muss sich gegenüber jeder anderen ausweisen (Zero Trust)
• Eine kompromittierte Identität (gestohlener API-Key, überprivilegierter Service-Account) kann potenziell die gesamte Infrastruktur betreffen

Das Prinzip der geringsten Rechte (Least Privilege)

Die häufigste Ursache für schwerwiegende Cloud-Sicherheitsvorfälle ist nicht ein ausgeklügelter Angriff, sondern schlicht zu weit gefasste Berechtigungen. Ein Service-Account, der eigentlich nur Objekte aus einem einzigen Storage-Bucket lesen soll, aber versehentlich Admin-Rechte auf das gesamte Konto besitzt, wird im Ernstfall zum größten Risiko.

Für eine Cloud-Plattform bedeutet konsequentes Least-Privilege-Design:

• Granulare Permissions statt grober Rollen: storage:read:bucket-x statt pauschal storage:admin
• Zeitlich begrenzte Zugriffe über kurzlebige Tokens statt permanenter Access-Keys
• Just-in-Time-Access: Erhöhte Rechte werden nur für die Dauer einer konkreten Aufgabe gewährt und danach automatisch wieder entzogen
• Regelmäßige Access-Reviews: Automatisierte Erkennung von Berechtigungen, die über längere Zeit nicht genutzt wurden, und Vorschläge zu deren Entzug

Menschen, Maschinen und alles dazwischen

Eine Besonderheit von Cloud-IAM gegenüber klassischem Identity Management: Es geht längst nicht mehr nur um menschliche Nutzer. Eine moderne Cloud-Plattform muss mindestens folgende Identitätstypen sauber verwalten:

• Menschliche Nutzer: Über SSO/OIDC angebunden, meist mit MFA abgesichert
• Service-Accounts: Für automatisierte Prozesse, CI/CD-Pipelines, Backend-Services
• Workload-Identitäten: Identitäten, die einer laufenden Workload zugeordnet sind, ohne dass dafür ein statisches Credential existieren muss (z. B. AWS IAM Roles for Service Accounts, GCP Workload Identity)
• Cross-Account-/Cross-Provider-Identitäten: Delegierte Zugriffe, wenn eine Plattform im Namen eines Kunden auf dessen Cloud-Konto zugreift

Jeder dieser Typen hat unterschiedliche Lebenszyklen und Risikoprofile, und das IAM-System muss das jeweils passende Modell bereitstellen, statt alle Identitäten über einen Kamm zu scheren.

RBAC, ABAC und die Grenzen einfacher Rollenmodelle

Reines Role-Based Access Control (RBAC) mit festen Rollen wie viewer, editor, admin stößt bei komplexeren Anforderungen schnell an Grenzen. Wenn Zugriffsentscheidungen vom Kontext abhängen, etwa “Nutzer aus Team A dürfen Ressourcen mit dem Tag team:a bearbeiten”, braucht es Attribute-Based Access Control (ABAC), bei dem Regeln dynamisch anhand von Attributen der Ressource, des Nutzers und des Kontexts ausgewertet werden:

{
  "effect": "allow",
  "action": "instances:update",
  "condition": {
    "resource.tags.team": "${principal.team}"
  }
}

Für eine wachsende Cloud-Plattform lohnt es sich, früh auf ein Modell zu setzen, das beide Ansätze kombinieren kann, statt sich früh auf starres RBAC festzulegen und später ein komplettes Redesign zu benötigen.

ReBAC: Zugriff über Beziehungen statt über Rollen oder Attribute

Ein dritter Ansatz, der in modernen Cloud-Plattformen zunehmend an Bedeutung gewinnt, ist Relationship-Based Access Control (ReBAC). Statt Zugriff über feste Rollen oder ausgewertete Attribute zu entscheiden, modelliert ReBAC Berechtigungen als Graph aus Beziehungen zwischen Objekten: Ein Nutzer ist Mitglied eines Teams, ein Team besitzt ein Projekt, ein Projekt enthält Ressourcen. Der Zugriff ergibt sich dann daraus, ob ein Pfad von einer Identität zu einer Ressource im Beziehungsgraphen existiert.

Bekannt wurde dieses Modell vor allem durch Googles internes Autorisierungssystem Zanzibar, das genau dieses Prinzip nutzt, um Berechtigungen für Google Drive, Docs und andere Produkte in großem Maßstab konsistent zu verwalten. Mittlerweile gibt es mit Systemen wie OpenFGA oder SpiceDB auch offene Implementierungen desselben Konzepts.

Ein typisches ReBAC-Tupel sieht so aus:

document:report-q3#viewer@user:alice
document:report-q3#parent@folder:finance-2026
folder:finance-2026#editor@team:finance

Die Zugriffsprüfung “Darf Alice den Report lesen?” folgt dann dem Graphen: Alice ist Mitglied im Team Finance, das Team hat Editor-Rechte auf den Ordner, der Ordner ist der übergeordnete Container des Dokuments, also erbt das Dokument die Berechtigung.

Warum ReBAC gerade für Cloud-Ressourcen gut passt

Cloud-Infrastrukturen sind von Natur aus hierarchisch und stark verschachtelt: Organisationen enthalten Projekte, Projekte enthalten Ressourcengruppen, Ressourcengruppen enthalten einzelne Ressourcen, und viele Ressourcen referenzieren sich gegenseitig (ein Volume gehört zu einer Instanz, eine Instanz gehört zu einem Subnetz, ein Subnetz gehört zu einem Netzwerk). Genau diese Art von verschachtelter, sich ändernder Struktur bildet ReBAC deutlich natürlicher ab als flache RBAC-Rollen:

• Vererbung über Hierarchien: Rechte auf einer Organisation vererben sich automatisch auf alle enthaltenen Projekte und Ressourcen, ohne dass für jede neue Ressource eine Rolle erneut zugewiesen werden muss
• Ressourcen-zu-Ressourcen-Beziehungen: Zugriff kann davon abhängen, mit welcher anderen Ressource ein Objekt verknüpft ist, nicht nur davon, welchem Nutzer welche Rolle zugewiesen wurde
• Dynamische Teamstrukturen: Wenn sich Teamzugehörigkeiten häufig ändern, muss nicht für jede Ressource neu autorisiert werden, sondern nur die Beziehung “Nutzer ist Mitglied von Team X” aktualisiert werden

ReBAC, RBAC und ABAC im Vergleich

In der Praxis schließen sich diese Modelle nicht aus. Viele moderne Cloud-Plattformen kombinieren ReBAC für die grundlegende Ressourcenhierarchie mit ABAC-artigen Bedingungen für kontextabhängige Zusatzregeln, etwa Zeitfenster oder IP-Einschränkungen, und nutzen RBAC-Rollen lediglich als benannte, wiederverwendbare Bündel von Berechtigungen innerhalb dieses Graphen.

Praktische Einstiegshürden bei ReBAC

Wer ReBAC einführen will, sollte zwei Punkte von Anfang an einplanen:

• Konsistenz bei Lese-Latenz: Da Berechtigungsprüfungen einen Graphen traversieren, muss sichergestellt werden, dass eine gerade entzogene Berechtigung nicht durch einen veralteten Cache-Eintrag noch kurzzeitig gültig bleibt. Zanzibar löst das über das Konzept der “Zookies”, also Konsistenz-Tokens, die den Zeitpunkt einer Berechtigungsprüfung an einen bestimmten Datenstand binden.
• Performance bei tiefen Hierarchien: Eine Berechtigungsprüfung kann bei sehr tiefen oder stark vernetzten Graphen mehrere Traversierungsschritte benötigen. Ein produktionsreifes ReBAC-System braucht deshalb effizientes Caching und Indexierung der Beziehungsdaten, nicht nur eine naive Graphdatenbank-Abfrage pro Request.

Auditierbarkeit ist kein optionales Extra

In regulierten Branchen, aber zunehmend auch darüber hinaus, ist die lückenlose Nachvollziehbarkeit von Zugriffen eine harte Anforderung. Ein IAM-System für die Cloud muss deshalb von Anfang an:

• Jede Berechtigungsänderung protokollieren: wer hat wann welche Rolle wem zugewiesen
• Jeden tatsächlichen Zugriff auf sensible Ressourcen loggen, nicht nur die Berechtigung dazu
• Diese Logs unveränderlich und für einen definierten Zeitraum aufbewahren (Compliance-Anforderungen wie SOC 2, ISO 27001 oder branchenspezifische Regularien verlangen das explizit)

IAM in der Multi-Cloud: Föderation statt Duplikation

Sobald mehrere Cloud-Provider im Spiel sind, verschärft sich die IAM-Herausforderung: Jeder Provider hat sein eigenes Identitätsmodell (AWS IAM, Azure AD/Entra ID, GCP IAM), die sich nicht 1:1 übersetzen lassen. Statt für jeden Provider getrennte Identitäten zu pflegen, was schnell zu Inkonsistenzen führt, sollte eine zentrale Identitätsquelle (Identity Provider) genutzt werden, von der aus Zugriffe über Föderation (z. B. SAML, OIDC, Workload Identity Federation) an die jeweiligen Provider delegiert werden. So bleibt die “Source of Truth” für Identitäten zentral, während die tatsächliche Autorisierung weiterhin providerspezifisch erfolgt.

Fazit

IAM ist in der Cloud keine Nebensächlichkeit, die man “auch noch” konfiguriert, sondern die zentrale Sicherheitsgrenze, die darüber entscheidet, ob eine Plattform sicher betrieben werden kann. Least Privilege, saubere Trennung von Identitätstypen, Auditierbarkeit und ein tragfähiges Modell für Multi-Cloud-Föderation sind keine nachträglichen Erweiterungen, sondern Grundvoraussetzungen, die von der ersten Design-Entscheidung an mitgedacht werden müssen.

• IAM
• Cloud
• Security

← Zurück zur Übersicht