1. 日志审计概述
日志审计，说白了就是把你系统里的日志翻出来，一条条地看有没有问题。有人会问：「不是有监控告警吗？为什么还要人工看日志？」嗯，我刚开始做运维时也这么想。直到有一次业务凌晨挂了，监控说一切正常，可用户就是登不上——最后我手动翻了十几台机器上的 access_log，才发现是负载均衡的会话亲和性配错了。
从那以后，我养成一个习惯：不管线上有没有告警，每天至少扫一遍关键日志。光靠监控是不够的，它只能告诉你「出事了」，但「为什么出事」「怎么出的」「是不是有人搞破坏」，这些都得靠日志审计来回答。
1.1 什么是日志审计
日志审计，是按规则收集、存储、分析系统日志，从而发现安全事件、合规异常或操作失误的过程。它不像监控那样只看“指标”，而是盯着“行为”——谁、在什么时间、从哪台机器、干了什么事。
我个人习惯把日志审计拆成三层：
- 采集层：从各种源头（Linux syslog、Windows Event Log、应用日志、数据库日志）把数据统一收上来
- 分析层：用规则或脚本匹配异常模式，比如凌晨三点有人批量删表、连续五次登录失败
- 响应层：触发告警、生成报告、归档留档
我用 Python 写过几个小脚本，每天凌晨跑一遍，把可疑行为摘出来发到钉钉群里。效果还不错，起码不用我天天盯着 Kibana 刷屏了。
1.2 为什么重要
你想想看，一个没有日志审计的系统，就像一个黑匣子坏了没记录的航班。出了事，你根本不知道是代码 bug、运维误操作还是被人黑了。
具体来说，日志审计的重要性体现在三方面：
| 维度 | 说明 |
|---|---|
| 安全溯源 | 攻防演练时，只有日志能还原攻击链。哪里进来的、横向移动了哪些机器、偷了什么数据，一目了然 |
| 合规要求 | 等保2.0、ISO27001、GDPR 都明确要求日志留存和审计。我去年帮一家金融客户过等保，光日志审计这一项就占了整改量的三分之一 |
| 故障定位 | 线上问题排查，大多数时候得靠日志时间线重建现场 |
避坑指南：我曾经遇到过一家公司，日志倒是都收了，但没做任何聚合。几百万条日志堆在 Elasticsearch 里，查一条 SQL 要 30 秒，基本等于没用。日志审计不是「存了就行」，还得考虑查询和分析的效率。
1.3 应用场景
日志审计不是只有安全部门才需要。我见过的典型场景包括：
- 运维排障：比如 Nginx 访问量突然下降，翻日志发现后端某个节点返回了连续 500 错误
- 安全事件调查：某业务数据库被删了，审计日志里能查到执行 delete 的 IP 和账号
- 内部违规审计：员工下班后登录核心服务器下载数据，审计脚本可以自动报给主管
- 变更合规检查：生产环境配置修改必须走工单，审计日志可以用来校验「谁改了配置文件」「是否有人跳过审批」
记得有一次，客户反馈凌晨三点数据库 CPU 飙到 100%。我们查了慢查询日志，发现是一个没有 where 条件的 update 语句。再翻操作审计日志——好家伙，是某位兄弟在测试环境跑错了服务器。从那以后，我们就在审计脚本里加了一条规则：非窗口期的 DDL/DML 操作都告警。
1.4 传统审计 vs 日志审计
很多人容易把「传统审计」（比如财务审计、流程审计）和「日志审计」搞混。其实两者差别很大：
| 对比维度 | 传统审计 | 日志审计 |
|---|---|---|
| 对象 | 纸质单据、流程记录、合同 | 电子日志、系统事件、网络流量 |
| 频率 | 定期抽检（季度/年度） | 持续采集、每日甚至实时分析 |
| 工具 | Excel、人工抽样 | Python脚本、ELK、SIEM、自动化规则引擎 |
| 覆盖面 | 抽样，5%~10% | 全量，理论上所有日志都能扫一遍 |
| 时效性 | 事后几周甚至几个月 | 事后几分钟到几小时 |
说白了，传统审计像「年终体检」，日志审计像「每天测体温」。你不可能等病到晚期再去看病——日志审计的价值就在于早点发现苗头，早点处理。
一个小技巧：你的日志审计脚本可以做成「分钟级」扫描。我习惯对高危日志（比如 SSH 登录失败、sudo 执行、数据库 DDL）做实时采集，低频日志（比如 cron 任务输出）做小时级汇总。既保证灵敏度，又不浪费计算资源。
1.5 日志审计的核心流程
下面这张图概括了我常用的日志审计数据流。你可以把它当作搭建审计系统的骨架：
实际项目中的做法：我习惯在分析层用 Python 写一个 audit_engine.py，每天凌晨跑一次。它会遍历当天所有日志索引，把不符合预设规则的条目摘出来，写到告警表中。规则可以用 YAML 配置，比如「user=admin AND action=delete AND time BETWEEN 02:00 AND 04:00」——这种模式基本覆盖了 80% 的异常场景。
1.6 日志审计的几个坑
- 日志不全：只收了应用日志，丢了系统日志和网络设备日志。我曾经在一个客户那里排查半天找不到问题，最后发现交换机日志根本没接进来。
- 时区不一致：服务器用 UTC，应用日志用 CST，分析脚本没做转换——时间线完全是乱的。我踩过这个坑，后来所有日志强制统一到 UTC 再存储。
- 日志轮转：不处理轮转的话，脚本可能读到一半文件被切走了。建议用 tail -F 或者直接对接 syslog，不要自己写轮转的竞态逻辑。
- 权限滥用：审计脚本自己有很高的数据库权限，反而可能成为攻击目标。一定要做好最小权限和脚本校验。
重要提醒：日志审计本身会生成大量审计日志（比如脚本每次读取的操行日志）。这些元日志要不要再审计？循环下去没完没了。我建议：审计脚本自身的运行日志单独存，不做二次分析，但保留 90 天以应付合规检查。
好，这一章我们先聊到这里。日志审计的概念、重要性、场景以及与传统审计的差异，我差不多都讲透了。后面我们会深入具体怎么做——用 Python 写一个审计日志巡检脚本，从采集、解析到告警，一步步手撸出来。