审计日志基础
什么是审计日志？
审计日志，说白了就是记录「谁、在什么时候、通过什么方式、对什么资源、做了什么操作、结果如何」的不可篡改流水账。我刚开始接触运维时，以为日志就是给程序员看异常信息的——直到某次安全事件，老板让我三天内查出内部数据泄露的根源，我才发现没有结构化审计日志根本无从下手。
审计日志和普通系统日志有本质区别：
| 维度 | 普通日志 | 审计日志 |
|---|---|---|
| 目的 | 故障排查、性能监控 | 合规审查、安全取证、风险追溯 |
| 字段要求 | 灵活，可随意增删 | 固定必填字段（时间、用户、事件类型、源IP、结果） |
| 保留策略 | 按磁盘空间滚动 | 按合规要求（通常至少180天或更长） |
| 防篡改 | 无特殊要求 | 需要签名、加密、写前日志锚定 |
核心原则：审计日志必须满足四性——完整性、真实性、不可否认性、可追溯性。缺任何一条，日志拿到法庭或合规审计里就是废纸。
审计日志的分类
我个人习惯按数据来源和事件性质分成五类，你想想看，几乎覆盖所有场景：
- 身份与访问日志——登录、登出、密码修改、权限变更、MFA认证结果。我曾在项目中抓到过一个攻击者反复尝试撞库，就是靠这类日志锁定的IP段。
- 操作行为日志——文件读写、命令执行、API调用、数据库CRUD。注意：高敏感操作（rm -rf、DROP TABLE、批量导出）必须单独标记和告警。
- 配置变更日志——防火墙规则改动、系统参数调整、应用部署版本更新。嗯，这里要注意，很多团队只记录最终变更结果，不记录变更前快照——出问题回滚时完全不知道原来长什么样。
- 安全事件日志——入侵检测告警、病毒查杀结果、网络攻击拦截、异常流量特征。
- 系统与基础设施日志——CPU/内存跑满、磁盘I/O异常、进程异常退出、硬件故障。
避坑指南：我曾经在某个金融项目里，开发同学把所有操作都记在一个不分级的超大日志文件里，每天几个TB。结果合规检查时，审计员要求按事件类型分分钟提取“失败登录记录”，刷了三天都没跑出来。分类粒度没设计好，后面全是坑。
采集标准
采集不是简单的「tail -f 然后抓走」，必须遵循三个硬标准：
- 全覆盖——所有需要审计的资源不能漏。我曾经接手过一个项目，他们觉得内网API网关不用审计，结果内部员工通过网关越权删了生产数据库，没有任何痕迹。
- 低延迟——从事件发生到日志写入存储，延迟控制在秒级。我们做密文检索时，检索结果必须关联最新审计记录，延迟超过10秒就可能丢失关键证据链。
- 高可靠——采集器挂了不能丢日志。常用方案：双活采集代理 + 本地磁盘缓存 + 异步批量发送。
采集过程通常分四步，我画了一张图帮你理清脉络：
存储格式
存储格式决定了后续检索效率和密文检索的可行性。我用过三种主流格式，各有优缺：
| 格式 | 典型代表 | 优点 | 缺点 |
|---|---|---|---|
| 文本行 | JSON Lines、Syslog | 人类可读、易用 grep | 无索引、检索慢、占用空间大 |
| 二进制 | Avro、Parquet | 压缩率高、支持谓词下推 | 不易直接查看、序列化反序列化开销 |
| 结构化数据库 | Elasticsearch、ClickHouse | 全文检索强、OLAP查询快 | 资源消耗大、索引维护成本高 |
我们的密文检索场景，我建议优先使用 Parquet + ClickHouse 的组合。为什么？
- Parquet 列式存储，支持加密嵌套字段——每个敏感字段可以单独加密，不影响其他字段的检索效率。
- ClickHouse 的物化视图和跳数索引能对加密后的散列值快速过滤，不用全表扫描。
注意：无论选哪种格式，时间戳必须使用UTC，且精确到毫秒。我见过太多跨时区系统因为日志时间戳混乱导致无法还原事件先后顺序。另外，主键不能直接用业务ID（比如用户手机号），要用UUID或雪花ID——否则审计日志就变成了攻击者的「数据字典」。
存储时还建议加上日志的数字签名或哈希链。嗯，最简单的做法：每写一条日志，记录前一条日志的SHA256摘要，形成区块链式不可篡改结构。我曾经帮一个客户整改，他们之前没有做这个，审计员要求提供「日志未被篡改的证明」，拿不出来，直接判了不合规。