审计日志基本概念：日志记录、来源、类型与格式
说实话，做KMS运维这几年，我接手过不少“日志盲盒”。明明配置了审计，出问题时却在日志里找不出线索——说白了，就是没搞懂日志到底记了啥、从哪来、长什么样。
我习惯把审计日志的核心拆成四块：记录了什么、从哪采集、长什么样子、怎么分类。今天咱们就按这个逻辑来捋一遍。
日志记录：到底记了什么？
审计日志不是流水账。每一行日志都必须回答三个问题：谁在什么时间对哪个密钥干了什么操作，结果是成功还是失败。
我曾经碰到一个团队，他们只看API名字和返回码，从不追调用来源IP。结果有次密钥被误删，日志里只看到“DeleteKey”和一个200——查了三天才发现是某个内部脚本跑错了环境。
一张表把核心字段列清楚：
| 字段 | 说明 | 我在项目中踩过的坑 |
|---|---|---|
| 用户/身份 | 谁发起的操作（IAM用户、角色、服务账号） | 匿名调用时为空，要格外留意 |
| 时间戳 | 操作发生的UTC时间 | 别直接拿时间排序，得先统一时区 |
| 操作类型 | CreateKey、Encrypt、Decrypt等 | 写脚本时别拼错大小写 |
| 资源ID | 操作涉及的具体密钥ID或别名 | 有些日志只记ARN，截取时要小心 |
| 来源IP | 调用方IP地址 | VPC内调用可能显示内网IP |
| 请求ID | 每次调用唯一标识 | 关联多个日志片段的关键字段 |
| 执行结果 | 成功、拒绝、错误码 | 403不代表“没发生”，别漏看 |
日志来源：谁在产生这些日志？
很多人以为只有用户调用KMS API才会产生日志。其实远远不止。我见过几次“莫名其妙”的日志条目，查到最后发现是KMS内部自动轮转密钥触发的。
主要来源就三类：
- 用户主动调用：通过CLI、SDK、控制台发起的API操作。这是最常见的来源，信息最完整。
- 系统自动触发生成：密钥轮转、过期自动禁用、跨区域同步等。这类日志有时会被忽略，但往往影响范围最大。
- 策略拒绝生成：当IAM或KMS密钥策略拒绝一次操作时，也会生成审计日志。请注意——拒绝操作的日志同样重要，甚至更值得关注。
你可能会问：“那跨账号访问呢？”没错，当其他账号的IAM角色访问你的KMS密钥时，日志会同时出现在你账号和对方账号中，但双方看到的字段不完全相同。我建议以被访问者（也就是密钥归属账号）的日志为准。
日志类型：按内容分，而非按来源
我个人习惯把审计日志按内容维度分类，而不是按API来源。这样在排错时更容易定位问题类型。
- 操作类日志：创建、禁用、启用、删除密钥，更新别名、标签等管理操作。这类日志最常见，通常用于合规审计。
- 使用类日志：Encrypt、Decrypt、GenerateDataKey等密码运算操作。这类日志量最大，我建议定期轮转，否则存储成本会吓你一跳。
- 配置变更类日志：修改密钥策略、调整轮转周期、变更密钥状态。这类日志一旦出现，往往意味着权限或安全策略在变，特别需要关注。
- 安全事件类日志：尝试访问被拒绝、来自异常IP的调用、大量重复Decrypt失败。这些日志是我每天巡检的重点。
日志格式：结构化和非结构化，你都该认识
不同云平台输出的审计日志格式有差异，但底层逻辑一致。我目前接触过的无外乎两种：结构化JSON和非结构化的Syslog风格。
我在项目中更推荐结构化JSON格式，原因很简单：好解析、好搜索、好归档。下面给一个典型的结构化日志片段：
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"arn": "arn:aws:iam::123456789012:user/admin",
"accountId": "123456789012"
},
"eventTime": "2025-03-15T08:12:33Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"resources": [
{
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:123456789012:key/abc123-def456"
}
],
"sourceIPAddress": "203.0.113.42",
"responseElements": {
"keyId": "abc123-def456",
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
}
}
至于非结构化格式，我曾在老版本环境中碰到过，大概是下面这种样子：
Mar 15 08:12:33 kms-proxy-1 Decrypt[28451]: User admin from 203.0.113.42, Key abc123-def456, result SUCCESS这种格式阅读体验确实差些，关键字段以固定位置对齐，没有明确的字段名。如果你还在用这种格式，我建议尽快升级采集方式，转为结构化格式来集中管理。
为什么我强调格式的重要性？因为格式决定了你能不能自动化处理。结构化格式方便写脚本做告警、做趋势分析、做成本归因。非结构化格式你只能靠人眼刷，效率低了不止一个数量级。
一张图看懂审计日志的核心脉络
我把以上概念画成了一张结构图。你看一眼，逻辑就全通了：
说白了，掌握审计日志就是从“记录-来源-类型-格式”这四层逐级理解。下一层是上一层的细化，你定位问题时也是按这个路径往下钻。