6.3 安全合规管理

6.3 安全合规管理

本节摘要：合规审计与自动化之间的翻译工作：审计方要的证据是什么，Ansible 能交付什么形态的证据，两者如何对上。内容包括合规基线的剧本化、证据链的三件套（版本记录、执行记录、状态核验）、以及把审计检查本身做成可重复运行剧本的思路。

审计方与自动化的语言差

一次安全审计的典型问询长这样："证明所有生产服务器在过去的检查周期内持续满足基线要求，包括但不限于口令策略、远程访问限制与日志留存。"注意其中的关键词：证明、持续、所有。而运维团队手里的常态证据往往是：一次三月份的手工检查记录、几台抽查机器的截图、一段口口相传的"应该都改了"。语言差的核心在于审计要的是"覆盖全量、可追溯、可复验"的证据，手工方式天然只能提供"抽查、快照、口头"。Ansible 恰好在三件事上是审计语言的母语者：全量覆盖（清单即范围）、可追溯（版本库加执行记录）、可复验（剧本重跑即复检）。合规章节的任务就是把审计问题翻译成这三件母语。

基线的剧本化

基线是一份"系统应当满足的安全要求清单"（口令策略、SSH 加固、日志配置、内核参数等），剧本化就是给每条要求找到一个对应的声明式任务。以 SSH 加固段为例：

---
- name: 安全基线 · 远程访问段
  hosts: all
  become: true
  tasks:
    - name: 禁止 root 直接远程登录
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?PermitRootLogin'
        line: 'PermitRootLogin no'
        validate: '/usr/sbin/sshd -t -f %s'
      notify: 重启 sshd

    - name: 禁用空口令
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?PermitEmptyPasswords'
        line: 'PermitEmptyPasswords no'
        validate: '/usr/sbin/sshd -t -f %s'
      notify: 重启 sshd

    - name: 内核参数 · 抑制 ICMP 重定向
      ansible.posix.sysctl:
        name: net.ipv4.conf.all.accept_redirects
        value: '0'
        sysctl_set: true
        reload: true
​

两个工程细节决定基线剧本的可用性。细节一，validate 参数：改 sshd 配置前先语法校验，配错了拒绝写入——没有这道防线，一次笔误就能把全部机器锁在门外（重启 sshd 失败而连接全断）。细节二，基线剧本必须幂等到极致：它是全机器反复跑的剧本，任何"每次 changed"的任务都会把漂移信号淹没在噪音里——6.1 节的幂等审问在这里不是建议而是硬要求。

证据链三件套

审计证据的组织形态，实践中收敛为三件套。证据一，定义版本：基线剧本在版本库中的历史，回答"基线是什么、何时改的、谁批的"。证据二，执行记录：每次基线运行的触发者、时间、目标范围、结果摘要——5.2 节的流水线触发加回调归档正好产出这些。证据三，状态核验：证明"当前时刻机器确实满足基线"的当次运行输出。三件套合起来覆盖审计问询的全部要素；缺任何一件，审计方都会追问人工补充证据，那正是手工方式的回潮。

把审计检查做成剧本

进阶形态：把"检查"与"修复"分成两个剧本。检查剧本只读不写——用 stat、command 加注册变量逐项核对基线，最后用 assert 汇总，不合规就列出主机与条目：

- name: 合规自检 · 口令策略段
  hosts: all
  become: true
  tasks:
    - name: 读取口令最长有效期设置
      ansible.builtin.command: grep '^PASS_MAX_DAYS' /etc/login.defs
      register: pass_max
      changed_when: false

    - name: 断言不超过 90 天
      ansible.builtin.assert:
        that: "'PASS_MAX_DAYS 90' in pass_max.stdout or 'PASS_MAX_DAYS 60' in pass_max.stdout"
        success_msg: "合规"
        fail_msg: "不合规：{{ inventory_hostname }} 的 PASS_MAX_DAYS 设置为 {{ pass_max.stdout }}"
​

检查剧本的运行被定时任务周期触发，输出进合规报表——这就是 5.2 节"漂移变监控"思路在合规域的完整落地。它带来一个身份转变：运维团队从"审计前突击整改"变成"随时可出示合规证据"，审计从惊吓变成例行公事。

图 6-3：审计问题到自动化证据的翻译表

敏感操作的合规红线

合规章不能只谈"证明合规"，还要划红线。红线一，审计日志不可关停：日志相关基线只能加强不能削弱，剧本仓库里出现"关闭审计"的提交要触发最高级评审。红线二，秘密不进审计证据：执行记录归档时会带上任务输出，含秘密的任务（改口令、写密钥）要加 no_log: true，否则证据链自己成了泄露源。红线三，变更审批不可绕过：5.2 节的人工卡点在合规语境下是义务而非选项，紧急绕行要有事后补审机制。三条红线的共同点：它们防的不是外部攻击者，而是自动化体系自身成为合规缺口。

合规剧本的分层维护

合规检查剧本落地后，维护问题随之而来：基线要求会随监管更新、检查项会随业务演进。实践中收敛出的分层维护法：底层是"检查项库"——每条基线要求对应一个可复用的检查任务片段，独立维护、独立测试；中层是"检查剧本"——按不同审计场景（等保、内审、专项）从检查项库组装不同组合；顶层是"报表与证据归档"——统一收集各剧本的运行输出，按审计周期归档。分层的收益在变更时显现：监管新要求落地时只新增检查项与一条组装配置，原有剧本零改动。与之配套的维护节奏是"审计日历倒推"：把年度审计的固定时间点标出来，检查剧本的更新窗口安排在审计前一个月，更新即全量跑一轮留档——审计来时拿现成证据，而不是临时补作业。合规工作从被动应答变成主动日历，是自动化带来的质变之一。