凭据泄露管理是什么
凭据泄露常发生在两处：代码提交（把密钥、口令、Token 写进仓库）与镜像层（构建时把凭据固化进镜像）。管理动作分两层：预防靠仓库密钥扫描、推送保护与提交前钩子；处置按「吊销 → 轮换 → 清理 → 验证」顺序执行。顺序不能颠倒，先删代码不轮换等于什么都没做。
基本信息
| 预防手段 | 仓库密钥扫描、推送保护、pre-commit 钩子、CI 阶段扫描 |
|---|---|
| 重灾区 | CI 变量、示例配置文件、测试脚本中的真实值 |
| 处置顺序 | 吊销 → 轮换 → 清理 → 验证 |
| 镜像场景 | 构建使用 --secret 或多阶段构建，避免凭据层留在镜像里 |
处置顺序
处置顺序
1. 吊销：立即在源端禁用/删除泄露的凭据
2. 轮换：生成新凭据并更新部署（评估影响面与回滚方式）
3. 清理：从代码与镜像中移除；历史提交清理需团队协调
4. 验证：确认旧凭据不可用，调用日志无异常
5. 预防：pre-commit 钩子 + CI 扫描 + 推送保护仓库侧核查示例
仓库侧核查示例
git log -p --all -- . | grep -nE 'AKIA[0-9A-Z]{16}|BEGIN [A-Z ]*PRIVATE KEY|password\s*=' | head
# 或使用密钥扫描工具对工作区与历史做全量检查，注意输出不要回贴到工单
# 镜像侧：检查是否存在包含凭据的层，发现后重建镜像而不是在原镜像上修改典型使用场景
- 收到密钥扫描告警：按处置顺序执行并记录时间线
- 外包交付验收：检查代码仓库与镜像中是否夹带真实凭据
- CI/CD 改造：把凭据统一改为平台凭据库注入，去掉明文变量
- 上线前检查：确认示例配置文件里是占位符而不是真实值
- 事件响应：评估凭据泄露时间窗内的异常调用记录
泄露渠道与对策
| 渠道 | 典型表现 | 对策 |
|---|---|---|
| 代码提交 | 配置文件中有真实密钥 | 推送保护 + 提交前扫描 |
| 镜像层 | 凭据写死在 Dockerfile | 构建密钥注入，多阶段构建 |
| 日志输出 | 调试日志打印密钥 | 日志脱敏与级别控制 |
| 第三方托管 | 外部仓库或文档含密钥 | 统一搜检并纳入供应商要求 |
把真实凭据写进示例配置是常见的习惯性错误：示例值一律用占位符，由部署环境注入，避免示例成为泄露源。
历史提交重写（强制推送）能清理内容，但缓存副本、派生分支与已克隆的本地仓库不受影响，因此清理动作必须与轮换配合。