安全加固策略需转化为可采集、可比对、可告警的检查项并嵌入运维流程；例如“禁用root远程登录”对应检查PermitRootLogin是否为no，“密码90天过期”需比对/etc/login.defs与/etc/shadow第5字段；脚本输出JSON格式结果，每日定时执行并自动告警修复。
安全加固策略本身不是巡检工具，但它能为自动巡检提供结构化基础和可验证锚点——真正提升实战效果的，是把加固要求转化为可采集、可比对、可告警的检查项，并嵌入日常运维流程。
把加固标准转成机器可读的检查清单
人工加固容易遗漏细节，而自动巡检必须依赖明确、无歧义的判定逻辑。例如：
- “禁用 root 远程登录” → 检查 /etc/ssh/sshd_config 中 PermitRootLogin 的值是否为 no 或 without-password
- “仅允许指定用户 SSH 登录” → 执行 awk -F: '$7 ~ /bash|sh$/ {print $1}' /etc/passwd，再比对 AllowUsers 列表是否全覆盖且无冗余
- “密码90天过期” → 解析 /etc/login.defs 的 MAX_DAYS 和 /etc/shadow 中各账号第5字段（最大天数）是否 ≤90
用轻量脚本+定时任务实现每日基线比对
无需部署复杂平台，一个 Bash 脚本配合 cron 就能完成核心巡检：
- 脚本统一输出 JSON 格式结果，含字段：check_id（如 ssh-root-login）、status（pass/fail）、actual（当前值）、expected（加固要求值）
- 每天凌晨 2 点执行，结果写入 /var/log/security-audit/$(date +%Y%m%d).json
- 失败项自动邮件通知负责人，并附修复命令（如 sed -i 's/^PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config && systemctl reload sshd）
权限架构巡检要聚焦“三类关键关系”
权限不是孤立配置，而是角色、资源、动作之间的映射。自动巡检应验证这三者的收敛性：
- 用户→组→sudo 权限链：检查 getent group | grep -E 'sudo|admin' 成员是否全部在 /etc/sudoers 显式授权列表中，避免隐式继承导致越权
- 服务→运行用户→文件权限：对 nginx、mysql 等关键服务，确认其进程 UID 与数据目录属主一致，且目录权限 ≤750（如 stat -c "%U:%G %a" /var/lib/mysql）
- 远程登录账号→shell类型→实际能力：筛选出 /etc/passwd 中 shell 为 /bin/bash 的非系统账号，再检查其 ~/.ssh/authorized_keys 是否存在、是否含危险指令（如 command= 绑定非限制命令）
让巡检结果驱动加固闭环
巡检报告不能只停留在“发现问题”，要直接触发加固动作：
- 发现空口令账号（awk -F: '$2==""{print $1}' /etc/passwd 输出非空）→ 自动执行 passwd -l $user 锁定，并记录到加固日志
- 检测到未启用公钥认证的 SSH 用户 → 生成临时密钥对，追加至 ~/.ssh/authorized_keys，并设 chmod 600 ~/.ssh/authorized_keys
- 识别出非必要开放端口（ss -tlnp | grep -v ':22$' | grep -v ':443$'）→ 调用 systemctl stop 对应服务，并标记为“待评估”，避免误关停业务
