3、日志审计基础：日志类型与日志标准

聊到日志审计，我经常跟团队里的小朋友说一句话：日志就是系统的DNA。你想想看，不管是性能抖动、安全入侵，还是业务异常，只要日志埋得对、收得全，基本都能顺着DNA找到根因。

我曾经在一个金融客户现场，看到他们的告警平台上挂了1800多条未处理告警。查了大半天，才发现是某台老旧Windows服务器的系统日志轮转配置炸了，硬盘写满，应用日志全部丢失。嗯，从那天起我就养成了一个习惯：先搞清楚日志从哪来、长什么样，再谈监控和分析。

这一节，咱们就把日志类型和日志标准这两个地基打牢。

3.1 日志的三种类型

从数据源的角度，日志可以粗暴地分成三类：系统日志、应用日志、安全日志。别小看这个分类，它直接决定了后面的采集方式和审计策略。

系统日志

说白了，系统日志就是操作系统自己的“日记本”。Linux下的/var/log/messages、/var/log/syslog、Windows的事件查看器里的System日志，都属于这一类。

• 典型内容：内核报错、磁盘I/O超时、NTP同步偏移、网络接口up/down
• 生成频率：高，一台服务器每天能产生几千到几十万条
• 审计价值：排障和容量规划的基础。我记得有一次某客户说数据库总是隔几天卡一次，我抓出系统日志一看，原来是crontab里有个定时任务在整点触发了全量备份，跟业务高峰撞车了。

应用日志

应用日志则是业务运行的轨迹。不管是Nginx的access.log，还是Java应用通过Log4j输出的日志，都归到这一类。

• 典型内容：请求URL、响应码、处理耗时、事务ID、数据库慢查询
• 生成频率：与调用量成正比。高并发的电商系统在促销时段，每分钟能产生上百万条
• 审计价值：根因分析的关键。我个人的经验是：应用日志里必须带上请求链路的trace_id，否则查问题就像大海捞针。

安全日志

安全日志是最“娇贵”的日志类型。它记录了谁、在什么时间、从哪里、做了什么事。

• 典型内容：用户登录成功/失败、权限变更、防火墙规则变更、IDS/IPS告警
• 生成频率：相对低，但每条都可能是安全事件的证据
• 审计价值：合规取证的核心。我见过很多客户的安全日志只保留30天，结果等发现异常回溯时，日志已经被轮转覆盖了。所以DSPM（数据安全态势管理）中对安全日志的保留周期，我一般建议至少180天。

3.2 三大日志标准

日志收上来了，但格式五花八门，怎么统一处理？这就得靠日志标准了。业内有三个最常见的标准，你基本上逃不开：Syslog、CEF、JSON。

Syslog —— 最老牌，也最通用

Syslog诞生于80年代，是网络设备和Unix/Linux服务器的“原住民”。它的消息结构最简单。

你会问，这年头为什么还要学Syslog？我刚开始接触日志审计时也这么想。后来在客户现场，一台老旧的Cisco ASA防火墙，只支持Syslog，不支持别的。你不接也得接。

典型的Syslog消息长这样：

<14>Aug 28 14:23:45 webserver sshd[12345]: Failed password for root from 10.0.0.5 port 22 ssh2

拆开来看：

• <14> —— 优先级值，由设施号(Facility)×8 + 严重级别(Severity)计算得出。14表示Facility=1(user-level)，Severity=6(informational)
• Aug 28 14:23:45 —— 时间戳
• webserver —— 主机名
• sshd[12345] —— 进程名和PID
• 之后的内容 —— 真正的消息体

CEF —— 安全设备的铁杆搭档

CEF（Common Event Format）由ArcSight发明，现在是很多安全产品的事实标准。它的优点是自带结构化字段，解析起来省事很多。

CEF的消息格式：

CEF:0|ArcSight|ArcSight|6.0|1000|Login Failed|5|src=10.0.0.5 dst=10.0.0.1 spt=12345 dpt=22 duser=root

分三个部分：

• Header（头部）：CEF:0|ArcSight|ArcSight|6.0|1000|Login Failed|5|—— 包括版本、设备厂商、设备型号、版本、事件ID、事件名称、严重级别
• Extension（扩展字段）：src=10.0.0.5 dst=10.0.0.1 spt=12345 dpt=22 duser=root—— key=value形式，都是标准化字段

我在项目中用CEF做过不少SIEM规则的编写。它的好处在字段名称有严格的字典定义。比如src一定代表源IP，duser是目标用户名。解析器看到这些字段名就知道怎么映射。

JSON —— 新时代的通用格式

JSON现在几乎成了所有新应用的首选。为什么？因为可读性好、扩展性强，而且几乎每种编程语言都能直接序列化/反序列化。

同样的登录失败事件，JSON写出来是：

{
  "timestamp": "2025-08-28T14:23:45Z",
  "event_type": "login.failed",
  "severity": 5,
  "source": {
    "ip": "10.0.0.5",
    "port": 12345,
    "user": "root"
  },
  "target": {
    "ip": "10.0.0.1",
    "port": 22
  },
  "device": {
    "vendor": "OpenSSH",
    "product": "sshd",
    "version": "8.9p1"
  }
}

你想想看，JSON可以嵌套对象和数组，这在描述复杂事件（比如恶意软件的多个行为链）时特别有用。但它的缺点也一样明显：没有Schema强制约束。同一个字段，在A系统叫user_name，在B系统叫username，你得用ETL做归并。

好，三种类型三种标准，结合下面的图，你应该能看清它们之间的关系了。