密钥轮换既要让泄漏的旧凭据失效，也要确认合法服务已切到新凭据。先列出使用者、权限和撤销能力，按服务风险安排切换；只在配置文件换值而不撤销旧密钥，可能没有结束泄漏窗口。
界定泄漏的具体秘密
区分数据库密码、应用程序密码、DNS API令牌和外部邮件服务密钥，它们的撤销入口与影响不同。记录秘密的标识和用途，不复制完整值进入调查文档。查询日志、版本库和备份中是否还有副本，明确需要处理的暴露范围。
绘制所有调用依赖
列出生产、测试、计划任务、CI脚本和人工工具使用同一凭据的位置。某个站点切换成功，不代表定时同步或灾备脚本已经更新。共享密钥增加轮换影响，今后应按服务拆分并限制必要权限。
选择可控的切换顺序
若服务支持新旧凭据并行，可先配置并验证新密钥，再尽快撤销旧密钥；高风险正在滥用时可能需要先撤销并接受短暂停机。按实际产品能力决定，不能假定所有服务都支持无缝双密钥。回退也不能恢复已经确认泄漏的秘密。
验证正反两条访问
用受控请求确认新凭据仅完成预期操作，旧凭据明确失败，相关任务下一周期仍正常。清理临时明文文件与不必要副本，但保留不含秘密值的轮换记录。对无法撤回的公开历史副本如实记录，不能把删除当前页面当作旧密钥失效。
关键区别
新密钥：恢复合法调用；限制必要权限。
旧密钥：结束泄漏窗口；必须确认撤销。
依赖清单：覆盖全部使用方；包括定时与测试。
怎样确认处理到位
新凭据在所有必要位置正常工作，旧凭据无法继续使用，权限与调用记录符合预期，临时副本处理有记录。
容易误判的边界
业务恢复不等于秘密已经撤销，删除泄漏文件也不等于外部副本消失；不要将已泄漏值当作恢复方案。
