AWS vs GCP vs Azure: Organisationshierarchie, IAM und Schlüsselmanagement im direkten Vergleich

Wenn Sie das Governance-Modell einer Cloud bereits kennen, beherrschen Sie 80 % der anderen beiden — die Konzepte sind identisch, nur die Terminologie ändert sich. Jede Cloud stellt Ihnen dieselben drei Fragen, bevor Sie etwas Reales bereitstellen: Wie organisiere ich meine Konten, wer darf was tun und wie werden meine Verschlüsselungsschlüssel erstellt und kontrolliert? Dieser Beitrag ordnet AWS, Google Cloud und Azure Schicht für Schicht ein und weist auf die vier Stellen hin, an denen die Analogie stillschweigend bricht.

Diese vier Schichten — Hierarchie, Guardrails, Identität und Schlüsselmanagement — bilden auch das Rückgrat jeder Cloud-Architektur- und Sicherheitsprüfung. Die Lektüre, die Ihnen eine Woche der Cross-Cloud-Verwirrung erspart, ist also der Großteil des Lehrplans für eine Zertifizierung. Zertifizierungen zur Vertiefung jeder Schicht sind am Ende verlinkt.

Die drei Probleme, die jede Cloud löst

Abseits des Marketings besteht jede Governance-Diskussion aus drei übereinanderliegenden Schichten:

• Struktur — eine verschachtelte Menge von Containern (Organisation → Gruppierung → Workload-Grenze), um Umgebungen zu isolieren, Guardrails anzuwenden und die Abrechnung aufzuteilen.
• Identität und Berechtigungen — welche Principals welche Aktionen auf welchen Ressourcen ausführen dürfen, plus die Obergrenze, die festlegt, welche Berechtigungen überhaupt vergeben werden können.
• Schlüsselmanagement — wo kryptografische Schlüssel gespeichert sind, wer sie verwenden und wer sie verwalten darf — zwei verschiedene Fragen, die oft verwechselt werden.

Die meisten Ingenieure können die Komponenten in der Cloud auflisten, die sie am besten kennen. Der schwierige Teil ist das Gesamtbild: die Schichten, die leicht vergessen werden, und wie sich jede Komponente auf die anderen beiden Clouds übertragen lässt.

Schicht 1 — die Ressourcenhierarchie

Jede Cloud verfügt über einen Top-Level organization node, eine optionale mittlere Gruppierungsschicht, die Sie für Abteilungen oder Umgebungen verschachteln, und eine workload boundary, die auch als Abrechnungseinheit und blast radius dient. Hoch angesetzte Richtlinien fließen in allen drei nach unten.

• Org root — AWS: eine Organization mit einem management account. GCP: der organization node. Azure: die tenant root management group, unterstützt durch einen Microsoft Entra tenant.
• Grouping container (verschachtelbar) — AWS: Organizational Unit (OU). GCP: folder. Azure: management group.
• Workload and billing boundary — AWS: account. GCP: project. Azure: subscription.
• Resource grouping inside the boundary — AWS: keine (tags, oder pro account). GCP: keine — das project ist der Container. Azure: die resource group, die obligatorisch ist; jede Ressource gehört zu genau einer.

Die erste echte Divergenz verbirgt sich hier. Bei AWS ist der account eine harte Trennwand — die Standardeinheit des blast radius — weshalb etablierte AWS-Installationen Dutzende oder Hunderte von accounts umfassen. Bei GCP erfüllt das project zwei Aufgaben gleichzeitig: Es ist sowohl die Gruppierungseinheit als auch die Abrechnungs-/Isolationseinheit, sodass es kein separates Konzept einer "resource group" gibt. Azure fügt eine vierte Ebene hinzu, die den anderen fehlt — die resource group — die unter der subscription als Lifecycle-Container dient, den Sie als Einheit bereitstellen und wieder entfernen.

Schicht 2 — präventive Guardrails (die Berechtigungsobergrenze)

Bevor Sie jemandem etwas gewähren, können Sie in jeder Cloud eine Obergrenze dafür festlegen, welche Berechtigungen jemals unterhalb eines Knotens existieren dürfen — eine Obergrenze, die keine einzelne Gewährung durchbrechen kann. Dies ist nicht dasselbe wie das Zuweisen von Zugriff; es ist die Ebene "Sie dürfen niemals, organisationsweit".

• Obergrenze für Aktionen von Principals — AWS: Service Control Policy (SCP). GCP: Organization Policy constraints plus IAM deny policies. Azure: Azure Policy.
• Obergrenze für Zugriffe auf eine Ressource — AWS: Resource Control Policy (RCP). GCP: IAM allow/deny policies auf der Ressource. Azure: Azure Policy plus deny assignments.
• Erzwingung der Dienstkonfiguration — AWS: declarative policies. GCP: Organization Policy constraints. Azure: Azure Policy (deny / audit / deployIfNotExists).

AWS hat diese Aufgabe geteilt. SCPs sind principal-zentriert ("unsere Leute dürfen X nicht tun") und die neueren RCPs sind ressourcen-zentriert ("niemand — nicht einmal ein externer account — darf diesen S3 bucket, KMS key oder role berühren, es sei denn, er befindet sich in unserer org"). Zusammen schließen sie Lücken, die keiner allein abdeckt. Die Falle: In AWS und GCP gewährt eine SCP oder Org Policy niemals etwas — sie zieht nur ab. Azure ist anders aufgebaut und trennt RBAC (Berechtigungen) sauber von Azure Policy (Compliance und Konfiguration), sodass die Aufgabe der Guardrails hauptsächlich Azure Policy obliegt, während "wer was tun darf" vollständig RBAC zugeordnet ist.

Schicht 3 — Identität und Berechtigungen

Jede Cloud drückt eine Berechtigung als dasselbe Dreiergespann aus — einen principal, eine role (ein Bündel von Berechtigungen) und einen scope — setzt die Komponenten jedoch unterschiedlich zusammen.

• Identity directory — AWS: IAM plus IAM Identity Center (SSO). GCP: Cloud Identity / Google Workspace plus IAM. Azure: Microsoft Entra ID.
• Berechtigungsbündel (die "role") — AWS: eine IAM policy, managed oder inline. GCP: eine IAM role — basic, predefined oder custom. Azure: eine RBAC role definition, built-in oder custom.
• Die Berechtigung selbst — AWS: eine policy, die an einen user, group oder role angehängt ist. GCP: ein IAM binding (member + role, optional eine condition) auf einer Ressource. Azure: ein role assignment (principal + role + scope).
• Conditions und explizite Deny — AWS: IAM condition keys und explizites Deny. GCP: IAM Conditions und deny policies. Azure: RBAC conditions und deny assignments.

Der größte Unterschied liegt darin, wo die Berechtigung verankert ist. Bei AWS hängen Sie die policy meist an die identity — einen role oder user — und die Berechtigung reist mit ihnen. Bei GCP wird die allow policy an die Ressource angehängt: Sie gewähren principal P die role R auf Ressource X, und dies wird die Hierarchie herunter vererbt. Azures role assignment ähnelt GCPs binding, ist aber an einen scope in der Kette management-group → subscription → resource-group → resource gekoppelt. Verinnerlichen Sie "AWS = identity-attached, GCP und Azure = resource/scope-attached", und ein Großteil der Cross-Cloud-Verwirrung verschwindet.

Schicht 3b — workload identity (der Teil, den man leicht vergisst)

Menschen sind nicht die einzigen principals. Ihr Code benötigt ebenfalls eine identity, und diese richtig zu konfigurieren, ist der größte Hebel für least privilege. Die goldene Regel überall: niemals langlebige statische Schlüssel ausliefern — stattdessen eine managed identity an die workload anhängen.

• Identity für eine laufende workload — AWS: eine IAM role, angenommen über instance profile, task role oder OIDC. GCP: ein service account, angehängt an die Ressource. Azure: eine managed identity, system- oder user-assigned.
• App / nicht-menschlicher principal — AWS: IAM role. GCP: service account. Azure: service principal.
• Schlüsselloses Vertrauen von außerhalb der Cloud — AWS: IAM roles mit OIDC/SAML federation. GCP: Workload Identity Federation. Azure: workload identity federation.

Achten Sie auf die Namensüberschneidung, die viele verwirrt: Eine "IAM role" in AWS ist eine workload identity, die Sie annehmen, während eine "role" in GCP und Azure lediglich ein Berechtigungsbündel ist — die identity ist ein service account oder eine managed identity. Dasselbe Wort, zwei unterschiedliche Aufgaben. GCP service-account keys und Azure service-principal secrets existieren zwar noch, aber beide Clouds drängen inzwischen stark auf keyless federation für alles, was außerhalb ihres Perimeters läuft.

Schicht 4 — Schlüsselmanagement

Zuletzt die Verschlüsselung. Jede Cloud bietet einen Managed Key Service, organisiert Schlüssel in einer kleinen Hierarchie und — entscheidend — trennt die Nutzung eines Schlüssels (encrypt/decrypt) von der Verwaltung eines Schlüssels (rotate, disable, set policy).

• Dienst — AWS: KMS, plus CloudHSM für dedizierte Hardware. GCP: Cloud KMS, plus Cloud HSM / external. Azure: Key Vault, plus Managed HSM für dedizierte Hardware.
• Schlüsselorganisation — AWS: KMS keys (CMKs), aliases, multi-Region keys. GCP: key ring → key → key version. Azure: vault → key / secret / certificate.
• Zugriffskontrolle — AWS: key policy + grants + IAM (alle drei kombinieren). GCP: Cloud KMS IAM bindings auf project-, key-ring- oder key-Ebene. Azure: RBAC standardmäßig, oder legacy per-vault access policies; Managed HSM verwendet sein eigenes lokales RBAC.
• Trennung Nutzung vs. Verwaltung — AWS: encrypt/decrypt actions vs. key-admin actions. GCP: cryptoKeyEncrypterDecrypter vs. admin roles. Azure: Rollen im Stil von "Crypto User" vs. "Crypto Officer".

Eine aktuelle Besonderheit, die man kennen sollte: Für neue Key Vaults mit neueren API-Versionen ist Azure RBAC jetzt das Standard-Zugriffsmodell, und die älteren per-vault access policies sind der Legacy-Pfad — was Key Vault endlich an die Art und Weise anpasst, wie der Rest von Azure Berechtigungen handhabt. AWS bleibt der Ausreißer: Die key policy eines KMS key ist maßgeblich und kann unabhängig von IAM Zugriff gewähren, sodass ein klassischer AWS-Fehler darin besteht, sich selbst aus einem key auszuschließen, indem man IAM bearbeitet und dabei die key policy vergisst. In GCP ist der KMS-Zugriff wie alles andere in IAM geregelt.

Wo das mentale Modell bricht

Eine saubere Zuordnung ist gefährlich, wenn man ihr zu wörtlich vertraut. Die vier Stellen, an denen die Analogie Lecks aufweist:

• "IAM role" bedeutet zwei verschiedene Dinge. In AWS ist es eine annehmbare identity; in GCP und Azure ist eine "role" lediglich ein permission set, wobei die identity separat gehalten wird. Übersetzen Sie es niemals Wort für Wort.
• AWS hängt Berechtigungen an identities; GCP und Azure hängen sie an Ressourcen und scopes. Ihr Instinkt, "wo suche ich nach Zugriffsprüfungen?", muss sich ändern, wenn Sie die Clouds wechseln.
• Account, project und subscription haben nicht den gleichen blast radius. Ein AWS account ist eine starke Trennwand; ein GCP project ist Wand, Rechnung und Gruppierung in einem; eine Azure subscription ist hauptsächlich eine Abrechnungs- und Skalierungsgrenze, wobei die resource group das tägliche Lifecycle-Management übernimmt.
• Guardrails subtrahieren, Berechtigungen addieren — außer Azure trennt die Aufgaben. SCPs und Org Policies beschränken Berechtigungen nur; Azure beschränkt über Policy und gewährt über RBAC als zwei getrennte Systeme.

Das zugrunde liegende Prinzip aller drei ist dasselbe: least privilege, durch Struktur erzwungen. Setzen Sie Guardrails hoch an (org, OU, folder, management group), gewähren Sie Berechtigungen eng und bevorzugen Sie roles gegenüber statischen Schlüsseln, und trennen Sie "einen Schlüssel verwenden können" von "einen Schlüssel verwalten können". Die Namen ändern sich über die Clouds hinweg; die Disziplin nicht.

Praktische Erkenntnisse

• Entwerfen Sie die Hierarchie vor der ersten workload. Das nachträgliche Anpassen von accounts, projects oder subscriptions ist in jeder Cloud aufwendig.
• Setzen Sie Obergrenzen hoch an, gewähren Sie Berechtigungen niedrig. SCP/RCP, Org Policy oder Azure Policy an der Spitze; spezifische roles im engsten passenden scope.
• Standardmäßig managed identities verwenden. IAM roles auf AWS, service accounts auf GCP, managed identities auf Azure — und keyless federation für alles, was eine Cloud-Grenze überschreitet.
• Behandeln Sie key admin als privilegiert. Trennen Sie encrypt/decrypt von rotate/disable/set-policy, und überprüfen Sie in AWS immer die key policy, nicht nur IAM.
• Wenn Sie Terraform oder OpenTofu verwenden, sind diese Primitive genau das, was Sie kodifizieren werden — aws_organizations_*, google_folder, azurerm_management_group, und die IAM/RBAC- und KMS-Ressourcen darunter.

Jede Schicht pro Cloud vertiefen

Die Architektur- und Sicherheitszertifizierungen jeder Cloud basieren direkt auf der Ressourcenhierarchie, IAM/RBAC und dem Schlüsselmanagement. Wenn Sie diese mit echten Prüfungsfragen üben möchten, bietet CertLabPro für jedes Thema einen Kurs:

• AWS — Solutions Architect Associate (SAA-C03) für die Hierarchie und IAM, und Security Specialty (SCS-C03) für SCPs, RCPs und KMS. Neu bei AWS? Beginnen Sie mit Cloud Practitioner (CLF-C02).
• Google Cloud — Professional Cloud Architect für organization, folders, projects und IAM, und Professional Cloud Security Engineer für IAM deny policies, Org Policy und Cloud KMS.
• Azure — Solutions Architect Expert (AZ-305) für management groups und governance, und Security Engineer (AZ-500) für RBAC, Azure Policy und Key Vault. Neu bei Azure? Beginnen Sie mit Azure Fundamentals (AZ-900).

Fazit

AWS, Google Cloud und Azure sind nicht so unterschiedlich, wie ihre Dokumentation es erscheinen lässt. Jede Cloud bietet eine Hierarchie zur Organisation von accounts, ein Identitätsmodell, das auf principal-role-scope aufbaut, eine Guardrail-Schicht, die die möglichen Berechtigungen begrenzt, und einen Key Service, der die Nutzung von Schlüsseln von deren Verwaltung trennt. Lernen Sie die vier Schichten einmal, und die Cross-Cloud-Übersetzung ist größtenteils Vokabular — und lernen Sie die vier Stellen, an denen die Analogie Lecks aufweist, und Sie werden die Fehler vermeiden, die das Vokabular verbirgt. Diese Grundlagen sind genau das, wofür die Fragenkataloge von CertLabPro entwickelt wurden, um sie in allen drei Clouds zu vertiefen.