1. 审计日志基础：从“谁动了我的系统”说起

说实话，刚开始接触审计日志那会儿，我也觉得它就是一堆杂乱无章的文本记录。直到有一次帮客户排查数据泄露事件，翻了三天日志才找到关键线索，我才真正意识到——审计日志不是干巴巴的记录，而是系统留给我们的‘黑匣子’。

这一节，我们就从最基础的东西聊起。我会结合自己踩过的坑，把审计日志是什么、有什么用、长什么样，给你掰碎了讲清楚。

1.1 什么是审计日志？

审计日志，说白了就是系统里所有关键操作的“流水账”。它记录了谁、在什么时间、从哪里、做了什么操作、结果怎么样。

你打开手机，会看到“上次登录时间”——其实这就是最简化的审计日志。对于真正的生产系统，记录要详细得多。

1.2 审计日志的价值在哪里？

很多团队把审计日志当成“合规的摆设”。我经历过最典型的一个场景：客户问“能不能查出来上周是谁删了核心数据表？”，结果发现审计日志根本没开……

真实的价值至少体现在这三个方面：

1.3 常见的审计日志类型

不同的系统组件，日志格式和内容差异很大。我把它分成三大类来讲。

1.3.1 操作系统日志

操作系统日志是你接触最多的那类。Linux和Windows各有自己的体系：

• Linux（syslog/rsyslog/journald）：记录登录、sudo操作、服务启停、内核事件
• Windows（Event Log）：分成系统、安全、应用程序三大类，Security日志尤其重要

我个人习惯用 journalctl 查Linux日志，但生产环境中更推荐统一采集到ELK或Splunk里集中分析。

# Linux 查看用户登录记录
last -F | head -5

# 查看 sudo 操作
journalctl -u sshd --since "2024-01-01"

# Windows 常见事件ID
# 4624: 成功登录
# 4625: 登录失败
# 4648: 使用显式凭据登录

1.3.2 数据库日志

数据库日志是审计的“重灾区”。为什么？因为数据是最核心的资产，而数据库本身的操作审计，很多团队做得不够细。

我在项目中遇到过一件事：一个DBA误操作删除了分区表，结果MySQL的binlog只保留了1天。想恢复数据？没门。从那以后，我给自己定了个规矩：生产库的审计日志，至少保留7天，binlog保留3天以上。

-- MySQL 启用审计日志（audit_log插件）
INSTALL PLUGIN audit_log SONAME 'audit_log.so';
SET GLOBAL audit_log_policy = 'ALL';

-- 查看当前审计配置
SHOW VARIABLES LIKE '%audit%';

1.3.3 应用日志

这个范围其实很广。Web服务器、微服务、API网关……只要是你自己开发的系统，都在这个范畴里。

应用日志的难点在于：没有统一标准。有人用JSON，有人用纯文本，有人什么都往一行里塞。嗯，这里我要强调一个观点：应用日志里如果没有“请求ID”和“用户标识”，排查问题基本靠猜。

// 一个良好的应用审计日志格式（JSON）
{
  "timestamp": "2024-06-15T09:23:17+08:00",
  "trace_id": "a1b2c3d4e5f6",
  "user_id": "uid_10086",
  "action": "DELETE_ORDER",
  "target": {
    "order_id": "ORD20240615001",
    "amount": 2999.00
  },
  "result": "success",
  "source_ip": "10.0.1.23"
}

1.4 整章知识结构

我把这一章的知识点画成了图。你看一眼就知道我们讲了什么：审计日志长什么样、为什么重要、以及最主要的三大类日志各自的特点。

图里把这三件事串了起来：左边是你需要知道的定义，中间是它能帮到你什么，右边是三大类日志往下展开的细节点。每一类日志都有它独特的适用场景和坑——后面我们会挨个展开聊。