AWS vs GCP vs Azure：组织层级、IAM 和密钥管理并排比较

如果您已经了解一种云的治理模型，那么您就了解了其他两种的 80% — 概念是相同的，只是词汇有所变化。在您交付任何实际内容之前，每个云都会让您回答相同的三个问题：我如何组织我的账户，谁被允许做什么，以及我的加密密钥如何创建和控制？本文将 AWS、Google Cloud 和 Azure 进行逐层映射，并指出这种类比悄然失效的四个地方。

这四个层级——层级结构、防护措施、身份和密钥管理——也是所有云架构和安全考试的核心骨干。因此，这份能为您节省一周跨云困惑的阅读材料，也是认证考试的大部分教学大纲。每个层级的深入学习认证链接在文章末尾。

每个云都解决的三个问题

抛开营销，所有的治理讨论都围绕着堆叠在一起的三个层级：

• 结构 — 一组嵌套的容器（组织 → 分组 → 工作负载边界），以便您能够隔离环境、应用防护措施并拆分账单。
• 身份和权限 — 哪些主体可以对哪些资源执行哪些操作，以及任何授权都无法逾越的权限上限。
• 密钥管理 — 密码密钥的存储位置、谁可以使用它们以及谁可以管理它们 — 这是人们经常混淆的两个不同问题。

大多数工程师可以列出他们最熟悉的云中的各个组成部分。但困难之处在于全貌：那些容易被遗忘的层级，以及每个组成部分如何转换为另外两个云。

层级 1 — 资源层级结构

每个云都有一个顶层的组织节点，一个可选的用于部门或环境的中间分组层，以及一个同时作为计费和爆炸半径单位的工作负载边界。所有三个云中，高层设置的策略都会向下流动。

• 组织根 — AWS：带有管理账户的 Organization。GCP：organization node。Azure：租户根管理组，由 Microsoft Entra 租户支持。
• 分组容器（可嵌套） — AWS：Organizational Unit (OU)。GCP：folder。Azure：management group。
• 工作负载和计费边界 — AWS：account。GCP：project。Azure：subscription。
• 边界内的资源分组 — AWS：无（通过 tags，或每个 account）。GCP：无 — project 就是容器。Azure：resource group，这是强制性的；每个 resource 都且只存在于一个 resource group 中。

第一个真正的分歧隐藏在这里。在 AWS 中，account 是一道硬隔离墙——默认的爆炸半径单位——这就是为什么成熟的 AWS 环境运行着几十或上百个 account。在 GCP 中，project 同时承担两个职责：它既是分组单位，又是计费/隔离单位，因此没有独立的“resource group”概念。Azure 则增加了其他两个云所没有的第四个层级——resource group——它位于 subscription 之下，作为可作为一个单元进行部署和拆除的生命周期容器。

层级 2 — 预防性防护措施（权限上限）

在您授予任何人任何权限之前，每个云都允许您设置一个节点之下可能存在的权限的上限——一个任何单个授权都无法突破的天花板。这与授予访问权限不同；它是“在整个组织范围内，你永远不能做”的层级。

• 主体可以做什么的限制 — AWS：Service Control Policy (SCP)。GCP：Organization Policy 约束加上 IAM deny policies。Azure：Azure Policy。
• 谁可以接触资源的限制 — AWS：Resource Control Policy (RCP)。GCP：资源上的 IAM allow/deny policies。Azure：Azure Policy 加上 deny assignments。
• 强制执行服务配置 — AWS：声明性策略。GCP：Organization Policy 约束。Azure：Azure Policy (deny / audit / deployIfNotExists)。

AWS 将这项工作分成了两部分。SCP 以主体为中心（“我们的人不能做 X”），而更新的 RCP 以资源为中心（“任何人都不能——即使是外部账户——接触这个 S3 bucket、KMS key 或 role，除非他们在我们组织内部”）。两者结合使用可以弥补单独使用时留下的空白。陷阱是：在 AWS 和 GCP 中，SCP 或 Organization Policy 从不授予任何东西——它只做减法。Azure 的工作原理不同，它清晰地将 **RBAC（权限）**与 **Azure Policy（合规性和配置）**分离，因此防护措施的职责主要归 Azure Policy 所有，而“谁能做什么”则完全归 RBAC 所有。

层级 3 — 身份和权限

每个云都将授权表达为相同的三元组——一个主体、一个角色（一组权限捆绑包）和一个范围——但它们组合这些组件的方式不同。

• 身份目录 — AWS：IAM 加上 IAM Identity Center (SSO)。GCP：Cloud Identity / Google Workspace 加上 IAM。Azure：Microsoft Entra ID。
• 权限捆绑包（“角色”） — AWS：一个 IAM policy，托管或内联。GCP：一个 IAM role — 基本、预定义或自定义。Azure：一个 RBAC role definition，内置或自定义。
• 授权本身 — AWS：附加到用户、组或角色的策略。GCP：资源上的 IAM binding（成员 + 角色，可选条件）。Azure：一个角色assignment（主体 + 角色 + 范围）。
• 条件和显式拒绝 — AWS：IAM condition keys 和显式 Deny。GCP：IAM Conditions 和 deny policies。Azure：RBAC conditions 和 deny assignments。

最深层的区别在于授权存储在哪里。在 AWS 中，您主要将策略附加到身份——一个 role 或用户——权限随之传播。在 GCP 中，allow policy 附加到资源：您授予主体 P 角色 R 在资源 X 上，它会沿层级结构继承。Azure 的 role assignment 类似于 GCP 的 binding，但锚定到管理组 → 订阅 → 资源组 → 资源链中的一个范围。记住“AWS = 身份附加，GCP 和 Azure = 资源/范围附加”，许多跨云的困惑就会消失。

层级 3b — 工作负载身份（人们容易忘记的部分）

人类不是唯一的主体。您的代码也需要一个身份，而正确地实现这一点是实现最小权限的最大杠杆。到处都适用的黄金法则：绝不发布长期静态密钥——而是将托管身份附加到工作负载。

• 运行中工作负载的身份 — AWS：一个 IAM role，通过实例配置文件、任务角色或 OIDC 承担。GCP：一个附加到资源的 service account。Azure：一个托管身份，系统分配或用户分配。
• 应用程序 / 非人类主体 — AWS：IAM role。GCP：service account。Azure：service principal。
• 云外部的无密钥信任 — AWS：带有 OIDC/SAML 联合的 IAM 角色。GCP：Workload Identity Federation。Azure：workload identity federation。

注意容易让人混淆的命名重叠：AWS 中的**“IAM role”是一个您可以承担的工作负载身份**，而 GCP 和 Azure 中的“role”只是一个权限捆绑包——身份是 service account 或 managed identity。同一个词，两个不同的职责。GCP service account keys 和 Azure service principal secrets 仍然存在，但两个云现在都大力推行针对其边界之外运行的任何事物的无密钥联合。

层级 4 — 密钥管理

最后，加密。每个云都有一个托管密钥服务，以一个小型的层级结构组织密钥，并且——关键在于——将使用密钥（加密/解密）与管理密钥（轮换、禁用、设置策略）分离。

• 服务 — AWS：KMS，加上用于专用硬件的 CloudHSM。GCP：Cloud KMS，加上 Cloud HSM / 外部。Azure：Key Vault，加上用于专用硬件的 Managed HSM。
• 密钥组织 — AWS：KMS keys (CMK)、aliases、multi-Region keys。GCP：key ring → key → key version。Azure：vault → key / secret / certificate。
• 访问控制 — AWS：key policy + grants + IAM（三者结合）。GCP：项目、key ring 或 key 级别的 Cloud KMS IAM bindings。Azure：默认 RBAC，或遗留的每个保管库访问策略；Managed HSM 使用其自己的本地 RBAC。
• 使用与管理的分离 — AWS：加密/解密操作 vs. 密钥管理操作。GCP：cryptoKeyEncrypterDecrypter vs. admin 角色。Azure：“Crypto User” vs. “Crypto Officer”风格的角色。

一个值得了解的当前细微差别是：对于最新 API 版本上的新 Key Vault，Azure RBAC 现在是默认的访问模型，而旧的每个保管库访问策略是遗留路径——这最终使 Key Vault 与 Azure 的其余部分处理权限的方式保持一致。AWS 仍然是异类：KMS key 的密钥策略是权威的，可以独立于 IAM 授予访问权限，因此一个经典的 AWS 自我伤害是：在编辑 IAM 的同时忘记密钥策略而将自己锁在密钥之外。在 GCP 中，KMS 访问与其他一切一样是普通的 IAM。

心智模型失效之处

如果您过于字面地信任一个干净的映射，那将是危险的。类比失效的四个地方：

• **“IAM role”意味着两个不同的东西。在 AWS 中，它是一个可承担的身份*；在 GCP 和 Azure 中，“role”只是一个*权限集，身份保持分离。绝不逐字翻译。
• **AWS 将权限附加到身份；GCP 和 Azure 将权限附加到资源和范围。**当您切换云时，您“我应该在哪里审计访问权限？”的本能必须转变。
• **账户、项目和订阅的爆炸半径不同。**AWS account 是一道强大的隔离墙；GCP project 集隔离、计费和分组于一体；Azure subscription 主要是一个计费和规模边界，日常生命周期由 resource group 处理。
• **护栏做减法，授权做加法——但 Azure 拆分了职责。*SCP 和 Organization Policy 只会限制*权限；Azure 通过 Policy 进行限制，通过 RBAC 进行授权，两者是独立的系统。

这三者背后的原则是相同的：最小权限，通过结构强制执行。将护栏设置在高层级（组织、OU、文件夹、管理组），狭隘地授权并优先使用角色而非静态密钥，并严格区分“可以使用密钥”和“可以管理密钥”。名称在不同云之间变化；但原则不变。

实践要点

• **在第一个工作负载之前设计层级结构。**稍后改造账户、项目或订阅会在所有云中造成麻烦。
• **设置高层级上限，低层级授权。**在顶层使用 SCP/RCP、Organization Policy 或 Azure Policy；在可行的最窄范围授予特定角色。
• **默认使用托管身份。**AWS 上的 IAM roles，GCP 上的 service accounts，Azure 上的 managed identities——以及用于跨云边界的任何事物的无密钥联合。
• **将密钥管理视为特权。**将加密/解密与轮换/禁用/设置策略分离，并在 AWS 上始终检查密钥策略，而不仅仅是 IAM。
• 如果您使用 Terraform 或 OpenTofu，这些原语正是您将要编码的内容——aws_organizations_*、google_folder、azurerm_management_group，以及它们之下的 IAM/RBAC 和 KMS 资源。

深入学习每个云的每个层级

每个云的架构和安全认证都完全建立在资源层级结构、IAM/RBAC 和密钥管理之上。如果您想通过真实的考试题目进行练习，CertLabPro 为每个主题都提供了学习路径：

• AWS — Solutions Architect Associate (SAA-C03) 用于学习层级结构和 IAM，以及 Security Specialty (SCS-C03) 用于学习 SCP、RCP 和 KMS。刚接触 AWS？请从 Cloud Practitioner (CLF-C02) 开始。
• Google Cloud — Professional Cloud Architect 用于学习组织、文件夹、项目和 IAM，以及 Professional Cloud Security Engineer 用于学习 IAM deny policies、Organization Policy 和 Cloud KMS。
• Azure — Solutions Architect Expert (AZ-305) 用于学习管理组和治理，以及 Security Engineer (AZ-500) 用于学习 RBAC、Azure Policy 和 Key Vault。刚接触 Azure？请从 Azure Fundamentals (AZ-900) 开始。

总结

AWS、Google Cloud 和 Azure 并不像它们的文档给人的感觉那样不同。每个云都提供一个层级结构来组织账户，一个基于主体-角色-范围的身份模型，一个限制可以存在哪些权限的护栏层，以及一个将密钥使用与密钥管理分离的密钥服务。一次性学习这四个层级，跨云翻译就主要在于词汇——并学习类比失效的四个地方，您将避免词汇所隐藏的错误。这些基础知识正是 CertLabPro 题库旨在训练的，涵盖所有三个云。