AWS IAM 安全：实用指南，真正可在生产环境中使用
Source: Dev.to
请提供您希望翻译的完整文本内容（除代码块、URL 和标题之外的正文），我将为您翻译成简体中文并保持原有的 Markdown 格式。谢谢！
Introduction
大多数 AWS 安全指南告诉你 what 要做的事情。本指南展示 how 在开发者需要交付代码且安全不能成为阻碍的生产环境中实现安全的方式。
最小权限在理论上听起来很美好，但在实践中却很混乱。开发者需要权限才能工作，但你不能随意授予 AdministratorAccess 并指望一切顺利。
基于角色的访问
从 基于角色的访问 开始，而不是基于用户的访问。创建映射到实际工作职能的 IAM 角色：
| 角色 | 权限 |
|---|---|
| 开发人员 | 对大多数服务拥有读取权限；仅对开发环境拥有写入权限 |
| DevOps / SRE | 对基础设施管理拥有提升的访问权限；对生产更改受限 |
| 安全团队 | 跨所有账户的审计和合规权限 |
| 财务 | 用于成本分析的只读访问 |
权限边界
使用权限边界作为安全网。即使用户或角色被授予了过多的权限，边界也会限制实际能够执行的操作。
- 设置一个阻止以下情况的权限边界：
- 超出角色工作职能所需的权限授予。
90 天权限审计
每个季度，审查实际使用的权限。
AWS Access Analyzer 让这变得简单——它显示过去 90 天内使用了哪些权限。
MFA 强制执行
MFA 应该是 不可协商 的：
- IAM 用户 – 为每个 IAM 用户启用 MFA；不例外。
- 策略级别强制 – 创建一个策略，除非存在 MFA 否则拒绝所有操作，除启用 MFA 的操作外。
- 控制台访问 – 要求在 AWS 管理控制台登录时使用 MFA。
- 编程访问 – 在假设角色时要求 MFA（无法直接将 MFA 附加到访问密钥）。
开发者的 MFA 模式
- 开发者获得具有最小权限的长期凭证。
- 为了执行工作，他们 假设一个需要 MFA 的角色。
- 被假设的角色为会话提供真实的权限。
访问密钥轮换
访问密钥是永久凭证，也是最常被泄露的。
- 轮换规则： 每 90 天（每季度）轮换访问密钥。
- 自动化： 使用 AWS Config 规则或自定义脚本检测超过 90 天的密钥并强制轮换。
对控制台密码也使用相同的规则——在密码策略中启用密码过期。
注意： 如果你仍然在生产工作负载中依赖长期访问密钥，那就是做错了。尽可能使用 IAM 角色。
使用 IAM 角色代替长期密钥
| Service | Recommended Credential Type |
|---|---|
| EC2 | 实例配置文件（角色） |
| ECS / EKS | 任务角色或服务账户 |
| Lambda | 执行角色 |
| Cross‑account | 假设角色 |
| Developers | AWS SSO 或使用临时凭证假设角色 |
会话时长 可以设置为 1 到 12 小时，较敏感的角色会获得更短的会话时间。
当长期密钥不可避免时
- CI/CD 流水线
- 第三方工具
- 遗留应用程序
在这些情况下，强制执行严格的轮换和监控。
网络控制
IAM 负责 谁 能做什么；网络控制决定 从哪里 可以连接。
- 在 IAM 策略中添加条件，要求连接来自特定 IP 范围（办公 IP、VPN 端点、授权的云环境）。
- 拒绝其他所有连接。
这可以阻止窃取凭证但不在您网络内的攻击者。
VPN 用于敏感操作
即使拥有有效凭证和多因素认证，也需要 VPN 连接才能访问生产环境。
VPN 配置文件
| 配置文件 | 要求 |
|---|---|
| 标准工作 | 任意地点 + MFA |
| 生产变更 | VPN + MFA |
| 关键操作（IAM 更改，安全修改） | VPN + 审批工作流 |
通过增加阻力而非直接阻止来适应远程工作。
服务控制策略 (SCP)
如果您使用 AWS Organizations，SCP 是您的“核选项”——它们会覆盖所有其他策略。
常见 SCP
- 防止禁用 CloudTrail 或 GuardDuty
- 阻止公共 S3 存储桶
- 将实例类型限制为批准列表
- 拒绝在未授权地区的操作
日志记录与监控
- CloudTrail – 在每个账户、每个区域都启用，且不例外。
- GuardDuty 和 Security Hub – 开启并积极审查发现。
安全不是一次性设置后就忘记；持续监控至关重要。
每月审计清单
| 区域 | 检查内容 |
|---|---|
| 访问密钥年龄 | 密钥超过 90 天？删除或轮换。过去 90 天未使用的密钥？删除。 |
| MFA 状态 | 未启用 MFA 的用户？强制启用。任何未使用 MFA 的控制台登录？调查。 |
| 权限使用情况 | 使用 Access Analyzer 检查未使用的权限。审查过于宽松的策略（通配符，*）。 |
| 异常活动 | 新建 IAM 用户/角色、关键资源的权限变更、失败的身份验证尝试、来自异常位置的 API 调用、根账户使用情况。 |
改进优先级
| 时间范围 | 重点 |
|---|---|
| Week 1 | 关键问题（例如，缺少 MFA，管理员访问权限过宽） |
| Weeks 2‑3 | 重要的加固任务（例如，SCP，网络限制） |
| Month 2 | 持续加固（密钥轮换自动化，日志增强） |
| Ongoing | 维护、持续审计以及增量改进 |
结论
完美的安全是不存在的。目标是让你的 AWS 环境 足够坚固，以至于攻击者转向更容易的目标。
- 在所有地方强制使用多因素认证（MFA）。
- 定期轮换凭证。
- 使用基于角色的访问控制和权限边界，遵循最小权限原则。
- 通过 IP 条件和 VPN 要求限制网络访问。
- 持续审计。
这些做法并不炫目，但确实有效——它们能让你免于在凌晨 3 点收到因凭证被盗而启动加密货币挖矿的紧急电话。