密钥轮换：为什么必须做，以及它的底层逻辑

咱们直接进入正题。密钥轮换，说白了就是定期换一把锁。

我记得刚接触云安全那会儿，有个客户问我：“我的密钥又没泄露，为啥要换？” 这个问题问得挺实在的。后来我陪他们重建了一次事故环境才想明白——密钥轮换不是为了解决“已经泄露”的问题，而是为了控制“万一泄露”的损失。

2.1 为什么非做不可？

你想想看，一把密钥用得越久，它加密的数据就越多。一旦泄露，所有数据都完蛋。这不是理论推演——我在项目中遇到过不止一起因为长期未轮换密钥导致的数据泄露事件。

具体来说，轮换解决三个核心问题：

• 缩小攻击面：每把密钥都有生命周期。轮换就是把有效窗口从“无限”压缩到“可接受范围”。
• 满足合规要求：PCI DSS、SOC 2、GDPR 等标准都明确要求定期轮换。我见过甲方被审计时因为没有轮换记录直接扣分。
• 应对密码学风险：算法会变弱，密钥可能被暴力枚举。定期换新能让旧密钥自然失效。

2.2 什么时候该轮换？

轮换不是瞎换。我通常把触发条件分成两类：

类型	触发条件	实际操作
定期轮换	按时间周期，比如 90 天、180 天、365 天	写进 CI/CD 流水线，定时触发
事件驱动轮换	可疑访问、人员离职、泄露怀疑、合规审计命令	立即执行，配合告警系统自动判定

我这里要强调一点：定期轮换是底线，事件驱动轮换是应急。 我在客户环境里见过只做定期不做事件的——结果某天有个员工的 Access Key 被提交到了 GitHub 公开仓库，等定期轮换周期到还要 50 天……那中间就是敞开的窗口期。

2.3 轮换的核心流程

轮换听起来简单——删旧的，加新的。但在 AWS KMS 里，你还有两种模式可选：自动轮换和手动轮换。咱们先看核心流程：

1. 生成新密钥：KMS 自动创建新的加密密钥材料。
2. 标记旧密钥：保留旧密钥，但标记为“已弃用”或“仅解密”。
3. 切换使用：所有新加密请求指向新密钥。
4. 迁移数据（如果需要）：用新密钥重新加密旧数据（这个很费劲，但有时必须做）。
5. 淘汰旧密钥：确认无依赖后删除或禁用。

这五步里，第 4 步是最容易被忽略的。我接手过一个项目，轮换做了三年，但核心数据库的列级别加密还是用的第一代密钥——相当于外面换了新锁，但屋里还挂着旧锁。嗯，这个坑咱们后面章节会专门讲怎么避免。

2.4 核心概念：密钥版本

在 KMS 里，一次轮换本质上就是创建了一个新的密钥版本。你可以理解成一把物理钥匙在不同时间点的复制品。

• 密钥 ID：唯一标识一个 KMS key，轮换了 ID 不变。
• 密钥版本 ID：每轮换一次就变一次。你加密数据时，KMS 会在密文里自动带上版本 ID。
• 默认密钥：当前用于加密的版本。
• 旧版本：只用于解密，不能用于加密。

我经常跟团队说一句话：“密钥不轮换是在赌博，轮换了不跟踪版本是在裸奔。” KMS 自动帮你管理版本，但你得知道哪些数据是哪个版本加密的。

2.5 手动 vs 自动轮换：选哪个？

AWS KMS 支持两种方式。我直接给你对比表：

维度	AWS 托管密钥（自动轮换）	客户管理密钥（手动轮换）
轮换频率	每年一次（固定，不能修改）	自己定，天级或小时级都行
控制粒度	低，不能选择版本保留策略	高，能控制版本数量和保留时间
配置难度	简单，勾选启用就行	需要脚本、流水线、权限管理
适用场景	无特殊合规要求的通用场景	金融、医疗、政府等高要求场景

我个人习惯是：能用自动的先用自动，因为省心。但遇到合规要求更高的环境，比如 PCI DSS 要求 90 天轮换一次，那就必须上手动。 自动轮换的“一年一次”在很多审计眼里是不够的。

2.6 本章核心逻辑图

下面这张 SVG 把本章的知识点串在了一起，你可以把它当成自己的“轮换决策脑图”。

2.7 总结几条硬经验

最后我给你三条我踩过坑之后的经验，希望你直接存下来：

• 轮换周期别拍脑袋定：先评估你的数据敏感等级，再结合合规要求。金融行业 90 天算常规，电商 180 天也行，开发环境一年都过得去。
• 别在轮换期间关掉 CloudTrail 审计：我见过有人在轮换脚本里不小心关掉了日志，结果出了事查不到是哪个版本密钥出问题。
• 做轮换演练：别等到生产事故了才试。至少每季度在测试环境跑一次完整的轮换流程，包括验证新密钥生效、旧密钥退役、服务无中断。