第1章 审计日志概述
1.1 什么是审计日志
审计日志，说白了就是一本不可篡改的流水账。它记录的是：谁、在什么时候、通过什么方式、对什么资源、做了什么操作。
我刚开始接触安全审计时，总觉得审计日志跟普通应用日志差不多。后来在项目里踩过一次坑——线上系统出了安全事件，查历史操作记录，发现应用日志被人改过。从那以后，我再也不敢把审计日志跟普通日志混为一谈了。
它们最核心的区别在于：审计日志必须保证完整性和不可抵赖性。普通日志可以删、可以改，但审计日志不行。它的记录要经得起事后审查，哪怕是一个无效的登录尝试，也不能丢。
1.2 审计日志的核心特性
我在多家公司参与过审计系统改造，总结下来，优秀的审计日志应当具备以下特性。嗯，这几点你想想看，哪条缺了，审查时都可能出问题。
- 完整性 —— 日志一旦生成，就不能被任何用户（包括 root）中途删除或修改。
- 不可抵赖性 —— 记录中包含数字签名或哈希链，确保操作者事后无法否认。
- 时间精确性 —— 时间戳必须统一使用 UTC 或 NTP 同步，不能依赖本地时间。
- 结构化与格式化 —— 字段固定，便于索引和查询。我见过一些团队直接存 JSON 字符串，查起来非常痛苦。
- 物理隔离 —— 审计日志最好单独存放到只写一次、不可覆盖的存储中，比如 WORM 设备或者加密的 S3 桶。
sequence_number 字段，配合时间戳可以快速发现是否有中间记录被删除。这是一个很小的优化，但排查问题时非常好用。
1.3 审计日志的常见来源
审计日志不是单个系统能搞定的。企业环境里，少说几十个组件，每个都在产生审计事件。我把最常见的来源整理成了表格，方便你对照检查。
| 来源类别 | 典型组件 | 记录的关键事件 |
|---|---|---|
| 操作系统 | Linux auditd、Windows EventLog | 用户登录/登出、权限变更、文件访问 |
| 数据库 | MySQL audit plugin、Oracle Audit Vault | SQL 执行、表结构变更、数据导出 |
| 应用系统 | Web 服务器、微服务网关 | API 调用、敏感数据查询、认证失败 |
| 网络设备 | 防火墙、VPN、交换机 | 连接建立/断开、规则变更、异常流量 |
| 云平台 | AWS CloudTrail、Azure Monitor | IAM 操作、资源创建/删除、密钥轮换 |
我记得有一次做异构审计系统对接，数据库的 audit log 时间戳用的是应用程序服务器的时间，跟系统日志差了两小时。排查那起事件时，光对齐时间就花了一周。所以，时间统一这件事再强调也不为过。
1.4 审计日志与合规要求
为什么企业非要花资源搞审计日志？很多时候不是因为技术需要，而是合规在背后推着走。你想想看，下面这些标准哪个不要求你保留审计记录？
- SOX 法案 —— 要求上市公司保留财务相关系统操作日志至少 7 年。
- PCI DSS —— 要求对持卡人数据的访问进行审计，日志保留 12 个月。
- GDPR —— 要求记录个人数据的处理活动，并且能提供可审计的证据。
- 国家等保 2.0 —— 要求三级以上系统审计日志保留 180 天以上。
这些合规要求有一个共同点：日志不仅要存，还要能高效查询。但问题来了——原始审计日志量极大，一天可能几亿条，直接查慢得要命。这就引出了我们这门课的核心：如何加密存储的同时，还能做到快速检索。
1.5 审计日志的生命周期
审计日志从诞生到销毁，通常经历五个阶段。我画了一张流程关系图，帮你建立整体认知。
这个生命周期图展示了最基本的闭环。你可以看到，加密存储和加密查询是本课程着重优化的两个环节。普通做法是存明文、加索引，但一旦加密，普通的 B-tree 就用不了了。怎么办呢？后面的章节我会带你一步步解开这个谜题。
1.6 本章小结
审计日志不是简单的“记录+存储”。它承载着安全追溯、合规审查、事件溯源等多重使命。在实际架构中，你不仅要考虑日志怎么收，更要提前规划好怎么加密、怎么查得快。
- 审计日志的特点：完整、不可抵赖、时间一致、结构清晰。
- 来源众多，必须统一时间、格式、协议。
- 合规要求推动我们必须加密存储，但加密不能拖垮查询性能。