01 它是干嘛的
IAM 是 AWS 所有资源的「总门禁系统」：决定谁（人或程序）能对哪些资源做哪些操作。它围绕四个概念运转——用户、角色、策略、临时凭证，核心纪律是「最小权限」：只给出完成工作所必需的那一点点权限，而不是为了省事发一张万能卡。
02 为什么会有它
云上最大的事故，往往不是被攻破，而是钥匙到处乱放
早期大家用云很简单：账号里只有一对主密钥，像一把能开整栋楼的万能钥匙。只要这把钥匙泄漏，对方就能删掉你的数据、开一堆贵机器、甚至把整个账号的钱花光。而偏偏这钥匙最容易被乱放：为了方便，有人把它写进代码里，然后把代码传到公开的代码仓库；有人把它贴进聊天记录；有人复制到配置文件中到处流传。
这些长期有效的密钥一旦泄漏，就很难第一时间发现，也不会自动过期，相当于把小偷的钥匙永远留在门锁上。业界不少严重的数据泄露事故，起因都不是什么高明的黑客攻击，而是有人把这样一把钥匙放错了地方。
IAM 的解决思路分两步。第一步是把「万能钥匙」拆成许多把针对性的门禁卡：开发只能改测试环境，运维只能重启机器，程序只能读写它自己那个存储桶。第二步更关键——尽量不发长期钥匙，而是发放「短期通行证」：要用的时候现场领取、几小时后自动失效。即使被偷走，也很快就没用了。这套机制如今是云上安全最基础、也最重要的一条防线。
03 它怎么工作
每一次对云上资源的操作，都要先回答两个问题：你是谁？你被允许做这件事吗？IAM 用身份确认前者、用策略判定后者，并且坚持「没明确允许，就一律拒绝」。
一次操作是怎么被批准的：身份、策略与临时凭证
- 1① 请求带上身份凭证
无论是人还是程序发起的操作，都要附上证明身份的东西：密码、长期的密钥，或临时的通行证。
- 2② 判断身份类型
是某个具体用户，还是某个被赋予角色的程序？角色是一种可以被临时「扮演」的身份，专门发给程序使用。
- 3③ 评估所有相关策略
策略是一段写明「允许或拒绝哪些操作、作用于哪些资源」的规则。系统会把所有相关策略叠加起来统一评估。
- 4④ 显式拒绝优先
只要有任何一条策略明确说了拒绝，无论其他地方怎么允许，最终结果都是拒绝。这是安全设计上的一贯作风。
- 5⑤ 发放短期凭证并记录
程序通过角色领取一份几小时内自动失效的临时凭证，用完即弃；所有操作同时留有记录，便于事后追溯。
04 谁在用它
按角色划分：开发只能操作测试环境，财务只能看账单，实习生看不到生产数据。
给运行在云上的程序绑定一个角色，让它自动获得临时权限，不必在代码里写死密钥。
给外部合作方一个限期、限范围的临时授权，到期自动失效，不必事后追着收回。
允许另一个账号里的特定身份来操作本账号的指定资源，实现既合作又隔离。
所有操作的「谁、何时、做了什么」都被记录，满足合规检查与事故追溯的需要。
05 怎么用
不是写代码，而是「设计规矩」：先分清有哪些角色、各自需要什么，再一条条落地。
- 01先用主账号创建一个管理员用户，并把主账号本身的日常密钥收起来不用，只在极端情况下启用。
- 02为不同岗位建立用户或角色，按「只给必需的权限」原则逐条写策略，从最小开始。
- 03给程序创建角色而不是长期密钥，让它在运行时自动获取临时凭证。
- 04强制开启多因素验证，即密码之外再加一道动态验证码，防止密码被盗即失守。
- 05开启操作日志，把所有权限变更与关键操作记录下来，定期检查异常行为。
- 06定期做一次权限梳理，收回不再需要的授权，避免权限越积越多。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyOneBucket",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::my-reports",
"arn:aws:s3:::my-reports/*"
]
}
]
}避坑提示
- !长期密钥写进代码、再上传到公开仓库，是云上最常见也最严重的失误之一；程序请改用角色与临时凭证。
- !不要图省事给程序配「全部权限」，一个被入侵的小服务会因此顺走整个账号的所有资源。
- !主账号（根账号）权限最大且无法被限制，务必开启多因素验证并尽量封存不用。
06 关键概念
- 用户
- 代表一个具体的人或一个长期存在的身份，拥有固定的密码或密钥。
- 角色
- 一种可以被临时「扮演」的身份，专门发给程序或临时人员，用完即失效。
- 策略
- 一段写明「允许或拒绝哪些操作、作用于哪些资源」的规则文本。
- 最小权限
- 只授予完成工作所必需的那一点点权限，多一点都不给。
- 临时凭证
- 定期失效的短期通行证，即使被窃取，很快也会自己作废。