日志审计是企业安全运营的 “黑匣子”，也是等保 2.0 的硬性要求。系统日志记录主机层面的所有关键行为，应用日志则记录业务层面的访问和操作，两者结合，才能在安全事件发生时完整溯源。
一、先搞懂：什么是系统与应用日志审计？
- 系统日志：操作系统生成的事件记录，包括登录、权限变更、进程创建、系统服务启停等，是主机安全的核心凭证。
- 应用日志：业务应用生成的事件记录，包括 Web 访问、数据库操作、接口调用、用户行为等，是业务安全的核心凭证。
- 审计的核心价值：
- 安全事件溯源：还原攻击者从入侵到横向移动的完整路径，定位攻击入口和影响范围
- 业务故障排障：通过日志定位业务异常、错误请求、接口报错等问题
- 合规审计：满足等保 2.0 对日志留存不少于 6 个月的要求，应对监管检查
- 威胁预警：通过分析日志发现异常行为，提前预警潜在攻击（如暴力破解、SQL 注入）
二、核心日志类型梳理（企业重点关注）
1. 系统日志（Windows / Linux）
表格
| 系统 | 核心日志文件 | 关键审计事件 |
|---|---|---|
| Windows | 安全日志（Security.evtx）、系统日志（System.evtx） | 登录 / 注销事件（成功 / 失败）、账户创建 / 修改 / 删除、权限变更、服务启停、进程创建 |
| Linux | /var/log/auth.log（Ubuntu）、/var/log/secure（CentOS）、/var/log/messages | SSH 登录 / 注销、sudo 权限使用、用户账户变更、系统服务启停、内核错误 |
2. 应用日志（业务重点关注）
表格
| 应用类型 | 核心日志文件 | 关键审计事件 |
|---|---|---|
| Web 应用 | access.log、error.log | HTTP 请求、状态码（200/404/500）、请求参数、用户代理、Referer、异常请求（SQL 注入 / XSS） |
| 数据库 | 审计日志（如 MySQL 的 general_log/audit_log） | 登录 / 注销、SQL 语句执行、权限变更、表 / 数据增删改查 |
| 中间件 | Tomcat/Nginx 日志 | 应用部署 / 启停、接口访问、错误请求、会话创建 / 销毁 |
| 业务系统 | 应用操作日志 | 用户登录、业务操作（增删改查）、权限变更、接口调用、异常报错 |
三、日志审计的核心落地要点
1. 日志采集：全覆盖，无盲区
- 采集范围：所有核心主机、服务器、业务应用，包括系统日志和应用日志，避免只采集部分设备
- 采集方式：通过 Syslog、Filebeat 等工具，将日志统一采集到企业日志平台（如 ELK、Splunk）
- 完整性校验：定期检查日志采集是否正常，避免日志丢失或不全
2. 日志留存：合规且安全
- 留存时间：不少于 180 天，满足等保 2.0 要求；核心业务日志建议留存 1 年以上
- 存储策略：日志文件按时间 / 大小滚动留存，配置合理的文件大小上限，避免日志文件过大
- 异地备份：定期备份日志到异地存储，防止日志平台故障或被攻陷后日志被删除 / 篡改
3. 日志分析：建立基线，识别异常
- 建立基线：统计正常日志模式，如 Web 请求量、数据库操作频率、用户登录时间 / IP
- 异常识别：结合基线和攻击特征，识别异常行为：
- 登录异常：非工作时间登录、异地 IP 登录、多次失败登录
- 操作异常：数据库批量删除 / 修改、高权限账户异常操作、大量 SQL 注入 / XSS 请求
- 流量异常：Web 请求量突增 / 突降、大量 404/500 错误、高频请求同一接口
- 关联分析：结合系统日志和应用日志，还原完整事件链条，如攻击者 SSH 登录主机后，修改了数据库数据
4. 告警与处置：分级闭环，不堆压
- 告警分级：高危告警（如多次失败登录、数据库数据删除）1 小时内响应；中低危告警定期处理
- 告警配置：避免告警风暴，设置合理的告警阈值，如单 IP1 分钟内 10 次失败登录告警
- 处置闭环：告警必须有处置记录，包括事件分析、处理措施、结果验证，避免告警堆压无人管
四、企业日志审计完整流程
- 评估阶段：梳理企业所有核心主机和业务应用，明确合规要求和审计范围
- 采集配置：部署日志采集工具，配置采集规则，确保所有核心日志被完整采集
- 留存配置：设置日志留存时间和存储策略，配置异地备份
- 分析与告警：建立日志基线，配置异常识别规则和告警策略
- 定期审计：每季度审计日志，检查是否存在异常行为、合规违规问题，优化采集和告警规则
- 持续优化：根据业务变化和新攻击手段，更新采集范围、基线和告警规则
五、企业落地常见误区（避坑指南）
- 误区 1：只采集系统日志，忽略应用日志：系统日志只能记录主机层面行为，无法还原业务操作，必须同时采集应用日志
- 误区 2：日志仅存本地，不做外发和备份：主机被攻陷后日志会被删除，无法溯源；日志不外发，设备故障时日志丢失
- 误区 3：只存不分析，日志堆在平台里无人管：采集了日志但不分析，等于没采集，必须建立告警处置闭环
- 误区 4：留存时间不足，无法满足合规要求：留存时间不足 6 个月，无法通过等保审计
- 误区 5：告警规则配置过严 / 过松：过严导致大量误报，过松导致异常行为无法被发现
- 误区 6：日志采集不全，存在盲区：只采集部分主机 / 应用日志，核心业务未覆盖，攻击发生后无法完整溯源
📝 本节小结
系统与应用日志审计的核心，不是 “日志越多越好”，而是全覆盖、安全留存、持续分析、告警闭环，确保所有关键行为都有迹可循，既能在攻击发生后溯源，也能满足合规要求。
下一节预告：我们将学习 数据备份与恢复策略，带你了解如何通过数据备份配置，在业务被攻击、数据被破坏时，快速恢复业务，降低攻击损失。
No responses yet