3. KMS审计日志格式基础

日志格式这件事，看起来枯燥，但绕不过去。我接手过好几个KMS审计项目，第一件事就是先搞懂日志长什么样。你想想看，格式都看不懂，后面的分析、告警、溯源全白搭。

今天咱们就把它拆开揉碎，看看到底什么是JSON格式、什么是XML格式，以及那些字段到底在说什么。

3.1 日志格式约定

主流KMS产品，审计日志基本就两种格式：JSON 和 XML。当然了，也有少数用纯文本的，但那是上古时代的东西了，碰到的概率不大。

JSON长什么样？看个最典型的例子：

{
  "timestamp": "2025-04-11T08:30:15.123Z",
  "eventId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "eventType": "Decrypt",
  "resource": "arn:kms:cn-north-1:123456789012:key/abc-123-def",
  "identity": {
    "userId": "user-001",
    "sourceIp": "192.168.1.100"
  },
  "requestParameters": {
    "ciphertextBlob": "AQICAHg..."
  },
  "responseStatus": "Success"
}

XML版本呢？内容一样，但包裹在 <AuditLog> 标签里。我个人很少手动去读XML，一般都转成JSON再看。

3.2 核心字段说明

一条审计日志里，字段多多少少，但核心字段就七个。我把它们排了个优先级，方便你记忆：

3.3 字段拆解 — 时间戳

timestamp 一定是UTC时间，这点很重要。好多人看到时间不对，先怀疑系统，其实只是时区问题。我习惯在分析前统一转成本地时区，比如UTC+8。

你可能会问：为什么不用本地时间？因为跨地域的KMS调用，日志必须有一个统一的时间基准，否则根本对不齐。

3.4 字段拆解 — 事件ID

UUID格式，全局唯一。它主要有两个用途：

• 去重：防止重复处理同一条日志。
• 关联：如果KMS有多个子系统（比如硬件安全模块、管理控制台），同一个操作可能产生多条日志，事件ID可以把它们串起来。

3.5 字段拆解 — 操作类型

这是最有价值的字段之一。我按常见度排了个级别：

• 高频：Decrypt、Encrypt、GenerateDataKey，这些是业务调用。
• 敏感：CreateKey、DeleteKey、DisableKey、ScheduleKeyDeletion，这些是管理操作。
• 异常：DecryptWithImportedKey、ExportKeyMaterial，这些基本意味着有人动了加密材料。

你监控的时候，重点盯后两类。

3.6 字段拆解 — 资源标识

ARN（Amazon Resource Name）格式，标准写法是：

arn:kms:region:account-id:key/key-id

实际项目中，有时候 key-id 会是个别名（Alias），不一定是真实密钥ID。我建议你在分析前先建立一张别名到真实ID的映射表，不然根本对不上。

3.7 字段拆解 — 身份与来源

identity 对象里常见子字段：

• userId — 调用者的唯一标识，可能是IAM用户、角色或者服务账户。
• sourceIp — 来源IP，有时候会是内网IP或者VPC端点IP。
• userAgent — 客户端的HTTP User-Agent，能判断是SDK调用还是控制台操作。

3.8 结构总览

下面这张图把整个KMS审计日志的字段层次串起来了。你可以用它当“指北针”，对着看任何一条日志都不会迷路。

3.9 实战避坑

最后总结几个常见坑：

1. 时间戳不是UTC？我见过某些自建KMS用本地时间输出日志，结果跨区域查问题根本对不上。如果你也碰到，建议先写个脚本统一转成UTC。
2. eventId重复？前面提过，不要完全信任eventId的唯一性。加个(时间+用户+操作)的组合校验会更稳。
3. 字段名大小写不统一？有些厂商用camelCase，有些用snake_case。我习惯在脚本里先做一次标准化映射，否则分析代码越改越乱。
4. 空值字段缺省？有些日志在requestParameters为空时直接不输出这个字段，而不是输出null。解析时要用getOrDefault或类似机制兜底。