01 · 复盘方法论
本档案库采用统一的四步复盘框架，每起事件回答四个问题：
| 步骤 | 内容 | 输出物 |
|---|---|---|
| 事实层 | 仅采用官方披露、司法文件、监管通报或权威媒体报道中的可查证事实（时间、规模、技术路径） | 事实卡（含来源链接） |
| 攻击链层 | 按初始访问→凭证获取→权限利用→数据接触的链路分步重建，区分"已证实"与"合理推断" | 攻击链图（steps图示） |
| 责任映射层 | 将每一步映射到第2页责任矩阵的具体格子，标出"无人认领的责任格"或"配置责任失守格" | 责任失守标注表 |
| 检测转化层 | 为每个失守点编写CSPM核查项与告警规则（第3、6页），形成可执行的验证用例 | 检测规则条目 |
事实纪律声明：本页所有规模数字、时间与责任认定均以公开披露为准：Capital One数据以公司2019年7月披露与美国司法部案件材料为准；Tesla事件以RedLock（后被Palo Alto Networks收购）2018年2月公开报告为准；Docker Hub以公司2019年5月官方通报为准；Deep Root Analytics以UpGuard 2017年6月公开报告为准；Exactis以Wired 2018年6月报道为准；Verizon-NICE以公司2017年7月公开声明为准。无公开依据的技术细节不做臆断。
02 · 深度案例：Capital One数据泄露（2019）
2.1 事实卡
| 项目 | 内容 |
|---|---|
| 时间 | 2019年3月发生，2019年7月17日公司披露（同年7月29日被捕，2022年6月西雅图联邦法院定罪） |
| 规模 | 约1亿美国客户与600万加拿大客户信息，含部分信用卡申请数据；公司公开声明未发生账号密码与登录凭证泄露、未发生信用卡账号大规模失窃 |
| 公开来源 | 公司事实页（capitalone.com/facts2019）、美国司法部（justice.gov）新闻稿与起诉文件、FBI |
2.2 攻击链重建（已证实部分）
2.3 责任失守标注与检测转化
| 失守点 | 责任矩阵格子 | 检测转化（第3页对应） |
|---|---|---|
| WAF/应用层SSRF | IaaS行"应用代码与配置"（客户全责） | 3.5节三件套③：出口收敛+元数据端点默认拒绝 |
| IMDSv1可用 | IaaS行"操作系统与配置"（客户全责） | 三件套①：全量强制IMDSv2 |
| 角色权限过宽 | IaaS行"身份与访问管理"（客户全责） | 三件套②+3.3节：S3前缀级最小授权+CIEM收敛 |
| 敏感数据未分级隔离 | IaaS行"数据分类分级与加密"（客户全责） | 数据分区存储+访问模式基线（异常列举告警） |
行业影响：该事件直接推动三件事成为行业基线：①IMDSv2的广泛强制（AWS随后默认对新实例启用HttpTokens=required）；②SSRF进入云安全审计必查项（OWASP SSRF防护清单被普遍引用）；③"凭证使用模式异常检测"（GuardDuty类服务增加相关检测类型）成为标配。
03 · 深度案例：Tesla Kubernetes挖矿（2018）
3.1 事实卡
| 项目 | 内容 |
|---|---|
| 时间 | 2018年2月由RedLock公开披露；发现时点为2018年1月其云安全情报团队监测到异常 |
| 事实要点 | RedLock披露：某Tesla在AWS账户内的Kubernetes控制台（dashboard）存在未授权网络可达问题，攻击者利用环境中暴露的访问凭证访问Kubernetes集群，部署挖矿软件；RedLock同时披露了同类问题的其他企业（含Aviva、Gemalto）云环境案例 |
| 公开来源 | RedLock官方博客报告（redlock.io，2018年2月）；Tesla对媒体确认并修复 |
3.2 攻击链与失守点
- 初始访问： Kubernetes控制台（Dashboard）未做访问控制即暴露于可被利用的网络位置——属典型的"控制面默认即开放"问题（对照第2页五大特征"广泛的网络访问"一节）。
- 凭证利用： 环境中以明文或弱保护方式存在的云服务凭证被用于访问集群资源——直接违反IAM治理基线（第3页：凭证不落盘、短期凭证、最小权限）。
- 滥用变现： 部署挖矿程序消耗计算资源——"可计量服务"特征使账单异常成为天然检测信号；RedLock正是通过监测到注册域名关联的恶意IP与异常资源使用模式发现异常。
对子课题02的接口：该案发生在Kubernetes控制面，其编排层基线（Dashboard访问控制、ServiceAccount令牌治理、CIS Kubernetes Benchmark）由子课题02承接；本课题提供责任矩阵标注（IaaS行"应用代码与配置"+"身份与访问管理"均失守）与检测信号（账单异常+DNS出口画像）两层抽象。
04 · 深度案例：Docker Hub凭证泄露（2019）
4.1 事实卡
| 项目 | 内容 |
|---|---|
| 时间 | 2019年5月（公司官方通报） |
| 规模 | 约19万个账户的用户名与哈希密码；部分使用自动化构建（Auto Builds）功能的账户，其GitHub/Bitbucket访问令牌被暴露 |
| 后果与处置 | GitHub/Bitbucket侧令牌被撤销并要求重新授权；密码强制重置流程启动；事件本身未涉及镜像内容被篡改，但令牌暴露直接威胁代码仓库与CI/CD流水线 |
| 公开来源 | Docker官方安全通报邮件与状态页公告（2019年5月） |
4.2 失守点与检测转化
- 平台侧（CSP责任）：数据库被未授权访问——属SaaS行"中间件/运行时以下各层"的CSP责任失守面；客户无法预防但可要求事件通知时限与透明度报告（第2页灰区合同要素）。
- 客户侧（不可转移的责任）：使用自动化构建的账户将代码仓库令牌托管于第三方平台——令牌最小权限（只读vs可写）、可撤销性与使用范围审计是客户的IAM治理责任（第3页IAM模式库）。
- 检测转化：①第三方平台托管令牌一律按"可泄露"假设配置最小权限与短时效；②CI/CD流水线令牌使用行为基线（异地/异常时间调用告警）；③平台安全事件通报纳入供应商持续监督流程（第4页STAR Level 4思想）。
05 · 档案集群：存储桶与数据库公开暴露（2017—2018）
| 事件 | 时间 | 可查证事实 | 公开来源 |
|---|---|---|---|
| Deep Root Analytics | 2017.6 | 云安全公司UpGuard发现一家与共和党合作的数据分析公司Deep Root Analytics将约1.98亿条美国选民相关记录存放于公开可访问的AWS S3桶（含姓名、住址、出生日期、电话等）；公司确认并关闭公开访问 | UpGuard公开报告（2017年6月）；Gizmodo等媒体报道 |
| Verizon × NICE Systems | 2017.7 | Verizon确认第三方供应商NICE Systems管理的AWS S3存储配置失误，导致约600万订阅用户记录（姓名、地址、账户PIN等）可被公开访问；安全研究人员发现后通报 | Verizon公开声明（2017年7月）；ZDNet等报道 |
| Exactis | 2018.6 | 据Wired报道，营销数据公司Exactis一台公开可访问的Elasticsearch服务器暴露约3.4亿条个人记录（约2.3亿人），含详细个人特征标签；公司未公开证实精确规模 | Wired报道（2018年6月）；报道中规模为公司估计值，未见官方确认文件 |
口径纪律：Exactis案的具体记录数系媒体报道引用的估计值（公司未正式发布披露文件），本档案将其明确标注为"未见官方确认"；其余数字均有公司或监管机构层面的公开声明。档案库中凡估计值一律标注来源属性，避免以讹传讹。
5.1 三案的共性失守链
- 公开访问配置 + 敏感数据入云：三者均非"被攻破"，而是"门本来就是开的"——印证CSA将错误配置列为云首要威胁的判断。
- 供应商链条稀释责任感知：Verizon案为第三方供应商配置失误，Deep Root案为数据分析合作链——责任矩阵在"供应商管理"格失守（第2页灰区合同要素中的分包商条款正是对此）。
- 发现途径依赖外部研究者：三案均由UpGuard/Wired等外部发现而非组织自身监测——暴露"配置持续审计"（CSPM）缺位的普遍性（第6页工具链的立项依据）。
06 · 跨案例模式统计与验证用例集
6.1 由档案派生的基线验证用例（节选）
| 用例ID | 验证用例 | 对应失守事件 |
|---|---|---|
| TC-01 | 新建存储桶默认私有；公开例外须审批登记并附有效期 | Deep Root、Verizon-NICE |
| TC-02 | 含敏感数据桶的列举/List权限禁止授予匿名主体 | Deep Root |
| TC-03 | 数据库类端口对公网0.0.0.0/0开放即触发严重级告警 | Exactis |
| TC-04 | 全部实例强制IMDSv2；例外清单双人复核 | Capital One |
| TC-05 | 实例角色权限按S3前缀级收敛；90天未使用权限自动回收 | Capital One |
| TC-06 | K8s控制台/Dashboard类管理面禁止公网直接可达 | Tesla |
| TC-07 | 云资源账单异常（算力突增+未知镜像）纳入SOC告警 | Tesla |
| TC-08 | 第三方平台托管令牌的权限最小化与季度复审 | Docker Hub |
本节参考来源（第5页）
以下均为公开可查来源；公司披露与司法文件优先于媒体报道。
Capital One官方事实页（2019年7月17日起持续更新）：capitalone.com/facts2019；美国司法部新闻稿与案件材料（justice.gov，2019年起诉、2022年定罪公开报道）。
RedLock《Cryptojacking Tesla》（官方博客报告，2018年2月）及媒体跟进报道；RedLock同期披露的Aviva、Gemalto案例说明该模式非孤例。
Docker官方安全通报（2019年5月，邮件与status页公告，涉及约19万账户与部分Auto Builds令牌）。
UpGuard《The RNC Files: Inside the Largest US Voter Data Leak》（2017年6月，Deep Root Analytics案）；Gizmodo同期报道。
Wired《A Huge, Mysterious Data Leak Exposes Personal Info of Millions of Americans》（2018年6月，Exactis案）；ZDNet对Verizon 2017年7月声明的报道。
AWS安全博客关于IMDSv2增强的公告（2019年，docs.aws.amazon.com/ec2/latest/userguide/configuring-instance-metadata-service.html）。