泄露的云密钥不是已经结束的事件。只要它还能认证，它就是一个有效入口，直到有人轮换、删除并检查它曾经能访问什么。Truffle Security 在 2026 年 8 月的研究说明了这个问题：危险不只是 AWS credentials 被公开，而是很多组织让这些密钥在公开后继续存活多年。

抽象云控制台、暴露的访问密钥、隔离胶带和轮换清单

Truffle Security 表示，它收集了 431,875 个已验证 AWS secret findings，去重后得到 64,024 个唯一 access keys，涉及 50,654 个账户。随后研究人员重新验证了 10,616 对完整密钥，这些密钥在 2022 年 8 月到 2026 年 8 月之间公开出现过。结果是 88% 仍然可以认证。9,308 个活跃密钥中，817 个与企业相关，其中 768 个拥有完整账户控制权：526 个 root keys，242 个 IAM users 带有 AdministratorAccess。

BleepingComputer、The Register、TNW 等媒体跟进报道。Corey Quinn 在 The Register 中把重点放在 AWSCompromisedKeyQuarantineV3。AWS 官方说明中，这项托管策略用于限制部分与欺诈相关的损害，同时不影响现有资源。关键问题在于：quarantine 不是 remediation。它能减少某些明显滥用，但不能代表账户已经安全。

这正适合“没有恐慌的网络安全”角度。答案并不神秘：root access keys 几乎不应该存在；长期 IAM access keys 必须有负责人、寿命和轮换计划；进入 Git history、Docker image、CI log、notebook 或 dataset 的 secret 应被视为永久公开；quarantine policy 是 incident response 的开始，不是结束。

研究发现了什么

431,875 这个大数字包含许多重复项，例如 forks、mirrors、logs、images 和 datasets。更重要的是去重后的 64,024 个唯一密钥，以及 2026 年 8 月 10 日重新验证的 10,616 对完整密钥。其中 9,308 个仍然有效。

企业相关部分规模较小，但风险更高。817 个活跃密钥与企业相关，768 个有完整管理员控制权。130 个 live root keys 位于 organization management accounts。这样的密钥不是普通开发者忘记删除的测试凭据，而可能是整个云组织的总钥匙。

密钥年龄也很重要。Truffle Security 报告称，仍然有效的泄露密钥年龄中位数为 1,831 天。也就是说，很多 credentials 公开多年仍然有效。只有 13.7% 的情况有更新密钥与泄露密钥并存，这不像完成了轮换，更像是旧访问被继续使用。

Hugging Face 在研究中是公开 datasets 中暴露密钥的重要来源。这不应被写成新的 Hugging Face breach。更准确的说法是：ML datasets、notebooks、model repositories 和 training corpora 继承了软件仓库的老问题，公开 artefacts 里有时会带着 credentials。

为什么 root key 更危险

IAM key 可能很危险。Root access key 更危险。Root user 代表 AWS account 本身。AWS 文档建议保护 root credentials，避免日常使用 root，并优先使用 IAM Identity Center、roles 和 temporary credentials。

区别在于范围。普通 IAM identity 可以通过 permissions、conditions、boundaries 和 organization policies 限制。Root 位于许多控制之上。root key 泄露涉及 billing、account settings、recovery paths，有时还涉及 organization management account。

Root keys 也会活得比负责人更久。工程师离职，承包商离开，个人账户变成公司账户，老自动化继续使用 2021 年能跑的 key。没人敢碰，因为怕生产系统中断。但这正是风险：没人负责的 credential 仍然能被攻击者使用。

成熟的云安全程序应该随时回答：是否存在 root access keys？谁批准？何时删除？如果答案是不知道，就没有真正控制。

删除一行代码不够

secret scanning 的基本规则仍然常被忽视：credential 一旦进入公开 artefact，就应假设已被复制。从最新 Git commit 删除它，不会清理 Git history。关闭仓库，不会删除 forks、mirrors、package caches、Docker layers、CI logs、notebooks、search indexes 或 datasets。

因此，泄露的 AWS key 应像公开密码一样处理：rotate or delete，调查使用情况，确认依赖它的 workloads，检查活动记录。若是 root 或 AdministratorAccess，还需要 CloudTrail、billing、secret inventory，以及 persistence or privilege escalation 检查。

开发者常以为“我删掉了那一行”。正确结论是：“那一行暴露了一个必须替换的 credential”。这是清理文件和关闭访问之间的区别。

Docker images 和 ML datasets 让问题更复杂。密钥可能留在旧 image layer、notebook output、debug log、benchmark corpus 或 ZIP 中。现代 secret management 不能只扫描主代码仓库。

AWS quarantine 代表什么

AWSCompromisedKeyQuarantineV3 是 AWS managed policy。官方文档称，它用于 compromised or publicly exposed IAM credentials，拒绝某些操作，以限制 fraud-related damage，同时不影响 existing resources。

最后这句话很关键。它是 harm reduction，不是完整修复。quarantined key 是 incident signal，不是安全证书。如果 policy 设计目标是不破坏 existing resources，那么某些现有路径可能继续工作。

Corey Quinn 批评的是 residual risk，例如 database operations、systems-management sessions、AssumeRole、audit-log disruption、messaging abuse、secret reads、backups 和 infrastructure changes。防守方不需要攻击步骤，也能理解结论：quarantine is a temporary guardrail, not incident closure。

这里确实有取舍。AWS 若自动关闭每个公开 key，可能打断客户生产。若继续允许认证，则避免 outage 但保留 exposure。因此组织必须有自己的快速轮换 playbook。

今天该检查什么

先检查 root。每个 AWS account 都要确认是否存在 root access keys。如果存在，确认 business reason、owner、last used 和 removal date。多数组织的目标状态应是 no root access keys。root user 应启用强 MFA，只用于极少数真正需要 root 的任务。

盘点 IAM access keys。按 age、last-used date、owner、workload 和 permission level 排序。AdministratorAccess、wildcard permissions、no owner、no recent use 或 no rotation date 都是高优先级。

查找 AWSCompromisedKeyQuarantine policy attachments。如果 AWS 加了 quarantine，把它当成 incident signal。找到 credential，轮换，删除旧 key，检查 CloudTrail、billing、budget anomalies 和 role assumption paths。

扫描范围要超过代码。包括 Git history、forks、public registries、container images、build logs、CI variables、notebooks、support bundles、public datasets 和 model repositories。Truffle Security 的研究提醒我们，secrets 越来越常存在于 data and ML artifacts。

尽量替换 static credentials。CI/CD 应使用 OIDC federation 和 short-lived role assumption，而不是 long-lived AWS keys in pipeline variables。人类用户使用 IAM Identity Center 或 federated access。workloads 使用 scoped roles。legacy static keys 应有 owner、expiration 和 monitoring。

如何不打断生产地轮换

很多泄露 key 存活多年，是因为团队害怕 outage。这种担心合理：直接删除未知 key 可能打断 build system、backup job、data pipeline 或老服务。但答案不是永远保留，而是 evidence-based rotation。

先识别 principal 和 last-used services。CloudTrail、IAM last-accessed data、application logs 和 cost anomalies 能帮助定位用途。然后找到 owner，创建权限更小的 replacement path，带监控部署，最后删除旧 key。若不能立刻删除，必须有 time-boxed exception、expiry date 和 named owner。

对于 root 或 AdministratorAccess，应假设可能已经被他人使用。检查 recent API activity、secret access、role assumptions、security-group changes、bucket policies、backup operations、IAM changes 和 unusual spend。启用 budget alerts 和 cost anomaly detection。

目标是在紧急情况前练习轮换。知道 owner 和替换模式的团队，可以在数小时内响应。无法识别 owner 的团队，会和一个 compromised key 周旋数周。

冷静结论

这项研究不意味着每个 AWS account 都已被攻破，也不意味着 AWS quarantine 没用，更不意味着应该随机删除 key。恐慌会打断生产；否认会制造 breach。

合适的反应是：把所有公开 credential 视为 compromised；删除 root keys；用 roles and federation 替代 long-lived IAM keys；扫描真实 artefacts；对 quarantine 做 incident response；练习 rotation；保持 billing alarms。

最不舒服的部分是：cloud access 常常是静默失效。key 泄露，scanner 报警，provider 限制部分动作，有人删除一行，大家继续工作。但 credential 仍然能认证。要修复的是 ownership、inventory、short-lived credentials 和 operational discipline。