一、为什么要用Puppet做基线合规审计和自动修复

1.1 传统人工方式的痛点

很多企业的运维人员都踩过这个坑：要做安全合规检查时，得登录每一台服务器，一个个翻配置文件、查密码过期时间、数冗余账号，20台服务器要花3天，还容易漏项——比如有一台测试服务器的root远程登录没关掉，被安全审计扣分，既费人又费时间，还容易出纰漏。这种人工方式就像大扫除，你擦完客厅忘擦阳台，永远没法保证全面干净。Puppet就像个带固定 checklist 的机器人，严格按标准来，不会漏，也不会错。

1.2 Puppet的适配性

现在大部分公司的服务器都是Linux系统（比如CentOS、Ubuntu），Puppet是专门管服务器配置的工具，相当于你有个“管家”，给所有服务器定好统一的规矩，比如“不许开root远程登录”“密码90天必须换”，管家会挨个检查，不合规矩的自动改，不用你跑一趟终端。它支持几乎所有主流服务器系统，哪怕混合Windows环境也能用，是目前做自动化合规的常用工具。

二、Puppet基线合规方案的核心流程

2.1 怎么定义公司的基线规则

基线就是公司的安全标准，比如安全部门要求的密码策略、防火墙规则、文件权限这些，都要写成Puppet能识别的规则脚本（叫Manifest），然后推送到所有符合条件的服务器上。这里给个完整的示例，用的技术栈是Puppet 7.x：

# 基线规则1：禁止root远程登录SSH
class ssh_baseline {
  # 修改sshd_config文件里的PermitRootLogin参数，不管原来是什么，都改成no
  file_line { 'sshd_permit_root_login':
    path  => '/etc/ssh/sshd_config',
    line  => 'PermitRootLogin no',
    match => '^PermitRootLogin',
  }
  # 改完自动重启sshd服务，让配置生效
  ~> service { 'sshd':
    ensure => running,
    enable => true,
  }
}

# 基线规则2：密码过期时间设置为90天
class password_baseline {
  # 修改系统登录配置文件，设置密码最长有效期为90天
  file_line { 'login_defs_pass_max_days':
    path  => '/etc/login.defs',
    line  => 'PASS_MAX_DAYS 90',
    match => '^PASS_MAX_DAYS',
  }
}

# 把规则应用到所有web服务器（节点名是web-server-开头的）
node 'web-server-*' {
  include ssh_baseline
  include password_baseline
}

这个脚本的意思是：所有叫web-server-开头的服务器，都会自动执行两个规则——把SSH的root登录关掉，把密码过期时间设成90天，要是某台服务器之前是root能登录，Puppet会自动改成no，重启服务后就生效，完全不用手动改。

2.2 合规审计怎么实现

Puppet自带“审计”功能，能自动检查服务器的配置是不是和基线规则一致，不一致就标记为不合规，要是开启修复的话，还能自动改回来。比如检查/etc/passwd文件的权限：

# 基线规则3：/etc/passwd文件权限必须是644，owner是root
class file_perm_baseline {
  file { '/etc/passwd':
    ensure => file,
    owner  => 'root',
    group  => 'root',
    mode   => '0644',
    audit  => content, # 审计文件内容，被篡改就标记不合规
  }
}

这里的audit参数就是告诉Puppet，每次运行都要检查这个文件的内容和权限，要是有人把文件改成了600，Puppet会自动改回644，还会把这个操作记到审计日志里，方便后续查。

三、实际应用场景

3.1 日常合规检查

每个月要做的等保2.0合规检查，之前运维团队要查密码、账号、防火墙，现在用Puppet，只需要在主控节点跑个命令，就能生成所有服务器的合规报告，哪台不合规，具体是哪个项，一目了然，不用一个个服务器翻，能省90%的时间。

3.2 新服务器上线初始化

新服务器刚装完系统，要手动改配置、关危险端口，容易漏，用Puppet的话，把基线规则写好，服务器一加入Puppet集群，就自动应用所有合规规则，上线后直接是合规状态，不会留安全漏洞。

3.3 突发事件响应

比如突然发现某个服务器开了3389（Windows远程桌面）端口，这个端口很危险，用Puppet的基线规则，能瞬间检查所有服务器的防火墙规则，把不必要的端口关掉，符合安全基线，不会等事故扩散再处理。

四、技术方案的优缺点分析

4.1 优点

  1. 标准化：所有服务器用同一套规则，不会出现有的合规有的不合规，比如生产环境的基线和测试环境的基线能分开，不会搞混。
  2. 自动化：审计和修复全自动，减少人为错误，比如你可能记错密码过期时间，Puppet严格按写好的规则来，不会出错。
  3. 可追溯：所有操作都有日志，哪天改了哪个服务器的配置，都能查到，审计的时候直接拿日志，不用手动整理。
  4. 适配广：支持CentOS、Ubuntu、Debian等几乎所有Linux系统，也支持Windows，适合混合环境的企业。

4.2 缺点

  1. 初始配置要花时间：得把公司的基线规则一个个写成Puppet模块，不过现在有现成的合规模块（比如puppetlabs/security_policy），不用全自己写，能省不少力。
  2. 依赖主控节点：Puppet的主控节点要是挂了，新服务器没法加入，不过可以做高可用，多部署几个主控节点，解决这个问题。
  3. 规则要和业务适配：比如有的业务需要root远程登录，那基线就不能设PermitRootLogin为no，要和业务部门沟通调整，不然会影响业务。

五、注意事项

5.1 基线规则要灵活调整

生产环境的基线要严格，测试环境可以宽松，比如测试环境允许root登录，生产环境绝对不行，要给不同环境分开设置规则，不能一刀切。

5.2 先在测试环境验证

改新的基线规则前，先在测试服务器跑一遍，确认不会影响业务，比如改SSH配置，先在测试机试，能正常连接再推到生产，不然会出现连不上服务器的事故。

5.3 定期备份审计日志

Puppet的审计日志是合规的依据，要是丢了，审计的时候没法证明服务器的合规性，所以要定期备份，或者用ELK工具收集Puppet日志，方便查询和可视化。

六、方案总结

这个方案就是用Puppet把抽象的安全合规标准变成可自动执行的规则，适合有一定规模（10台以上服务器）的企业，能减少人工运维成本，提升服务器的安全性和合规性。核心是把公司的安全要求拆解成Puppet能识别的规则，自动检查和修复，不用人工干预，是目前企业做自动化合规的实用方案。