真正有效的“一键加固”需结构化设计与闭环控制，覆盖账户认证、ssh访问、文件权限、uid/gid唯一性、sudo最小授权五类关键项，并通过ansible实现幂等执行、预检验证与多环境适配。
Linux 系统权限安全基线配置不是靠“一键运行”就万事大吉，而是把真实合规要求（如等保2.0、CIS Benchmark）转化为可重复、可验证、出错能回退的自动化流程。真正有效的“一键加固”，核心在于结构化设计与闭环控制，而非简单堆砌命令。
覆盖五类权限关键项，避免假加固
很多脚本只改几个参数就标榜“已加固”，但实际漏掉权限链条中的关键断点：
- 账户认证：强制密码最小长度≥8位（含大小写字母+数字+特殊字符）、90天过期（
PASS_MAX_DAYS 90）、5次失败锁定（pam_faillock）、禁用空密码（awk -F: '($2 == "") {print $1}' /etc/shadow） - SSH访问控制：
PermitRootLogin no、PasswordAuthentication no、PubkeyAuthentication yes、AllowUsers admin@192.168.1.0/24（按需限制来源） - 文件系统权限：
/etc/shadow必须为400（非600），/etc/passwd和/etc/group≤644；/tmp和/var/tmp挂载选项含noexec,nosuid,nodev - UID/GID唯一性：执行
awk -F: '($3 == 0) {print $1}' /etc/passwd，输出仅允许root；发现admin、test等 UID 0 账户必须排查依赖后禁用或删除 - sudo最小授权：禁止
ALL=(ALL) NOPASSWD: ALL，改用admin ALL=(ALL) /usr/bin/systemctl, /usr/bin/journalctl等明确白名单
用 Ansible 实现可靠权限加固
Shell 脚本易因权限、路径或返回值异常中断，甚至误删配置；Ansible 原生支持幂等、备份与条件执行，更适合生产环境：
- 用
user模块创建管理账号时，同步设定shell: /bin/bash、password（加密后）、groups: wheel和sudo权限白名单 - 用
file模块设/etc/shadow权限为mode: '0400'，并启用backup: true自动保留原文件 - 用
lineinfile修改/etc/pam.d/system-auth，插入auth [default=die] pam_faillock.so …规则，避免手动编辑顺序错误导致登录锁死 - 用
community.general.expect验证加固效果：例如检查sshd -t是否通过、确认grep '^PermitRootLogin' /etc/ssh/sshd_config输出no
适配多环境，靠角色拆分+变量驱动
开发、测试、生产环境对权限策略常有差异（如是否启用 SELinux、是否允许特定 IP 登录），硬编码会导致维护崩溃：
- 将账户策略、SSH 控制、sudo 白名单分别拆成独立 role，如
role/password-policy、role/ssh-access-control、role/sudo-restrictions - 在
group_vars/all.yml中定义通用变量：max_password_age: 90、enable_sudo_whitelist: true - 按发行版区分变量文件：
roles/hardening/vars/RHEL-8.yml与roles/hardening/vars/Ubuntu-22.04.yml，自动匹配内核模块路径与包管理器命令 - 通过
-e env_type=production动态传参，使同一套代码在不同场景下启用/跳过特定加固项
配套预检、验证与报告机制
没有验证的加固等于没做：
- 执行前跑
pre-check.yml：检测当前是否已有 UID 0 非 root 用户、/etc/shadow权限是否超标、sshd_config是否语法合法 - 执行后触发
post-validate.yml：检查pam_tally2 -u admin是否归零、ls -l /etc/shadow是否为----------、sudo -lU admin是否只列白名单命令 - 生成结构化报告（JSON/HTML）：包含每项检查项的原始值、目标值、执行状态、失败原因及回滚命令，供审计直接调阅
不复杂但容易忽略。
