4、身份与访问管理(IAM)基础：IAM核心概念、用户与角色、策略与权限边界、信任策略
好，咱们今天聊聊IAM。说白了，IAM就是云上的门禁系统。你想想看，你的Serverless应用跑在云上，谁可以进来？进来能干什么？能碰哪些资源？这些问题，全得靠IAM来回答。
我刚开始接触云安全那会儿，觉得IAM不就是建个用户、设个密码嘛。后来有一次，一个同事不小心把生产环境的数据库删了——嗯，就是因为权限给得太宽。从那以后，我对IAM的态度就变成了：能不给的权限，坚决不给。
IAM核心概念：主体、资源、动作
IAM里就三个核心要素：
- 主体（Principal）：谁在发起请求。可以是用户、角色，也可以是某个服务。
- 资源（Resource）：要访问的东西。比如一个S3桶、一个Lambda函数。
- 动作（Action）：想干什么。读、写、删除、调用……
这三者组合起来，就是一个权限判断。我习惯把IAM理解成一张权限检查清单：每次请求过来，云平台都会拿着这张清单，一条一条核对。有一条不满足，直接拒绝。
核心原则：默认情况下，所有请求都是被拒绝的。只有显式允许的，才能通过。
用户与角色：谁在操作？
用户和角色，都是IAM里的主体。但它们的用法完全不同。
用户是长期存在的身份。比如你的运维同事、你的CI/CD机器人。每个用户有固定的凭证（密码或访问密钥）。我建议：能用角色的地方，尽量别用用户。为什么？因为用户的密钥容易泄露。我曾经见过一个项目，把AWS的Access Key硬编码在代码里，结果被扫描工具抓到了……嗯，那场面，挺尴尬的。
角色是临时身份。它没有固定的凭证，而是通过信任策略来获取临时令牌。谁可以扮演这个角色？什么时候可以扮演？能扮演多久？全由信任策略说了算。
| 对比项 | IAM用户 | IAM角色 |
|---|---|---|
| 凭证 | 长期有效（密码/密钥） | 临时（STS令牌） |
| 适用场景 | 人类用户、长期服务 | 跨账号访问、临时任务、Lambda执行 |
| 风险 | 密钥泄露风险高 | 令牌过期自动失效 |
我个人习惯：Lambda函数执行时，永远用角色，不用用户。你想想看，Lambda是事件驱动的，每次执行都可能在不同的环境里。给它一个角色，让它自己去申请临时凭证，安全又省心。
策略与权限边界：能做什么？不能做什么？
策略就是权限的规则。它告诉云平台：谁可以干什么。
策略有两种写法：
- 基于身份的策略：挂载在用户或角色上。比如「这个角色可以读S3桶A」。
- 基于资源的策略：挂载在资源上。比如「这个S3桶允许哪些人读」。
这里有个坑：两种策略必须同时允许，请求才能通过。说白了，就是「两边都说行，才行」。我在项目中遇到过这样的情况：给Lambda角色配了S3的读权限，但S3桶的策略里没允许这个角色。结果Lambda一跑就报403。排查了半天……嗯，后来我学乖了，每次配权限都检查两边。
小技巧：用aws iam simulate-principal-policy命令可以模拟权限。我每次上线前都会跑一遍，确保权限没配错。
权限边界是个好东西。它像一个「天花板」：你可以给用户或角色授权，但权限边界限制了授权的上限。举个例子：你给一个开发团队设了权限边界「只能操作开发环境的资源」。那么就算他们给自己配了生产环境的权限，也越不过这个边界。
我曾经在一个大项目里用过权限边界。当时有十几个团队，每个团队都有自己的环境。我给他们每个团队设了一个权限边界，然后让他们自己在边界内自由发挥。效果很好——既给了灵活性，又守住了底线。
信任策略：谁可以扮演这个角色？
信任策略是角色的「门禁」。它定义了：谁可以来扮演这个角色。
举个例子。你有一个Lambda函数，需要访问DynamoDB。你会创建一个角色，给它DynamoDB的访问权限。然后，你需要在角色的信任策略里写上：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}这段策略的意思是：只有Lambda服务可以扮演这个角色。其他服务？不行。其他账号？也不行。
信任策略还可以更精细。比如：
- 只允许某个特定账号的角色来扮演
- 只允许在特定时间范围内扮演
- 只允许携带特定标签的请求来扮演
注意：信任策略和权限策略是两回事。信任策略管的是「谁能进来」，权限策略管的是「进来后能干什么」。两者缺一不可。
我见过一个案例：某公司给第三方服务商配了一个跨账号角色。信任策略写得太宽，允许了所有外部账号。结果第三方的一个离职员工，用自己的个人账号扮演了这个角色，把数据拖走了……嗯，信任策略一定要精确到具体的账号和条件。
实战建议：最小权限原则
说了这么多，最后给几个实操建议：
- 从拒绝开始：默认拒绝所有权限，然后一点点放开。别一开始就给「管理员权限」。
- 用角色代替用户：尤其是Serverless场景。Lambda、API Gateway、Step Functions，全用角色。
- 权限边界是护身符：给每个团队、每个环境设好边界。出了事，边界能兜底。
- 信任策略要精确：别用
"Principal": "*"。指定具体的服务、账号、条件。 - 定期审计：我每季度会跑一次IAM权限审计。看看有没有「僵尸权限」——那些很久没用过的权限，该回收就回收。
IAM这东西，看着简单，但坑不少。你想想看，一个权限配错了，轻则功能跑不通，重则数据泄露。所以，慢一点，细一点，安全第一。
下一章，咱们聊聊Serverless中的IAM最佳实践。到时候我会分享一些具体的配置模板和踩坑经历。嗯，敬请期待。