📚 课程目录第2章审计日志概述

审计日志概述

审计日志到底是个什么东西？

说白了，它就是系统里所有“谁在什么时候、干了什么、结果如何”的流水账。

我在刚接手加密搜索系统的那会儿，日志就是我的“黑匣子”。系统出了事，第一反应是翻日志。要是日志不全，你连事故原因都找不到，更别说做安全审计了。

审计日志的定义

审计日志（Audit Log）是一种不可篡改的、按时间顺序记录的事件序列。它记录了用户操作、系统调用、数据访问、权限变更等关键行为。

在我这个行当里，它有个更贴切的名字——「数字世界的黑匣子」。航空业靠黑匣子分析空难，安全团队就靠审计日志分析安全事件。

审计日志的作用

我把它总结成了四个核心作用，记好这张表就够了：

作用	一句话说明	我在项目中遇到的真实场景
责任追溯	找到“谁干的”	有一次内部数据泄露，全靠登录日志锁定是某个运维同事的非正常时间段操作
合规审计	证明“我守规矩了”	ISO 27001审计时，审计员只看审计日志是否完整、是否防篡改
异常检测	发现“不对劲”	加密搜索系统的API调用频次突然暴涨，日志帮我发现了暴力破解尝试
故障定位	回答“为啥挂了”	生产环境一次慢查询，跟踪到是一条加密索引重建导致的锁等待

一个重要的点：审计日志不能只有记录功能。它还必须做到“不可否认”，也就是当事人事后无法抵赖。这就引出了日志签名和链式哈希存储的概念，后面章节会展开。

常见字段

每个系统的字段可能不同，但我个人习惯把字段分成三组：谁、何时、干了啥。字段不全的日志，在我眼里就是“半残废”。

字段名	含义	示例值	备注
`timestamp`	事件发生时间	`2025-03-21T14:32:10.123Z`	建议用UTC，别用本地时间，否则取证时转换很痛苦
`user_id`	操作人标识	`uid_1083`	不要只用IP，IP会变，用户ID才是稳定锚
`action`	操作类型	`SEARCH`	动词为主，比如CREATE、READ、UPDATE、DELETE
`resource`	被访问的资源	`/encrypted_index/user_data`	具体到路径或对象ID
`client_ip`	来源IP	`10.0.12.5`	内网场景下注意NAT转换，最好同时记录真实源
`result`	执行结果	`SUCCESS` / `FAILURE`	失败时附带错误码，别省这一点

我的一点经验：除了上面这些，建议额外加一个 session_id。有一次追查加密搜索的“幽灵查询”，就是靠 session_id 把同一用户的一次完整会话串起来的。

格式标准

格式不统一，审计就是灾难。你想想看，10套系统10种格式，解析脚本写到你崩溃。所以，业界形成了两个主流标准：CEF 和 JSON。

CEF（Common Event Format）

CEF 是 ArcSight 提出的格式，核心思想是“用竖线分隔关键字段 + 扩展键值对”。举个例子：

CEF:0|Security|EncryptedSearch|1.0|100|EncryptedQuery|10|
src=10.0.12.5 spt=54321 dpt=443  
request=/search?q=encrypted user=uid_1083  
msg=Query index_alpha success

CEF 的前七个字段是固定的：设备类型、产品、版本、签名ID、名称、严重等级、扩展字段。后面的扩展部分可以自由加键值对。

我个人觉得 CEF 在 SIEM（安全信息与事件管理）系统里特别好用，因为它结构严谨，解析效率高。

JSON（JavaScript Object Notation）

JSON 格式更灵活，也是我现在的首选格式。每个字段都是键值对，读写方便，嵌套结构也不怕。

{
  "timestamp": "2025-03-21T14:32:10.123Z",
  "event_type": "SEARCH",
  "severity": "low",
  "user": {
    "id": "uid_1083",
    "role": "analyst"
  },
  "resource": {
    "type": "encrypted_index",
    "name": "user_data"
  },
  "action": {
    "name": "read",
    "method": "query"
  },
  "result": "SUCCESS",
  "client": {
    "ip": "10.0.12.5",
    "port": 54321
  }
}

警告：JSON 虽好，但别忘了做字段校验。我曾经遇到过一个场景，某系统输出的 JSON 里 timestamp 字段时而字符串、时而数值，导致下游解析全部报错。解决方案是在日志生成侧就做 schema 校验。

格式对比

我把 CEF 和 JSON 的优缺点对比了一下：

维度	CEF	JSON
可读性	中等（竖线分隔，眼睛要适应）	优秀（键值对一目了然）
解析性能	快（固定位置解析）	中等（需要完整解析语法树）
扩展性	良好（扩展字段键值对）	优秀（任意嵌套结构）
系统兼容性	SIEM 工具原生支持	几乎所有系统都支持
我的场景选择	日志需要直接输入商业 SIEM 时	需要与微服务、云平台深度集成时

我的建议：如果你的团队在搭建新系统，直接上 JSON 格式。如果对接的是遗留的 SIEM 或 SOC 平台，CEF 更省事儿。但无论选哪个，注意记录都要带上时间戳、用户标识和结果状态。

嗯，这张图是我自己在做安全审计时画的心法。从源头采集到最终复盘，审计日志是有生命周期的，每一步都环环相扣。格式标准化是承上启下的关键环节，这一点怎么强调都不过分。