AWS 在其官方工具中引入了安全风险 在最近的一系列博客文章中，我们探讨了在 AWS 环境中安全设置跨账户访问的四个危险误解。在这个系列的最后一部分，我们将通过一个真实案例说明，即使 AWS 自己也存在这些问题。他们的 Account Assessment for AWS Organizations 工具，本应帮助用户审计资源策略中的高风险跨账户访问，却因为部署指导的漏洞无意间引入了更大的风险。 案例的起因与背景 在调查某客户 AWS 环境中的一个关键权限升级风险时，我们发现了一个在生产账户和管理账户中均存在的 IAM 角色，该角色信任开发账户中的两个角色。这些角色拥有广泛的权限，可以调用敏感的 API，包括 IAM 和数据相关操作，这些权限对所有资源生效，一旦被滥用后果不堪设想。由于开发账户的安全措施较弱，这种角色假设路径成为重大风险：攻击者如果攻破了开发账户中的受信任角色，就可以立即获得在生产和管理账户中的这些敏感权限。 我们在深入研究后发现，这不仅仅是客户的部署错误，实际上 AWS 的官方文档无意间鼓励了这种不安全的配置。 Account Assessment for AWS Organizations工具的问题 Account Assessment for AWS Organizations 是 AWS 开发并发布的一款工具，旨在“集中评估和管理 AWS 组织内的账户”，帮助用户更好地理解账户之间的依赖关系。该工具主要用于并购、安全审计、集中策略探索和管理账户转换等场景。然而，这款工具的部署指导存在严重问题。 根据官方文档，工具建议将“中心堆栈”（Hub stack）部署到组织中的任意成员账户，但明确排除了管理账户。这一指导导致许多客户在安全性较低的账户（如开发账户或测试沙箱账户）中部署了中心角色（Hub role），从而创建了一条从低安全性账户到高安全性账户（如生产环境和管理账户）的直接信任路径。 具体来说，如果客户在开发账户（通常安全性较弱）中部署了中心角色，攻击者一旦攻破开发账户，就能利用中心角色访问整个组织的所有账户，包括最敏感的生产环境和管理账户。这不仅增加了权限升级的风险，还使整个 AWS 组织更容易受到控制。 事件的影响与检测 任何在 2025 年 1 月 28 日之前按照 AWS 官方指导在比管理账户安全性低的账户中部署此工具的组织都处于高风险状态。对于受影响的组织，中心账户成为攻击者的高价值目标。如果攻击者控制了中心角色，他们可以轻松地假设其他联动账户中的角色，进入高度敏感的环境。 检测方法： 1. 检查部署时间：查看与工具相关的角色的 CreateDate 属性。如果是在 2025 年 1 月 28 日之前部署的，建议将其删除，除非中心角色已经位于高安全性账户中（如专用的基础设施或 DevOps 账户）。 2. 卸载工具：删除 Hub、Spoke 和 Org-Management 组件的 CloudFormation 堆栈。详细步骤请参照 AWS 官方的卸载指南。 3. 谨慎重新部署：如果组织仍需要该工具，应将中心角色部署在与管理账户同等安全性的账户中，以防止权限升级风险。 AWS 的回应与修复 我们识别到这个问题后，立即将报告提交给 AWS 安全团队。AWS 迅速审查了我们的发现，并承认存在安全问题。他们与我们合作，更新了官方文档，明确建议客户将中心角色部署在与被评估账户相同或更高安全性的账户中，以防止意外的权限升级风险。 AWS 安全团队的积极响应和对客户安全的承诺值得称赞。他们认真对待问题，迅速采取行动修复文档，确保未来的部署更加安全。 业内人士评价与公司背景 这次事件再次提醒科技行业，即使是像 AWS 这样的顶级云服务提供商，在安全指引上也可能出现疏漏。Token Security 公司的机器优先身份安全平台能够检测这类信任策略风险，无论是由 AWS 工具、人为错误还是配置疏忽引起。希望这个案例能让更多人意识到信任策略管理的重要性，避免类似的潜在风险。