4、KMS支持的审计事件类型：密钥创建、密钥轮换、密钥删除、密钥使用、密钥导入
聊KMS审计日志，最核心的事就是搞明白它到底能审计什么。说白了，就是哪些操作会被记录下来，被你事后翻查。
我个人把KMS支持的审计事件归纳成五大类。这五类几乎覆盖了密钥生命周期的所有关键动作。你想想看，一把密钥从生到死，中间经历轮换、被调用、被导入，每一环都得留下痕迹。下面我一个一个说。
4.1 密钥创建（CreateKey）
这是所有故事的起点。你调用KMS API去生成一把新的密钥，无论是对称的AES密钥，还是非对称的RSA/ECC密钥对，都会触发这个事件。
审计日志里会记录什么？
- 谁干的：调用者的IAM身份（用户ID或角色ARN）
- 从哪干的：源IP地址、客户端代理信息
- 干了什么：API名称（CreateKey）、请求参数（密钥类型、用途、描述）
- 结果：成功/失败、返回的KeyId
- 时间戳：精确到毫秒的UTC时间
4.2 密钥轮换（RotateKey / EnableKeyRotation）
密钥轮换是个好东西，但不做审计，你根本不知道它有没有真的执行成功。我记得有个朋友跟我抱怨过，说他开了自动轮换，结果发现轮换配置错了参数，三年没换过一次。嗯，审计日志就能揪出这种低级错误。
轮换事件分两种：
| 事件名称 | 触发场景 | 典型错误码 |
|---|---|---|
EnableKeyRotation |
开启/关闭自动轮换策略 | AccessDenied（权限不足） |
RotateKey |
手动执行一次轮换（或自动轮换触发） | KeyStateInvalid（密钥状态异常） |
正确的做法是：轮换前先查一次密钥状态，确认它确实“活着”并且“能用”。
4.3 密钥删除（ScheduleKeyDeletion / CancelKeyDeletion）
这是我最关注的审计事件，没有之一。密钥删除是不可逆的，一旦删除，所有用它加密的数据就再也解不开了。所以KMS设计了一个“软删除”机制——你先调度删除，进入一个等待期（通常是7-30天），期间可以取消删除。
审计日志在这时会记录两条重要的时间线：
- 调度删除事件：记录谁提交了删除请求、删除等待期天数、预计执行时间。
- 取消删除事件：如果你在等待期内后悔了，取消操作也会被详细记录。
ScheduleKeyDeletion事件设置实时告警。一旦触发，立刻发通知给安全负责人。因为密钥删除经常是误操作，或者是恶意内部人员的破坏行为。“快一步阻止，胜过事后找备份。”
4.4 密钥使用（Encrypt / Decrypt / Sign / Verify / GenerateDataKey）
这是日常调用最频繁的一类。你的应用每调用一次KMS做加解密或签名验证，就会产生一条审计日志。
但有个容易忽略的点：密钥使用日志的数据量可能极其庞大。例如一个高并发的在线支付系统，每秒可能调用上千次加密操作。如果你把所有调用日志都保存到同一个地方，存储成本和查询效率都会出问题。
我通常建议的做法是：
- 对普通使用事件（成功调用）做采样记录，比如每天只保存10%的样本。
- 对异常使用事件（解密失败、权限拒绝、密钥不存在）做全量记录。
4.5 密钥导入（ImportKeyMaterial）
嗯，这里要注意。密钥导入虽然需求场景多（比如把本地生成的密钥迁到KMS），但在审计层面它是个“高危操作”。为什么？
- 你可以导入外部密钥材料，这就意味着密钥的“真身”曾经脱离过KMS的安全边界。
- 一旦导入，KMS无法保证这颗密钥从未被泄漏过（比如导入前在网络传输中被截获）。
所以审计日志里，导入事件必须额外记录：
| 字段 | 说明 |
|---|---|
WrappingAlgorithm |
导入时使用的密钥包装算法（RSA_OAEP等） |
KeyMaterialOrigin |
密钥材料的来源标记（固定为EXTERNAL） |
ValidTo |
导入密钥材料的过期时间（如果设置了的话） |
WrappingAlgorithm，导致后续审计时无法确认密钥导入时是否用了足够强度的加密算法。结果合规审查没过，返工了整整两周。所以我建议，导入密钥时一定要记录完整的请求参数，特别是算法类型和过期时间。这些信息是合规审查的硬通货。
五类事件一览与全局流程
为了让你一眼看清它们的关系，我画了一张图。这张图展示了审计事件从“产生”到“归档”的全链路。你会发现，所有事件最终都汇聚到同一个日志管道里，但不同类型的事件在风险等级和保留策略上是有差异的。
这张图把刚才讲的五类事件串了起来。你可以看到，所有操作请求先到达KMS API层，API层完成鉴权和处理后，根据操作类型生成对应的审计事件，最终全部写入统一的审计日志管道（比如AWS的CloudTrail或阿里云的ActionTrail）。注意右下角的说明框——我特意标了，删除事件和导入事件在整个流中风险等级最高，建议你优先为它们设置告警。
小结一下这五类事件的差异
用一张表来收尾，帮你快速对比这五类事件的关键属性：
| 事件大类 | 审计必含字段 | 风险等级 | 推荐保留策略 |
|---|---|---|---|
| 密钥创建 | KeyId, KeySpec, 调用者身份 | 中 | 长期保留（至少1年） |
| 密钥轮换 | KeyId, RotationConfig, 启动时间 | 低 | 保留至下次轮换成功后 |
| 密钥删除 | KeyId, PendingWindowInDays, 操作者 | 极高 | 永久保留 + 实时告警 |
| 密钥使用 | KeyId, Algorithm, 调用次数（采样） | 低（正常）→ 高（失败） | 采样保留，失败日志全量保留 |
| 密钥导入 | KeyId, WrappingAlgorithm, KeyMaterialOrigin | 高 | 永久保留（合规审查必须） |
到这里，你应该对KMS能审计什么有了清晰的认知。接下来配置审计规则时，就能针对不同类型的事件设置不同的处理方式了。