为什么密钥轮换不是可选项
在现代分布式系统中，服务之间的通信几乎都依赖加密机制。比如用户登录后，系统生成一个令牌（Token），这个令牌背后可能就用到了某个密钥进行签名。如果这个密钥长期不变，一旦被泄露，攻击者就能伪造身份，后果不堪设想。这就像你家的钥匙借给了别人，多年没换锁，谁都能进来。
密钥轮换的本质，就是定期更换这些“数字钥匙”，把潜在风险控制在最小范围。尤其在微服务架构下，几十个服务之间频繁调用，任何一个环节的密钥出问题，都可能波及整个系统。
轮换策略怎么定
常见的做法是设定固定周期，比如每30天自动轮换一次。但也不能太频繁，否则运维成本高，还可能引发服务间认证失败。更灵活的方式是结合使用时长和访问频率动态调整。例如某个API密钥在过去一周被调用了上百万次，系统可以标记为“高风险”，提前触发轮换。
Google Cloud 和 AWS 都提供了密钥管理服务（KMS），支持自动轮换。以 AWS 为例，你可以为 KMS 密钥启用自动轮换来：
{
"KeyPolicy": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"Service": "kms.amazonaws.com"},
"Action": "kms:EnableKeyRotation",
"Resource": "*"
}
]
}
}轮换过程中的兼容性处理
新密钥生成后，旧密钥不能立刻作废。因为分布式环境中，不同服务的更新节奏不一致，有的可能还在用老密钥解密数据。这时候需要一个“过渡期”，让新旧密钥并存。
JWT 令牌就是一个典型场景。服务A签发的JWT，服务B负责验证。如果A换了密钥，而B还没同步，验证就会失败。解决办法是在配置中保留多个公钥，按kid（密钥ID）区分：
-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwJ...\n-----END PUBLIC KEY-----
# kid=pubkey-2024-08
-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxK...\n-----END PUBLIC KEY-----
# kid=pubkey-2024-09每次签发时带上kid，接收方根据ID选择对应公钥验证，平滑过渡。
实际落地的小技巧
某电商平台在做支付网关升级时，采用了双阶段轮换。第一阶段先将新密钥推送到所有节点缓存，但不启用；第二阶段通过配置中心统一开关切换生效时间。这样避免了因网络延迟导致部分节点拿不到新密钥的问题。
另一个常见问题是密钥存储位置。别把密钥写死在代码或配置文件里。应该使用专门的密钥管理工具，比如 Hashicorp Vault。启动服务时动态拉取，运行期间定期刷新。
轮换完成后，记得清理旧密钥。很多安全事故源于“以为已经禁用”的密钥仍然有效。可以在监控系统中设置告警，发现某密钥连续7天无调用，就自动归档。