基线修复中哪些例外必须加白

基线修复中，没有哪类告警仅凭“业务在用”就必须加白。真正应纳入例外管理的，是检查规则不适用，或整改确实会中断必要业务、且暂时无法通过更安全配置替代的项目。加白只是改变告警处置方式，不会消除底层风险。

规则不适用，应排除无效检查

典型情况是资产统一采用非密码登录，却仍被要求设置密码失效时间。应先确认密码登录已禁用、没有遗留使用路径，再对相关检查子项加白或调整检查策略。

这里的边界是只豁免不适用的要求，而不是把整台服务器的身份鉴别检查全部关闭。采用密钥登录，也不能据此忽略多余管理员账号或不必要的权限。

业务确有依赖，只能有条件加白

必须保留的管理端口、遗留系统账号、计划任务所需高权限，都属于候选例外，不是天然白名单。判断前应核实：谁在使用、依赖哪条业务路径、能否缩小访问范围或降低权限，以及替代方案为何暂不可行。

例如，端口必须保留，不代表必须向所有来源开放；备份脚本需要读取特定目录，也不等于整个任务必须长期保留全部高权限。能通过限制范围解决的问题，应优先整改，而不是直接屏蔽告警。

确需暂时保留时，应记录涉及资产、具体检查项、业务依据、风险、补偿控制、审批责任人和复核条件。临时例外还应明确退出安排，避免业务依赖解除后白名单继续生效。

修复困难，不等于可以豁免

SSH 弱口令、敏感文件不必要的可写权限、多余管理员账号，不能因为“怕影响业务”就加白。影响尚未查清时，应暂停自动修复并核验依赖；需要改造时，应保留整改跟踪，而非把风险包装成合理例外。

最终判断可以收束为一句话：不适用的检查调整规则，无法立即消除的必要风险受控接受，其余问题继续整改。每条例外都应能回答“为什么保留、由谁负责、何时重新判断”，否则只是让报告变干净。