日志轮转归档可不强制哈希校验,但加入sha256sum校验能提升完整性与防篡改能力;需配合delaycompress、显式权限、服务重载及定期验证机制,构建轻量可靠审计体系。

生产环境日志轮转归档本身不强制要求哈希校验,但加入校验可显著提升日志完整性与防篡改能力。logrotate 原生不提供哈希计算功能,但可通过 postrotate 调用 sha256sum 或 md5sum 生成校验文件,配合明确的存储路径和定期验证机制,即可构建轻量、可靠、可审计的校验体系。
确保轮转策略稳健可靠
哈希校验的前提是轮转过程本身不出错:归档文件必须完整、原子、可定位。否则校验失去意义。
-
触发条件建议双控:对高流量服务(如 Nginx、应用日志),同时配置
daily和size 100M,任一满足即触发,避免单一大日志阻塞轮转或空转浪费 -
保留与压缩要协同:设
rotate 30保留 30 个归档;启用compress+delaycompress,确保.1文件未压缩(便于快速读取和校验),其余自动压缩节省空间 -
权限与创建必须显式声明:用
create 0640 www-data adm(Debian/Ubuntu)或create 0640 nginx root(RHEL/CentOS),防止新日志因权限问题写入失败 -
务必通知服务重载日志句柄:例如 Nginx 使用
kill -USR1 $(cat /var/run/nginx.pid),rsyslog 使用systemctl kill --signal=USR1 rsyslog,避免日志丢失
在轮转后自动生成 SHA256 校验文件
推荐使用 sha256sum(系统默认安装、无依赖、输出简洁),在 postrotate 中为刚生成的归档文件生成校验值,并保存为同名 .sha256 文件。
示例配置(放入 /etc/logrotate.d/nginx):
/var/log/nginx/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 0640 nginx root
sharedscripts
postrotate
# 仅对刚轮转出的 .1 文件生成校验(未压缩状态)
if [ -f /var/log/nginx/access.log.1 ]; then
sha256sum /var/log/nginx/access.log.1 > /var/log/nginx/access.log.1.sha256 2>/dev/null || true
fi
if [ -f /var/log/nginx/error.log.1 ]; then
sha256sum /var/log/nginx/error.log.1 > /var/log/nginx/error.log.1.sha256 2>/dev/null || true
fi
# 通知 Nginx 切换日志
[ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid) 2>/dev/null || true
endscript
}
注意:delaycompress 是关键——它让 .1 保持未压缩,确保 sha256sum 计算的是原始内容;若启用普通 compress,.1 会立即被 gzip 压缩,校验对象就变成了压缩包,失去对原始日志的保护意义。
校验文件的管理与验证机制
生成只是第一步,必须配套可执行的验证流程,否则校验形同虚设。
-
校验文件需与归档同步备份:将
.log.1与对应.log.1.sha256一同归档至只读存储(如 S3 WORM 模式、NAS 快照),禁止在生产机上长期留存明文日志+私钥+校验文件三者共存 -
定期抽检验证完整性:运维脚本可每月随机抽取 3–5 个归档,运行
sha256sum -c access.log.1.sha256,检查返回是否为OK;失败则告警并暂停相关审计流程 -
状态文件也要纳入监控:
/var/lib/logrotate/status记录每次轮转时间,应定期比对它与归档文件的mtime是否逻辑一致(例如.1文件修改时间 ≈ status 中该路径的最后轮转时间) -
避免校验路径歧义:不要用通配符批量生成(如
sha256sum /var/log/nginx/*.log.1 > sum.sha256),必须一一对应命名,否则无法精准验证单个文件
与数字签名的区别及选型建议
哈希校验 ≠ 数字签名。前者只防意外损坏或传输错误,后者(如 GPG/openssl)可防恶意篡改并提供身份溯源。生产环境中:
- 若只需满足等保2.0“日志完整性保护”基础条款,
sha256sum+ 同步归档 + 定期验证已足够,实施成本低、无密钥管理负担 - 若需满足金融级审计或具备责任认定要求(如“谁在何时修改了哪条日志”),才应升级为 GPG 签名方案,并严格隔离私钥、记录签名日志、分发公钥给审计方
- 切勿混用:同一份日志既打 SHA256 又打 GPG 签名,反而增加运维复杂度且无实质增益











