第1章 审计日志基础：你系统里的“黑匣子”
聊到审计日志，我脑子里第一个蹦出来的画面，是飞机上的黑匣子。
每次系统出故障，大家第一反应就是“查日志”。但到底查什么？查出来怎么用？很多人其实没想清楚。
嗯，咱们得先把这件事掰扯明白。审计日志，说白了就是一套不可篡改的、按时间顺序记录的系统行为流水账。我见过不少团队把普通应用日志当审计日志用，结果出了事要举证，发现日志被覆盖了...那叫一个头疼。
1.1 审计日志到底是个啥？
官方定义很绕。我用一句话给你讲透：审计日志是“谁、在什么时间、通过什么渠道、对什么资源、做了什么操作、结果怎样”的完整记录。它跟你平时用 console.log 打出的调试日志完全不同。
1.2 审计日志 vs 普通日志
这俩经常被混为一谈。你不信？去翻翻你项目里的 error.log，里面是不是还混着用户登录退出的记录？这就是典型的“没分清楚”。
| 对比维度 | 普通日志 | 审计日志 |
|---|---|---|
| 主要目的 | 排查故障、调试问题 | 安全合规、责任追溯 |
| 数据格式 | 自由文本，随意度大 | 结构化，字段严格固定 |
| 不可篡改性 | 可随意删除、修改 | 要求防篡改（WORM） |
| 保留周期 | 几天到几周 | 数月到数年（法规要求） |
| 典型场景 | “这里报500了，快看看” | “谁在凌晨3点删了数据库？” |
你看，普通日志是写给开发者看的，带一堆调试信息；而审计日志是写给审计员和法律看的，必须清晰、完整、不可抵赖。我个人建议，即使技术方案允许，也绝不要把这两者写到同一张表或同一个文件里。
1.3 审计日志能干啥？
你想想看，一个系统如果没有审计日志，就像一辆车没有后视镜。平时没事，真要并线或倒车的时候，全靠猜。我经历过一次线上事故，DBA误操作删了一张核心表，恢复数据花了6个小时。幸好我们的审计日志记录了完整的操作流水，谁在执行、在哪个窗口、执行的什么SQL，一目了然。这才没让背锅侠变成替罪羊。
具体来说，审计日志有四大核心作用：
- 故障溯源 —— 系统出问题时，快速定位是代码bug、配置错误还是人为误操作。这是最直观的用处。
- 安全威胁检测 —— 发现异常登录、权限滥用、数据批量导出等可疑行为。我见过一个案例，审计日志发现某个运维账号连续三天凌晨访问客户数据库，最终揪出了内鬼。
- 合规证明 —— 满足等保2.0、GDPR、SOX、PCI-DSS等法规要求。没留审计日志，合规检查直接一票否决。
- 业务分析 —— 比如追踪用户行为路径、分析系统资源使用趋势。虽然这不是主要目的，但用好审计数据，往往能发现意想不到的业务洞察。
1.4 常见审计日志类型
审计日志不是一种东西，而是覆盖系统各层的一套“证据链”。我习惯把它分成五个层次：
高能预警：下面这5类日志，是任何一个健康系统都必须采集的。如果你的系统还缺某一类，立刻开工单去补。
- 系统层 —— Linux/Windows secure event log，记录用户登录、sudo提权、系统启停、ssh连接等。这是最基础的。
- 数据库层 —— MySQL general log / audit log，Oracle audit trail，记下每个DML、DDL语句。这个我在项目中踩过坑——审计日志跟业务日志混在一起，一天写十几个GB，把磁盘撑爆了。
- 中间件层 —— Nginx access log（特别是带有POST body的敏感请求），Redis的connect/disconnect记录。记住，不要只记状态码200还是500。
- 应用层 —— 你代码里埋的审计点：用户权限变更、订单状态流转、财务操作等。这是定制性最强的一层，我会在第三章专门讲埋点设计模式。
- 网络层 —— VPC flow log，负载均衡器日志，VPN接入日志。用来追踪数据是否流出边界。
这里我想强调一点：很多时候，单一层级的日志无法还原完整的攻击链或操作路径。比如一个普通员工删了线上数据库，应用层只看到他点了“删除”按钮；系统层记录了他的IP和SSH key；数据库层记录了具体的SQL。只有把这三层关联起来，才能完整还原“是谁、怎么做到的、做了什么”。
知识结构图：审计日志全景
下面这张图可以帮你理清基础知识之间的逻辑关系：