IAM 策略 vs 资源策略：来自生产（以及健身房）的经验
Source: Dev.to
背景
在我的 AWS 之旅早期，我遇到了一个让我抓耳挠腮好几个小时的问题。
一位前端工程师找到了我：
“Tony，我只想让用户看到我们的应用 logo 和图片，但它们根本无法显示。他们一直被拒绝。”
我仔细检查了 IAM 权限——一切看起来都正常。用户拥有正确的访问权限。那为什么人们仍然被阻止？
根本不是 IAM 的问题，而是 S3 存储桶的 资源策略。
这时我恍然大悟：管理 AWS 访问就像管理一家健身房或坚持有纪律的健身计划。
IAM 策略 = 你的私人教练
IAM 策略就像你的私人教练。它们定义了你（身份）被允许做什么：
- 今天可以举重吗？
- 可以在跑步机上跑步吗？
- 可以跳过有氧训练吗？
在 AWS 中，IAM 策略附加到 用户、组或 角色。它们控制身份可以执行的操作以及可以作用的资源。
在生产环境中，我还为所有 IAM 用户强制使用 MFA。把它想象成在进入 VIP 健身区之前增加的第二道检查点——你可能有钥匙卡（密码），但没有指纹（MFA）就进不去。简单，却能显著提升安全性。
资源策略 = 健身房规则
资源策略就像贴在健身房墙上的规则。即使你的教练给了你权限，规则仍可能限制你的访问：
- 只有 VIP 会员才能使用某些设备
- 某些区域禁止进入
在 AWS 中，资源策略直接附加到 资源（S3 存储桶、Lambda 函数、SQS 队列等）。它们定义 谁 可以访问该资源，包括其他 AWS 账户或公众。
我在生产环境中所做的
- ALB 日志 – 修改了存储桶策略，使我们的应用负载均衡器（ALB）能够安全地发送访问日志，而无需额外权限。
- 前端图片/Logo – 创建了一个存储桶策略，允许用户读取 logo 和图片，同时阻止对敏感文件的访问。用户得到了恰好需要的内容。
访问扩展：IAM 与资源策略的对比
我很快学到的一件事：规模会改变一切。
- IAM 策略 最适合 身份 的规模化管理。一个策略可以管理多个用户、组或角色——非常适合内部团队。
- 资源策略 最适合 资源 的规模化管理。当跨账户或公开共享时，资源策略让资源本身掌控访问权限。
两者结合使用是必不可少的。IAM 确保用户只做该做的事，而资源策略则在即使拥有 IAM 权限的情况下仍然保护资源本身。
示例：我们的财务报告存储桶为财务用户配置了 IAM 权限，但资源策略将访问限制在我们自己的 AWS 账户内。分层安全防止了意外或恶意访问，让我们更加安心。
分层安全 = 分层纪律
在 AWS 访问控制中取得成功，就像在健身中取得成功，需要层层纪律：
- IAM = 你的训练计划 → 定义身份可以做什么
- 资源策略 = 健身房规则 → 定义谁可以访问资源
两者共同作用，才能产生可持续的效果，防止错误、泄露或滥用。忽视其中任何一层就像跳过有氧训练或不记录卡路里——你可能会看到一些进展，但问题迟早会显现。
在 AWS 中，仅依赖 IAM 而忽视资源策略会导致“神秘拒绝”错误和用户沮丧。
要点
- 同时检查 IAM 和资源策略。任意一方的 deny 都会阻断访问。
- 强制使用 MFA。这是一小步，却能带来巨大的安全回报。
- 对跨账户或公开访问使用资源策略——尤其是在共享日志、图片或 API 时。
- 测试每一条访问路径。用户可能拥有正确的 IAM 权限，却仍被阻止。
- 采用分层思维：身份控制 + 资源控制 = 安全、可扩展的访问。