2. 审计日志概述：CloudTrail / Azure Monitor 等云审计服务介绍、审计日志的格式与关键字段
说到 BYOK 场景的异常识别，你首先得知道「日志从哪来、长什么样」。这一章我就把几大主流云的审计服务拉出来遛一遛，再把日志格式拆开揉碎。嗯，都是基本功，但翻车往往就翻在这些基础字段上。
2.1 主流云审计服务一览
我自己经手的项目中，95% 的 BYOK 异常都是靠审计日志发现的。你想想看，密钥操作都被记下来了，谁在什么时候碰了哪个密钥，跑不掉。下面是几家主流的审计服务，我挑重点说。
| 云厂商 | 审计服务名称 | 主要用途 | 密钥相关事件示例 |
|---|---|---|---|
| AWS | CloudTrail | 记录 AWS API 调用 | CreateKey, Decrypt, GenerateDataKey |
| Azure | Azure Monitor (Activity Log + Diagnostic Settings) | 订阅级活动日志 + 资源级诊断 | Microsoft.KeyVault/vaults/keys/action |
| GCP | Cloud Audit Logs | 管理活动、数据访问、系统事件 | google.cloud.kms.v1.KeyManagementService.Decrypt |
| 阿里云 | ActionTrail | 记录云资源操作 | KMS Decrypt, Encrypt |
说白了，各家都有类似的「黑匣子」。不过字段命名、时间格式、敏感信息处理方式差别挺大。如果你刚接触 BYOK，我建议先从 CloudTrail 入手 —— 文档最全，社区踩坑案例也多，容易学。
2.2 AWS CloudTrail 深度解析
CloudTrail 是我用得最多的。基本每条记录都是一个 JSON，里面关键字段就那几个，但很多人栽在 eventSource 和 recipientAccountId 上。我见过有人把跨账户请求的 recipientAccountId 当成自家账户查半天……
必须牢记的 CloudTrail 核心字段：
- eventTime — 时间戳，UTC，精确到毫秒。注意时区，我一般统一转成 ISO 8601。
- eventSource — 如 kms.amazonaws.com，表示服务。BYOK 场景下常见 kms、secretsmanager。
- eventName — 操作名，比如 Decrypt、GenerateDataKey。这是最直接的异常信号。
- awsRegion — 区域。偶尔有跨区域调用，要警惕。
- sourceIPAddress — 来源 IP。如果你看到来自非白名单 IP 的 Decrypt 请求，赶紧查。
- userIdentity — 谁做的。包含 type、arn、accountId。我曾经发现一个临时凭证使用异常，就是靠这里抓到的。
- requestParameters — 请求参数。比如密钥 ID、加密上下文。明文打印，小心敏感信息。
- responseElements — 响应内容。可能包含密钥明文（比如 GetSecretValue 的响应，但 KMS 一般只返回密文）。
举个例子，一个典型的 CloudTrail 事件（精简后）：
{
"eventVersion": "1.08",
"eventTime": "2023-11-15T14:30:22Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.42",
"userIdentity": {
"type": "AssumedRole",
"arn": "arn:aws:sts::123456789012:assumed-role/AdminRole/user1"
},
"requestParameters": {
"keyId": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123def456",
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"resources": [
{ "ARN": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123def456" }
]
}你注意看 keyId 和 userIdentity.arn。如果这个角色平时从不调 Decrypt，突然在凌晨两点跑了一大堆，那基本可以确定是异常。我建议你建立基准基线，否则日志量太大根本看不过来。
2.3 Azure Monitor 与 Activity Log
Azure 这边稍微绕一点。它有 Activity Log（订阅级操作）和 Diagnostic Settings（资源级操作）。BYOK 场景常用的是 Key Vault 的诊断日志，通过 Diagnostic Settings 发送到 Log Analytics 或 Storage。
关键字段有：
- time — 事件时间 (UTC)
- resourceId — 资源 ID，比如 /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vault}
- operationName — 如 Microsoft.KeyVault/vaults/keys/action
- resultType — Success 或 Fail
- callerIpAddress — 调用者 IP
- identity — 用户或服务主体
- properties — 包含详细操作（如 encrypt、decrypt、wrap、unwrap），以及密钥 ID
个人经验：Azure 的 Diagnostic Settings 需要手动开启，而且按量收费。我遇到过客户开了 Activity Log 但没开 Key Vault 的诊断，结果查异常时发现日志不全。千万记得检查诊断配置。
2.4 其他云审计服务简要对比
| 特性 | CloudTrail | Azure Monitor (Activity + Diagnostic) | GCP Cloud Audit Logs |
|---|---|---|---|
| 默认保留时间 | 90 天（可延长到 S3/Glacier） | 90 天（支持导出） | 30 天（支持导出到 BigQuery） |
| 敏感字段脱敏 | KMS Decrypt 响应不回传明文 | Key Vault 可配置是否记录明文 | 数据访问日志可记录明文（需谨慎） |
| 跨账户审计 | 通过组织追踪或 S3 跨账户写入 | 跨租户需发送到外部 | 组织日志汇聚 |
| 实时流 | CloudWatch Events / EventBridge | Event Hubs / Logic Apps | Pub/Sub |
需要注意的是，GCP 的 Cloud Audit Logs 分为三种类型：Admin Activity（免费）、Data Access（收费）、System Event。如果你要监控 KMS 的 Decrypt 操作，必须开启 Data Access 审计，否则根本拿不到。我曾经有一次就是因为没开这个，导致客户说「日志里怎么没有 Decrypt 记录」，然后发现是审计级别没配对。
2.5 审计日志的通用结构模型
虽然各家字段不同，但本质上都遵循一个模式。我画了一张图，你可以把它当作通用框架来理解。
你看，审计日志最终都可以归纳成这个模型。不同云只是字段命名有差异，但结构一致。这样一来，你写跨云检测规则时，只要把字段名做个映射就行。
2.6 关键字段的异常识别切入点
最后我总结几个高优先级的字段，你在做日志分析时可以重点盯：
- eventName / operationName — 出现 Decrypt、GenerateDataKey、GetSecretValue 等敏感操作，尤其是在非业务时间。
- sourceIPAddress / callerIpAddress — 来自异常 IP、外部 IP、公共 VPN 出口。
- userIdentity / identity — 使用了不该有此权限的临时凭证、服务主体或跨账户角色。
- requestParameters — 密钥 ID 请求频率激增、重复使用过期密钥。
- responseElements — 返回了大量明文或密钥，必须马上报警（通常 KMS 不返回，但 Secrets Manager 会）。
避坑指南：我曾经在项目中遇到 CloudTrail 日志里没有记录 Decrypt 操作，查了半天才发现是因为客户只开启了管理事件（Management Events），没有开启数据事件（Data Events）。KMS 的 Decrypt 属于数据事件，默认不记录。千万检查你的 Trail 配置。