审计日志概述
聊审计日志之前，我先问个问题：你回忆一下，系统出故障的时候，第一步是去翻什么？大多数人肯定会说——查日志。没错，日志就是系统的“黑匣子”。但今天聊的审计日志，比普通日志更讲究。
审计日志到底是什么？
说白了，审计日志就是一份不可篡改的“操作流水账”。它记录了谁、在什么时候、从哪、做了什么事、结果如何。这跟开发调试时打的 log 不太一样。
我曾经接手过一个金融项目，日志量每天几个 TB。刚开始团队的开发同学习惯性打了一堆 debug 信息，真正出问题时，翻半天找不到是谁干的。后来我们重新梳理了审计日志的标准格式，才把问题理清楚。
核心定义：审计日志是面向安全与合规的、具有固定结构和不可否认性的操作记录。它不是为了追踪 bug，而是为了回答“谁动了我的系统”。
| 维度 | 普通日志 | 审计日志 |
|---|---|---|
| 目标用户 | 开发者、运维 | 安全审计员、合规官 |
| 记录内容 | 变量、异常栈、性能 | 用户、时间、操作、结果 |
| 数据结构 | 自由文本 | 固定的字段集合 |
| 保留周期 | 几天到几周 | 几个月到几年 |
| 易篡改性 | 很高 | 极低（需要做防篡改） |
它的价值在哪？
很多公司把审计日志当成“合规任务”，但我觉得这太浪费了。审计日志真正的作用是三级递进的：
- 事后追责：数据泄露了、配置被改了、某某删了库，审计日志能定位到具体用户和 IP。我记得有一次同事误操作删了一张生产表，6 小时内通过审计日志找出了完整的操作链路。
- 异常发现：日志里藏着攻击者的脚印。比如凌晨 3 点某个普通用户连续尝试删除 500 条记录，这种模式在审计日志里一目了然。
- 合规证明：等保、GDPR、SOX 都有明确的日志留存要求。
我的建议：别等到被审计了才开始搭审计日志。一开始就规划好字段结构，后面改起来成本极高。我见过不少团队为了补日志记录，最后不得不改数据库框架，那叫一个痛苦。
日志从哪儿来？
审计日志的来源其实很广。我习惯把它们归成三类：
- 系统层面：Linux 的
/var/log/secure、Windows 的安全事件 ID 4624/4625。这些日志天生自带审计属性，但粒度粗。 - 应用层面：这是最灵活的一块。自己写的业务系统，想记什么就记什么。但要注意不要记私密信息，比如明文密码。
- 数据库层面：MySQL 的 general log、Oracle 的 audit trail。我自己踩过坑——生产环境开了全量审计日志，直接 IO 打满，数据库挂了。所以一定要按需开启。
每个来源的典型字段
你想想看，不同来源的审计日志，字段其实有共通之处，也有各自的特点。
| 来源 | 典型字段 | 常见问题 |
|---|---|---|
| 系统日志 | 时间、用户、源 IP、操作类型（登录/退出/权限变更） | 时间戳精度不够，只能到秒级 |
| 应用日志 | 会话 ID、请求参数、响应码、执行耗时 | 容易把敏感信息（如 ）写进去 |
| 数据库日志 | SQL 语句、影响行数、事务 ID、登录用户 | 全量开启后磁盘容量暴涨，IO 成为瓶颈 |
我曾经踩过的坑：在一套支付系统里，把完整的请求体写进了审计日志。结果有一天日志文件被拉去分析，直接把用户的银行卡号暴露了。从那以后，我要求所有审计日志字段都必须经过“敏感字段清洗”步骤，手机号、身份证、密码必须脱敏或者直接不记录。
审计日志的定义、作用和来源，说白了就是一门“记录”的学问。但记录得好不好，直接决定了后面的告警规则能不能发挥作用。嗯，这里要注意一个点：所有来源的日志，时间戳必须统一用 UTC，不然跨系统做关联分析时你会疯掉的。