4.2 身份与访问管理 IAM

4.2 身份与访问管理 IAM

本节摘要：IAM（Identity and Access Management）是云安全的第一道闸门，管两件事：身份验证（Authentication）确认"你是谁"，授权（Authorization）决定"你能做什么"。本节拆解 IAM 的四大构件——身份验证、授权、角色、策略，讲清 RBAC 如何让权限管理从"人肉维护"变成"角色管理"，并给出 MFA、最小权限、定期审查、禁用根账户等最佳实践清单。

读前必看（上）

阅读完本节，你应当能够：

1. 区分身份验证与授权，并各自说出一种典型实现。
2. 解释角色（Role）、策略（Policy）在 IAM 中的关系。
3. 描述基于角色的访问控制（RBAC）如何简化权限管理。
4. 说出 IAM 的五个最佳实践，并解释各自的价值。

一、问题与直觉

一个云账号有几十个资源、十几个使用者：研发要开机器，数据组要管数据库，财务要看账单，实习生只该看看，离职同事的账号早该注销。怎么管住这些"谁能干什么"？

最简单的答案是"都给管理员"，但你很快会发现：实习生误删了生产数据库，离职同事的账号被人拿来横向移动。权限失控是云上最常见的"隐形炸弹"——它不像漏洞那样显眼，却每天都在放大风险。

IAM 就是把"谁"和"能干什么"拆开管理的系统：身份验证回答"你是不是你说的那个人"，授权回答"你有权做这件事吗"。 理解这两个词的区分，是理解 IAM 的钥匙——很多人把它们混为一谈，导致"验证通过就以为万事大吉"，忘了授权才是权限控制的真正闸门。

二、核心原理

2.1 身份验证：确认"你是谁"

身份验证（Authentication）的方式分三档：你知道的（密码、PIN）、你拥有的（手机、硬件令牌、证书）、你是什么（指纹、人脸）。多因素认证（MFA）把多档组合起来——比如密码 + 手机验证码，即使密码泄露，攻击者也过不了第二关。MFA 是性价比最高的安全投入，尤其对管理员账号几乎是必选项。

2.2 授权：决定"你能做什么"

授权（Authorization）确定"通过验证的用户，有没有权限执行某个操作"。云上的授权通常是"策略"驱动的：策略（Policy）定义"允许/拒绝什么资源的什么操作"，角色（Role）是"一组权限的集合"。授权时把角色分配给用户或组，用户获得角色所带的权限。

2.3 RBAC：用角色管理代替人肉管理

基于角色的访问控制（RBAC）是授权的核心模式。它把权限管理从"给张三配权限、给李四配权限"变成"定义几个角色，把人分进角色"。收益有三：一致——同一角色的人权限一致，不会因人而异；好维护——要调整一组人的权限，只改角色不改人；可审计——权限结构清晰，审查容易。

2.4 策略与角色如何配合

一次云资源访问的完整链路是：用户请求 → 身份验证（确认身份）→ 授权检查（确认用户所属角色/策略是否有权限）→ 允许或拒绝。策略写在角色上，角色绑在人上，人动角色不动——这就是 IAM 设计的基本盘。第 2.5 节讲过的"服务角色"同理：程序访问云资源也走角色，拿到临时凭证而不是长期密钥。

三、工程实践要点

3.1 认证与授权流程

3.2 五个最佳实践与价值

⚠️ 常见坑：把长期访问密钥写进代码或配置文件，等于把保险柜钥匙贴在门上。密钥一旦进代码仓库，就等于公开。程序访问云资源一律用服务角色 + 临时凭证。

💡 关键直觉：IAM 的核心心智是"人动角色不动"——权限挂在角色上，人只是角色的使用者。离职删人、换岗改角色，权限体系才不会随人员流动烂掉。

3.3 IAM 的治理节奏

IAM 不是配完就结束的静态配置，而需要持续的治理节奏：人员入职/离职/换岗时更新角色归属；定期（季度或半年）审查策略是否仍有过度授权；每次架构变更时检查新资源是否被纳入权限体系。把 IAM 审查排进固定的运维日历，权限体系才能跟上组织的动态。

四、常见问题（FAQ）

Q1：IAM 和 SSO 是一回事吗？

不完全是。IAM 管"身份与权限"，SSO（单点登录）管"一次登录、多处访问"。两者常配合：SSO 是身份验证的体验层，IAM 是权限控制的管理层。用 SSO 登录企业门户，背后是 IAM 在做每次访问的授权判定。

Q2：普通用户账号可以开管理员权限吗？

理论上可以，但强烈不建议。管理员权限应该走"临时提权"模式：平时用普通权限，需要管理操作时申请临时管理员权限，用后即销，全程留痕。这比"常年挂管理员"安全得多，也符合最小权限原则。

Q3：服务账号和用户账号有什么区别？

服务账号（Service Account）是给"程序"用的身份，不是给人用的。它通过角色获得权限、用临时凭证访问资源，没有"登录控制台"这类人类操作。用服务账号的好处是权限可以精确限定在"程序该做的事"上，且不会因人员离职而失效。

Q4：权限审查怎么做不费劲？

分两步：第一步"清单化"，把所有账号、角色、权限导出来；第二步"对账单"，逐一核对"这个权限还有人在用吗"。可以借助云平台的 IAM 分析工具自动检测"未使用权限"和"过度授权"，把人工审查量降到最低。

Q5：MFA 的验证码有时收不到怎么办？

给 MFA 配"备用验证方式"——多绑一个设备或配恢复码，防止手机丢失或被锁。恢复码要离线妥善保存。MFA 偶尔不便，但比起密码泄露的代价，这点麻烦完全值得。

五、IAM 的边界：别指望它解决所有问题

最后给 IAM 画个边界。IAM 管的是"身份与权限"，但有两类问题它管不了：第一类是"权限给对但操作失误"——有权限的人误删了数据，IAM 无法阻止，这要靠备份与变更流程（第 3.1、3.5 节）；第二类是"合法身份的恶意行为"——内部人员刻意窃取数据，IAM 挡不住，这要靠审计与数据防泄漏（第 4.5 节）。

所以 IAM 是整个安全体系的第一道门，但不是唯一一道门。IAM 负责"把不该进的人挡在门外"，门内的事还要靠其他防线配合。 这也呼应了 4.1 的纵深防御思想——身份层只是五层防线之一，与网络层、数据层、应用层、审计层各司其职。把 IAM 理解到位，再看后面几节，你会看到它们如何与身份层咬合成完整防线。

六、一次 IAM 加固的实战演练

把 IAM 的知识落成动作，最有价值的是一次"加固演练"。假设你接管了一个运营多年、权限常年没人理的云账号，按下面顺序做一轮加固。

第一步，摸底盘点。导出账号下所有用户、角色、策略清单，同时导出每个资源的使用日志。目标：知道"谁在、谁有权限、谁真的在用"。这一步会先暴露出大量"僵尸账号"和"幽灵权限"。

第二步，先删后审。对确认离职、长期无登录记录的账号直接停用；对"看起来还在用但权限可疑"的账号，先把权限降到最低，观察一段时间——如果业务没报障，说明权限确实冗余。删除永远比"留着再说"安全。

第三步，角色重构。把散乱的人肉授权收敛成若干标准角色：开发者、运维、只读、财务。所有用户的权限都迁移到角色上，不再有人肉直配。这一步做完，权限体系从"一团乱麻"变成"有结构的树"。

第四步，加 MFA 与密钥治理。全员强制 MFA；扫描代码仓库和服务器上的长期密钥，全部换成服务角色 + 临时凭证；清理公网暴露的管理入口。

第五步，建审查节奏。把"季度权限审查"写进运维日历，配合 IAM 分析工具自动检测未使用权限。

这套演练走完，账号的安全性会有质的提升。它不是某个产品的魔法，而是"盘点—收敛—结构化—加固—常态化"五个动作的组合——这五个动作本身，就是 IAM 治理的完整方法论。你可以把它当作一个 checklist，对接手的每一个云账号都走一遍。

七、IAM 与零信任的关联

最后把 IAM 放回更大的趋势里看一眼。近年安全界流行"零信任"（Zero Trust）理念，核心主张是"永不信任，始终验证"——不再默认"内网可信"，每一次访问都要验证身份与权限。IAM 正是零信任的基石：没有可靠的"身份 + 权限"体系，零信任就是空中楼阁。

云环境天然适合零信任落地：所有访问都经过统一的身份层（IAM），网络位置不再等于信任等级（VPC 内也不自动可信），每一次操作都可以验证与审计。可以这么理解：IAM 让"你是谁"成为第一安全边界，而不是"你在哪个网络"。 这与第 5.5 节云原生的安全设计一脉相承。记住这个视角，你会更明白为什么 IAM 在云安全里地位如此之重——它不只是"管账号的工具"，而是整个信任模型的地基。在后续读到 5.5 云原生时，请带着"身份第一、网络其次"这个视角回看本节，两个概念会互相照亮。

本章回顾

• 身份验证 vs 授权：验证"你是谁"，授权"你能干什么"，两者缺一不可。
• MFA：多因素认证，性价比最高的安全投入，管理员强制。
• 角色与策略：策略定权限，角色集权限，人绑角色，权限体系结构化。
• RBAC：用角色管理代替人肉管理，换来一致、好维护、可审计。
• 服务角色：程序用临时凭证访问资源，长期密钥绝不进代码。
• 最小权限：缩小破坏半径，配"临时提权"机制平衡效率。
• 治理节奏：IAM 要随人员与架构动态维护，排进运维日历。
• IAM 边界：管住"进门的门槛"，门内的失误与内鬼要靠其他防线。

人管住了，数据呢？下一节讲数据加密与保护——静态加密、传输加密、密钥管理三件套，让数据"就算被偷也读不了"。