3、主流云平台身份体系对比：AWS IAM、Azure AD、GCP Cloud IAM

好，咱们进入第三讲。说实话，做多云管理这几年，我踩过最大的坑，就是「以为各家IAM差不多」。你想想看，AWS叫IAM，Azure叫Azure AD（现在叫Microsoft Entra ID），GCP叫Cloud IAM。名字都带个「身份」，但骨子里的设计哲学，差得可不是一星半点。

这一节，我就带你把这三位「大佬」的身份体系扒个底朝天。咱们不搞教科书式的罗列，而是从实战角度，看看它们到底怎么用、怎么配、怎么坑。

3.1 AWS IAM：资源为王，策略驱动

AWS IAM，说白了就是「谁（身份）能对什么（资源）做什么（动作）」。它的核心是策略（Policy）。

身份类型：用户（User）、用户组（Group）、角色（Role）。嗯，这里要注意，AWS的角色不是给「人」用的，而是给「服务」或「跨账号访问」用的。我记得刚入行时，总把角色当用户用，结果权限死活配不对。

策略结构：一个典型的策略长这样：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-bucket"
    }
  ]
}

你看，它明确指定了资源ARN。这就是AWS的风格——资源导向。每个资源都有唯一的ARN，策略必须精确指向它。

3.2 Azure AD（Microsoft Entra ID）：身份为中心，目录即边界

Azure AD跟AWS IAM完全是两个路子。它本质上是一个身份目录服务，管理的是「人」和「应用」的身份。

身份类型：用户、服务主体（Service Principal）、托管标识（Managed Identity）。服务主体说白了就是「应用的身份」，托管标识则是Azure自动管理的服务主体。

权限模型：Azure AD用的是RBAC（基于角色的访问控制）。角色分为「目录角色」和「Azure资源角色」。举个例子：

• 目录角色：全局管理员、用户管理员——这些控制Azure AD本身
• 资源角色：虚拟机贡献者、存储账户贡献者——这些控制Azure资源

你想想看，一个用户可能既是「全局管理员」（能改目录设置），又是「虚拟机贡献者」（能创建VM）。这种双重身份，在AWS里是不存在的。

条件访问：这是Azure AD的杀手锏。你可以设置「只有从公司IP登录，且设备合规，才能访问财务系统」。这种策略在AWS里实现起来就麻烦多了。

3.3 GCP Cloud IAM：扁平化，资源层次清晰

GCP的IAM，我个人觉得是三者中最「清爽」的。它把资源组织成层次结构：组织 -> 文件夹 -> 项目 -> 资源。权限通过角色绑定到成员上。

成员类型：Google账号、服务账号、Google群组、G Suite域名。嗯，这里要注意，GCP的服务账号跟AWS的角色有点像，但更灵活——你可以把服务账号当「人」用，给它赋予角色。

角色类型：

• 基础角色：Owner、Editor、Viewer——太粗了，不建议用
• 预定义角色：比如Compute Admin、Storage Object Viewer——够用
• 自定义角色：自己拼权限——最灵活

GCP的策略绑定是这样的：

// 给用户 user@example.com 绑定「项目查看者」角色
resource "google_project_iam_binding" "project" {
  project = "my-project"
  role    = "roles/viewer"
  members = [
    "user:user@example.com"
  ]
}

你看，它没有AWS那种复杂的策略语法，就是「谁 + 角色 + 资源层次」。简单粗暴。

3.4 三者的核心差异对比

好了，咱们用一张表来总结一下。我建议你把这个表截图保存，以后做多云架构时，直接拿出来对照。

维度	AWS IAM	Azure AD	GCP Cloud IAM
核心设计	资源导向，策略驱动	身份导向，目录即边界	资源层次，角色绑定
身份类型	用户、组、角色	用户、服务主体、托管标识	Google账号、服务账号、群组
权限粒度	极细（可到单个对象）	中等（基于角色）	中等（基于角色+层次）
策略语法	JSON策略文档	角色定义 + 分配	角色定义 + 绑定
跨账号管理	角色信任（STS）	B2B协作 / Lighthouse	跨项目服务账号
条件访问	基于IP、时间、MFA	条件访问策略（强大）	基于条件角色（有限）
学习曲线	中等（策略语法复杂）	中等（角色多，概念多）	低（简洁直观）

3.5 实战建议：多云场景下怎么选？

说实话，没有「最好」的IAM，只有「最合适」的。我个人的习惯是：

• 如果你主要用AWS：老老实实学透IAM策略语法，尤其是「条件键」和「权限边界」这两个高级特性。我在项目中遇到过，有人用权限边界限制了开发人员只能操作特定VPC，效果很好。
• 如果你主要用Azure：重点掌握Azure AD的条件访问和PIM（特权身份管理）。Azure的强项是「身份安全」，别浪费了。
• 如果你主要用GCP：用好资源层次和自定义角色。GCP的IAM虽然简单，但「继承」特性容易导致权限扩散。建议在组织层面就定义好角色，别让项目自己乱配。

好了，这一节就到这里。下一节，咱们聊聊「多云身份同步的坑与解法」——这可是我踩过无数坑才总结出来的经验。