4. 启用密钥自动轮转：控制台与CLI操作归纳总结
密钥轮转这事，说白了就是给加密材料安排「定期换岗」。手动换太累，还容易忘。我记得有次帮客户做安全审计，发现一把用了三年的 KMS 密钥从未轮转过——当时数据的加密周期长得吓人。从那以后，我养成了一个习惯：只要不是测试环境，能自动轮转就别手动。
这一节，我们把控制台和 CLI 两种方式都过一遍。你不需要记住所有按钮的位置，但得清楚配置背后的逻辑。
4.1 为什么要用自动轮转？
KMS 的自动轮转，不是把密钥本身换掉，而是生成一份新的加密材料（Ciphertext）。旧密钥的 ID 和元数据保留，只是底层材料变了。这意味着：
- 已有的密文仍然可以解密（老材料还在）
- 新加密的数据使用新材料
- 审计日志里能看到轮转事件
为什么要这么做？因为合规要求越来越严。PCI DSS、SOC 2、FedRAMP 这些标准，几乎都要求密钥轮转周期不超过一年。自动轮转就是帮你「无感合规」。
4.2 控制台操作：三步搞定
控制台操作比较直观，适合单次配置。我建议你按照这个顺序来：
- 找到目标密钥：进入 KMS 控制台，在「客户管理型密钥」列表里选中你要配置的密钥。
- 打开轮转配置：在密钥详情页，找到「密钥轮转」标签页，点击「编辑」。
- 设定周期并保存：勾选「启用自动轮转」，选择轮转周期（默认 365 天，部分密钥类型支持 90/180 天），点「保存」。
配置完成后，你可以在「密钥轮转」页签里看到下一次轮转时间和历史轮转记录。每次轮转都会在 CloudTrail 中生成一条 RotateKey 事件。
4.3 CLI 操作：批量自动化
如果你管理几十个账号或上百把密钥，点控制台会点到手抽筋。CLI 才是正经用法。
先看看基础命令：
# 启用自动轮转（周期默认 365 天）
aws kms enable-key-rotation --key-id arn:aws:kms:us-east-1:123456789012:key/abc12345-...
# 查看轮转状态
aws kms get-key-rotation-status --key-id arn:aws:kms:us-east-1:123456789012:key/abc12345-...enable-key-rotation 不支持自定义周期。如果你想改周期（比如 90 天），必须用 rotate-key-on-demand 配合 --rotation-period-in-days 参数。
批量操作时，我喜欢写个简单脚本：
# 列出所有客户管理型密钥，逐个启用轮转
for key in $(aws kms list-keys --query 'Keys[].KeyId' --output text); do
aws kms enable-key-rotation --key-id "$key"
echo "已启用: $key"
done这个脚本跑一遍，所有密钥就自动轮转了。嗯，这里要注意：过滤掉托管型密钥。怎么过滤？用 list-keys 的 --filter 参数：
aws kms list-keys --filter "key-manager-type=CUSTOMER_MANAGED"4.4 轮转后的审计日志长什么样？
这是很多人忽略的点。你配置了轮转，但审计系统如果没识别到对应的日志，等于白配。
一次成功的自动轮转，会在 CloudTrail 中生成这样一条记录：
| 字段 | 值示例 |
|---|---|
eventName |
RotateKey |
eventSource |
kms.amazonaws.com |
requestParameters.keyId |
arn:aws:kms:us-east-1:123456789012:key/abc12345-... |
responseElements.keyRotationEnabled |
true |
responseElements.rotationPeriodInDays |
365 |
你会看到 eventName 是 RotateKey，而不是 CreateKey。这是区分「轮转」和「新建」的关键指标。我在做审计报告时，经常写一条查询语句专门抓这个事件：
# 查询过去 7 天的自动轮转事件
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=RotateKey \
--start-time $(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ')4.5 控制台 vs CLI：怎么选？
我干了这么多年，经验是这样的：
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 单把密钥快速配置 | 控制台 | 可视化，不容易出错 |
| 批量操作（10+ 密钥） | CLI + 脚本 | 省时间，可重复执行 |
| 集成 CI/CD 流水线 | CLI + IaC（如 Terraform） | 可审计、可回滚 |
| 需要自定义轮转周期 | CLI (rotate-key-on-demand) |
控制台不支持自定义 |
4.6 避坑指南：轮转后别忘了检查
配置完不是终点。我在项目里遇到过好几次：轮转配置是开了，但实际 CLoudTrail 里一条日志都没有。问题出在哪？
- 权限不足：KMS 的轮转需要
kms:RotateKeyOnDemand权限，如果 IAM 策略里没写，CLI 会静默失败。 - 密钥状态不对：处于
PendingDeletion或Disabled状态的密钥，不会触发轮转。 - 跨区域误区：自动轮转只影响当前区域的加密材料。如果你的密钥是多区域副本，每个区域需要单独配置。
我曾经因为忘了检查 CloudTrail 日志，导致客户的审计报告里出现了三个月的轮转空窗期。嗯，从那以后我养成了个习惯：配置轮转的当天，手动查一次日志。
4.7 本章知识体系
下面这张图概括了「启用自动轮转」的完整逻辑：从配置触发，到 KMS 内部处理，再到审计日志产出，最后是管理员验证。你品品这个流程。
4.8 小结
自动轮转不是什么黑科技，但配置不当会留下审计漏洞。你记住几个要点：
- 控制台适合「点一下就跑」的场景
- CLI 适合「批量+自动化」
- 配置完务必查 CloudTrail 日志
- 托管型密钥别碰，碰了也没用
后面几节我们会深入审计日志的具体字段和查询技巧。但这一节的内容，我建议你立刻动手试一下——在非生产环境里开一把密钥的自动轮转，然后去 CloudTrail 看一眼。亲身验证过的知识，比看十遍文章都牢靠。