📚 课程目录第4章 KMS关键操作日志

4. KMS 关键操作日志：密钥创建、启用、禁用、轮换、删除的日志特征

日志审计这活儿，说白了就是跟记录打交道。我做了十来年KMS审计，最怕看什么？不是日志量大，而是日志记录不准。密钥从生到死的每个动作，都得在日志里留下清晰的脚印。今天咱就聊聊最常见的五个操作：创建、启用、禁用、轮换、删除。

你想想看，一个密钥的生命周期管理，如果连操作日志都查不清楚，那安全评估基本就是走过场。嗯，咱们一个一个拆开看。

4.1 密钥创建（CreateKey）

密钥创建是所有后续操作的前提。日志里必须记录清楚：谁、什么时间、在哪个区域、创建了什么类型的密钥。

关键字段特征：

事件名称： CreateKey 或 KMS.CreateKey
请求参数： 密钥类型（对称/非对称）、密钥用途（ENCRYPT_DECRYPT / SIGN_VERIFY）、密钥规格（Aliyun_AES_256 / RSA_2048 等）
响应结果： 新生成的密钥ID（KeyId）、密钥ARN、创建时间戳
调用来源： 用户ID、角色ARN、调用方IP、UserAgent

我个人习惯在审计时特别关注 密钥规格 这个字段。曾经有客户创建了RSA_1024的密钥用于生产环境，这强度根本不够。日志里如果发现不合规的密钥规格，得立刻标记。

4.2 密钥启用与禁用（EnableKey / DisableKey）

这两个操作往往是成对出现的。禁用一个密钥，意味着所有依赖该密钥的加密解密操作都会失败。日志里必须能追溯到谁做的这个决定。

关键字段对比：

操作	事件名称	状态变化	风险点
启用	EnableKey	Disabled → Enabled	是否未经审批直接启用已废弃密钥
禁用	DisableKey	Enabled → Disabled	是否影响生产业务，是否有应急预案

避坑指南： 我曾经遇到一个案例：某运维人员禁用一个密钥后，依赖该密钥的微服务直接崩溃，导致业务中断2小时。日志显示，禁用操作前没有任何审批流程记录。所以，我要求审计时必须核对禁用操作的“审批号”或“工单号”字段是否为空。

4.3 密钥轮换（RotateKey / UpdateKeyRotationPolicy）

密钥轮换是安全领域的核心实践。但日志里往往藏着不少猫腻。你以为轮换了，实际上可能只是改了配置，旧密钥还在用。

有两种轮换方式，日志特征不一样：

自动轮换：
- 事件名称：通常是 UpdateKeyRotationPolicy
- 日志特征：记录轮换周期（如365天）、是否启用自动轮换
- 重点：是否真的产生了新密钥版本，需要查 ScheduleKeyDeletion 或 CreateKey 的关联日志
手动轮换：
- 事件名称：CreateKey + UpdateKeyAlias
- 日志特征：先创建新密钥，再把别名指向新密钥
- 重点：旧密钥是否被立即禁用或删除？如果不处理，那就是半吊子轮换

实战经验： 我记得有一次审计，看到日志里连续3年都有“UpdateKeyRotationPolicy”，但一查密钥版本列表，发现只有一个版本。这说白了就是“假轮换”。日志审计不能只看表面事件，要交叉验证密钥版本号。

4.4 密钥删除（ScheduleKeyDeletion / CancelKeyDeletion）

删除操作是最高风险动作。KMS一般设计为“软删除”，先安排删除计划，等待期过后才能彻底删除。日志里必须清晰记录这两个阶段。

关键字段：

ScheduleKeyDeletion：
- 事件名称：ScheduleKeyDeletion
- 参数：PendingWindowInDays（等待天数，如7、30）
- 状态：密钥进入 PendingDeletion 状态
- 时间戳：计划删除时间 = 当前时间 + PendingWindowInDays
CancelKeyDeletion：
- 事件名称：CancelKeyDeletion
- 状态：密钥从 PendingDeletion 恢复到 Enabled
- 原因：一般需要关联“撤销工单”或“审批记录”

我通常会在安全评估报告里列一个“高危操作清单”，其中密钥删除排在第一位。为什么呢？因为删除之后，所有用该密钥加密的数据就永远解不开了。我曾经见过某大厂因为误删线上密钥，导致几十TB的数据彻底报废。

4.5 日志特征总结与场景示例

下面这个表格是我自己整理的“五类关键操作日志速查表”，审计时可以直接对照：

操作类型	必检字段	常见异常特征	审计优先级
创建	KeySpec, KeyUsage, KeyId	密钥规格过低、创建频率异常高	高
启用/禁用	状态变化字段, 操作者	非工作时间操作、无关联工单	高
轮换	轮换周期, 新版本ID	轮换后旧版本未禁用、周期过长	中
删除	等待窗口, 删除时间	等待窗口设置为0、未关联审批	最高

实际日志长什么样？我截个典型的 ScheduleKeyDeletion 日志片段，你感受一下：

{
  "eventName": "ScheduleKeyDeletion",
  "requestId": "A1B2C3D4-5678-90ab-cdef-EXAMPLE",
  "userIdentity": {
    "accountId": "123456789012",
    "arn": "acs:ram::123456789012:user/ops-lihua"
  },
  "requestParameters": {
    "keyId": "key-hz123abc",
    "pendingWindowInDays": 7
  },
  "responseElements": {
    "deletionDate": "2025-04-15T10:30:00Z",
    "keyState": "PendingDeletion"
  },
  "eventTime": "2025-04-08T10:30:00Z",
  "sourceIpAddress": "10.0.1.100"
}

你看这个日志，关键信息都在：谁（ops-lihua）、什么时间（4月8日）、哪个密钥（key-hz123abc）、等待多久（7天）、最终删除时间（4月15日）。如果审计时发现 waiting window 设成了0天，那就是立刻删除，风险极高。

这个图把咱们刚才讲的五个操作串起来了。核心就是：每个操作都必须有对应的日志字段来支撑审计判断。审计时不要只看事件名称，要深入到请求参数和响应结果里去。

  核心结论： KMS关键操作日志审计，说白了就是做“五查”：查身份、查时间、查状态变化、查参数合规性、查关联审批记录。少了任何一项，日志审计就成了样子货。