合规性报告不等于安全加固效果，它仅反映是否符合规则而非规则防攻击能力；failed项需结合实际攻击面、依赖关系和部署环境判断真实风险与副作用。

合规性报告本身不能直接等同于安全加固效果。它只说明系统是否满足某套规则，不验证这些规则在真实攻击场景中是否真正起作用。评估加固效果的关键，在于把报告里的每一条检查结果，放到你自己的业务环境里去判断——有没有攻击面、有没有实际依赖、会不会引发副作用。

别只盯FAILED数量，先看攻击面是否存在

很多团队一看到报告里几十个FAILED就立刻动手修复，结果改完服务挂了。其实有些“失败”根本构不成风险：

• ssh PermitRootLogin yes 在公网跳板机上是高危，但在内网离线管理节点上，压根没人能连过去，就不需要改
• password_max_age 90 检查失败？但如果所有用户都用 SSH 密钥登录，密码根本不用，这条策略实际没生效
• CIS 要求禁用 IPv6？可你的容器网络靠 IPv6 分配地址，硬关会导致 Pod 启动失败

注意工具和运行时状态不一致的情况

扫描工具看到的，未必是你系统当前真实状态：

• auditd 日志说 /etc/shadow 权限是 0644（应为 0600），但 ls -l 显示明明是 0600 —— 很可能是工具读的是镜像层或快照，不是运行中的文件
• oscap 扫描提示某个 sysctl 参数未生效，但在 containerd 环境里，该参数可能需在宿主机、runtime 或 pod spec 三层分别设置才真正起效

加固后出问题？重点查隐式出站连接

启用 iptables/nftables 默认 DROP 后，curl 开始超时，常见原因不是没放行目标端口，而是漏掉了支撑连接的底层依赖：

• 没放行 lo 接口：iptables -A OUTPUT -o lo -j ACCEPT
• systemd-resolved 监听 127.0.0.53:53，但只开了 53/udp，没放开 53/tcp（大响应包会降级）
• /etc/nsswitch.conf 把 dns 放在 files 前面，而 /etc/hosts 又没配全，导致 DNS 查询变慢甚至失败

真正难的是搞清规则的作用域

同一行加固配置，在不同部署形态下表现完全不同：

• net.ipv4.conf.all.rp_filter=1 在裸金属上防 IP 欺骗有效，在 KVM 中可能干扰虚拟网卡转发，在 containerd 里可能被 CNI 插件覆盖
• SELinux 策略在物理机上限制严格，在容器中若未启用 --security-opt label=… 就完全不生效
• Windows 的 LSA 保护策略对本地登录有效，但对域控环境下的 Kerberos 认证链可能造成兼容问题