2.1 IAM / RAM / CAM 身份与访问对照
2.1 IAM / RAM / CAM 身份与访问对照
本节摘要：身份与访问管理（Identity and Access Management）是云上"谁、可以做什么"的根。AWS IAM、阿里云 RAM、腾讯云 CAM 三家在产品命名、策略语言、临时凭证模型上高度同构（毕竟 RAM/CAM 的产品设计都参考了 AWS IAM），但在 API 风格、默认配额、跨账号角色的实现细节上有差异。本节给一张三栏对照表 + 一段实战选型建议。
本节学什么
图：跨账号角色扮演
阅读完本节，你应当能够：
- 说出 IAM / RAM / CAM 各自的全称与所在云厂商，并能用一句话讲清三者的关系（"RAM/CAM 借鉴了 IAM 的策略模型"）。
- 理解"用户、组、角色、策略"四要素在三家的命名差异，并能画出一个简单的策略示例（JSON）。
- 用临时凭证（STS）做跨账号角色扮演：理解为什么"长期 AccessKey 是反模式"，应该用 AssumeRole / SwitchRole 替代。
- 针对"一个企业内部多账号管理"场景给出 IAM/RAM/CAM 的实操路径。
一、问题与直觉：长期 AccessKey 是反模式
很多新手开通云账号后第一件事是"创建 AccessKey，存到代码里"。这是最常见的云上安全事故源。
举一个真实反例（已脱敏）：某公司 2019 年把阿里云 AccessKey 硬编码到前端 JS 文件里，OSS 桶里 4TB 用户图片被攻击者用 1 个月时间扫描下载完，最后发现 2.3 万元出向流量 + 监管罚款 15 万。AccessKey 一旦泄露，无法追溯"是谁在什么时间用什么 IP 调用"——因为是"账号级别"凭证，不是"用户级别"。
正解是用"角色 + 临时凭证"：每个工程师通过自己的 RAM/CAM/IAM 用户登录，调用 AssumeRole 获取 1 小时有效的临时 AccessKey，凭证过期自动失效。这是云原生身份管理的核心模式，三家都支持。
二、核心原理：四要素与策略语言
2.1 四要素对照
| 概念 | AWS IAM | 阿里云 RAM | 腾讯云 CAM |
|---|---|---|---|
| 身份 | User / Role / Group | 用户 / 角色 / 用户组 | 用户 / 角色 / 用户组 |
| 策略 | Policy（JSON 文档） | 策略（JSON 文档） | 策略（JSON 文档） |
| 临时凭证 | STS AssumeRole | STS AssumeRole | STS AssumeRole |
| 跨账号 | Cross-account Role | 角色 SSO / 跨账号角色 | 跨账号角色 |
| 资源命名 | ARN（Amazon Resource Name） | ACS Resource（Alibaba Cloud Service） | qcs::（QCService） |
| 默认配额 | 每个账号 5000 个 IAM User | 每个账号 5000 个 RAM User | 每个账号 1000 个 CAM User |
| API 风格 | AWS Signature V4 | Alibaba Cloud RPC over HTTPS | TC3-HMAC-SHA256 |
2.2 一段典型的策略示例（AWS IAM）
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::my-bucket/*" }, { "Effect": "Deny", "Action": "s3:DeleteBucket", "Resource": "*" } ] }
阿里云 RAM 写法几乎一致，只是 Action 字段用 oss:GetObject / oss:PutObject，Resource 用 acs:oss:*:*:my-bucket/*。腾讯云 CAM 同样结构。
2.3 跨账号角色扮演流程
这个流程在三家的实现高度一致：用户用
AssumeRole拿到 1 小时临时凭证，业务代码用临时凭证调用云 API。不要把长期 AccessKey 放到代码里、配置文件里、CI/CD 环境变量里——这是云安全的头号反模式。
三、工程实践要点：多账号管理与实战选型
3.1 一个企业内部的多账号架构
某互联网公司的标准多账号架构（3 个账号）：
| 账号 | 用途 | 谁有管理员权限 |
|---|---|---|
| 管理账号 | 统一身份、计费聚合、跨账号角色 | 安全团队 |
| 开发测试账号 | 开发、测试环境 | 研发团队 |
| 生产账号 | 生产环境 | SRE 团队 |
工程师登录"管理账号"后，通过 SwitchRole / AssumeRole 切换到目标账号，只在需要时获得生产账号的临时权限。这种"账号边界 + 角色切换"是云上权限隔离的最佳实践。
3.2 三家"角色"概念的差异
虽然概念类似，但有一处关键差异：AWS IAM Role 是个独立实体，可以"被任何账号扮演"；阿里云 RAM Role 同样独立；腾讯云 CAM Role 也是独立实体。但**跨账号扮演的"信任策略"**三家略有差异：
- AWS：在 Role 的 Trust Policy 里写
"AWS": "arn:aws:iam::123456789012:root"。 - 阿里云：在 RAM Role 的信任策略里写
"Service": [ "ecs.aliyuncs.com" ]或具体账号 ID。 - 腾讯云：在 CAM Role 的信任策略里写
qcs::cam::uin/123456789:root。
3.3 反例：哪些坑要避开
| 反例 | 后果 | 正解 |
|---|---|---|
| 长期 AccessKey 存到代码里 | 泄露后无法追责 | 用 AssumeRole + 临时凭证 |
| 给所有工程师 AdministratorAccess | 谁都能删生产数据 | 按需给最小权限 |
把生产 RAM Role 信任策略写成 * |
任何账号都能 Assume | 限定到具体账号 ID + 条件 |
| 不开 CloudTrail / 操作审计 | 出事后无法追查 | 强制开 + 日志归档到只读账号 |
3.4 实战选型建议
| 场景 | 推荐做法 |
|---|---|
| 工程师访问自己公司的云资源 | 主账号 + AssumeRole 到子账号 |
| 第三方 SaaS 服务访问你的 OSS | 角色 + 限定 IP 段 + 限定桶名 |
| CI/CD 流水线调用云 API | OIDC Token + AssumeRole（无需长期 Key） |
| 跨云资源访问 | 不要用云上身份做——用专门的服务账号 |
⚠️ 常见坑：AccessKey 一旦泄露，唯一的止血方式是"禁用"而不是"修改密码"。因为 AccessKey 等同于密码，泄露 = 密码泄露，没有"改密码"的概念。强烈建议开启"AccessKey 异常调用告警"——云厂商都有这个能力。
💡 关键直觉：身份管理是云上"零号问题"。如果身份权限配置错乱，后面所有 IAM 策略、ACL、安全组都是空中楼阁。多账号 + 角色 + 临时凭证是工业级标准，单账号 + 长期 Key 是入门练习。
本节要点回顾
- IAM / RAM / CAM 高度同构，都遵循"用户、组、角色、策略"四要素 + JSON 策略语言。
- 长期 AccessKey 是反模式，应该用 AssumeRole + 临时凭证（1 小时有效）。
- 跨账号角色扮演是云上权限隔离的标准做法：管理账号 + 子账号 + SwitchRole。
- 资源命名三家不同：ARN / ACS / qcs::，写自动化脚本时要分别处理。
- 多账号架构：管理账号（统一身份）+ 开发账号 + 生产账号，每个账号最小权限。
下一节我们把视角从"身份"切到"计算"——三家云的虚机、容器、K8s 服务对照。