如何查找任意 S3 存储桶的 AWS 账户 ID
一种新技术通过滥用 IAM 条件匹配，展示了如何推断任意给定 S3 存储桶所属的 AWS 账户 ID，引发了人们对哪些原本隐含的元数据现在可以被映射和关联的讨论。评论者大多同意 AWS 账户 ID 本就不应被视为秘密——AWS 也明确这么说——但在是否应因运营安全或关联风险而将其视为“敏感信息”这一点上存在争论。许多人认为，这提醒我们安全绝不能依赖隐藏标识符或模糊性，而真正需要解决的危险是错误配置的跨账户策略和元数据泄露。
发现范围
- 该技术利用 S3 存储桶策略和带通配符的
s3:ResourceAccount条件，推断某个存储桶归属哪个 AWS 账户。 - 许多人认为这更像是一种有趣的旁路信息，而不是直接突破：你仍然需要错误配置或额外信息才能获得访问权限。
AWS 账户 ID 是秘密还是敏感信息？
- AWS 文档明确说明，账户 ID 不是秘密、敏感或机密信息。
- 一种观点：账户 ID 必须被视为公开信息；把系统设计建立在其保密性之上是糟糕的安全实践，是一种“错误假设”。
- 另一种观点：它们虽然不是“秘密”，但仍然“敏感”；泄露会给攻击者增加价值，在可行时应尽量减少。
运营安全与元数据泄露
- 主要担忧不是原始 ID，而是它们之间的关联：
- 将多个存储桶关联到同一所有者（例如不同品牌、客户、内部项目）。
- 把“隐藏的”或预发布存储桶与已知的生产账户关联起来。
- 商业情报 / 间谍活动用途（例如，从存储桶名称中了解项目）。
- 有人认为这属于 opsec，而不是安全问题；也有人认为 opsec 仍然确实重要。
“安全性依赖于模糊性”之争
- 许多人认为，模糊性最多只是薄弱、不可轮换的一层，绝不应被当作控制手段来依赖。
- 也有人反驳说，“非公开但非秘密”的信息本身就是一个合理的 opsec 问题，并不意味着你把它当作访问控制机制。
- 共识点：不要设计 IAM 或威胁模型时假设账户 ID 会一直保持隐藏。
IAM 通配符与策略设计
- 许多人对 IAM 允许在账户 ID 上进行通配符（
StringLike）匹配感到惊讶；不少人认为这没有正当的访问控制用途。 - 给出的解释包括：
- 通用、宽松类型的策略语言，为了简化而在各处都使用字符串操作符。
- 可能但值得怀疑的用途（按前缀对许多账户分组、分片、减少策略大小）。
相关枚举向量与工具
- AWS 访问密钥 ID 内嵌了账户 ID，并会出现在预签名 URL 中，因此许多 ID 可能早已在泄露。
- 其他全局命名空间（例如 AMI 供应商、其他公开资源）也会自然暴露账户 ID。
- 带组织级聚合和 Athena 的 AWS Config 被强调为在内部查找某个资源归属哪个账户的“正确”方式，不过它并不是免费的。