核心要点（TL;DR）
- 等保测评关注的是篡改可发现、可告警、可恢复，而非单一产品。
- 仅靠定时比对文件哈希无法满足实时性要求，需事件级监控。
- Web目录应禁止运行账号写入，发布走统一通道。
- 整改要留下日志与演练记录，否则视为未落实。
痛点：为什么“装了防篡改”还是被扣分
不少运维在等保测评前买了防篡改软件，结果现场核查仍被判定不符合。原因往往不是产品不行，而是网页防篡改合规要求落到了“有没有买”而不是“有没有生效”：告警没记录、日志留不住、发布账号能直接写 Web 目录。测评看的是可验证的证据链，本文按核查逻辑给出可直接执行的整改步骤。
条款在查什么：完整性保护的三个证据
等保 2.0 对网站完整性保护的落脚点可归纳为三问：篡改能否及时发现、过程能否留痕追溯、内容能否快速恢复。对应证据分别是监控部署与告警记录、集中日志留存、备份与恢复演练。
| 核查点 | 常见不达标表现 | 可提交证据 |
|---|---|---|
| 实时监控 | 仅每日定时比对哈希 | 事件告警截图、监控策略 |
| 日志留存 | 本地日志可被删除 | 集中日志平台检索记录 |
| 发布管控 | 运行账号可写站点目录 | 权限清单、变更工单 |
| 恢复能力 | 无备份或未演练 | 恢复演练报告 |
第一步：部署文件完整性监控并验证告警
以 Linux 为例，用 auditd 监控站点目录的写入事件，比定时哈希更贴近实时要求：
auditctl -w /var/www/html -p wa -k web_tamper
aureport -k web_tamper | tail -20随后手动制造一次变更验证链路：
echo test > /var/www/html/__probe.html
aureport -k web_tamper | grep __probe能看到记录后，把规则写入 /etc/audit/rules.d/ 持久化，并将 audit 日志转发到集中平台。若使用商业防篡改产品，同样要做一次“改文件—收告警”的实测，截图存档。
第二步：收敛 Web 目录权限与发布通道
运行账号可写是篡改成功的前提。把站点目录设为属主可写、运行账号只读：
chown -R root:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;上传目录单独隔离，禁止执行脚本；发布统一走 CI 或跳板机专用账号，并保留变更工单。这样既满足网站完整性保护，也不影响迭代效率。
第三步：补齐日志留存与恢复演练
确认日志集中留存不少于六个月、服务器时间同步，并定期做恢复演练：从备份还原一个页面，记录耗时与操作人。演练报告是测评时最容易被忽略却最有说服力的材料。防护建议上，可在主机侧叠加 AegisX 的文件完整性监控与告警联动能力，把变更事件直接接入统一告警，减少自建脚本的维护成本。
整改自查清单
- 站点目录是否已部署事件级监控，并完成一次告警实测？
- 运行账号是否对 Web 目录只读，上传目录是否禁止执行？
- 防篡改与发布日志是否集中留存六个月以上？
- 是否完成一次篡改发现与恢复演练并留档？
- 发布流程是否有工单或流水线记录可追溯？
行动建议：先按清单逐项自查，把缺失项排优先级，优先补“告警实测记录”和“权限收敛”两项，通常能覆盖大部分扣分点；随后再做一次完整演练，形成闭环证据提交测评。
常见问题（FAQ）
等保测评里网页防篡改到底查什么？
核心查三件事：能否及时发现篡改、能否留存证据、能否快速恢复。测评人员通常查看防篡改或文件完整性监控的部署证明、告警记录与日志留存周期，并现场尝试修改测试文件观察是否告警。只装软件不出记录，往往被判定为未有效落实。
开源方案能做网页防篡改吗？
可以。用 inotify 或 auditd 监控站点目录的文件创建、修改、删除事件，配合脚本比对哈希并推送告警，即可满足中小站点的基本要求。关键是配置合理的事件白名单、保证日志集中留存，并定期做篡改演练，形成可查的记录。
网站更新频繁，防篡改会不会影响发布？
会冲突，但可以通过发布通道解决。建议把 Web 目录设为运行账号只读，发布由 CI 或跳板机以专用账号写入，发布期间临时放行并记录工单。这样既满足完整性保护，也不牺牲迭代效率，测评时还能提供规范的变更记录。
日志留存多久才符合要求？
网络安全法要求网络日志留存不少于六个月，等保测评通常按此核查。防篡改告警、文件变更记录、发布操作日志都应纳入集中日志平台，并确保时间同步。留存不足或日志可被本地删除，是常见扣分点。
被篡改后应该怎么处置？
先隔离而非直接删除：保留现场快照与日志，确认篡改入口，再从可信备份恢复页面。随后排查 webshell、弱口令与上传漏洞，修补后重新基线核查。整个过程要形成处置报告，作为整改闭环证据提交测评机构。