1. 凭据轮换概述
1.1 什么是凭据轮换
凭据轮换，说白了就是定期换掉你的「钥匙」。 不管是数据库密码、API 令牌还是 SSH 密钥，用久了就该换。你想想看，你家门锁半年不换，万一有人配了把钥匙呢？系统凭据也一样。
我最早接触轮换是因为一个合规审计项——PCI DSS 要求每 90 天换一次数据库密码。当时觉得真麻烦，后来才明白，这是最朴素的防线。
核心定义：凭据轮换是指按预定周期或事件触发，用新凭据替换旧凭据，并确保旧凭据立即失效的过程。
1.2 为什么需要自动轮换
手工轮换？我曾经在某金融项目里干过一晚上换 37 个数据库密码的事。凌晨三点，手抖输错一个字符，生产库直接连不上…… 嗯，从那以后我坚决推自动轮换。
- 降低泄露风险：凭据在野存活时间越短，被利用的可能性越低。
- 满足合规要求：SOC 2、ISO 27001、PCI DSS 都要求定期轮换。
- 减少人为失误：手工轮换漏一个服务就出事故，我见过太多次了。
- 应急响应提速：发现泄露后，一键触发轮换比跑机房改密码快太多了。
血的教训：不要以为凭据「没人知道」就不轮换。内部员工离职、代码仓库被扫、日志泄露…… 真出了问题再换就晚了。
1.3 常见凭据类型
不同的凭据有不同的轮换策略。我整理了一张对比表，帮你快速看清差异：
| 凭据类型 | 典型示例 | 轮换周期建议 | 轮换难度 |
|---|---|---|---|
| 云厂商 Access Key | 30~90 天 | 中 | |
| 数据库密码 | MySQL 连接密码 | 60~90 天 | 高（需协调应用） |
| JWT / OAuth 令牌 | 刷新令牌、访问令牌 | 按过期时间（通常 1h~24h） | 低（自动刷新机制） |
| SSH 密钥 | 服务器登录密钥对 | 180 天或人员变动时 | 中 |
| TLS 证书 | HTTPS 证书 | 90 天（Let's Encrypt）或 1年 | 低（ACME 自动续签） |
我的习惯：对于 ，我会设置 45 天自动轮换加 72 小时旧 Key 宽限期。这样既安全又避免应用因为缓存导致中断。
1.4 手工轮换的痛点
你可能会想：「我脚本写好了，定时跑不行吗？」告诉你，没那么简单。我在一个 SaaS 平台就踩过坑：
- 依赖链断裂：改了 A 服务的密码，B 服务还在用旧连接池，全报 401。
- 回滚困难：新凭据有问题，旧凭据已经删除，服务直接瘫了。
- 审计黑洞：谁换了？什么时候换的？手工操作基本靠喊。
说白了，手工轮换 + 多服务 = 事故预订。
1.5 自动轮换的核心逻辑
自动轮换不是简单「改个密码」，它是一条闭环链路。下面这张图是我经常用来和团队对齐的流程：
这个闭环有五个关键动作：
- 生成新凭据：随机、高熵、符合复杂度要求。
- 存储到安全仓库：比如 Vault、AWS Secrets Manager，而不是配置文件里硬编码。
- 部署到应用：通过 SDK 或 Sidecar 热加载，无需重启。
- 验证新凭据：用新凭据做一个真实请求，确认通顺。
- 回收旧凭据：确认新凭据生效后，立即删除或禁用旧凭据。
我的建议：在验证步骤加一个「宽限期」，例如让新旧凭据同时生效 5 分钟。很多轮换事故都是因为旧凭据还在连接池里，一回收就断。
1.6 自动轮换的技术方案对比
选工具这事，我用过的坑不少。给你一个快速对比：
| 方案 | 成本 | 适合场景 | 我踩过的坑 |
|---|---|---|---|
| 云原生服务（Secrets Manager） | 中等 | 全云上、无自建需求 | 跨账号轮换时权限配置复杂 |
| HashiCorp Vault | 较高 | 混合云、需要细粒度策略 | Initial rollout 容易忽略集群节点同步 |
| 开源脚本 + Cron | 低 | 小规模、快速实验 | 没有回滚机制，炸过两次 |
| 自定义 Sidecar | 高 | 遗留系统、专用协议 | Sidecar 版本与主服务兼容要命的 |
我个人的经验是：别一开始就上最重的方案。先用云服务跑起来，再慢慢演进。想一步到位？往往半年还在规划阶段。
注意：无论选哪种方案，一定要有「轮换失败时通知」的机制。我曾经在凌晨 3 点被轮换失败告警吵醒，那次是因为数据库主从延迟导致新密码没同步到从库… 嗯，后来加了 pre-check 环节。