应分层选用工具：高敏单文件用sha256sum，全系统监控用aide，配置文件批量巡检用ansible.builtin.stat；sha256sum需写入受保护位置并chattr+i，aide初始化后须重命名数据库，stat比对时需trim基准值且follow:yes处理软链。
别用 md5sum 做系统级完整性校验，它防不了篡改；真正要落地配置任务，得按文件重要性分层选工具——高敏单文件用 sha256sum，全系统监控用 aide，配置文件批量巡检用 ansible.builtin.stat。
用 sha256sum 配置关键文件轻量级校验
适用于 /etc/passwd、/etc/shadow、SSH 主机密钥等极少数必须秒级响应的文件。校验逻辑简单，但细节决定成败：
- 首次生成必须写入受保护位置：
sha256sum /etc/passwd /etc/shadow /etc/ssh/ssh_host_*_key > /root/filesums.sha256 - 校验脚本里要用
-c+--status，只依赖退出码：if ! sha256sum -c --status /root/filesums.sha256 2>/dev/null; then echo "ALERT: critical file changed"; fi -
/root/filesums.sha256自身必须防篡改：运行chattr +i /root/filesums.sha256，否则攻击者可同步替换校验值 - 别把校验脚本和校验文件放在同一磁盘分区——根分区满时，
chattr和写日志都会失败
用 aide 配置全系统文件完整性监控
aide 是唯一能同时捕获内容变更、权限翻转、属主切换、ACL 修改、SELinux 上下文变动的生产级工具，但默认配置全是坑：
- 初始化必须在系统干净后立刻执行：
aide --init，然后手动重命名数据库：mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz，漏掉这步后续--check永远报 “database not found” -
/etc/aide.conf里不能无脑写/etc p+i+n+u+g+s+b+m+c+sha256：像/etc/resolv.conf、/etc/mtab这类动态文件必须显式排除，否则每次检查都刷屏Changed - 排除规则要精确：
!/etc/**.log要求启用 glob 支持；更稳妥的是逐条列明：!/etc/nginx/access.log、!/etc/docker/daemon.json - 数据库路径必须与配置中
database=file:/var/lib/aide/aide.db.gz完全一致——大小写、.gz后缀、斜杠方向一个都不能错
用 ansible.builtin.stat 配置配置文件周期比对
适合管理多台服务器上 Nginx、MySQL、Kubernetes 等服务的配置一致性，不依赖本地命令，跨平台行为稳定：
- 基准采集阶段必须在可信状态（如刚部署完）执行：
get_checksum: yes+checksum_algorithm: sha256，结果存到 Git 或只读 NFS，不能存在被管主机本地 - 比对时用
lookup('file', ...)读取基准值，注意清理前后空格："{{ (lookup('file', '/path/base.sha256') | trim).split()[0] }}" - 断言必须用
assert模块，不能靠shell+grep：前者失败直接中断 Playbook 并返回非零退出码，后者容易静默忽略 - 别在同一个 Playbook 里混用
stat和copy：若先 copy 再 stat，可能因文件未落盘导致哈希不一致；加ignore_errors: yes或拆成两个独立 Play
绕不开的陷阱：校验结果怎么才算“真正有效”
所有工具都可能“跑完就完事”，但真出问题时你根本不知道它是不是真的校验了——最常被忽略的是三件事：
-
aide --check返回 0 只代表“没发现异常”，不代表“数据库可用”；得加2>&1 | grep -q "AIDE database initialized"确认数据库加载成功 - 用
sha256sum -c校验时，如果校验文件里路径是./config.yaml，你就必须在同目录下执行，否则报No such file——路径是相对的，不是绝对的 - Ansible 的
stat模块对符号链接默认不追踪目标文件，要校验软链指向的内容，得加follow: yes，否则/etc/systemd/system/myservice.service这种软链永远显示“未变更”
