1、审计日志基础：什么是审计日志、常见审计日志类型

各位好，我是老张。干安全运维这些年，跟日志打交道的日子比跟我老婆说话的时间还长。记得刚入行那会儿，领导让我查一台服务器的异常登录，我对着几十个日志文件翻了一下午，最后发现是同事在调试……从那以后我就明白一个道理：不懂日志，就别谈安全。

这一章我们先把地基夯实。什么是审计日志？说白了，就是系统里发生的每一件“值得记录的事”按时间顺序留下的脚印。你想想看，一台服务器从开机到关机，用户登录、文件修改、网络连接、进程启动——这些行为都会被记录。审计日志就是这些记录的集合，它告诉我们：谁、在什么时间、从哪里、做了什么操作。

1.1 审计日志的核心价值

有人问：系统自带那么多日志，为什么非要搞“审计”？我一般只反问一句：如果半夜服务器被入侵，你靠什么还原攻击路径？

• 追责：谁删了数据库？看他账号的操作日志就行。
• 异常检测：凌晨三点大批量登录失败，大概率是暴力破解。
• 合规审计：等保、GDPR都要求保留操作日志半年以上。
• 故障排查：应用挂了？先看错误日志，再看系统日志，定位原因。

1.2 常见审计日志类型

日志类型很多，但常用的就那么几类。我直接列个表格，你一眼就能看明白。

你看，不同类型的日志记录的重点不一样。系统日志关注机器本身的状态，应用日志关注业务行为，安全日志则专盯“异常”和“违规”。

1.3 审计日志的典型字段

不管哪种日志，核心字段其实就那么几个。我习惯把它们归类为“5W1H”：

• Who：用户ID、客户端IP、进程PID
• When：时间戳（精确到毫秒甚至纳秒）
• What：操作类型（登录、读取、删除、写文件）
• Where：源IP、目标IP、文件路径、数据库表名
• How：操作结果（成功/失败）、错误码、返回数据量
• Why：很少直接有，但可以通过上下文推断

举个例子，一条SSH登录失败的日志大概长这样：

2025-03-21 02:15:23 sshd[12345]: Failed password for root from 10.0.0.5 port 54321 ssh2

谁：用户root；时间：凌晨2:15；操作：密码认证失败；从哪里：10.0.0.5；结果：失败。这条日志就是典型的安全日志。

1.4 日志的完整生命周期

写到这里，你可能以为日志就是一条文本文件。其实从产生到销毁，它有一套完整的流程。下面这张SVG图可以帮你快速理解。

从图上可以看出，审计日志就像一个中心枢纽，各类型的日志从四面八方汇聚过来。在实际生产中，这些日志往往分散在不同服务器上，需要我们用采集工具（如Filebeat、Fluentd）统一收拢，然后存储到ES或S3里，最后供异常检测模型消费。

1.5 日志采集的几个要点

光知道类型还不够，怎么收、收多少、存哪，这些坑我一个个踩过。简单说几点：

1. 采集不要影响业务：日志量大的时候，IO和网络都可能被打满。我建议用异步发送、限流、压缩。
2. 格式统一：不同来源的日志格式千差万别，用解析器（如Logstash grok）转换成JSON结构，异常检测模型才能读懂。
3. 存储策略：热数据（最近7天）放ES，冷数据压缩存到对象存储。别傻傻的全都扔ES，钱包受不了。
4. 敏感信息脱敏：密码、身份证、银行卡号别原样记录。我曾经见过一条日志明文打印了用户支付密码……嗯，那是别人的项目。