基线要靠自动化才能守住
安全基线是一组明确的安全配置要求，例如账号与口令策略、远程登录限制、服务最小化、日志与审计开启、关键文件权限。它的难点不在定义，而在长期保持：机器会新增、配置会被临时改动、版本升级会重置默认值。靠人工检查无法跟上规模，所以基线必须用自动化执行——但执行方式要分开：巡检只读并报告偏差，修复才真正改配置，两者混在一起会让偏差失去可见性。
基本信息
| 适用对象 | 服务器、容器基础镜像与网络设备配置 |
|---|---|
| 基线内容 | 账号与口令策略、登录限制、服务最小化、日志审计、文件权限 |
| 两种模式 | 巡检（只读检测报告）与修复（幂等收敛） |
| 版本管理 | 基线本身需版本化，随系统版本与合规要求变化 |
| 关键要求 | 例外情况必须显式登记，否则偏差与例外无法区分 |
落地要点
- 巡检与修复分离：先用只读模式看偏差分布，再决定修复节奏与影响面
- 修复保持幂等：同一份基线重复执行结果一致，避免每次都产生变更
- 例外显式登记：必须不同的主机单独记录原因与负责人，避免被静默覆盖
- 基线版本化：基线随系统镜像与合规要求一起管理，改动需评审
- 结果可复检：修复后重新巡检一次，用前后对比证明偏差确实收敛
- 变更留痕：自动化修复同样属于变更，需记录执行批次与影响主机
巡检优先的执行方式
巡检优先的执行方式
ansible-playbook -i inventory baseline.yml --check --diff -f 5 # 只读巡检，输出差异
ansible-playbook -i inventory baseline.yml --check | tee baseline-report-$(date +%F).log
ansible -i inventory all -m setup -a 'filter=ansible_ssh_host*' # 收集基础事实用于比对
sshd -T | grep -Ei 'permitrootlogin|passwordauth' | head # 抽样核对关键项
awk -F: '($2==""){print $1}' /etc/shadow # 核对无口令账号
ansible-playbook -i inventory baseline.yml --limit 'prod-web01' # 单机先试修复
ansible-playbook -i inventory baseline.yml --check | grep -c 'changed' # 修复后复检偏差数量偏差类型与处置
| 偏差类型 | 成因 | 处置方式 |
|---|---|---|
| 配置被临时改宽 | 应急操作后未恢复 | 纳入修复并由修复覆盖 |
| 基线过时 | 系统版本升级改变默认值 | 先更新基线再批量修复 |
| 合理例外 | 业务需要与其他主机不同 | 显式登记例外并限定范围 |
| 误报 | 检测项判断条件不准确 | 修正检测逻辑而非放宽基线 |
| 新增主机未纳管 | 上线流程未接入基线 | 纳入上线检查项 |
批量修复的破坏性往往被低估：一条基线误判就会同时改动成百台主机的配置，其中可能包含登录方式与服务端口这类会立刻影响可用性的项。因此修复应先单机验证，再小批量，最后全量，并要求在改后可验证。
与登录、审计、防火墙相关的基线项改动会直接影响可达性。修复前保留可用会话与回滚方式，改后先验证服务与登录仍然正常，再继续推进剩余主机。