Ansible 默认的执行日志不足以直接满足等保合规，需要结合系统审计工具（如 auditd）和集中日志存储方案，确保操作可追溯且留存达标。单纯依赖 Ansible 自带日志无法通过等保测评，必须配置目标系统的审计规则并将日志集中存储。
先说结论：合规审计需要“双日志”策略，即 Ansible 控制器日志记录自动化动作，目标系统 auditd 日志记录底层操作行为。
- 先判断：确认等保三级对日志留存时间（通常不少于 6 个月）和字段的具体要求
- 优先做：通过 Ansible 批量部署 auditd 规则并开启控制器日志记录
- 再验证：检查日志是否包含用户、IP、时间且留存周期达标，并确保日志防篡改
核心概念澄清
等保 2.0 明确要求信息系统必须具备完整的操作审计功能。这里存在两个层面的日志：
- Ansible 控制器日志：记录谁在什么时间执行了哪个 Playbook，用于追溯自动化运维行为。
- 目标系统审计日志（auditd）：记录 Playbook 执行后在目标服务器上实际发生的系统调用、文件修改和命令执行，用于追溯底层操作。
合规的核心在于三点：一是审计记录必须包含时间、用户、IP 地址和操作内容等核心字段；二是日志留存时间通常要求不少于 6 个月；三是日志需要集中管理以防本地被清除。因此，需要利用 Ansible 去配置目标系统的审计能力，并将 Ansible 自身的执行日志也纳入集中存储。
步骤一：配置 Ansible 控制器日志
修改 ansible.cfg 文件，指定日志存储路径，确保每次执行 playbook 都有本地记录。建议将该日志文件权限设置为仅 root 可读，防止被篡改。
# ansible.cfg 配置示例
[defaults]
log_path = /var/log/ansible/ansible.log
log_level = VERBOSE# 建议配合日志轮转配置，防止磁盘写满
# /etc/logrotate.d/ansible
/var/log/ansible/ansible.log {weeklyrotate 52compressmissingoknotifempty
}
步骤二：批量部署系统审计规则
利用 Ansible 的幂等性，向所有目标服务器推送 auditd 规则。重点监控关键配置文件（如/etc/passwd、/etc/sudoers）和敏感命令。以下是一个完整的部署 Playbook 示例，包含规则写入与服务重载：
- name: 部署等保合规审计规则hosts: allbecome: yestasks:- name: 确保 auditd 服务已安装package:name: auditstate: present- name: 配置审计规则 - 监控关键文件lineinfile:path: /etc/audit/rules.d/ansible_compliance.rulesline: "{{ item }}"create: yesloop:- "-w /etc/passwd -p wa -k identity"- "-w /etc/sudoers -p wa -k sudoers"- "-w /etc/ssh/sshd_config -p wa -k sshd_config"- name: 配置审计规则 - 监控特权命令lineinfile:path: /etc/audit/rules.d/ansible_compliance.rulesline: "-a always,exit -F arch=b64 -S execve -k exec_monitor"create: yes- name: 重载 auditd 规则使其生效command: auditctl -R /etc/audit/rules.d/ansible_compliance.ruleschanged_when: true- name: 确保 auditd 服务开机自启并运行systemd:name: auditdenabled: yesstate: started
注意：仅配置规则文件不会立即生效，必须执行 auditctl -R 命令或重启 auditd 服务。生产环境建议先在测试机验证规则是否影响业务性能。
步骤三：配置日志集中存储
本地日志存在被入侵后清除的风险。应配置 rsyslog 将目标服务器的 audit 日志和 Ansible 控制器日志统一投递到中央存储区。以下是 rsyslog 转发配置示例：
# /etc/rsyslog.d/audit-forward.conf
# 将所有 audit 日志转发到日志服务器
audit.* @192.168.1.100:514# 重启 rsyslog 生效
systemctl restart rsyslog
在日志存储端设置生命周期规则，确保审计日志留存时间满足合规要求。需定期检查存储空间，避免因磁盘已满导致新日志无法写入。
验证与自查
1. 检查日志字段完整性
使用 ausearch 工具查询审计日志，确认每条记录是否包含时间、操作用户、来源 IP 和具体操作命令。
# 查询最近的 sudo 操作记录
ausearch -m USER_AUTH -ts recent# 查询特定关键字的审计记录
ausearch -k identity -ts today
查看 Ansible 日志，确认包含执行用户和时间戳：
grep "PLAYBOOK START" /var/log/ansible/ansible.log
2. 验证留存周期
在日志管理系统中查询 6 个月前的日志数据，确认是否仍可检索。若使用本地轮转，检查历史归档文件是否完整。
3. 测试防篡改能力
尝试修改审计日志文件（仅测试环境），确认系统是否有告警或记录该修改行为。合规要求日志具备防篡改机制，通常通过权限控制（chmod 600）或写入只读存储实现。
常见风险与规避
1. 日志本地存储风险
若日志仅保存在目标服务器本地，一旦服务器被攻破，攻击者可能清除日志掩盖痕迹。务必配置日志外发至独立存储，并开启传输加密（如 TLS）。
2. 时间同步问题
审计日志的时间戳必须准确。若服务器时间未同步，日志溯源时将无法确定真实操作时间，导致合规失效。建议统一配置 NTP 服务，并确保时区一致。
# 配置 chrony 时间同步
yum install chrony -y
systemctl enable `--now` chronyd
3. 磁盘空间不足
高频操作会产生大量日志。若未设置合理的轮转策略或存储容量不足，可能导致旧日志被过早覆盖或新日志丢失。需监控存储使用率并在达到阈值时告警。
参考文档
- Ansible Configuration Settings: https://docs.ansible.com/ansible/latest/reference_appendices/config.html
- Linux Audit Framework Documentation: https://linux.die.net/man/8/auditd
- GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求
- Red Hat System Audit Guide: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-audit-to-monitor-system-activity_security-hardening
原文链接：https://www.zjcp.cc/ask/11100.html