第三讲·审计日志基础：格式、来源与存储
审计日志啊，你想想看，搞密文检索最头疼的是什么？不是算法选型，不是性能调优，而是出了事找不到证据。我入行那会儿带我的师父说过一句话，我到现在都记得——“没日志，你连甩锅的资格都没有。”
这一讲咱们就聊聊审计日志。说白了，它是整个安全审计体系的原料。原料质量决定了你能做出什么菜。你可能会觉得日志不就是记点东西吗？没那么简单。我见过太多因为日志格式不统一导致巡检脚本跑崩的案例了。
3.1 日志格式：别在这个坑里摔两次
常见的审计日志格式就那么几种。但我劝你一句，别以为格式是小事。格式不统一，后面所有工具链都得跟着遭殃。
| 格式类型 | 典型代表 | 我的评价 |
|---|---|---|
| CEF | ArcSight | 字段清晰，解析起来很爽 |
| LEEF | QRadar | 扩展性强，但容易写烂 |
| JSON | Elasticsearch | 灵活，但也最考验规范 |
| Syslog | RFC 5424 | 老古董，但依然常见 |
我个人习惯用 JSON 格式。为什么呢？因为它结构化程度高，而且现在大部分安全分析工具都原生支持。我曾经在一个项目里碰到过团队自研的二进制日志，解析脚本写了三天，最后发现还是在用文本存 key-value——你说这折腾的啥呢？
避坑指南
千万不要在日志里混用多种分隔符。我见过一个日志文件，同一行里既有竖线又有逗号还有制表符——那感觉就像吃火锅吃出三种蘸料混在一起，恶心。
3.2 日志来源：你知道的，和你该知道的
好，格式聊完了，咱们聊聊来源。审计日志从哪来？你可能会说“服务器日志嘛”。没错，但不够全。
3.2.1 系统层日志
- 操作系统日志：Linux 的 /var/log/secure、Windows 的 EventLog。我建议你把 auth.log 和 syslog 都收了，别漏。
- 网络设备日志：防火墙、IDS/IPS。这些家伙的日志量特别大，要做好抽样策略。
- 数据库日志：尤其是审计日志插件输出的东西。MySQL、PostgreSQL 都有。
3.2.2 应用层日志
- WAF 日志：Web 应用防火墙的访问记录，里面藏着大量攻击线索。
- 认证服务日志：LDAP、Kerberos、OAuth。登录失败记录特别重要。
- API 网关日志：密文检索的流量入口，每个请求都有日志。记得把 脱敏。
一点建议
我在项目里经常见到只收集系统层日志的团队。结果出了事才发现，应用层的那个关键 API 调用根本没记下来——那种感觉，真叫一个欲哭无泪。所以，宁可多收，不要少收。存储不够可以压缩，但漏了就是漏了。
3.3 日志存储：光有地方放可不够
日志收集来了，放哪？硬盘？当然可以。但你想想看，每天几十个 G 的审计日志，全都扔在本地磁盘上，等你想查的时候——不好意思，半年后了。
我给大家分享一个我踩过坑的真实案例：
我曾经犯过的错
有一次项目上线，我图省事，把审计日志直接写到了应用服务器的本地盘。结果出事那天，硬盘直接写满了，日志丢失了最后两个小时的数据——那两小时，正好是攻击者最活跃的时间段。从那以后，我再也不把日志往本地盘上糊了。
合理的做法是什么？分层存储。来个表格说清楚：
| 存储层 | 用途 | 保留周期 |
|---|---|---|
| 热存储 | 实时分析与最近追查 | 7-30 天 |
| 温存储 | 月报、合规审计 | 3-6 个月 |
| 冷存储 | 长期存档、司法取证 | 1 年以上 |
我在实际项目里喜欢用 Elasticsearch 做热存储，S3 或 HDFS 做温冷存储。再加上一个定时的归档脚本，把超过 30 天的日志压缩后移走。嗯，这里要注意：压缩前一定要做完整性校验。我曾经一次归档脚本写错了，搬过去的数据全是断行——你说愁不愁？
3.4 核心逻辑：一条审计日志的生命周期
讲了这么多，我觉得有必要画一张图来帮大家建立整体认识。从日志产生到最终落地存储，中间经过多少步？
3.5 实战：一个日志记录示例
光说不练假把式。我给你看段去年我写的一个审计日志记录片段。这个例子来自一个密文检索服务的 API 调用审计：
{
"timestamp": "2025-03-15T14:23:17.852+0800",
"source_ip": "192.168.1.105",
"user_id": "U20230315001",
"action": "SEARCH",
"query_hash": "a1b2c3d4e5f6...",
"result_count": 27,
"elapsed_ms": 345,
"status": "SUCCESS"
}看到没？每个字段都很有用。timestamp 决定了时间线分析能不能对齐；query_hash 是密文检索查询的特征值，你用它关联多笔日志就能画出一条攻击链条。我就在一次内部演练里，靠这个 hash 追到了三台被控机器之间的一跳。
小技巧
我建议你给日志字段名设定一个前缀规范。比如所有审计字段以 audit_ 开头，这样未来做字段映射的时候会省很多事。千万别想到什么字段加什么字段，最后就变成了大杂烩。
3.6 说说时间对齐这件事
最后聊一个特别容易忽略的点：时间戳。不同设备、不同服务产出的日志，时间戳格式五花八门。有的用 UTC，有的用本地时区，有的干脆不带时区。你想想看，把相差了 8 个时区的两条日志放一起分析，那能对得上吗？
我的做法很简单：全部统一成 UTC，并且强制使用 ISO 8601 格式。这个在日志收集阶段就做掉，别拖到分析阶段再处理。嗯，说起来简单，但我当初调这个逻辑调了整整一个下午才把 logstash 的时间解析插件配置对。
好了，审计日志的基础到这里就差不多了。格式、来源、存储、时间对齐——这四个点你吃透了，后面讲巡检和异常检测，你才能跟得上。