上一篇 SSO + MFA讲的是”门怎么开”——证明你是你。这一篇讲进门之后:你能去哪、能摸什么、谁记录你做了什么。这就是 IAM。
一句话:IAM 把”谁能干什么”从聊天群里的口头授权,变成系统里可审计、可撤销、可自动化的规则。
顶层结论
- IAM ≠ 软件,是一整套流程 + 工具,管”身份 → 权限 → 审计”全生命周期
- 两条底层原则:最小权限 和 职责分离——所有 IAM 设计都在落地这两条
- 三种授权模型:MAC / DAC / RBAC,选哪个看你是政府、是 Google Drive、还是普通公司
- AAA 和 IAM 高度重叠,可以理解成 AAA 是骨架,IAM 是把骨架做成完整产品
1. 两条底层原则:整个 IAM 都在落地它们
最小权限(Principle of Least Privilege)
用户只拿完成任务所需的最低权限,多一个都不给。
- 实习生不需要 production database 写权限
- 客服不需要看用户密码字段(就算是 hash)
- 你的网站后端不需要 root 权限
为什么 vibe-coder 必看:AI 写后端代码时最爱给 service account 灌满权限——“反正能跑就行”。结果一旦 service account 被偷,整个云账号陷落。
职责分离(Separation of Duties,简称 SoD)
关键操作不能让一个人从头干到尾。
例子:
- 录入采购单的人 ≠ 审批采购单的人(防止虚构供应商套钱)
- 写代码的人 ≠ 部署到生产的人(防止恶意代码绕过 review)
- 管 IAM 权限的人 ≠ 审计 IAM 日志的人(防止改完日志洗掉痕迹)
最小权限限制”一个人能拿多少”,职责分离限制”一个人能从头干到尾多少”。两者互补。
2. IAM vs AAA:同一件事的两种叫法
| AAA | IAM | |
|---|---|---|
| 全称 | Authentication / Authorization / Accounting | Identity and Access Management |
| 起源 | 网络设备(RADIUS/TACACS+)、电信运营商 | 企业 IT、SaaS、云 |
| 侧重 | 协议层、网络接入 | 身份生命周期、应用层授权 |
| 典型产品 | Cisco ISE、FreeRADIUS | Okta、Azure Entra ID、AWS IAM |
实际上重合度极高。两边都在做这四件事:
| 环节 | 干什么 | 例子 |
|---|---|---|
| Identification | 你声称你是谁 | 输入用户名 |
| Authentication | 证明你是你 | 密码 + MFA |
| Authorization | 你能干什么 | RBAC 策略放行/拒绝 |
| Accounting / Audit | 你干了什么 | 登录日志、操作日志 |
只要看到 AAA 或 IAM,默认是同一件事的两种说法。课程里 AAA 多见于网络题,IAM 多见于云和 SaaS 题。
3. User Provisioning:身份的生与死
Provisioning = 创建账号 + 发权限。 Deprovisioning = 离职/调岗时收回账号和权限。
⚠️ vibe-coder 常忽略 deprovisioning——前员工账号还能登,是数据泄露案最常见的来源之一。
正确做法是把账号生命周期挂到 HR 系统上:
HR 系统:员工状态 = "已离职"
↓ (自动同步)
IAM 系统:停用账号、撤销所有 token、踢出所有 session
如果你用 Google Workspace / Okta 当 IdP,关掉一个账号 = 所有挂在 IdP 后面的应用同步失效。这是 SSO 最大的运维红利。
4. 三种授权模型:选哪个看场景
授权(authorization)= 决定”通过认证的人,能干哪些事”。课程里讲三种主流模型:
MAC — Mandatory Access Control(强制访问控制)
- 谁说了算:中央管理员 / 系统策略
- 数据所有者能不能改:不能
- 典型场景:军队、情报机构、政府机密文件
- 特点:最严,基于”需要知道”(need-to-know)原则,每次访问都得走审批
例子:你是分析员,想看一份”机密”级文件——必须由有授权的上级在系统里把你加进白名单,文件作者本人都没权决定。
DAC — Discretionary Access Control(自主访问控制)
- 谁说了算:数据所有者
- 数据所有者能不能改:能,随便改
- 典型场景:Google Drive、Dropbox、个人电脑文件夹
- 特点:最灵活,但也最容易出错(用户随手 share 给 anyone with link)
例子:你在 Google Drive 建了个文件夹,点”共享”,加谁、给什么权限(查看 / 评论 / 编辑)全由你决定。
RBAC — Role-Based Access Control(基于角色的访问控制)
- 谁说了算:角色的设计者(通常是 IT / 安全团队)
- 怎么发权限:不是给”张三”发权限,是给”市场运营”这个角色发权限,然后把张三放进这个角色
- 典型场景:绝大多数企业 SaaS、AWS IAM、数据库权限
- 特点:可扩展,人员变动只改角色归属,不改具体权限
例子:marketing 角色 → 能看用户分析、能发邮件;engineer 角色 → 能登 staging 服务器、能合 PR;张三今天从 marketing 转到 engineer,只改一行——把他的角色换掉,所有权限自动跟着变。
怎么选
| 场景 | 用哪个 |
|---|---|
| 政府 / 军队 / 金融机密 | MAC |
| 个人协作 / 文档分享 | DAC |
| 企业内部系统 / SaaS / 云资源 | RBAC(95% 的情况) |
vibe-coder 默认用 RBAC。AI 给你写权限系统时,如果上来就是
if user.id == X这种硬编码,直接打回——让它改成角色 + 角色权限表。
5. 还有一类高级模型(课程没讲但你会遇到)
- ABAC (Attribute-Based) —— 基于属性:“工作时间 + 公司 IP + 部门=财务” 才能访问。比 RBAC 灵活
- PBAC (Policy-Based) —— 写策略语言(OPA/Rego、AWS IAM JSON)定义授权规则
- ReBAC (Relationship-Based) —— Google Zanzibar / Auth0 FGA,适合 “A 是 B 的朋友所以能看 B 的相册” 这种社交关系
vibe-coder 看到 AI 推荐这些时:多半是过度设计,先从 RBAC 开始,真不够用了再升级。
6. vibe-coder 让 AI 接权限时该审计什么
| 审计点 | 怎么看 |
|---|---|
| 有没有 deprovisioning 通路 | 删了 user 表的行,token 和 session 是不是真的全失效? |
| service account 权限多大 | AI 写后端时给的 DB 账号,只给它真的要用的表的权限,不要给 GRANT ALL |
| 管理操作有没有职责分离 | ”删用户”和”看删用户日志”不能是同一个 endpoint / 同一个角色 |
| 权限检查在前端还是后端 | 前端隐藏按钮不算授权,后端每个 endpoint 都必须重检 |
| 有没有审计日志 | 谁在什么时候做了什么——出事时这是唯一线索 |