📚 课程目录第2章审计日志基础

审计日志基础：日志格式、关键字段、标准规范

做密文检索审计，第一步不是看算法，而是搞清楚日志到底长什么样。你想想看，日志格式都认不全，后面做巡检、排故障就是瞎忙活。我个人习惯先把日志的“骨架”摸清楚——它用什么标准来组织？核心字段有哪些？

我在项目中遇到过好几次，因为日志格式理解偏差，导致解析脚本写错，最后审计结果全偏了。所以这一章我把最常用的 Syslog 和 JSON 掰开揉碎讲，配合关键字段说明，你上手就能用。

1. 两条主流标准：Syslog 与 JSON

审计日志的格式没有统一强制标准，但业界公认两大方向：Syslog 和 JSON。Syslog 历史久、轻量，适合网络设备和 Unix/Linux 系统；JSON 结构化好、可读性强，是 Web 应用和云平台的标配。

维度	Syslog	JSON
起源	1980s，BSD Unix	2000s，Web 2.0
结构	文本行，定长头部 + 可变消息	键值对嵌套，层次分明
可读性	中等（需要懂格式规则）	高（直接看字段名）
解析性能	较高（文本切割）	稍低（完整解析需库）
典型场景	防火墙、路由器、Linux /var/log	REST API、微服务、云审计

我的建议：不要二选一。实际环境往往是两种格式混用。比如网关用 Syslog 上报流量，后端应用用 JSON 记录用户操作。你的解析层必须同时兼容这两类。

2. 核心字段：审计日志的“身份证”

不管用哪种格式，一套审计日志里总有几个字段是必须有的。我把它们叫“六要素”：

时间戳：精确到毫秒或微秒，时区标识不能省。我排查过一次跨时区故障，就是因为日志用 UTC 但审计系统按本地时间算，结果对不上。
源 IP / 设备标识：谁发来的日志？哪个模块？最好同时记录 IP 和主机名。
事件类型：登录、查询、变更、异常……用枚举值或统一编码，别用自由文本。
用户 / 身份：用户 ID、角色、会话 ID。匿名操作要标记清楚。
操作内容：具体干了什么。比如密文检索场景，要记录“检索关键字哈希值”或“密文数据范围”。
结果状态：成功、失败、拒绝、超时。失败时附上错误码。

我曾经踩过的坑：某次审计发现大量“无用户”日志，原来开发把用户字段写成了可空。你想想看，没有用户的审计日志等于废纸——谁操作的你都不知道。所以字段的非空约束必须落地。

3. 典型格式示例

口说无凭，直接看实例。

Syslog 示例（RFC 5424）

<14>1 2025-03-21T10:15:30.123Z my-audit-host app - - [audit@12345 eventType="SEARCH" userId="u1001" sourceIP="10.0.1.5" status="SUCCESS"]
用户 u1001 执行密文检索，关键词哈希 0xaf3b…

这里拆开看：<14> 是设施+优先级编码，1 是版本，然后是时间戳、主机名、应用名。结构化数据放在 [audit@12345 ...] 里。最后那条自由文本是给人看的。

JSON 示例

{
  "timestamp": "2025-03-21T10:15:30.456Z",
  "source": "cipher-search-engine",
  "event": {
    "type": "search",
    "userId": "u1001",
    "sessionId": "sess-abc123",
    "keywordsHash": "0xaf3b...",
    "resultCount": 5
  },
  "status": "success",
  "durationMs": 128
}

JSON 的优势一目了然：字段名自解释，解析时用 json.load 就能拿到所有信息。我建议新系统优先用 JSON，除非有强兼容需求才保留 Syslog。

4. 日志生命周期：从产生到归档

你光看懂格式还不够，还得知道日志怎么流动。下面这张图是我根据实际审计链路总结的：

核心要点：审计日志的格式不是随便选的。Syslog 适合嵌入式和遗留系统，JSON 适合现代微服务。但不管哪种，六要素（时间、源、事件、用户、操作、状态）一个都不能少。解析脚本里必须做字段校验，不然你巡检时发现字段缺失，排查成本会翻倍。

我个人习惯在日志生成层就统一一个 JSON Schema 或者 Syslog 模板，避免后期清洗。你要是接手老系统，先做一次“字段覆盖度审计”，把缺的字段补上。

5. 标准规范加持

除了格式本身，还有几个规范值得了解：

RFC 5424：Syslog 的现代标准，支持结构化数据。老旧的 RFC 3164 建议尽快迁移。
ECF（Common Event Format）：ArcSight 推广的键值对格式，很多 SIEM 工具原生支持。
NDJSON / JSON Lines：每行一个完整的 JSON 对象，适合流式处理。
ISO 8601：时间戳必须用这种格式，且带时区（推荐 Z 或 +08:00）。

你可以在代码里加一段校验，比如用正则匹配 ISO 8601 时间。我曾经因为时间戳格式不统一，导致跨系统关联分析时完全对不上事件先后顺序——从那以后我强制所有日志生成模块都必须输出 UTC+ISO 8601。

避坑指南：Syslog 的消息体默认只有 1024 字节，超过会截断。如果你要记录完整的密文检索参数，务必启用 RFC 5424 的 MSG-LEN 扩展，或者改用 JSON 通过 TCP 传输。我亲眼见过 Syslog 截断导致审计日志里的关键词哈希丢失，无法追溯。

好，格式和字段你都清楚了。下一块是真正动手巡检时你应该关注哪些日志异常指标。不过那是后面的事，先把今天的内容消化掉——找个生产环境的审计日志，用 cat 或者 jq 看看它的格式结构，逐一比对六要素是否存在。这是最快的学习路径。