📚 课程目录第4章审计日志类型

4、审计日志类型：系统日志、应用日志、数据库日志、网络日志、安全设备日志

审计日志到底长什么样？这个问题我当年刚入门时也困惑过。你以为审计日志就是txt文件里一堆时间戳？其实没那么简单。不同类型的系统，日志格式、内容、采集方式天差地别。今天咱们就掰开揉碎了说说这五类最常见的审计日志。

4.1 系统日志

系统日志是操作系统的亲儿子。Windows的Event Log，Linux的/var/log/messages、/var/log/secure，这些都是系统级事件的直接记录。说白了，谁登录了、什么时候重启的、哪个内核模块报错了，全在这。

我个人的习惯，做合规审计时一定先检查系统日志里的认证事件。为什么？因为这是攻击者的第一落脚点。你在Windows安全日志里看到连续10次登录失败然后第11次成功，这大概率就是暴力破解得手了。

系统日志必看字段

事件ID / Event ID：Windows用4624表示登录成功，4625表示登录失败
时间戳：精确到毫秒，UTC标准
用户ID：SID或UID，别只看用户名
源IP：登录来源，内网/外网要区分
进程ID：是谁启动了这次操作

# Linux查看认证失败的SSH登录记录
grep "Failed password" /var/log/secure | tail -5

# 输出示例
# Jun 12 03:14:08 web01 sshd[12345]: Failed password for root from 10.0.0.33 port 51234 ssh2
# Jun 12 03:14:10 web01 sshd[12345]: Failed password for root from 10.0.0.33 port 53212 ssh2

我曾经遇到过一家客户，系统日志被删了前三个月的，问他们怎么回事，说是磁盘满了自动清理。嗯，这里要注意——合规审计要求日志保留至少180天，系统日志的轮转策略必须在合规框架内设计。

4.2 应用日志

应用日志是你的业务大脑。电商的订单创建、银行的转账记录、CRM的客户修改，全写在应用日志里。审计时我最关注应用日志，因为它直接反映业务操作的真实意图。

应用日志的格式各家不同，但一般包含：请求URL、请求参数、响应码、处理耗时。我建议你在设计阶段就约定一个日志规范，否则后期解析会让你崩溃。

应用日志设计黄金法则

每一条应用日志必须能回答三个问题：谁（用户ID）？做了什么（操作类型）？结果怎么样（成功/失败/拒绝）？

# 一个规范的应用日志条目示例
{
  "timestamp": "2025-04-08T09:15:23.456Z",
  "user_id": "u_2023_zhangsan",
  "session_id": "sess_abc123",
  "action": "ORDER_CREATE",
  "resource": "order/ORD20250408-001",
  "amount": 2999.00,
  "source_ip": "192.168.1.100",
  "result": "SUCCESS",
  "duration_ms": 123
}

4.3 数据库日志

数据库日志是数据的最后防线。你想想看，业务应用说删了条数据，到底真删了没？谁执行的DELETE？数据库日志会告诉你真相。MySQL的binlog、Oracle的redo log和audit log、PostgreSQL的WAL，都属于这类。

我在项目中遇到过客户说数据被恶意修改了，查了一圈应用日志都是正常的，最后在数据库审计日志里找到了一个从数据库管理工具直连的IP。这个IP根本不是应用服务器，而是攻击者通过跳板机直接连了数据库主库。嗯，入口没锁好。

数据库审计日志启用警告

数据库审计日志会显著影响写入性能。我建议生产环境只对关键表（用户表、订单表、权限表）开启审计，不要全库全表审计。我曾经见过有人全表开启后，写入TPS直接从5000掉到800。

数据库类型	日志文件	审计启用方式
MySQL	binlog / 审计插件	-- audit_log=ON
Oracle	redo / audit trail	AUDIT_ACTIONS 策略
PostgreSQL	WAL / log_statement	log_statement = 'all'
SQL Server	.ldf / 审计日志	创建服务器审计

4.4 网络日志

网络日志是你的高速公路监控。防火墙连接记录、路由器NetFlow、交换机端口日志，这些记录了每一段网络流的来龙去脉。审计时我习惯先看网络日志里的东西向流量，很多内网横向移动攻击就藏在这里。

举个例子，某台业务服务器平时只跟应用服务器和数据库通信，突然大量连接外部IP，那十有八九是被日了在往外传数据。网络日志里的目的IP、端口、传输字节数，全都能作为证据。

网络日志审计清单

防火墙连接创建/拒绝/超时记录
VPN用户登录/注销/异常断开
DNS查询日志（疑似C2通信）
NetFlow/流量元数据（跨区访问）
DHCP IP分配日志（设备接入记录）

# 防火墙日志片段示例
# 格式: 时间 | 源IP:端口 | 目的IP:端口 | 协议 | 动作
2025-04-08T09:20:00 192.168.1.10:51234 -> 203.0.113.5:443 TCP ALLOW
2025-04-08T09:20:01 192.168.1.10:51235 -> 203.0.113.5:443 TCP ALLOW
2025-04-08T09:20:02 10.0.1.5:3389   -> 10.0.2.10:3389 TCP DENY

网络日志采集策略

我建议只保留安全相关的事件：拒绝连接、异常端口访问、跨子网访问、外网连接。所有的ALLOW的普通流量，只保留1天即可，否则存储成本你扛不住。

4.5 安全设备日志

安全设备日志是你的哨兵。WAF拦截的SQL注入、IDS/IPS捕获的异常流量、EDR检测到的恶意进程、DLP拦截的数据外发，这些都是安全日志的核心。审计合规要求中，安全日志的留存周期通常是其他日志的两倍——不少标准要求保留至少1年。

我记得有一次做等保测评，客户说他们有WAF日志，一看，发现WAF日志里记录了每天上百条SQL注入攻击，但安全团队根本没看。为什么？因为没有日志分析平台，全堆在设备本地，根本没人去翻。

安全日志常见误区

不要以为开日志就等于有安全审计。我曾经见过客户把IDS日志的告警级别全设成最高，结果每天几万条告警，没人看也没人分析。日志要有告警降噪策略，要定期review，否则就等于没日志。

# WAF安全日志示例
{
  "type": "WAF",
  "rule_id": "942100",
  "severity": "CRITICAL",
  "attack_type": "SQL_INJECTION",
  "src_ip": "185.220.101.23",
  "request_url": "/product?id=1 UNION SELECT * FROM users",
  "action": "BLOCKED",
  "timestamp": "2025-04-08T09:25:00Z"
}

不同类型的安全设备日志格式差异很大。WAF关注HTTP请求负载，EDR关注进程行为，防火墙关注网络流，DLP关注数据内容。但你记住，所有安全日志最终要归一到同一个标准字段体系下，不然你的SIEM没法做关联分析。

4.6 五类日志总结对比

学完这五类日志，你可能会觉得内容有点多。嗯，来，我帮你梳理一下核心区别：

日志类型	核心关注	典型攻击场景	保留期限建议
系统日志	登录、权限、进程	暴力破解、提权	180天
应用日志	业务操作、错误	越权访问、逻辑漏洞	180天
数据库日志	SQL、数据变更	SQL注入、数据泄露	180天
网络日志	连接、流量、协议	C2通信、横向移动	90天
安全设备日志	威胁告警、拦截	Web攻击、恶意软件	1年+

最后再强调一句：审计日志不在于多，在于有效。与其堆满TB级别的冗余日志，不如把这五类日志的关键字段梳理清楚。很多合规审计的整改项，其实就是在日志完整性上出了问题。你能做到每类日志都有、关键字段全覆盖，基本就能通过大部分合规检查了。