3. 审计日志基础介绍

咱们直接进入正题。审计日志这东西，说白了就是谁在什么时间、对什么东西、干了什么事的一份流水账。在 BYOK 场景下，这份账本格外重要——因为密钥是你自己的，云厂商到底有没有误操作、有没有越权访问，你得靠日志来验证。

我在项目里踩过不少坑，最典型的就是：租户把密钥交上来了，结果审计日志没开，或者开了但字段不全。等到真要排查问题时，两眼一抹黑。所以，先把这个基础打牢。

3.1 审计日志是什么

审计日志记录的是对云资源的操作行为。它跟普通业务日志不一样。

一个典型的审计日志条目，至少包含四个要素：

• 主体（谁）：调用 API 的用户或服务账号。通常是 AK/SK 对应的身份。
• 客体（对什么）：被操作的具体资源。比如一个 KMS 密钥 ID、一个 Bucket 名称。
• 动作（干了什么）：操作类型。比如 CreateKey、Encrypt、Decrypt。
• 时间（什么时候）：操作发生的精确时间戳。一般精确到毫秒。

你想想看，如果缺少了其中任意一项，这日志就没法用来做责任认定。我见过一个案例，日志里记录了密钥被删除，但查不到是谁删的，因为主体字段是空的——这种日志基本废了。

3.2 为什么在 BYOK 场景下审计日志是刚需

BYOK 的核心信任模型是“密钥由我掌控”。但你要是连谁碰过你的密钥都不知道，还谈什么掌控？

嗯，这里要注意。很多云厂商默认只保留 90 天或 180 天的审计日志。如果你有长期合规需求，我建议提前配置日志转储到你的对象存储里。这份数据是你自己备份的，云厂商删不掉。

3.3 审计日志的核心字段

不同云厂商的审计日志格式略有差异，但核心字段基本通用。咱们以常见的云审计服务为例：

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDA123456789EXAMPLE",
    "arn": "arn:aws:iam::123456789012:user/admin",
    "accountId": "123456789012"
  },
  "eventTime": "2024-03-15T10:30:00Z",
  "eventSource": "kms.amazonaws.com",
  "eventName": "Decrypt",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "203.0.113.1",
  "requestParameters": {
    "keyId": "arn:aws:kms:us-east-1:123456789012:key/mrk-1234abcd5678efgh"
  },
  "responseElements": null,
  "requestID": "abcd1234-5678-90ef-ghij-klmnopqrstuv",
  "eventID": "12345678-90ab-cdef-1234-567890abcdef"
}

我个人习惯重点关注这几个字段：

• eventName：一眼看出操作类型。加密、解密、密钥轮换、删除，都在这里。
• requestParameters.keyId：操作的是哪个密钥。这是租户隔离检查的关键。
• sourceIPAddress：来源 IP。可以跟你的准入白名单做交叉验证。
• userIdentity：谁干的。这里要注意区分是主账号、子账号还是服务角色。

3.4 审计日志的流转路径

从操作发生到日志落地，大致经过这几个环节：

1. 用户发起请求：通过 API、CLI 或控制台操作云资源。
2. 云服务生成事件：KMS 等内部服务记录操作上下文。
3. 审计服务采集：云审计服务聚合各类操作事件。
4. 存储与索引：写入日志存储，并建立可检索的索引。
5. 告警与导出：根据规则触发告警，或转储到外部存储。

为什么会这样设计？因为审计日志写入速度如果影响业务主流程，就是设计失败。所以大部分云厂商把审计日志做成异步的——操作先返回结果，日志后补。这也意味着，日志不是实时到达的，可能会有几十秒到几分钟的延迟。

3.5 知识结构总览

这一节的核心逻辑可以用下面这张图串起来。它帮你理清楚审计日志在整个 BYOK 租户隔离检查中的位置。

3.6 实操中必须注意的坑

讲几个经验点，都是我在真实项目中碰到过的：

• 时间戳对齐问题：审计日志用的是 UTC 时间。你的业务系统如果用的本地时间，对比时记得做时区转换。我曾经排查一个问题查了两小时，最后发现是时间差了8小时。
• 日志量可能很大：高并发场景下，一天可能产生几千万条审计日志。不要对全量日志做盲查，要学会用 keyId 或 eventName 做过滤。
• 保存与搜索的平衡：全量保存到对象存储（便宜），但搜索慢。建议把关键操作（密钥删除、权限变更）独立出来，做一份快速索引。我一般会用云原生 SLS 服务来实现这个双写策略。