三个核心概念
| 概念 | 含义 |
|---|---|
| Identity（身份） | 谁——人 / 服务 / 设备 |
| Permission（权限） | 能做什么——列表 / 读 / 写 / 删 某个资源 |
| Policy（策略） | 把权限和身份关联的规则 |
各家云商名字略有不同（AWS IAM / GCP IAM / Azure RBAC / 阿里 RAM / 腾讯 CAM），模型一致。
用户 vs 角色 vs 服务账号
人类用户（IAM User）
→ 通常应该 SSO，不直接 attach 长期凭据
角色（Role）
→ 一组权限的"帽子"，由用户 / 服务"扮演"
→ AWS STS / GCP Service Account Impersonation 临时签发
服务账号（Service Account）
→ 给非人类身份用——CI、Pod、定时任务
最小权限原则（Principle of Least Privilege）
"每个身份只拥有完成它工作所必需的权限——不多不少。"
实操：
- 不要给
*:*（全权限）——除非明确就是 admin role - 不要把 prod 权限给 dev 账户
- 服务账号按服务划分——不要"一个 account 走天下"
- 临时需要更高权限 → JIT（just-in-time）申请，限时
多账号策略（Multi-Account）
大公司标准做法：
Management Account（顶层）
├── Audit Account （日志聚合）
├── Security Account （SecOps 用）
├── Prod Account （生产）
├── Staging Account
├── Dev Account
└── Sandbox Account （试验）
好处：
- 爆炸半径小（生产被入侵 ≠ 全部被入侵）
- 账单分离
- 权限边界清晰
工具：
- AWS Organizations + Control Tower
- GCP Resource Hierarchy + Folders
- 阿里云 资源目录 / 腾讯云 集团账号
短期凭据（再强调一次）
第 29 篇讲过 secrets 角度，IAM 视角再说一次：
- 长期 access key几乎没必要存在——除非要临时给外部脚本用
- Pod / Lambda / Cloud Run / 函数计算 → 一律用 Workload Identity（IRSA / Workload Identity Federation / RAM Role for Pod）
- 人类用户 → SSO + STS assume role
长期 access key 泄露（git 误推、CI 日志暴露、备份外泄）至今仍是常见的事故来源——新建账号默认不要给长期凭据，要用 SSO + STS 或 Workload Identity。
审计日志
每个云都有：
| 云 | 服务名 |
|---|---|
| AWS | CloudTrail |
| GCP | Cloud Audit Logs |
| Azure | Activity Log + Microsoft Entra Audit |
| 阿里云 | ActionTrail |
| 腾讯云 | CloudAudit |
默认开 + 日志写到独立 audit 账号 + 长期保留——这是合规审计的基础证据。
查询场景：
- 谁删了某个生产桶
- 这条 IAM 策略上次什么时候改的
- 出事时段哪些 API 被异常频率调用
离职 / 权限回收的纪律
离职第一天：
- SSO 账号停用
- 长期凭据全部作废 + 轮换
- Slack / Jira / 文档系统 退出
- 个人邮箱 forwarding 到 manager（视情况）
很多公司故事是"两周后才意识到 Foo 还有 prod admin"——把这套流程自动化：HR 离职单 → 触发权限回收脚本 → 多个系统同步停用。
几个反模式
- 应用直接用根 / Owner 账号：撞上漏洞 → 全公司被接管
- K8s ServiceAccount 全用 default：每个 Pod 都有"很多权限"
- IAM 策略写完不审：策略数量 6 个月翻一番，没人知道哪些过时
- MFA 没强制开：弱密码 + 没 MFA = 等被钓鱼
- 生产 console 权限给 10+ 人：减到 2-3 个，其他人通过工单 / IaC 改
检查清单（最低安全配置）
- 根账号绑定 MFA + 锁起来不日常用
- 所有人类用户 SSO + 强制 MFA
- 没有任何长期 access key 在生产用（用 STS / Workload Identity）
- 审计日志开了 + 写到独立账号 + 保留 ≥ 1 年
- 生产管理员人数 ≤ X（你团队定）
- 服务账号按服务划分，最小权限
- 有定期权限审查流程（季度）
推荐阅读
- AWS IAM Best Practices
- Google Cloud IAM Best Practices
- CIS Benchmarks — 各云商 / 操作系统的安全基线（业界最常引用）
- SPIFFE — 跨云的 Workload Identity 标准
- NIST SP 800-63 (Digital Identity) — 身份认证标准
下一篇是这一批最重的话题——合规框架，只指官方文档不解读条款。