核心是构建可追溯、可验证、可映射的合规巡检闭环：先锁定等保2.0/cis等基线标准，逐条筛选适用项并标注唯一条款编号，用ansible原生模块精准采集结构化结果，分层聚合生成含条款编号、状态、验证命令及输出的溯源报告，并通过定时执行、告警推送与自动归档实现落地。
核心是让每项检查可追溯、可验证、可映射到具体条款，不是堆命令，而是建逻辑闭环。
先锁定合规基线，再写检查逻辑
不对照标准写的巡检脚本，等于没写。必须明确用哪套规范：等保2.0三级？CIS Benchmark v2.0？还是金融行业补充要求？然后逐条筛选适用项：
- 剔除不适用项，比如容器节点跳过 BIOS 密码检查，云主机忽略物理控制台策略
- 每项检查标注唯一条款编号，例如 [等保2024 6.3.2.1] 或 [CIS 2.1.1]
- 区分强制项（如日志保留≥180天）和建议项（如启用 SELinux），报告中分类呈现
用 Ansible 模块做精准采集，避免 Shell 误判
Ansible 原生模块自带状态校验和幂等保障，比 raw/command 更可靠：
- 查 SSH 配置用 lineinfile + check_mode: yes 预检，匹配 PermitRootLogin no 是否生效
- 验账户策略用 user 模块查密码最长使用期、失败锁定次数等字段值
- 核日志配置用 stat 检查 /var/log/secure 权限是否为 600，并用 find 模块确认保留周期
- 所有采集任务统一设 register 变量，返回结构化结果（state、value、clause_id）
分层聚合结果，生成带溯源能力的报告
采集只是起点，关键在把零散结果变成审计能认的证据链：
- 聚合层用 set_fact 统计 PASS/FAIL/WARN 数量，计算单项得分与总合规率
- 报告层用 template 渲染 Jinja2 模板，固定包含三栏：条款编号｜当前状态｜验证命令+原始输出
- 每项 FAIL 必须附可复现命令，例如：
sudo grep -r "auth.*required.*pam_faillock" /etc/pam.d/→ 返回空 - 敏感操作（如备份 /etc/shadow）自动记录路径，格式为
/etc/shadow.bak.1745829360（含时间戳）
跑起来才算落地：定时 + 告警 + 归档
脚本写完不执行，等于白做。真正运转需三件套齐备：
- 用 cron 模块部署每日凌晨 2 点自动执行，日志按日期命名存入
/var/log/audit/ - 对 FAIL 条目触发告警：调企业微信 Webhook，消息含主机名、条款编号、简要描述
- 保留最近 30 天报告，旧报告自动压缩归档至
/backup/audit/，防止磁盘撑满
