第1章 IAM基础概念：定义、核心组件与云安全价值
说起IAM，很多人第一反应就是“用户登录”那点事。其实不然。我在云安全审计中踩过的坑，十有八九都和IAM配置不当有关。说白了，IAM是整个云安全的“大门”，门没锁好，里面再安全也没用。
1.1 什么是IAM？
IAM，全称是 Identity and Access Management，翻译过来就是“身份与访问管理”。它要干的事情就两件：证明你是谁，以及你能干什么。在云环境里，IAM不是某个单一功能，而是一整套策略、流程和服务的组合。
你想想看，传统机房靠防火墙和物理隔离来保护资源。到了云上，边界没了，一切都通过API调用。这时候怎么控制权限？靠的就是IAM。我经常跟团队说一句话：“在云里，IAM就是你的新防火墙。”
IAM的本质：将“身份”与“权限”解耦，通过统一的策略引擎，控制谁（身份）在什么条件下（环境）可以对什么资源（目标）执行什么操作（动作）。
我记得刚接触云安全那会儿，有个客户把管理员的Access Key硬编码在代码里，结果被实习生不小心提交到了公开仓库。那叫一个惨。从那以后，我对IAM的敬畏心就上来了——这东西配置好了是守护神，配不好就是后门。
1.2 IAM的核心组件
IAM听起来抽象，拆开看其实就四个核心零件：用户、组、角色、策略。把这四个东西搞明白，IAM就算入门了。
1. 用户（User）
用户代表一个“身份”。可以是真人，也可以是服务账号。每个用户有独立的凭证（密码或Access Key），用来登录控制台或调用API。我见过很多企业给所有人用同一个root账号操作，说实话，这个习惯得改——出了事连谁干的都查不到。
2. 组（Group）
组是用户的集合。你把权限绑在组上，然后把用户加到组里就行。这样做的好处是：来了新人，直接加组；有人离职，从组里移除。我在项目里一直坚持“权限只赋给组，不赋给人”这个原则，省了太多麻烦。
3. 角色（Role）
角色也代表一组权限，但它不像用户那样有长期凭证。角色是“被信任的身份”去“扮演”的。比如，让一个EC2实例访问S3，你就给实例绑定一个角色。角色在临时授权、跨账号访问的场景里特别好用。
4. 策略（Policy）
策略是权限的“规则书”。它用JSON格式写明：谁可以对什么资源做什么操作。在云IAM里，策略分为身份策略（绑定到用户/组/角色）和资源策略（绑定到资源本身）。策略的编写是IAM中最容易出错的地方——多一个星号，可能就把整个数据库暴露了。
小技巧：写策略时遵循“最小权限原则”——只给完成工作所需的最小权限。先拒绝再允许，宁窄勿宽。我每个季度都会做一次策略审计，清理那些“为了省事”留下的宽松权限。
| 组件 | 描述 | 典型用途 | 注意事项 |
|---|---|---|---|
| 用户 | 代表一个身份实体，有长期凭证 | 管理员登录、应用程序调用 | 避免共用账号，每用户独立 |
| 组 | 用户的逻辑集合 | 批量管理权限，简化授权 | 权限只赋给组，不直接赋给人 |
| 角色 | 临时身份，无长期凭证 | 跨账号授权、服务间访问 | 设置合理的信任策略和会话时长 |
| 策略 | 权限规则定义（JSON格式） | 细粒度控制访问 | 小心通配符，定期审计 |
下面是一个典型的IAM策略片段。说白了，就是告诉系统：允许对哪个桶执行List操作。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example-bucket"
}
]
}注意：这个策略只允许列出桶里的对象，不能读取或下载。如果想把权限收得紧，就这么写。我在审计中见过太多把 s3:* 写在Resource为 * 上的策略，那相当于把保险柜的钥匙挂在门口。
1.3 IAM在云安全中的重要性
为什么IAM这么重要？我给你三个理由。
- 边界消失，身份即边界。传统网络安全依赖IP和端口，云上全靠IAM做鉴权。IAM一旦失守，攻击者就能直接操作你的核心资源。
- 权限滥用是头号风险。云安全事件里，超过一半和“权限过大”或“凭证泄露”有关。不是黑客多厉害，而是我们给出去的权限太大。
- 合规审计的基石。无论是等保、GDPR还是SOC2，审计员第一眼看的就是IAM策略。策略乱糟糟，合规就别想通过。
曾经有个血的教训：我有一个客户，把S3桶的写权限开放给了所有认证用户。结果内部员工误操作删了整个桶的数据，备份也过期了。恢复花了三天，损失几十万。事后分析，就是一条策略里多了个 "Principal": "*" 的事。所以我现在看到宽松的策略，条件反射地紧张。
我在做IAM审计时总结了一个规律：80%的安全事件，根源都在IAM配置上。不是技术有多难，而是细碎、容易疏忽。你想想看，一个策略写错一个字符，可能就打开了大门。所以，把这章的基础打牢，后面的检测和审计才能有的放矢。
话说回来，IAM在云里还有一个容易被低估的作用——隔离故障。好的IAM策略能限制“爆炸半径”。就算某个服务被攻破，因为权限收得紧，攻击者也只能在一个很小的范围内活动。这个思路，我称之为“权限的纵深防御”。
这张图把四个核心组件的关系串起来了。你从上往下看：IAM系统统一管理身份主体（用户、组、角色）和权限规则（策略）。组和角色通过策略获得权限，最终汇聚到权限评估引擎，决定每一次访问请求是“通过”还是“拒绝”。
我建议你把这幅图记在脑子里。以后每次做权限配置，都想想当前的操作落在图的哪个位置——是“身份侧”还是“策略侧”？这样不容易犯糊涂。