4. KMS密钥轮换：自动轮换策略、手动轮换场景、轮换对现有加密数据的影响

密钥轮换，说白了就是定期换锁。你想想看，一把锁用久了，总归有被破解的风险。云上的密钥也一样，虽然KMS底层做了大量保护，但安全最佳实践还是建议我们定期轮换。

这一章，我主要跟你聊聊轮换的两种玩法——自动和手动，以及轮换之后那些老数据怎么处理。这些都是我在生产环境里踩过的坑，希望能帮你少走弯路。

4.1 自动轮换策略：让系统帮你干活

我个人习惯，能用自动轮换的场合，绝不动手。KMS的自动轮换很省心，你配置好周期，剩下的交给系统。

自动轮换的核心逻辑：

• KMS会为你的CMK创建新版本（Key Version），旧版本保留。
• 加密时默认使用最新版本。
• 解密时，KMS会自动识别数据是用哪个版本加密的。

配置自动轮换（以AWS KMS为例）：

# 启用自动轮换
aws kms enable-key-rotation --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
# 检查轮换状态
aws kms get-key-rotation-status --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

轮换周期：AWS默认是每年一次。你可以用CloudWatch Events自己写定时任务，实现更灵活的周期。

我记得有一次，客户要求每90天轮换一次。嗯，AWS默认不支持改周期，我们就用了Lambda+EventBridge，每个月触发一次手动轮换。说白了，自动和手动结合才最灵活。

4.2 手动轮换场景：什么时候必须自己来？

自动轮换虽然好，但有些场景你必须亲自上手。我在项目中遇到过以下几种情况：

场景	说明	处理方式
合规要求	审计要求立即轮换，不等自动周期	立即创建新CMK，更新应用配置
密钥泄露风险	怀疑密钥被滥用	立即禁用旧密钥，创建新密钥
跨区域迁移	需要把密钥复制到其他区域	手动创建CMK，迁移数据后重新加密
版本回退	新密钥出问题，需要回滚	重新启用旧版本（如果未删除）

手动轮换的标准流程：

1. 创建新CMK：用全新KeyId，别试图复用旧ID。
2. 更新应用配置：把KeyId换成新的。
3. 保留旧CMK：别急着删，旧数据还需要解密。
4. 逐步迁移数据：用新密钥重新加密旧数据。
5. 清理旧密钥：确认所有数据都迁移完后，再禁用并删除旧CMK。

4.3 轮换对现有加密数据的影响

这个点，我觉得是本章最重要的。很多人以为轮换后旧数据就自动解密不了，其实不是。

对称加密：

• 轮换后，旧版本CMK还在，解密不受影响。
• 但加密新数据会使用新版本。
• 旧数据卷，如果不重新加密，就会一直绑着旧版本。

非对称加密：

• 私钥轮换后，旧私钥依然可以解密。
• 公钥轮换后，新数据用新公钥加密，旧数据用旧私钥解密。
• 签名验证也不受影响，新旧公钥都保留。

4.4 密钥轮换的生命周期管理

为了让你更直观地理解，我画了一张图。这张图展示了密钥从创建、轮换到退役的完整流程。

4.5 轮换策略的选择建议

不同场景用不同策略，我整理了一个参考表：

业务场景	推荐策略	轮换周期	备注
通用数据加密	自动轮换	1年	省心，安全基线
金融/医疗	自动+手动结合	90天	合规要求高，手动应对紧急情况
核心数据库加密	手动轮换+维护窗口	按需	避免自动轮换影响读写性能
临时测试密钥	手动轮换	每次测试后	用完就换，避免遗留

为什么金融行业要用90天？我举个例子。你去银行办业务，银行柜员的系统密码是90天一换的。密钥轮换也是一样，缩短周期可以降低单个密钥泄露带来的影响范围。