结论先行：防火墙策略库里有两类"看不见"的问题规则：一类是长期零命中的僵尸策略，另一类是排在更宽泛规则之后、永远轮不到匹配的隐藏策略。后者更隐蔽——它不产生告警，却让配置清单看起来"已经配过了"，掩盖真实的安全意图，还会在排障时误导判断。排查方法是先用规则顺序与命中日志做静态分析标出候选，再逐条确认业务归属，最后按依赖顺序删除并复测连通性。
隐藏策略是怎么产生的
防火墙按自上而下的顺序匹配，命中即停止。只要前面存在一条更宽泛的允许规则，后面写得再精细的规则都不会被匹配到。常见的产生路径有四条。
- 临时放行为赶进度。业务催得急，先在靠前位置加一条大范围允许规则应急，事后忘记回收，原本精细的规则就此失效。
- 策略迁移时顺序错乱。从旧设备搬迁或跨品牌迁移时，策略按名称或编号排序导入，原有的优先级关系被打乱。
- 多人长期维护。不同工程师按各自习惯插入规则，没有人定期从全局审视顺序关系。
- 组织变更后未清理。业务下线、部门调整后，相关的精细规则留在原地，而覆盖它的宽泛规则被保留下来。
三类"看着在、其实没用"的策略
隐藏策略常与另外两类问题规则混在一起，治理前先分清。
| 类型 | 特征 | 判别方法 | 处理建议 |
|---|---|---|---|
| 隐藏策略 | 被上游更宽泛规则完全覆盖，永不匹配 | 规则顺序静态分析 + 命中日志长期为零 | 确认无业务意图后删除 |
| 僵尸策略 | 本身可匹配，但长期无流量命中 | 30 天以上命中数为零 | 先观察一个完整业务周期再回收 |
| 冗余策略 | 与其他规则重复或可合并 | 源、目的、端口、动作比对 | 合并后保留一条 |
三者的处置节奏不同：僵尸策略要等，隐藏策略要查顺序，冗余策略要合并。混在一起处理，很容易把还有业务意图的规则误删。
排查四步
- 导出全量策略并还原顺序。按顺序号完整导出，不要只导规则内容——隐藏策略的判定完全依赖顺序关系，脱离顺序的清单没有意义。
- 做覆盖关系分析。逐条判断是否存在上游规则在源地址、目的地址、端口、动作四个维度上完全包含它。四个维度全部被覆盖，才可判定为隐藏候选。
- 交叉验证命中日志。静态分析给出候选，命中日志做佐证：候选规则长期零命中，且上游规则有持续命中，基本可以确认。
- 确认业务意图。这一步不能省。把候选清单发给对应业务与运维方确认，重点问一句：这条规则是不是在表达"这里应该被限制"？如果是，要处理的不是这条规则，而是压在它上面的宽泛规则。
删除前的三条确认
- 确认上游宽泛规则的处置方案已定。直接删掉隐藏策略而不动上游规则，等于默认了宽泛放行的现状，暴露面反而被固化。
- 确认变更窗口与回退预案。批量删除前留存全量配置快照，分批执行，每批之后做连通性抽检。
- 确认审计留痕。删除原因、审批人、执行时间一并记入操作日志，避免下次审计时说不清规则去向。
怎么防止再堆积
清理一次不难，难的是不再长回来。三条机制值得建立：
- 下发前自动分析。新策略在变更流程中自动做覆盖关系检测，发现会被上游规则覆盖时直接拦截提示，从源头减少新增。
- 临时规则带有效期。应急放行的宽泛规则必须填写到期时间，到期自动进入复核，超期未续期则告警。
- 周期性健康检查。每季度跑一次全量分析，输出隐藏、僵尸、冗余、高风险四类清单，纳入常态运维。
奇摩在做存量策略治理时，一般把隐藏策略与僵尸策略分成两个批次处理：先清隐藏规则厘清真实意图，再回收零命中规则，避免顺序关系干扰判断。
如果您正在规划相关建设，欢迎预约咨询，奇摩技术团队可基于现网数据做一轮评估，再决定是否推进。