审计日志基础：日志格式、来源、常见类型
讲到审计日志，很多新手第一反应就是“不就是系统里那些记流水账的文件嘛”。这么说倒也没错，但如果你真把它当流水账看，后面做异常检测时就会处处碰壁。我自己的经验是——搞懂日志的“骨架”比看懂某一条日志重要得多。
这一章咱们就把审计日志的底裤扒干净：它长什么样、从哪来、通常记些什么。你如果能把这三块吃透，后面建模、调特征的时候至少能少踩一半的坑。
2.1 日志格式：不只是文本，是有结构的
审计日志要是没格式，那跟菜市场里的喊价声一样——听得见但抓不住规律。现实中的日志格式五花八门，但大部分能归到下面这几种。
| 格式 | 典型代表 | 结构特点 | 适用场景 |
|---|---|---|---|
| Syslog (RFC 5424) | Linux / Unix 系统日志 | 头部固定：时间、主机、进程、消息体 | 系统级监控、安全审计 |
| JSON | 云平台日志 (AWS CloudTrail、Azure Monitor) | Key-Value 对，可嵌套，易于解析 | 程序化处理、机器学习特征提取 |
| CEF (Common Event Format) | SIEM 工具 (ArcSight、QRadar) | 管道符分隔，标准字段 + 扩展键值 | 安全事件集成、跨设备关联 |
| W3C 扩展日志 | Web 服务器 (IIS、Apache) | 固定字段序，空格/制表符分隔 | Web 访问审计 |
我个人最常用的是 JSON 格式。为啥？因为解析成本低、扩展性好。你在 JSON 里加一个新字段完全不影响老的解析器——这在异常检测特征迭代时太重要了。
我的小习惯：
如果你是自建日志收集系统，强烈建议统一输出 JSON。哪怕上游是 syslog，也先转成 JSON 再入库。我在一个国家级安全项目里见过直接拿原始 syslog 做 ML，结果字段错位导致模型全废——白干了两个月。
2.1.1 一个典型的 JSON 审计日志长这样
{
"timestamp": "2025-06-10T14:32:17.123Z",
"source": "auth-server-01",
"user": "zhangsan",
"action": "LOGIN_FAIL",
"target": "ssh://192.168.1.100",
"result": "DENIED",
"reason": "invalid_password",
"session_id": "sess-a1b2c3d4",
"src_ip": "10.0.0.55",
"extra": {"attempt_count": 3}
}
你仔细看——time、source、user、action、result 这五个字段是所有异常检测算法的“铁三角”。无论你用统计方法还是深度学习，这三个维度几乎一定会被用到。嗯，这里要注意：extra 字段千万别滥用。我见过有人把几十个键都塞到 extra 里，结果解析性能掉了 30%。
2.2 日志来源：该收哪些、不该收哪些
很多初学者恨不得把全公司的网络设备日志全收了——CPU 100%，存储天天告警，最后模型效果还稀烂。你想想看，日志来源也是要筛选的。
下面这张 SVG 图把审计日志的核心来源、格式、类型串起来了，你先拿它当大脑皮层的地图。
2.3 常见类型：你真正需要盯住的几类
审计日志的类型成百上千，但真正对异常检测有用的就那么几类。我按照自己在多个项目中的复盘经验，给你列了一个“必收清单”。
2.3.1 认证与授权事件
这是异常检测的“第一道防线”。登录成功/失败、会话创建/销毁、密码修改、权限提升……连续失败的登录几乎就是暴力破解的指纹。但你要注意：很多攻击者会拉长时间窗口来绕过阈值检测。我曾经接手一个案子，攻击者每天只试 5 次密码，连续搞了 3 周——传统的阈值报警完全没用，最后还是靠时序异常检测才逮住。
2.3.2 访问控制事件
谁在什么时间、通过什么方式、访问了什么资源。这里要特别关注 特权账号的操作。比如 root 在凌晨三点登录了 Web 服务器，或者一个普通用户突然开始读 /etc/shadow——这类事件在正常环境中非常稀疏，一旦出现基本可以判定为异常。
2.3.3 变更操作事件
配置修改、软件安装、防火墙规则变更、用户权限变更。异常检测里一个很重要的思路是基线偏离：如果一台服务器过去 90 天从未在晚上 10 点后发生过配置变更，今天突然变了，这本身就是一个强信号。我在金融客户那里做过一个模型，专门抓“非维护窗口的配置变更”，效果奇好。
2.3.4 系统异常事件
服务崩溃、磁盘写满、CPU 飙高、网络端口扫描……这些事件往往不是攻击本身，而是攻击的前兆或副作用。举个例子，挖矿木马会大量占用 GPU 资源，导致温度告警——如果你只看认证日志，永远看不到。
核心建议：
前期不要贪多。先收齐 认证 + 访问 + 变更 这三类，跑通第一个异常检测管道。后期再加系统异常和其他来源。我在一个创业公司见过把 200 种日志全收进来，结果模型训练跑了三天三夜没收敛——那真是自己给自己挖坑。
2.4 日志采集的常见陷阱
最后，我再说几个自己踩过的坑。你如果在搭建采集架构时能避开，我保证后面省一半的排查时间。
- 时间同步问题：不同设备的时间戳不一致，导致关联分析时出现“未来事件”。解决方案统一用 NTP，并且在日志中保留 UTC 字段。
- 日志截断：有些设备默认单条日志长度限制是 1024 字节，超长日志会被截断。我曾经因为没注意这个，导致模型在解析 payload 时总缺关键字节。解决方案是采集端配置 truncate 警告或自动分片。
- 重复日志：多个采集端同时收同一来源的日志，造成 event_id 重复。这会让基于计数的异常指标完全失真。务必在 pipeline 入口做 dedup。
- 敏感信息洗脱：审计日志里可能包含明文密码、身份证号、信用卡。如果你直接把原始日志灌到 ML 模型里，容易被审计法规锤。建议在采集端做脱敏或过滤。
⚠ 记得做日志回滚
你收集的所有审计日志都会占用磁盘。别等到存储爆了才想起删。定个策略：原始日志保留 30 天，提取的特征保留 180 天。我见过客户把 5 年的日志全堆着，结果给运维找麻烦——而且异常检测模型根本用不到那么老的数据。
好，这一章的内容就到这里。你只要理清了格式、来源、类型这三根柱子，后面建模型的时候就相当于有了坚实的地基。下一步我们就要拿这些日志实际做特征提取了——记得把本章的 JSON 示例存下来，后面会反复用到。