leak对比：一次事故复盘
leak对比最有价值的地方，是把事故前后的做法摆在一起看。下面复盘一个常见场景：测试项目把云存储密钥推到仓库，虽然不是惊天大案，但流程里每个小洞都很典型。
第1步：异常账单先冒头
事情开始于一张云存储账单。平时测试桶一天几百 MB 流量，某天突然冲到几十 GB。开发最初以为是压测没关，查对象访问日志才发现，有陌生 IP 在批量列目录和下载文件。
事故前后的 leak对比很明显：之前只看服务报错，不看云资源账单；之后把流量、请求次数、跨地域访问都接进告警。很多泄漏不是从安全平台发现的，而是从费用异常露头。
第2步：回溯密钥来源
团队按时间线查，发现一个测试脚本里硬编码了 AccessKey。脚本三个月前被推到私有仓库，后来仓库临时给外部协作方开过权限。没人能证明密钥没被复制，所以只能按已泄漏处理。
这里的对比更扎心：事故前觉得私有仓库等于安全；事故后规定密钥不能进代码，测试脚本也必须读环境变量。私有不是保险柜，它只是门口多了一把锁。
第3步：先止血，不纠结甩锅
处理顺序很关键。团队没有先开会追责，而是先禁用旧 key，新建最小权限 key，限制只能访问测试桶，并把桶策略改成禁止列目录。接着清点桶内对象，确认没有生产用户数据。
这一步的 leak对比是权限粒度。事故前一个 key 能读写多个桶；事故后按项目拆 key，读写分开，测试环境只保留必要权限。密钥泄漏不可怕，可怕的是一个 key 像万能房卡。
第4步：清理历史，不假装没发生
禁用密钥后，团队用工具扫描仓库历史，发现旧提交里还有两处同类写法。清理历史提交只是为了减少二次传播，不是为了让泄漏“撤回”。被别人拉走过的内容，技术上没法保证消失。
事故前没人扫历史；事故后把 Gitleaks 接进 CI，并要求外部协作仓库同样跑扫描。更实用的一点是：扫描报告里必须有负责人和关闭时间，不然警告会变成背景噪音。
第5步：把复盘变成规则
复盘最后产出了四条规则：仓库禁止硬编码密钥；云 key 默认最小权限；测试桶对象30天过期；云资源异常账单进告警。每条都能被检查，不写“提高安全意识”这种空气话。
这次 leak对比带来的结论很简单：事故前靠人记得，事故后靠系统拦住。真正有效的复盘，不是PPT做得漂亮，而是下次有人犯同样错误时，流程会直接把他拦在门外。
推荐阅读
常见问题
leak对比复盘要看哪些维度？
看发现方式、泄漏源头、权限范围、止血速度、后续规则五个维度。只讲原因不讲改造，复盘价值很低。
私有仓库里的密钥泄漏算严重吗？
算。只要密钥进入仓库，就要假设可能被复制。正确处理是轮换密钥，并检查访问日志和权限范围。
对象存储密钥泄漏后怎么止血？
先禁用旧密钥，再创建最小权限新密钥；同时检查桶策略、访问日志和对象内容，必要时设置临时封禁和过期策略。