先止血，再复盘。发现 Key 泄露时，第一动作是停用或切换，而不是先找是谁提交的。
一、什么算可疑
- Key 出现在公开仓库、截图、日志或第三方工具里。
- 来自不认识的 IP。
- 请求模式与业务正常曲线不符。
- 存在大量 401 / 403 / 429。
- 单 key 消耗突然暴涨 3 倍以上。
二、标准处置流程
紧急步骤
1. 立即停用或编辑该 Key 2. 生成新 Key 3. 业务侧更新新 Key 4. 检查近 7 天日志，确认异常调用范围 5. 撤销可能被泄露的部署凭据 6. 记录时间线和影响金额 7. 复盘根因并改进
三、如何安全轮换
- 先创建新 Key，不要直接删除旧 Key。
- 业务里按 Key 名称或环境变量切换。
- 旧 Key 设为只读或提高限流，观察 24 小时。
- 确认没有再消耗后，再停用。
- 同时更新 CI/CD、客户端和服务器上的所有配置。
四、常见泄露点
- 前端代码。
- 公开 Git 仓库。
- 上传到对象存储的截图或日志。
- 桌面工具的配置文件。
- 把生产 Key 交到临时第三方工具里测试。
五、事后复盘模板
- 什么时候开始异常？
- 谁先发现？通过什么告警？
- 影响多少请求和金额？
- 是否影响用户业务？
- 根因是什么？
- 如何避免再次发生？
六、轮换自动化
大团队里不要靠人记住，建议每个 Key 都有到期时间：
示例
key_rotation_policy: default_days: 90 warn_before_days: 14 emergency_rotate_hours: 1 warn_channels: [email, slack] grace_period_hours: 24
到期前 14 天提醒，到期前 1 天开始双 Key 并行，到期后统一停用旧 Key。
七、泄露快速判断表
| 现象 | 优先级 | 动作 |
|---|---|---|
| 公开仓库里发现 Key | P0 | 立即停用并复盘 |
| 陌生 IP 出现少量请求 | P1 | 提高监控并确认来源 |
| 生产 Key 放入前端代码 | P0 | 立即换 Key，不再复用 |
| 供应商临时测试使用 Key | P1 | 单独发临时 Key，到期自动停 |
| Key 出现在共享文档 | P1 | 缩短权限，通知相关人 |
八、预防措施
- 生产 Key 存在密钥管理器。
- 测试 Key 与生产 Key 分开。
- 所有 Key 有过期时间。
- 仓库里加 secret scanning。
- 所有临时测试用一次性 Key。
九、交接文案
出现事故后，先给团队发一段标准文案：
示例
各位， [时间] 发现 [key_name] 疑似泄露。 已停用旧 Key，业务已切到新 Key。 影响范围正在核对。 预计 [时间] 更新复盘通知。
先通知，再补细节，避免大家在等待完整复盘时继续被动暴露。
十、关键心态
Key 泄露不是丢脸的事，真正的问题是发现后是否处理得快。复盘重点不是惩罚人，而是让下一次不会再因为同一个动作把 Key 暴露出去。