1. 审计日志概述：定义、重要性、常见来源
大家好，我是老张，做安全运维差不多十年了。今天咱们正式开始聊审计日志异常检测。第一节课，先把底子打牢——审计日志到底是什么，为什么重要，以及它从哪里来。
说白了，审计日志就是系统里的一本“流水账”。每个用户干了什么，系统哪个进程出了问题，数据被谁改过，全记在里面。没有这本账，出了事你就是两眼一抹黑。
核心一句话：审计日志是数字世界的“黑匣子”，记录一切可追溯的操作行为。
1.1 审计日志的定义
官方定义你查文档都查得到，我按自己理解给你拆一下。审计日志需要满足三要素：
- 谁（用户/进程/IP）
- 什么时间（精确到毫秒的时间戳）
- 做了什么（操作类型、对象、结果）
举个例子，你登录服务器时系统会记一条：2025-07-11 14:32:18, user=zhangsan, action=ssh_login, source_ip=10.0.0.5, success=true。这就是一条典型的审计日志。我在项目里见过不少团队把应用日志和审计日志混在一起，结果出问题时根本分不清是业务异常还是安全事件，坑得很。
我的习惯：审计日志必须独立存储，不能和应用日志混用同一个文件或数据库表，否则检索效率极低。
1.2 为什么审计日志这么重要？
你想想看，没有审计日志，出了安全问题你怎么复盘？总不能靠猜吧。重要性我归纳成四个点：
| 维度 | 说明 |
|---|---|
| 合规审计 | 等保、GDPR、SOX 等法规要求保留操作记录，没有日志直接违规。 |
| 安全溯源 | 检测到攻击后，靠日志反推入侵路径、定位漏洞。 |
| 故障排查 | 系统挂掉时，日志能告诉你崩溃前的最后一刻发生了什么。 |
| 行为分析 | 异常检测的原材料就是日志，数据质量决定告警准确率。 |
我记得有一次线上数据库被删了，幸亏有审计日志，发现是一个离职员工的账号还在有效期内。从那以后我强制所有系统都做了账号回收和日志实时监控——血的教训啊。
注意：日志量越大，存储成本越高。但别为了省钱减少关键字段的采集，否则等于白记。我曾经见过某团队为了省硬盘，把 source_ip 字段去掉了，然后溯源时完全找不到攻击来源，急得跳脚。
1.3 审计日志的常见来源
来源其实挺杂的，但主流就三大类：系统日志、应用日志、安全日志。下面这张图可以帮你快速建立框架：
1.3.1 系统日志
操作系统和基础设施组件产生的日志。比如 Linux 的 /var/log/messages、/var/log/syslog，Windows 的事件查看器。内容涵盖设备状态、服务启停、硬件告警等。我建议你重点关注 /var/log/secure 或 Windows 安全日志里的登录事件，这是异常检测的重灾区。
1.3.2 应用日志
业务软件自己打印的记录。比如 Nginx 访问日志、Tomcat 的 catalina.out、MySQL 的 slow query log。这类日志格式差异最大，我见过有的团队自己研发的微服务日志居然用竖线分隔字段，解析起来特别痛苦。异常检测时，应用日志里的错误码和响应时间突变是很好的特征。
1.3.3 安全日志
专门的安全设备或模块输出的日志。防火墙、WAF、IDS/IPS、VPN、堡垒机都属于这一类。数据量相对少，但价值超高，几乎每条都可能和攻击相关。我曾经在处理一次勒索病毒事件时，就是靠防火墙的 deny 日志发现了被感染的机器在内网横向移动。
个人经验：很多公司只收集了系统日志，忽略了应用日志和安全日志，导致异常检测覆盖面只有不到 30%。我建议三个来源都要接入，缺一不可。
1.4 日志的基本格式
不管来源是哪一类，好的日志应该包含以下字段（我称之为“黄金五元组”）：
| 字段 | 描述 | 示例 |
|---|---|---|
| 时间戳 | 事件发生的精确时间 | 2025-07-11T14:32:18.123Z |
| 来源 | 产生日志的组件/主机/IP | 10.0.0.5 或 app-server-01 |
| 主体 | 执行操作的用户或进程 | zhangsan 或 cron |
| 动作 | 执行的操作类型 | read, write, delete, login |
| 结果 | 是否成功及附加信息 | success, failed(Error 403) |
嗯，这里要注意——缺少任何一个字段都会导致后续检测困难。我见过最头疼的情况是：时间戳没有时区信息，或者来源字段只写了 localhost，排查时根本不知道是哪台机器。
避坑指南：我曾经接手过一个客户的日志系统，时间戳格式竟然有Unix秒、ISO8601、自定义格式三种混用，导致时序分析完全乱套。建议统一用 ISO8601 带时区的格式，比如 2025-07-11T14:32:18.123+08:00。
1.5 小结
这一章咱们把审计日志的底子打好了。搞清楚了它是黑匣子，它来自系统、应用、安全三大块，每条日志都该有“黄金五元组”。后面所有的异常检测算法和告警策略，都是建立在这些基础之上的。
说白了，日志质量决定了检测上限——垃圾进，垃圾出。所以下一步，我们要聊聊怎么把这些不同来源的日志统一采集和清洗，让它们变成机器能理解的结构化数据。别急，一步步来。