第3章 主流云厂商身份服务对比：AWS IAM、Azure AD、GCP Cloud Identity、阿里云RAM
做多云身份统一，第一步不是写代码，而是搞清楚各家云厂商的「身份服务」到底长什么样。我见过不少团队，上来就想搞个万能对接层，结果被各家API的差异折腾得够呛。说白了，你得先知道每个平台能做什么、不能做什么，才能设计出靠谱的统一方案。
这一章，咱们把四大云厂商的身份服务拉出来遛遛。我会从核心概念、权限模型、适用场景三个维度去拆，最后给一张对比表，方便你快速查阅。
3.1 AWS IAM：老牌劲旅，权限颗粒度最细
AWS IAM（Identity and Access Management）是云身份管理的「老大哥」。2011年就推出了，这么多年迭代下来，成熟度没得说。
核心概念
- User（用户）：代表一个人或一个服务账号。
- Group（组）：用户的集合，权限附加到组上。
- Role（角色）：没有长期凭证的身份，可以被用户、服务或外部身份「扮演」。
- Policy（策略）：JSON格式的权限文档，定义「谁可以对什么资源做什么操作」。
我个人习惯把AWS的权限模型理解成「策略驱动」。你写一个Policy，挂到User、Group或Role上，权限就生效了。策略的语法很灵活，支持条件判断（比如「仅允许来自公司IP的请求」），也支持资源级ARN精确控制。
关键特点
- 权限颗粒度极细：可以精确到某个S3桶的某个前缀下的某个对象。
- 支持临时凭证：通过STS（Security Service）生成，有效期可设，安全性高。
- 与外部IdP集成：支持SAML 2.0和OIDC，可以对接企业AD或Okta。
我的经验：我在项目中遇到过一家客户，把所有权限都挂在User上，结果员工离职时清理权限累到崩溃。后来我建议他们改用Role + 临时凭证的方式，管理成本直接降了一半。记住：能用Role就别用User，能用临时凭证就别用长期密钥。
3.2 Azure AD：企业级身份中心，主打「目录即服务」
Azure AD（现在叫Microsoft Entra ID）跟AWS IAM的思路完全不同。它本质上是一个云上的身份目录服务，脱胎于微软的Active Directory。说白了，它不只是管云资源的访问，更是企业身份的中心化存储。
核心概念
- Tenant（租户）：一个Azure AD实例，代表一个组织。
- User（用户）：目录中的身份对象，可以同步自本地AD。
- Group（组）：支持安全组和Microsoft 365组，可以动态成员规则。
- Service Principal（服务主体）：应用程序在Azure AD中的身份，类似AWS的Role。
- Managed Identity（托管标识）：Azure资源自动获取的身份，无需管理凭证。
Azure AD最让我欣赏的一点是「条件访问」（Conditional Access）。你可以设置策略：只有从公司设备、在特定地理位置、使用合规客户端的用户，才能访问某个应用。这在多云场景下特别有用——你可以用它来控制谁可以访问AWS或GCP的资源。
注意：Azure AD的RBAC（基于角色的访问控制）和AWS IAM的RBAC不是一回事。Azure AD的RBAC管理的是Azure资源（如虚拟机、数据库），而Azure AD本身还有「目录角色」（如全局管理员、用户管理员）。这两个层级容易搞混，我刚开始做Azure项目时就踩过这个坑。
与外部IdP集成：Azure AD原生支持SAML和OIDC，也可以作为IdP被其他云厂商信任。你想想看，如果你用Azure AD做统一身份源，AWS和GCP都信任它，那用户登录一次就能访问所有云资源——这就是「单点登录」的核心思路。
3.3 GCP Cloud Identity：Google的「轻量级选手」
GCP的身份服务叫Cloud Identity，它跟Google Workspace（以前叫G Suite）共享同一个身份后端。如果你公司用Gmail或Google Calendar，那Cloud Identity基本上就是现成的。
核心概念
- Google Account（谷歌账号）：个人身份，可以是@gmail.com或自定义域名。
- Cloud Identity Account（云身份账号）：企业管理的账号，不包含Google Workspace订阅。
- Service Account（服务账号）：GCP中非人类身份的标准方式，类似AWS的Role。
- IAM Policy（IAM策略）：绑定到资源或项目上的权限声明，支持角色（Role）和条件（Condition）。
GCP的权限模型跟AWS很像，但有一个关键区别：GCP的权限是「资源继承」的。你在项目级别设置一个角色，项目下的所有资源都继承这个角色。AWS则更倾向于「显式附加」，每个资源可以有自己的策略。哪种更好？我个人觉得GCP的方式更简洁，但AWS的方式更灵活。
GCP的独特优势
- 与Google Workspace深度集成：用户和组织结构自动同步。
- 支持「Google Groups」作为权限容器：一个群组可以同时管理邮件列表和云权限。
- 条件角色（Conditional Roles）：可以基于IP、时间、资源标签等条件动态授权。
嗯，这里要注意：GCP的Service Account默认有「自动生成密钥」的能力，但密钥一旦泄露风险很大。我曾经帮一个客户做安全审计，发现他们有个Service Account的密钥居然硬编码在代码里，而且有项目删除权限。那场面，想想都后怕。
3.4 阿里云RAM：中国市场的「本土化标杆」
阿里云的RAM（Resource Access Management）是四大云里最「年轻」的，但迭代速度很快。如果你主要做中国市场，阿里云RAM是绕不开的。
核心概念
- RAM用户：对应一个人或应用，有独立的登录密码和AccessKey。
- RAM角色：类似AWS的Role，可以被阿里云服务或外部身份扮演。
- 权限策略：JSON格式，支持系统策略（预定义）和自定义策略。
- 资源组：将资源分组管理，权限可以绑定到资源组级别。
阿里云RAM有一个让我印象深刻的特性：「信任策略」。你可以设置一个RAM角色只能被特定阿里云账号或特定服务扮演。这在多云场景下特别有用——比如你让AWS的某个服务扮演阿里云的RAM角色来读取OSS数据，信任策略就是安全的第一道防线。
避坑指南：我曾经在阿里云上配置跨账号访问时，发现RAM角色的「信任策略」和「权限策略」是两个独立的东西。信任策略决定「谁能扮演这个角色」，权限策略决定「扮演后能做什么」。很多新手只配了权限策略，忘了配信任策略，结果角色永远无法被扮演。记住：两个都要配。
阿里云还有一个「RAM用户无权限」的默认行为：新创建的RAM用户默认没有任何权限，你必须显式授权。这跟AWS的「隐式拒绝」逻辑一致，但跟Azure AD的「默认允许部分操作」不同。设计统一方案时，这个差异要特别注意。
3.5 四大云厂商身份服务对比总表
| 维度 | AWS IAM | Azure AD | GCP Cloud Identity | 阿里云RAM |
|---|---|---|---|---|
| 推出时间 | 2011年 | 2013年（Azure AD） | 2015年（Cloud Identity） | 2015年（RAM） |
| 核心模型 | 策略驱动 | 目录驱动 | 资源继承 | 策略驱动 |
| 用户类型 | IAM User | Azure AD User | Google Account / Cloud Identity Account | RAM User |
| 非人类身份 | IAM Role | Service Principal / Managed Identity | Service Account | RAM Role |
| 权限粒度 | 资源级ARN，条件丰富 | 管理平面 + 数据平面，支持条件访问 | 项目/资源级，支持条件角色 | 资源级，支持资源组 |
| 外部IdP支持 | SAML 2.0, OIDC | SAML 2.0, OIDC, WS-Fed | SAML 2.0, OIDC | SAML 2.0, OIDC |
| 临时凭证 | STS（最长36小时） | 访问令牌（最长24小时） | OAuth 2.0令牌（最长1小时） | STS（最长1小时） |
| 中国市场适配 | 一般（需使用中国区） | 一般（由世纪互联运营） | 较差（无中国区） | 优秀（本土化完善） |
3.6 一张图看懂四大云身份服务的关系
下面这张SVG图，我用「身份源」和「权限模型」两个维度，把四家云厂商的位置画了出来。你可以看到：Azure AD偏身份源侧，AWS和阿里云偏权限模型侧，GCP则居中。
3.7 选型建议：你的场景适合哪家？
看完对比，你可能想问：那我到底该选哪家？其实没有标准答案，但有几个判断维度可以参考。
- 如果你已经有企业AD或微软生态：Azure AD是天然选择。它的目录同步和条件访问能力，其他三家暂时追不上。
- 如果你追求极致的权限控制：AWS IAM的Policy语法最灵活，适合复杂的企业合规场景。
- 如果你主要做中国市场：阿里云RAM的本土化做得最好，比如支持手机号登录、实名认证等。
- 如果你团队小、追求简洁：GCP Cloud Identity的「资源继承」模型上手最快，适合初创团队。
重要提醒：多云身份统一方案的核心不是「选哪家」，而是「如何让它们协同工作」。下一章我们会深入这个话题，但在此之前，请确保你理解了每家云厂商的身份服务边界。我曾经见过一个团队，花三个月写了一个「万能适配器」，结果发现Azure AD的OIDC令牌和AWS的STS令牌根本不能互换——这就是没理解边界的结果。
好了，这一章的内容就到这里。记住：对比不是为了分高下，而是为了在统一方案中「各取所长」。你想想看，如果能把Azure AD的身份源能力、AWS的权限控制、GCP的简洁性、阿里云的本土化结合起来，那才是真正的「多云身份统一」。