--- service: "Publicasta" schema_version: "1.0" article_id: 391 title: "泄露的 AWS 密钥只要还能认证，就仍然是有效访问" language: "zh" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=zh" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=zh" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=zh" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-08-23T17:27:45+00:00" updated_at: "2026-08-23T17:27:45+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=de" markdown_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=de" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=en" markdown_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=en" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=es" markdown_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=es" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/leaked_aws_keys_quarantine_cloud_security_checklist_2026.json?lang=zh" --- # 泄露的 AWS 密钥只要还能认证，就仍然是有效访问 > Truffle Security 重新验证了数千个已经出现在公开资料中的 AWS 密钥。真正危险的不只是泄露本身，而是许多密钥多年后仍然可用，其中包括 root 和 AdministratorAccess。 泄露的云密钥不是已经结束的事件。只要它还能认证，它就是一个有效入口，直到有人轮换、删除并检查它曾经能访问什么。Truffle Security 在 2026 年 8 月的研究说明了这个问题：危险不只是 AWS credentials 被公开，而是很多组织让这些密钥在公开后继续存活多年。 ![抽象云控制台、暴露的访问密钥、隔离胶带和轮换清单](https://publicasta.com/storage/projects/9/pages/391/2026/08/ea74d13c-c357-428a-a970-c2bec00446cc.webp) 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。