密钥生命周期管理：每个阶段的审计事件
今天我们来聊聊密钥的生命周期。说白了，一个KMS密钥从诞生到销毁，就像一个人从出生到退休。每个阶段都会在CloudTrail里留下脚印。我最早学这个的时候，总觉得审计日志太琐碎，直到有一次被客户问“为什么这个密钥被删了？”——查日志才发现是运维脚本搞错了。从那以后，我再也不敢小看这些事件了。
密钥的“一生”：五个核心阶段
我们先画个简单的流程图，把密钥的整个生命周期串起来。你看看，是不是很清晰？
嗯，这图一看就明白。一个密钥从创建开始，之后就是各种状态切换。我习惯把它分成两个维度：状态变更和配置修改。状态变更就是启用、禁用、删除这些直接改变“生死”的操作；配置修改是轮换策略、标签、别名这些“调参”操作。审计事件都围绕它们转。
阶段一：创建密钥
这是所有故事的起点。CreateKey 事件会记录密钥的初始参数。我觉得最值得注意的是：创建时指定的 Origin（是AWS KMS内部生成，还是外部导入）和 KeyUsage（加密解密、签名验签等）——这两个参数一旦定下就不能改。
| 事件名称 | 主要字段 | 个人关注点 |
|---|---|---|
| CreateKey | keyId, origin, keyUsage, keySpec, tags | 记得看看IAM权限是否最小化 |
| ImportKeyMaterial | keyId, importToken, wrappedKeyMaterial | 检查导入的密钥材料是否来自可信源 |
Owner 标签，能省去不少扯皮。
阶段二：启用与禁用
启和禁用，说白了就是“拔掉钥匙”和“插回钥匙”。EnableKey 和 DisableKey 事件很简单，就记录个密钥ID和操作时间。但这里有个坑——我原来以为“禁用”就是彻底不能用，实际上它只是让密钥状态变成 Disabled。已经加密的数据还能解密吗？如果之前没有缓存数据密钥，解密就失败了。
| 事件名称 | 关键字段 | 说明 |
|---|---|---|
| EnableKey | keyId, requestParameters, responseElements | 启用后即可用于加密/解密 |
| DisableKey | keyId, requestParameters, responseElements | 禁用后不能用于加密，但已加密数据仍存在 |
阶段三：密钥轮换
轮换是密码学里的基本操作。AWS KMS支持自动轮换和手动轮换。我个人建议，对于长期使用的密钥，一定要开启自动轮换。EnableKeyRotation 事件会记录你开启或关闭了自动轮换。RotateKeyOnDemand 是手动轮换时触发的事件。
| 事件名称 | 事件来源 | 影响 |
|---|---|---|
| EnableKeyRotation | 控制台/API | 每年自动轮换一次 |
| DisableKeyRotation | 控制台/API | 停止自动轮换 |
| RotateKeyOnDemand | API（手动） | 立即创建新的密钥版本 |
这里要注意：轮换不会过期或删除旧材料。AWS KMS会保留所有历史版本，加密时默认用最新版本。你想想看，这设计多巧妙——既保证了数据安全，又不会导致旧数据无法解密。我曾在项目里遇到一个“密钥轮换后旧数据读不出来”的恐慌，后来发现是业务代码硬编码了密钥ID，而不是用别名。改用别名，世界就清净了。
RotateKeyOnDemand 的 sessionContext 和 sourceIPAddress，判断轮换操作是否来自预期的人员和机器。
阶段四：计划删除
删除是开弓没有回头箭。ScheduleKeyDeletion 会设置一个等待期（默认30天，可设为7-30天）。在这期间，密钥处于 PendingDeletion 状态。如果你后悔了，CancelKeyDeletion 可以取消删除，密钥恢复原状。
| 事件名称 | 附加信息 | 我的建议 |
|---|---|---|
| ScheduleKeyDeletion | pendingWindowInDays | 别设太短！至少留7天 |
| CancelKeyDeletion | 无特殊参数 | 操作前确认没有服务依赖 |
if key_state == 'PendingDeletion': then_check_dependencies()
阶段五：密钥过期（外部密钥材料）
如果你用的是导入的密钥材料（External key store 或 Custom key store），那就多了一个 过期 阶段。你导入时可以设置一个过期时间（24小时到365天）。到期后，密钥自动变成 Expired 状态，不再可用。这时会触发什么事件？嗯……其实没有单独的事件。
GetParametersForImport 拿到导入令牌，ImportKeyMaterial 导入材料——这些事件一起构成了“导入生命周期”。没有单独的 KeyExpired 事件。但 DescribeKey 返回的状态能告诉你它过期了。
| 相关事件 | 作用 | 注意事项 |
|---|---|---|
| GetParametersForImport | 获取导入令牌和公钥 | 令牌有24小时有效期 |
| ImportKeyMaterial | 导入加密后的密钥材料 | 可设置过期时间 |
| DeleteImportedKeyMaterial | 主动删除密钥材料 | 删除后密钥不可用 |
快速参考：生命周期审计事件全表
最后，我整理了一个总表。你把它收藏起来，查日志时对号入座就行。
| 阶段 | 核心审计事件 | 状态影响 | 个人标记 |
|---|---|---|---|
| 创建 | CreateKey, ImportKeyMaterial | Enabled | 🔑 检查密钥规格 |
| 启用 | EnableKey | 从 Disabled → Enabled | 🟢 确认依赖方就绪 |
| 禁用 | DisableKey | 从 Enabled → Disabled | 🔴 先排查依赖 |
| 轮换 | EnableKeyRotation, RotateKeyOnDemand | 无状态变化，创建新版本 | 🔄 检测是否自动开启 |
| 删除 | ScheduleKeyDeletion, CancelKeyDeletion | PendingDeletion → 临时保留 | ⚠️ 不要设0天等待期 |
| 过期 | （无单独事件，配合 DescribeKey） | Expired | ⏳ 导入材料注意时间 |
好了，密钥生命周期的审计事件就这些。你想想看，审计日志其实就是个“时间轴相机”，把每个阶段的动作都拍下来了。你只要学会看懂这些“照片”，密钥管理的任何风吹草动都逃不过你的眼睛。