审计日志的基本概念：事件、日志记录、审计策略
做审计日志这行，你首先得搞清楚三个最基础的东西：事件、日志记录、审计策略。这三个词看着简单，但实际落地时坑不少。我刚开始接触审计日志时，以为只要把系统日志全打开就行，结果被海量日志淹没了，连异常都找不到。后来才明白，这三个概念是层层递进的关系。
一、事件：审计日志的“原子单位”
什么是事件？说白了，就是系统里一个“发生了的事”。用户敲了一条命令、程序打开了一个文件、防火墙拒绝了一个连接——这些都是事件。不过呢，不是所有事件都要记录，否则磁盘会爆炸。我曾在项目里见过有人开启了Windows的“所有登录事件”审计，结果域控一天写了20GB日志，最后不得不连夜改策略。
事件通常包含几个关键属性：
- 事件来源——哪个组件产生的？（如Linux auditd、Windows Security Log、MySQL audit log）
- 事件类型——登录、文件操作、权限变更、网络连接等。
- 时间戳——最好是高精度时间（纳秒级），免得排查时对不上账。
- 主体——谁干的？（用户ID、进程ID、服务账号）
- 客体——对什么操作的？（文件名、注册表项、数据库表）
- 结果——成功还是失败？
关键认知：事件本身是瞬时发生的，而日志记录是事件的“快照”。事件只在内存里存在几微秒，但日志可以存几年。审计策略决定哪些事件值得抓拍。
二、日志记录：把事件变成可读的存证
日志记录就是把事件“写下来”的过程。我见过不少团队，以为把日志写到文件里就完事了。其实格式、轮转、传输、防篡改都是大问题。举个例子，你写了一条日志，但磁盘满了写不进去，那跟没记有什么区别？
常见的日志记录形式：
| 格式 | 特点 | 典型场景 |
|---|---|---|
| 纯文本（Syslog） | 易读、占用小、解析麻烦 | Linux系统、网络设备 |
| JSON | 结构化、易解析、字段可扩展 | 微服务、云原生环境 |
| 二进制（ETW） | 高性能、低开销、需工具解析 | Windows高级审计 |
| 数据库表 | 支持索引、查询快、但写压力大 | 自建审计系统 |
我个人比较推荐JSON格式做集中式审计。它的可读性和可解析性平衡得最好。有一次做合规审查，甲方要求审计日志必须包含“源IP、目标IP、操作类型、时间、结果”五个字段。用JSON，我直接在日志里加个字段就搞定，文本文件就得改正则，麻烦多了。
实用技巧：每条日志记录最好包含一个唯一ID（UUID或递增序列号），方便后续去重和关联分析。我曾经因为没加这个，排查重复告警时浪费了半天。
三、审计策略：决定记什么、不记什么
审计策略就是一套规则，告诉审计系统：“你盯着这些事，其他的别管。”没有策略，就是裸奔或过度记录。我见过最典型的问题是：为了省事，直接开启“记录所有操作”，结果日志量暴涨，存储成本飙升，真正有价值的信息反而被淹没。
定义审计策略时，通常要考虑这几个维度：
- 谁被审计？——所有用户？敏感账号？root/administrator？
- 什么操作？——登录/注销、文件读写、权限提升、配置变更。
- 什么条件触发？——成功还是失败？一次还是多次？
- 记录到哪里？——本地文件、远程syslog、SIEM平台？
- 何时告警？——失败次数超过阈值？非工作时间操作？
你想想看，如果公司有人事系统，你会记录所有人查工资单的操作吗？通常只记录管理员和异常行为就够了。策略粒度要细，否则就是给自己挖坑。
避坑指南：我曾经在一家金融公司做审计整改，旧策略里把“读取任何文件”都记下来了。结果一个开发同学每天编译代码，产生上百万条“读取.so文件”的日志……这完全没意义。后来策略改成只记录“写操作”和“权限变更”，日志量直接降了90%。
三者关系：从事件到策略的链条
我再用一句话总结它们的递进关系：
- 事件是原材料——客观发生的事，不可控。
- 日志记录是加工工序——你决定怎么把原材料变成可用的半成品。
- 审计策略是质检标准——你决定哪些半成品值得保留，哪些扔掉。
没有审计策略的日志记录，就像没有食谱的厨房——你切了所有食材，但不知道要做什么菜。没有优质日志记录的事件，就像记在餐巾纸上的菜谱——内容是对的，但容易丢失、无法共享。
搞清这三者的区别，后续配置auditd、Windows高级审计、或者写自定义审计脚本时，你才知道自己到底要控制哪一步。嗯，这点很重要，很多新手把精力全花在“怎么记录”上，却忘了先想“该记什么”。