第三章 审计日志的关键字段与格式

审计日志要合规，关键字段一个都不能少。说白了，字段就是日志的「骨架」，格式就是「衣服」。骨架歪了、衣服不合身，安全审计员一眼就能看出问题。我这么多年做合规审计，至少有三次因为字段缺失被客户打回重做——嗯，后来我学乖了，先把最常见的字段罗列清楚，再挑合适的格式。

3.1 常见字段：少一个都算「残次品」

不同行业标准对审计字段要求略有差异，但有几个是通用的。我把它们分成「必备四件套」和「辅助扩展包」。

3.1.1 必备四件套

1. 时间戳 —— 事件发生的精确时刻。格式统一是关键，我用的是 UTC+8 的 ISO 8601，比如 2025-06-12T15:30:00+08:00。为什么强调这个？我见过跨国项目里，同一台日志源有北京时间、有 UTC，对账直接乱掉。
2. 用户ID —— 谁干的？可以是用户名、邮箱、员工号。但注意：一定要区分真实用户和系统账号，我曾经在项目中看到全部写 root，一眼假。
3. 操作类型 —— 是读、写、删、改、登陆还是登出？推荐用枚举值，别用自由文本。比如 LOGIN、DELETE、MODIFY，这样后面做告警规则好写。
4. 来源IP —— 发起请求的客户端 IP。如果走代理，记得保留原始 IP 字段。我踩过坑：反向代理后面全是内网 IP，根本查不到攻击源。
5. 结果 —— 成功还是失败？或者更细粒度的状态码。比如 SUCCESS、FAILED、DENIED，失败的要记录错误原因。

3.1.2 辅助扩展字段

根据业务场景，你可能还需要：

• 请求详情（URL、请求体大小）
• 目标资源（文件路径、数据库表名）
• 会话ID（用于关联同一用户的多步操作）
• 设备标识（移动端或 IoT 场景必备）

3.2 推荐格式：CEF、LEEF、JSON 怎么选？

你想想看，字段定义好了，总得有个「壳」装起来。市面上主流的三种格式：CEF（Common Event Format）、LEEF（Log Event Extended Format）、JSON。我具体讲清楚它们的区别和适用场景。

3.2.1 我们直接看一张对比表

3.2.2 每种格式长什么样？

CEF 示例（来自 ArcSight）：

CEF:0|Security|threatmanager|1.0|100|login failed|5|src=10.0.0.1 dst=10.0.0.2 sUser=admin act=login outcome=failure

CEF 用竖线分隔前 7 个固定字段，后面是键值对。我个人建议：如果团队只有一两款产品用 CEF，可以接受；如果接入源太多，维护扩展字段索引很头疼。

LEEF 示例：

LEEF:1.0|IBM|QRadar|1.0|loginAttempt|devTime=Jun 12 15:30:00 src=10.0.0.1 usrName=admin cat=LOGIN sev=5

LEEF 用管道分隔前缀，后面也是键值对。我曾经在 QRadar 项目中用过 LEEF，优点是解析快，但如果你用的不是 IBM 全家桶，社区支持会弱一些。

JSON 示例：

{
  "version": "1.0",
  "timestamp": "2025-06-12T15:30:00+08:00",
  "userId": "admin",
  "action": "LOGIN",
  "sourceIp": "10.0.0.1",
  "result": "FAILED",
  "reason": "Invalid password",
  "sessionId": "abc123"
}

JSON 是现在的默认首选，尤其公有云和容器场景。结构自解释，嵌套对象天生适合复杂事件。不过有个坑：如果日志量特别大（比如每秒百万条），JSON 的解析开销会比较明显。

3.3 字段与格式的匹配策略

为什么单独说这个？因为光知道字段和格式还不够，要能匹配起来才能落地。我一般按这个逻辑做选择：

• 如果 SIEM 是 ArcSight 或 Micro Focus，优先 CEF，省得写很多 parser。
• 如果 是 IBM 生态或金融合规场景（如 SOX 审计），LEEF 自带字段映射，减少配置量。
• 如果 你从零搭建日志平台，或者用 ELK、Splunk，JSON 是最灵活的。

但有一个原则必须守住：字段名、数据类型、枚举值必须提前定义好 schema。没有 schema 的 JSON 就是一团浆糊。

3.4 一张图看懂审计日志字段与格式关系

3.5 避坑指南

• 别乱用枚举值：操作类型用 CREATE、UPDATE、DELETE，别用 1、2、3，除非你附带映射表。
• 时间戳必须带时区：我见过一个经典 bug——日志里是 2025-06-12 15:30:00，没写时区，审计追责时鸡同鸭讲。
• 敏感信息脱敏：来源 IP 如果是内网 IP 无所谓；但如果记录银行卡号、密码，必须脱敏后才写日志。合规和隐私保护双重压力。
• 格式统一再入库：如果同一系统同时收到 CEF 和 JSON，建议在采集层统一转成 JSON，避免后期查询混乱。我习惯用 Logstash 或 Fluentd 做标准化。