公司刚上了一套日志审计系统，界面挺漂亮，能查IP、看访问时间、导出Excel报表，管理员拍着胸脯说：‘等保2.0肯定过了！’结果等保测评一来，测评老师翻了三页配置文档就问：‘原始日志保留180天的策略在哪设的？有没有防篡改机制？日志传输用的是什么协议？’——当场卡壳。
等保不是买个软件就完事
等保2.0里，对日志的要求散落在多个控制项中，比如安全审计（三级系统要求a、b、c三项全满足）、剩余信息保护、可信验证等。光有‘能看日志’远远不够。举个例子：你家监控录像能回放，但硬盘一拔就丢数据、录像时间能手动改、没人知道谁删过片段——这种监控再高清也没法通过消防检查，日志审计也一样。
关键三条硬指标，缺一不可
第一，日志必须完整采集。不只是HTTP访问日志，还包括操作系统登录日志、数据库操作日志、中间件异常日志、防火墙拒绝记录。某教育局被测时，只接了Web服务器日志，漏了教务系统数据库的SQL执行日志，直接被判定‘审计覆盖不全’。
第二，存储必须防篡改+够时长。等保三级明确要求：日志保存不少于180天，且具备防止日志被删除、修改、覆盖的能力。常见错误是把日志存本地磁盘，或者用普通FTP同步到另一台服务器——没校验、没权限隔离、没操作留痕，等于裸奔。
第三，分析能力得真管用。不是生成个‘TOP10访问IP’饼图就行。要能关联分析：比如同一IP在3秒内连续5次失败登录后，又访问了后台管理路径；或者某个账号在非工作时间导出超1000条学生成绩记录。这些规则得可配、可启、可告警，不能全靠人工盯屏幕。
实操中容易踩的坑
有些单位用ELK（Elasticsearch+Logstash+Kibana）搭日志平台，看着很开源很高级，但默认配置下日志传输走HTTP明文、索引没设只读、Kibana管理员密码还是‘changeme’……测评时一扫就爆出高危漏洞。还有单位买了商业审计设备，但把‘日志自动归档’功能关了，认为‘磁盘够大，不用清理’，结果半年后日志撑爆分区，系统直接停采——这已经违反‘可用性’基本要求。
真正合规的做法，比如某媒体公司在部署日志审计时，做了三件事：一是所有日志经TLS加密发往专用审计服务器；二是在服务器上启用WORM（一次写入多次读取）模式的存储卷；三是把关键操作日志（如稿件发布、用户权限变更）单独接入SIEM平台，设置‘1小时内同一账号修改5个以上栏目权限’自动触发工单。这才能让测评老师点头。
附：自查小清单（对照看看）
• 是否所有业务系统（含老旧Java应用、PHP站点、FTP服务）的日志都已接入？
• 日志时间戳是否统一NTP校时？有没有被人为调快/调慢的可能？
• 删除或清空日志的操作，是否在审计系统自身留下完整操作日志（谁、何时、删了哪段）？
• 网络设备（交换机、防火墙）的日志，是否开启syslog并指向审计服务器？协议是否为TCP+SSL？
等保不是应付检查的纸面功夫。日志审计的本质，是让每一次操作都有迹可循、无法抵赖、长期可证。设备买回来只是开始，配置、验证、持续运营，一个环节松动，整条链就断了。