为什么需要做密钥轮换
想象一下你家的钥匙丢了，虽然不确定有没有人捡到，但最稳妥的做法肯定是换锁。系统中的密钥也是一样。长期不更换的密钥一旦泄露，攻击者就能冒充合法身份访问资源。定期轮换密钥，就像定期换锁，能有效降低长期暴露带来的风险。
尤其在微服务架构中，服务之间频繁通过密钥认证通信。某个服务密钥被窃取，可能引发连锁反应。所以密钥轮换不是“有空再做”，而是运维日常必须项。
常见密钥轮换策略
轮换不是简单删旧建新。直接替换会导致正在运行的服务中断。推荐使用“双密钥并行”模式：先添加新密钥，让系统同时接受新旧密钥；等所有客户端都切换到新密钥后，再移除旧密钥。
比如你在用 AWS 的 KMS 服务，可以先生成新版本的密钥，更新应用配置指向新密钥 ID，等确认所有请求都走新密钥后，再将旧版本设为禁用。
以 JWT 签名密钥为例
假设你的 Web 应用用 RSA 密钥对签发 JWT。轮换时，先生成一对新的公私钥：
ssh-keygen -t rsa -b 2048 -f jwt-new-key -N ""把新的公钥（jwt-new-key.pub）部署到验证端，比如网关或认证中间件。应用继续用旧私钥签发 token，但验证时优先尝试新公钥，失败再用旧公钥兜底。
等所有客户端刷新登录、拿到新签发的 token 后，逐步切到只用新公钥验证。这时就可以下线旧私钥了。
自动化轮换实践
手动轮换容易遗漏，建议结合工具自动化。比如用 Hashicorp Vault 管理密钥生命周期：
vault write /transit/keys/jwt-key/config auto_rotate=true rotation_period=72h这行命令设置密钥每 72 小时自动轮换一次。Vault 会保留历史版本，确保旧 token 还能验证，直到过期。
如果你用 Kubernetes，可以把密钥存进 Secret，配合 Operator 监听轮换事件，自动滚动重启相关 Pod，实现无缝切换。
轮换中的注意事项
别忘了通知依赖方。比如你负责的 API 密钥轮换了，调用方没同步就会报错。可以通过邮件、公告或在响应头里加个 X-Next-Key-ID 提前预告。
日志要记录轮换动作。某天出问题，查日志发现密钥刚换过，排查方向就清晰多了。另外，旧密钥别急着删，留几天缓冲期，防止某些延迟请求失败。
最后，测试环境先跑一遍流程。生产环境一敲回车，可没法 Ctrl+Z 撤销。