安全轮换泄露的密钥

为什么先吊销而不是先清理历史

清理 Git 历史既慢又不彻底：克隆、CI 缓存和日志中可能早已存在该密钥。只有在服务提供方吊销凭据，才能可靠地阻止滥用。历史重写是清理动作，不是遏制手段。

openssl rand -base64 32
# 将新值存入密钥管理器，不要写入被提交的文件。
aws secretsmanager update-secret \
  --secret-id prod/app \
  --secret-string "$(openssl rand -base64 32)"

步骤

1. 在服务提供方立即吊销已暴露的凭据，不要等待历史清理完成。
2. 生成新密钥，存入密钥管理器，更新部署环境，然后重新部署所有使用方；确认新值可用后再处理旧值。
3. 从工作树和 Git 历史中移除旧值。相关会话、令牌和 Webhook 也应一并轮换。
4. 使用 git filter-repo 重写历史，例如 git filter-repo --path .env.production --invert-paths，然后通知协作者重新克隆。
5. 搜索当前工作树、CI 配置和构建产物，确认没有仍然可用的旧值；在事故记录中写明吊销时间、替换时间与观察到的访问情况。

验证

• 服务提供方拒绝旧凭据。
• 应用使用新凭据启动，并成功完成一次真实请求。
• git grep 与构建产物扫描找不到旧值的有效副本。
• 协作者已重新克隆或重置到重写后的历史。
• 事故记录说明泄露凭据可能访问的范围与持续时间。

限制与风险

历史重写无法删除已被克隆、被 CI 缓存或被第三方索引的副本，因此吊销是唯一可靠的遏制措施。部分服务商要求双凭据重叠轮换，请遵循其官方流程。强制推送共享分支前必须协调团队，避免覆盖未合并的工作。