第3章 常见KMS产品日志特性：AWS KMS、Azure Key Vault、HSM等日志差异
做KMS日志审计，你首先得清楚一件事：没有两朵云是完全一样的。我在不同项目里切换过好几个云环境，每次换平台，日志字段都得重新熟悉一遍。说白了，AWS KMS、Azure Key Vault、以及传统的HSM（硬件安全模块），它们在日志记录上差别还挺大。
这一章，我就把这三个主流方案的日志特性拿出来掰开揉碎讲。你审计时看什么、漏什么、怎么对比，我们一次聊透。
3.1 AWS KMS 日志：精细到每次调用
AWS KMS 的日志走的是 CloudTrail 通道。每一条密钥操作都会被记录为 CloudTrail 事件。我个人觉得，它是三家里面最「啰嗦」的，但也最实用。
3.1.1 核心字段
每次调用 KMS API（比如 GenerateDataKey、Decrypt、Encrypt），CloudTrail 都会记录：
- eventSource：kms.amazonaws.com
- eventName：操作名称，如 Encrypt、Decrypt、CreateKey
- resources：被操作的密钥 ARN
- sourceIPAddress：调用方 IP
- userIdentity：调用者角色或用户
- requestParameters：加密算法、密钥ID、加密上下文
审计要点：AWS KMS 日志里，requestParameters 会暴露加密上下文（EncryptionContext）。这个字段在评估密钥使用合规时非常关键。我曾经遇到过一个案例，某应用把用户邮箱直接写进了加密上下文，结果日志泄漏了隐私数据。
3.1.2 特殊事件
AWS KMS 有两种特殊事件值得关注：
- DisableKey / ScheduleKeyDeletion：密钥生命周期变更，必须审计谁动的手。
- KeyPolicyChange：密钥策略变更，直接影响谁可以访问密钥。
注意：CloudTrail 默认不记录 Data 级别的加密操作详情（比如加密后的密文）。你只能看到元数据，看不到实际密钥材料。这是设计如此，别误会日志丢了。
3.2 Azure Key Vault 日志：诊断设置为前提
Azure Key Vault 的日志走的是 Azure Monitor 的诊断设置。你得先在 Key Vault 的「诊断设置」里启用，指定把日志发送到 Log Analytics 工作区或存储账户。我见过不少人忘了开这一步，审计时什么都查不到。
3.2.1 日志类别
Key Vault 的日志分两大类：
| 日志类别 | 说明 | 审计重点 |
|---|---|---|
| AuditEvent | 所有管理操作和部分数据操作 | 密钥创建、删除、备份、恢复 |
| AzurePolicyEvaluationDetails | Azure Policy 策略评估详情 | 检查密钥是否违反企业策略 |
3.2.2 核心字段差异
相比 AWS，Azure 的日志字段更侧重资源上下文：
- ResourceId：Key Vault 的全路径，比如
/subscriptions/.../vaults/myVault - OperationName：类似 AWS 的 eventName，但命名方式不同，例如
VaultPut、KeyDecrypt - ResultSignature：HTTP 状态码，200 表示成功，403 可能代表权限拒绝
- CallerIPAddress：来源IP
我的习惯：在 Azure 审计时，我会先检查 ResultSignature 为 403 的条目。这些往往是你发现未授权尝试的第一道线索。有一次我帮客户做评估，看到大量 403 来自未知IP，顺藤摸瓜发现是某个内部测试脚本没有配置正确的访问策略。
3.2.3 一个要注意的点
Azure Key Vault 默认只保留日志 90 天（取决于设置）。如果你需要长期审计，记得把日志导出到存储账户或事件中心，我这里吃过亏，等要查半年前的操作时，发现日志早被清掉了。
3.3 传统 HSM 日志：硬件级的粒度
HSM 是物理设备（也有云HSM），日志记录在设备内部。常见厂商有 Thales、Entrust、Utimaco。它们走的不是云API，而是设备自己的审计日志（Syslog 或专用格式）。
3.3.1 日志内容
HSM 日志包含三类信息：
- 身份认证事件：谁登录了 HSM（分管理员、审计员、操作员）
- 密钥操作：生成、导出、导入、删除密钥，以及密钥的哈希校验
- 系统事件：设备启动、重启、风扇故障、网络断开
审计要点：HSM 日志里最核心的是「密钥使用计数器」和「密钥校验值」。每次调用密钥都会增加计数。你可以用这个计数器检测密钥是否被滥用。我曾经审计过一个金融客户，发现在夜间有大量密钥使用记录，但当时并没有业务请求——结果是某个批处理脚本忘了下线，多跑了三天。
3.3.2 格式差异
各厂商日志格式不统一。Thales 用 CEFLIS 格式，Entrust 用自研的 nCipher 日志格式，Utimaco 支持 Syslog 和 XML。这就很头疼了。我建议在对接时先确认日志格式，并拿到厂商的字段映射表。
| 厂商 | 日志格式 | 访问方式 | 常见问题 |
|---|---|---|---|
| Thales (Luna) | CEF / LIS | SSH 到 HSM 或者 Syslog 转发 | 时间戳有时是设备本地时间，需校准 |
| Entrust (nCipher) | nCipher log | nCipher API / 文件 | 日志不包含源IP，因为 HSM 是底层设备 |
| Utimaco (SecurityServer) | Syslog / XML | 通过 SecurityServer 软件读取 | 日志量庞大，默认不限制大小，可能撑满分区 |
3.4 三方日志对比总览
下面这张对比表，是我做评估时经常拿出来参考的，你直接拿走用：
| 维度 | AWS KMS | Azure Key Vault | 传统 HSM |
|---|---|---|---|
| 日志通道 | CloudTrail | Azure Monitor 诊断设置 | 设备 Syslog / 文件 |
| 加密操作记录 | 元数据（有 EncryptionContext） | 操作记录（无加密上下文） | 密钥计数器、校验值 |
| 密钥生命周期事件 | 记录完整（创建、启用、禁用、删除） | 记录完整（VaultPut/KeyDelete等） | 部分厂商记录，需开启审计模式 |
| 源IP记录 | 有 | 有 | 通常无（设备层） |
| 访问控制策略记录 | KeyPolicyChange 事件 | AccessPolicyChange | HSM 管理员变更事件 |
| 保留期限 | CloudTrail 默认90天，可延长 | 诊断设置自定义（最长2年） | 取决于设备磁盘，建议定期归档 |
3.5 统一审计框架：求同存异
因为每个平台的日志字段都不一样，你不可能写一套查询脚本通吃。但别担心，我们可以抽象出公共维度。我一般用下图这种框架来统一分析：
框架的核心思路是：先把各平台的日志字段映射到统一的「事件时间」「操作类型」「调用者」「资源」「结果」五要素，然后在这个基础上做审计分析。这样无论是 AWS、Azure 还是 HSM，你都可以用同一套规则来检测异常。
经验之谈：我建议你先做一个「字段映射表」，把每个平台的关键字段对应到自己的统一名称。比如 AWS 的 eventName、Azure 的 OperationName、HSM 的 操作码，统一叫 action。这样写查询脚本时，只需要修改映射的那一层，分析逻辑不用动。
3.6 日志整合的常见坑
最后聊几个我踩过的坑，你注意避一下：
- 时间戳不一致：HSM 常用 UTC，但部分设备用本地时间。我曾经因为时区问题，把上午的误报当成下午的问题排查了大半天。
- 日志不完整：Azure 如果没开诊断设置，就没日志。AWS 如果关闭了 CloudTrail 踪迹，也没日志。这些坑在审计初期就要确认。
- 密钥材料本身不可审计：所有平台都不会在日志里输出明文密钥。你要是想审计密钥内容，那得靠别的方案，比如密钥轮换记录、使用计数等间接证据。
嗯，这一章的内容基本就是这些。三种主流 KMS 产品的日志各有特点，但审计的逻辑是相通的。你掌握好字段差异和映射方法，后面做安全评估就能游刃有余了。