在2026年使用 IAM 用户是一种人生选择
Source: Dev.to
传统 IAM 用户的隐藏成本
云安全事件并不是从泄露开始的——它们始于考古。
你打开 IAM 控制台，滚动查看，看到类似下面的内容：
legacy-service-migration
Access keys: active
never
unknown没有人记得它为什么会存在，也没有人知道删除它会导致什么破坏，所以它一直保留着。这不是疏忽，而是一种营养级联效应。
级联是如何开始的
- “我们需要给脚本提供访问权限。”
- “CI 需要凭证。”
- “这是临时的，稍后再清理。”
创建了一个 IAM 用户，生成了访问密钥，系统继续运行。没有出错，也没有警报。
为什么 IAM 用户会超出其用途而长期存在
IAM 用户不会过期。它们会超出：
- 脚本
- CI 流水线
- 团队
- 架构决策
快进几年：脚本不见了，流水线变了，团队轮换了，但 IAM 用户仍然在。于是出现了：
- 所有权不明确的凭证
- “以防万一” 添加的权限
- 对影响范围缺乏信心
这就是 身份卫生债务。
当临时变为永久
随着时间推移，IAM 用户不再被视为临时的。你会听到：
- “别动那个。”
- “它可能在某处被使用。”
- “我们以后再审计。”
- “它已经存在很久了。”
安全性从声明式转向历史式：“我们不知道它为什么存在，但它一定是必须的。”
未知的身份比没有身份更糟，这种脆弱性解释了为何真实世界的事故会造成严重伤害。
实际案例：2025 年 SSRF 利用
在 2025 年，针对 CVE‑2025‑51591（Pandoc 文档转换器中的 SSRF 漏洞）的活跃利用尝试，锁定了 AWS 实例元数据服务（IMDS）。攻击者提交了精心构造的 HTML，旨在迫使服务器发起内部请求，特别是针对 IMDS 的以下地址：
http://169.254.169.254/latest/meta-data/iam/infohttp://169.254.169.254/latest/meta-data/iam/security-credentials
为什么是 IMDS？ 因为它可以返回 AWS 凭证。
Wiz 观察到攻击者在探测元数据路径。在许多环境中，由于 IMDSv2 的存在，攻击失败了——IMDSv2 需要会话令牌并阻止盲 SSRF。
令人不安的问题
如果这些工作负载使用的是静态 IAM 用户密钥而不是角色，会怎样？
这就是连锁反应的完整过程。
- 凭证过期 → 会话失效 → 访问自然中断
- 凭证持久 → 攻击者可稍后返回 → 轮换需手动进行（且常被遗忘）
SSRF 只是一个入口点；IAM 用户的卫生状况决定了冲击范围和持续时间。
常规 IAM 审查的发现
- IAM 用户创建于 2016–2018
- 拥有广泛权限（S3、EC2、IAM）的活跃访问密钥
- 最近没有 CloudTrail 活动
- 没有文档，没有负责人
删除它们感觉风险很大。真实的失败状态是：不作为比行动更安全，生态系统会腐烂。
现代 AWS 身份假设
- 短期凭证
- 明确所有权
- 上下文访问
- 自动过期
推荐控制
- IAM 角色 代替用户
- 用于联合访问的 OIDC 和 SSO
- IMDSv2 仅限使用
- 明确的控制以限制 IAM 用户创建
IAM 用户应当：
- 稀少
- 有文档记录
- 有所有者
- 经过审计
- 像放射性物质一样对待（即，不能使用默认设置）
Fixing the Cascade: A Step‑by‑Step Plan
- 列出所有 IAM 用户
- 识别所有者
- 审查最近使用情况（CloudTrail，最近登录）
- 删除未使用的密钥
- 在可能的情况下用角色替代用户
- 在可行的情况下阻止新 IAM 用户（策略防护）
- 将未知身份视为缺陷
是的，可能会出现故障。但出现故障总好过悄悄拥有你的云。
结论
使用 IAM 用户在 2026 年并不是因为无知；而是有意识地接受：
- 永久凭证
- 无界限的冲击半径
- 身份考古
- 脆弱的安全姿态
云故障不是突发的——它们是生态性的。发现 2017 年的 IAM 用户没有人理解，这不仅是技术债务；更是生态系统已经崩溃的警示信号。