IAM 和安全性（DVA-C02）

如果你是第一次学 DVA，这一章最容易卡住，因为你会看到一堆词：User、Role、Policy、STS、Deny、SCP。

我先给你一个真实开发场景，你会马上知道为什么这些词必须一起学。

---

先看一个真实场景（把问题讲清楚）

你写了一个订单函数：

• API Gateway 调 Lambda
• Lambda 把订单写入 DynamoDB
• 同时把原始请求存到 S3

本地调试正常，上线后报错：AccessDenied。

这时你真正要回答的不是“DynamoDB 是什么”，而是这 3 个问题：

1. 谁在发起这次请求（身份是谁）？
2. 这个身份被允许做哪些动作（规则是什么）？
3. 为什么被拒（哪一层拦截了）？

IAM 这章，学完就是要把这 3 个问题回答清楚。

---

1. 先把“人和规则”分开看

很多人第一次学 IAM 会混淆：

• 以为 Policy 是身份
• 以为有 Admin 就一定能做任何事

先记一句：

• 身份是“谁”
• Policy 是“规则”

1.1 四个核心对象（用开发视角理解）

对象	你在开发中怎么用它	一句话记忆
User	人登录 AWS 的长期身份	给人，不给程序
Group	批量管理人的权限	团队打包授权
Role	程序/服务使用的临时身份	程序默认用 Role
Policy	允许或拒绝操作的规则	Policy 决定能不能做

图解说明：

• 这张图在讲什么：身份主体（User/Group/Role）与权限规则（Policy）的关系。
• 你应该先看哪里：先看 Role，因为 DVA 里程序调用 AWS 资源几乎都靠 Role。
• 考试怎么问：常问“哪个不是 identity”（答案是 Policy）。

---

2. 为什么程序必须用 Role（不是口号，是为了少踩坑）

你可以给程序硬编码 Access Key，但长期一定出问题：

• 泄露风险高
• 轮换麻烦
• 出事很难追责

Role + STS 的好处是：

• 临时凭证自动过期
• 权限更容易收敛
• 审计链更清楚

2.1 开发中的标准姿势

• 本地开发：SSO 或 AssumeRole（短期凭证）
• 运行环境（Lambda/ECS/EC2）：绑定执行角色
• 跨账户：调用方有权限 + 目标账户信任策略放行

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/DVAAppRole \
  --role-session-name local-dev-session

如果你记不住所有概念，只记这句也够： “人可以用 User，程序优先 Role。”

---

3. Policy 到底该怎么看（第一次学最容易迷糊）

不要上来就读整段 JSON。先只看四个字段：

• Effect
• Action
• Resource
• Condition

3.1 一张表把常见错点讲明白

字段	你在看什么	常见错误
Effect	Allow 还是 Deny	忘了 Deny 优先
Action	具体 API 动作	写太宽或写错动作名
Resource	ARN 是否精确匹配	少了 /* 或账户/区域错
Condition	条件是否满足	Tag、IP、时间条件没命中

3.2 一个“刚好够用”的最小权限例子

这是典型 DVA 场景：Lambda 读 S3、写 DynamoDB。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-input-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": ["dynamodb:PutItem"],
      "Resource": "arn:aws:dynamodb:ap-southeast-2:123456789012:table/orders"
    }
  ]
}

这里的核心不是背 JSON，而是学会这条思路： 按调用链列动作 -> 精确到资源 ARN -> 最后再加条件。

---

4. “明明有权限却失败”为什么会发生

这就是考试高频陷阱。

权限不是单看一个 policy，而是“多层一起算”。

4.1 你可以这样理解评估流程

请求进来
 -> 有没有 Explicit Deny（有就直接拒绝）
 -> 有没有被 SCP / Boundary / Session Policy 限制
 -> Identity-based Policy 是否允许
 -> Resource-based Policy 是否允许
 -> 最终结果

口诀：Deny 永远先判。

这就是为什么“我都挂了 AdministratorAccess 还被拒”。 往往不是你那条 policy 问题，而是上层限制（SCP / Boundary）拦了。

---

5. Lambda 权限：一定要分成两条线

DVA 里最常见的误判就是把 Lambda 权限混成一条。

实际上有两条独立链路：

1. 谁能调用我（Resource-based policy）

• 例：API Gateway、EventBridge、跨账户调用

2. 我能访问谁（Execution Role）

• 例：函数访问 S3、DynamoDB、SQS

图解说明：

• 这张图在讲什么：调用权限和执行权限是两条不同的权限面。
• 你应该先看哪里：先判断报错在“入口调用”还是“函数内部访问资源”。
• 考试怎么问：同样是权限错误，问你应该改哪个策略面。

---

6. 给第一次学习的人：一套可执行排错顺序

你以后看到 AccessDenied，按这 6 步走，不要乱猜。

1. 看失败主体是谁（User / AssumedRole / Service Role）
2. 看失败动作是什么（比如 dynamodb:PutItem）
3. 看 Resource ARN 是否精确匹配
4. 看 Condition 条件是否命中
5. 看是否被 SCP / Boundary / Session Policy 限制
6. 去 CloudTrail 看真实失败事件（不要只看应用层报错）

高频报错速查

现象	最可能原因	第一检查位
AssumeRole 失败	信任策略没放行	Trust Policy
Lambda 触发成功但写库失败	执行角色缺权限	Execution Role
本地通、线上不通	运行时身份不同	Runtime Role
有 Admin 仍失败	组织层限制	SCP
间歇性 403	STS 会话过期	Session Duration

---

7. 用 3 道 DVA 场景题收口

题 1

本地调用成功，ECS 中访问 S3 失败。

正确思路：

• 看 ECS Task Role
• 看 s3:GetObject 是否在角色策略里
• 看 bucket policy 有没有显式拒绝

题 2

调用方有 lambda:InvokeFunction，跨账户调用仍失败。

正确思路：

• 目标函数 Resource-based policy 是否允许调用方主体
• 函数 ARN 是否对（账户/区域/别名）

题 3

策略允许 s3:*，删除对象仍失败。

正确思路：

• 优先查 SCP / Permission Boundary
• 再查 bucket policy 的显式 Deny

---

8. 本章你至少要带走这 4 句话

1. 程序身份优先用 Role，不要长期 Access Key。
2. Deny 优先，最终权限是多层策略共同结果。
3. Lambda 权限必须拆成“谁能调用我”与“我能访问谁”。
4. 排错先定位主体和动作，再看策略层，不要盲改权限。

---

官方参考

• IAM User Guide: https://docs.aws.amazon.com/IAM/latest/UserGuide/
• Policy Evaluation Logic: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
• STS API: https://docs.aws.amazon.com/STS/latest/APIReference/
• Lambda Permissions: https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html