AWS IAM 安全最佳实践 — 为什么过度授权访问是您最大的云风险
Source: Dev.to
TL;DR
我去年审计了一家Series A创业公司的AWS账户。七名开发者，全部拥有 AdministratorAccess。三名已离职员工的账户仍然处于激活状态，仍拥有完整权限。根账户未启用 MFA。18 个月内未轮换 API 密钥。这并不罕见；这已成常态。IAM 配置错误是云环境中首要的攻击向量——而修复它只需要时间，不需要额外费用。以下是需要立即修复的具体措施。
为什么 IAM 很重要
AWS 身份与访问管理 (IAM) 是在您的 AWS 账户中控制谁可以做什么的系统。每一次 API 调用、每一次控制台登录、每一个触及您云基础设施的自动化流程，都要经过 IAM。
如果 IAM 配置错误，所有其他安全控制都会被削弱——拥有相应 IAM 凭证的攻击者可以：
- 读取您的数据，
- 修改您的基础设施，
- 删除您的备份，
- 导出您构建的所有内容。
根据 CrowdStrike 2025 全球威胁报告，2024 年云相关漏洞同比增长 75 %，凭证攻击和 IAM 配置错误始终被列为主要入口。这并非高级攻击手段——而是对从未正确配置的访问控制的利用。
我常见的问题
-
每个人都有
AdministratorAccess
AdministratorAccess相当于给每位员工一把公司所有系统、数据库和配置的主钥匙。开发者在早期需要它来快速推进，但问题是它从未被移除。等公司到达 A 轮融资时，整个工程团队通常仍然拥有他们从未需要且不该拥有的完整管理员权限。 -
前员工的非活跃账户仍保持启用
当有人离职时，需要禁用其 IAM 用户并最终删除。这一步经常被跳过——要么是因为离职清单中没有列出，要么是因为“我们下个冲刺再处理”。三个月后，账户被遗忘但仍然活跃。前员工——或是攻击者获取了他们的邮箱并触发密码重置——就能完全访问你的生产环境。 -
根账户用于日常操作
AWS 根账户是你首次注册时创建的账户。它不能被 IAM 策略限制——拥有对所有资源的绝对、无限制访问。根账户绝不应当用于日常操作，且其访问密钥根本不应存在。我进行的几乎所有初创公司审计都发现根账户被活跃使用，并且常常 未启用 MFA。 -
长期未轮换的访问密钥
IAM 访问密钥（AKIA…密钥 ID 和密钥）授予编程 API 访问权限。与密码不同，它们默认不会过期。创建于 18–24 个月前的密钥——可能分配给已离职的开发者或已退役的应用——仍然有效，如果这些密钥在任何地方泄露，就会成为可被利用的凭证。 -
拥有管理员权限的服务账户
当开发者需要让某个服务访问 AWS——如部署流水线、Lambda 函数、第三方集成——最快的办法是创建一个拥有宽泛权限的 IAM 用户。正确的做法是使用拥有该服务所需最小权限的 IAM 角色。拥有AdministratorAccess的服务账户只差一次被攻破的应用，就可能导致整个账户被接管。 -
缺少 IAM 权限边界或服务控制策略（SCP）
在多开发者账户中，若没有权限边界或 SCP，拥有 IAM 权限的开发者可以自行提升权限——创建新管理员用户、给自己附加管理员策略，或假设拥有更高权限的角色。权限边界和 SCP 是防止这种情况的护栏，但在早期账户中很少被配置。
原则：最小特权
最小特权意味着每个身份——无论是人还是机器——只能访问其执行职能所需的内容，且不多余。
AWS IAM 示例
| 身份 | 所需操作 | 范围 |
|---|---|---|
| 部署到特定 S3 存储桶的开发者 | s3:PutObject, s3:GetObject | 仅该特定存储桶的 ARN |
| 从 DynamoDB 表读取的 Lambda 函数 | dynamodb:GetItem, dynamodb:Query | 仅该表 |
除非绝对必要，否则不要在 * 上使用 s3:* 或 AdministratorAccess。
实践方法
- 从更宽泛的权限开始
- 启用 AWS CloudTrail 和 IAM Access Analyzer
- 使用这些工具生成的数据 来识别每个角色实际使用的内容
- 将权限范围缩小 以匹配实际情况
AWS 的 IAM Access Advisor 显示每个权限的最近使用时间，使识别和删除未使用的权限变得直观。
步骤式整改清单
| 步骤 | 操作 | 操作方法 |
|---|---|---|
| 1 | 生成 IAM 凭证报告 | 在 AWS 控制台中：IAM → Credential Report → Download Report。CSV 列出所有 IAM 用户、密码/访问密钥状态、最近使用时间戳和 MFA 状态。任何 password_last_used 显示 never 或超过 90 天的用户都需要立即审查。 |
| 2 | 确认 AdministratorAccess 分配 | 在 IAM → Users 中，按 AdministratorAccess 策略进行过滤。审查所有拥有此策略的用户或角色；如果原因不明确或已不再需要，移除该策略。 |
| 3 | 检查根账户 | 登录 AWS 控制台，确认根账户已启用 MFA（在 IAM 仪表盘的 IAM Security Recommendations 面板中可见）。如果根账户存在访问密钥（在凭证报告中显示），请立即删除。 |
| 4 | 审查访问密钥年龄 | 在凭证报告中，查找任何活跃且超过 90 天的访问密钥。轮换这些密钥并更新所有使用它们的系统。 |
| 5 | 审计不活跃用户 | 任何 90 天以上无活动的 IAM 用户应 禁用。无论最近活动如何，前员工的账户应立即禁用。 |
| 6 | 用 IAM 角色替代服务的 IAM 用户 | 对于 EC2 实例、Lambda 函数、CI/CD 流水线以及第三方集成，使用 IAM 角色（配合最小权限策略），而不是长期有效的 IAM 用户凭证。 |
使用 IAM 角色代替 … (原文在此结束；请继续添加贵组织的具体指南)
最后说明
修复 IAM 配置错误在金钱上是 免费 的；它只需要时间和纪律。执行上述步骤，强制最小权限策略，你将显著降低最常见的云攻击向量。 🚀
IAM 最佳实践
-
使用 IAM 角色而不是长期访问密钥
- IAM 角色是临时假设的，会自动颁发短期凭证。
- 它们没有可以泄露或遗忘的静态访问密钥。
- 在 AWS 中运行的任何服务——EC2 实例、Lambda 函数、ECS 容器——都应通过 IAM 角色进行身份验证，而不是使用长期访问密钥。
-
对所有人工 IAM 用户强制使用 MFA
- 附加一条 IAM 策略，除非在当前会话中使用了 MFA，否则拒绝所有操作。
- 这种两分钟的实现可消除仅凭证的人工账户妥协风险。
- AWS 在其文档中提供了 MFA 强制策略示例。
-
绝不要在日常操作中使用根账户
- 为管理任务创建专用的管理员 IAM 用户。
- 为该管理员用户启用 MFA。
- 将根账户凭证妥善保管，仅在严格需要根权限的账户级操作时使用。
典型攻击链
-
获取有效凭证
- 在公共 GitHub 仓库中泄露的访问密钥。
- 利用 SSRF 漏洞访问 EC2 元数据端点并返回实例角色凭证。
- 对开发者进行钓鱼攻击。
-
枚举权限
- 像 Pacu（一个开源的 AWS 利用框架）之类的工具可以自动化此步骤：“这个凭证到底能做什么？”
-
权限提升
- 如果被 compromise 的凭证拥有
iam:CreateUser、iam:AttachUserPolicy或iam:PassRole权限，攻击者可以：- 创建一个新的管理员用户，或
- 提升到更高权限的角色。
- 从此整个账户被攻陷——所有服务、数据存储和机密信息均受到威胁。
- 如果被 compromise 的凭证拥有
这并非理论情景。它已在真实的安全事件以及 AWS 自身的安全指南中有所记载。
有用的 AWS 原生和开源工具
| 工具 | 描述 | 成本 |
|---|---|---|
| IAM Access Analyzer | 内置的 AWS 服务，可识别可从账户外部访问的资源和角色，或授予超出预期的更广泛访问权限。 | 免费 |
| AWS Trusted Advisor（安全检查） | 提供 IAM 相关的建议：根账户的 MFA、访问密钥轮换、权限审查。适用于 Business 和 Enterprise 支持计划。 | 包含在支持计划中 |
| Prowler | 开源的云安全扫描器，对您的 AWS 账户执行数百项检查（CIS 基准、AWS 最佳实践），全面覆盖 IAM。 | 免费（开源） |
对您的 AWS 账户运行 Prowler
pip install prowler
prowler aws --services iam这些步骤和工具将帮助您强化 IAM，检测配置错误，降低凭证攻击的风险。