大多数团队的密钥清单活在三个人的脑子里：运维记得数据库口令，后端负责人记得支付网关的私钥，某位已经离职的同事曾经配置过对象存储的凭证。出事那天，问题不是"密钥怎么换"，而是"到底有几个"。
轮换之所以做不成，通常和技术无关。密钥管理系统早就支持新版本、支持双版本并存，做不成是因为没有人对清单负责、没有验证过换完是否生效、也没有任何证据能证明自己换过了。
这篇讲的是这件事的组织面：清单、归属、验证、编排、证据，以及什么时候这套机制本身收益很低。
1. 轮换要成立的三件事
| 要件 | 缺失时的表现 | 判断方法 |
|---|---|---|
| 有清单 | 出事时现找，找到的还不是全量 | 能否在十分钟内列出所有长期凭证 |
| 有归属 | 没人敢动，因为不知道谁会断 | 每个密钥能否指名一个负责人 |
| 有验证 | 换完不知道有没有生效 | 能否给出新旧密钥的生效与失效时刻 |
三件事的难度是递增的：清单是体力活，归属是组织问题，验证是工程问题。多数团队停在第一件，是因为第二件没人愿意接。
// 密钥清单的最小条目：缺 owner 的条目在轮换时一定卡住
secret_id: db-order-primary
holder: service // 人 / 服务 / CI / 第三方
owner: team-order-platform // 具体到团队，不写"运维"
consumers:
- svc-order-api
- svc-order-batch
storage: vault/secret/db/order-primary
last_rotated: 2026-08-14
rotate_every: 180d
blast_radius: 订单读写全断
2. 四种持有者与轮换难度
| 持有者 | 典型形态 | 轮换难度 | 主要阻力 |
|---|---|---|---|
| 人 | 控制台口令、跳板机账号 | 中 | 依赖个人习惯，改完要通知 |
| 服务 | 数据库口令、内部 API token | 低到中 | 需要双版本并存窗口 |
| CI | 部署凭证、镜像仓库 token | 中 | 流水线缓存与并发任务 |
| 第三方 | 支付、短信、云厂商 AK | 高 | 对方审批周期不受控 |
难度差异不在技术，而在"你能不能单方面决定"。第三方密钥的轮换节奏由对方控制，所以对它要做的是并行准备与降级预案，而不是排一个季度计划就认为搞定。
3. 频率的依据是暴露概率与爆炸半径
| 场景 | 暴露概率 | 爆炸半径 | 合理节奏 |
|---|---|---|---|
| 长期不变的数据库口令 | 中（配置、备份、镜像里都可能留存） | 全库读写 | 半年，且随人员变动立即换 |
| CI 部署凭证 | 高（日志、工单里常被贴出） | 可发布任意版本 | 季度 |
| 第三方支付密钥 | 低（不落地本地） | 资金与对账 | 按对方要求，配合自己的复核 |
| 内部服务 token | 低 | 单个内部接口 | 年度或随架构变更 |
频率不该从合规条文倒推。合规只给下限，真正决定节奏的是两件事：这个密钥在多少地方留下过副本，以及它失效时谁会疼。把这两件事写进清单，频率自然有依据。
4. "换过了"的证据
轮换最难的部分不是执行，而是证明。一次可被审计的轮换至少留下三个时间点：
─── 证据三元组：缺一个就无法证明换过 ───
新密钥生效时间 2026-08-14T02:10:00+08:00
旧密钥失效时间 2026-08-21T02:10:00+08:00 // 并存窗口一周
调用方零报错窗口 2026-08-14 ~ 2026-08-21 // 这段时间内无鉴权失败
这三个时间点必须来自系统记录，不能来自人的口述。判断标准很直接：如果只能拿出"我们换过了"，而拿不出旧密钥在哪一刻失效，那这次轮换在审计意义上没有发生。
─── 从调用侧找反例：并存窗口内的鉴权失败次数应为零 ───
grep -c 'AUTH_FAILED' /var/log/order-api/*.log // 窗口内的计数
awk '/AUTH_FAILED/ {print $1}' app.log | sort | uniq -c // 按天看是否集中在切换当天
5. 三类轮换方案与可用性代价
| 方案 | 机制 | 可用性代价 | 适用 |
|---|---|---|---|
| 双密钥并存 | 新旧同时有效，逐步迁移 | 几乎为零，但窗口内两把都能用 | 大多数场景的默认选择 |
| 热切换 | 系统推送新值，进程热加载 | 取决于实现，可能有个别实例读旧值 | 有配置中心与热加载能力时 |
| 停机切换 | 停服、改配置、起服 | 一次明确的中断 | 无热加载、调用方不可控时 |
双密钥并存的代价常被忽略：并存窗口越长，泄露面越大。窗口该由"调用方全部迁移所需时间"决定，而不是"留一周比较保险"。
6. 失败最常见的原因：调用方不知道要换
─── 轮换失败的典型顺序 ───
1) 平台侧生成新密钥
2) 平台侧更新自己持有的配置
3) 旧密钥被禁用
4) 某个只读服务仍在用旧值 → 开始 401
5) 排查方向变成"服务挂了"，而不是"密钥换了"
根因是消费者清单不全：清单里写了 consumers，但漏了那个"临时加过一个只读副本"的服务。所以轮换前的第一件事不是生成新密钥，而是核对谁在调用——这个动作在密钥管理系统之外，只能从访问日志或网关侧拿。
─── 用访问侧反查消费者，而不是依赖人工登记 ───
grep -oE 'client_id=[a-z0-9-]+' gateway-access.log | sort | uniq -c | sort -rn
7. 密钥散落的位置与清理顺序
| 位置 | 常见形态 | 清理顺序 |
|---|---|---|
| 环境变量 | 容器 env、systemd unit | 随部署调整，先改这里 |
| 配置文件 | yaml、properties、ini | 与环境变量同批 |
| 镜像层 | 构建期 COPY 进去的 | 重建镜像，不能只删文件 |
| 日志 | 启动时打印的完整连接串 | 先停打印，再清历史 |
| 工单与聊天记录 | 排障时贴出的凭证 | 走归档与访问限制，无法删除 |
清理顺序的原则是"先止血再清创"：先让新的泄露不再产生（停止打印、停止贴群），再去处理已经存在的副本。反过来做，清完历史副本后下一次排障又会贴一遍。
8. 吊销与轮换不是一件事
| 动作 | 触发 | 目标 | 副作用 |
|---|---|---|---|
| 吊销 | 已确认或高度怀疑泄露 | 立刻切断 | 可用性可能瞬间归零 |
| 轮换 | 计划内 | 缩小暴露窗口 | 需要迁移窗口 |
把吊销当轮换用，会在应急时忘了并存窗口，导致服务直接全断；把轮换当吊销用，则会以为"换了就安全了"，但旧密钥在并存窗口内仍然有效。应急时正确的顺序是：先吊销、再按轮换流程补一把新的，两件事分开做。
9. 编排：谁发起、谁批准、谁执行、谁验证
| 角色 | 职责 | 不该由谁兼 |
|---|---|---|
| 发起 | 按清单与到期时间提出轮换 | 不应由唯一持有者发起（他可能不在） |
| 批准 | 确认窗口与影响面 | 不应由执行者自批 |
| 执行 | 生成、下发、切流 | 不应同时负责验证 |
| 验证 | 核对新旧生效时刻与零报错 | 不应是执行者本人 |
四人分工在小团队里通常压到两人，这时至少要保持"执行"与"验证"分离——验证是唯一能发现"以为换了其实没换"的环节。
// 轮换工单：把四个角色写成字段，缺字段就不允许开始
rotation_ticket:
secret_id: db-order-primary
initiated_by: platform-sre
approved_by: team-order-platform
executed_by: platform-sre
verified_by: team-order-platform
window: 2026-08-14T02:00+08:00/2026-08-21T02:00+08:00
rollback: 保留旧版本至窗口结束
10. 第三方密钥无法轮换时的替代手段
| 手段 | 作用 | 代价 |
|---|---|---|
| IP 白名单 | 缩小可用来源 | 出口 IP 变化时要同步 |
| 二次鉴权 | 拿到密钥也不能直接用 | 多一次调用与延迟 |
| 频次上限 | 限制泄露后的破坏速度 | 需要按业务定阈值 |
| 独立子账号 | 把爆炸半径切小 | 管理成本上升 |
这些手段都不改变"密钥可能泄露"这个事实，它们改变的是泄露之后的速度与范围。当对方不给轮换能力时，这是唯一能做的事，且必须写进清单而不是留在口头约定里。
11. 度量
| 指标 | 看什么 | 参考方向 |
|---|---|---|
| 清单覆盖率 | 已登记密钥占实际使用之比 | 应接近全量 |
| 平均密钥年龄 | 距上次轮换的时长 | 不应超过设定节奏 |
| 轮换成功率 | 一次成功、无需回滚的比例 | 应随流程成熟上升 |
| 暴露后处置时长 | 从发现到吊销完成的耗时 | 分钟到小时量级 |
前两个是常态指标，后两个是应急指标。只看年龄会诱导"为了达标而换"，不看处置时长则会在真出事时才发现流程跑不通。
12. 排错：轮换卡住的常见形态
| 现象 | 原因 | 处理 |
|---|---|---|
| 换完立刻 401 | 消费者清单漏了调用方 | 从网关日志反查，补齐清单 |
| 不敢换 | 没有回滚路径 | 先做并存窗口，旧版本保留到窗口结束 |
| 换了但审计不认 | 只有执行记录，没有生效与失效时刻 | 补三个时间点，写进工单 |
| 同一把密钥反复出现 | 副本散落在镜像与工单里 | 先停打印，再清副本 |
| 第三方迟迟不批 | 对方审批周期长 | 提前一个周期发起，配降级预案 |
13. 边界：什么时候这套机制收益很低
| 条件 | 可简化到什么程度 | 理由 |
|---|---|---|
| 无状态、无长期凭证的架构 | 只保留清单与归属，不做定期轮换 | 短期凭证本身就在高频更换 |
| 单机内部服务 | 可简化流程，但不能无归属 | 出事时仍要有人能改 |
| 密钥从不离开进程内存 | 降低频率，保留应急吊销 | 暴露面本来就窄 |
反过来，只要存在"密钥被写进配置文件并分发到多台机器"这种情况，清单与归属就是必需项。轮换频率可以谈，归属不能谈。
14. 自测
- 为什么"密钥清单"是体力活，"归属"却是组织问题？
- 一次轮换要留下哪三个时间点，缺了哪个就无法证明换过？
- 双密钥并存的窗口该由什么决定，而不是由"留一周比较保险"决定？
- 为什么轮换失败最常见的根因是调用方清单不全，而不是密钥生成出错？
- 吊销与轮换在应急时为什么要分开做？
- 在无状态、无长期凭证的架构下，轮换机制还剩哪些不可省的部分？