合并清理的前提
多条策略覆盖同一业务时，适度合并可以降低维护成本，但合并前必须确认行为等价：动作不同（允许与拒绝）、日志要求不同、带时间或用户条件的策略都不适合合并。清理的原则是先看命中数据再动手，保留日志与审计要求，并在低峰窗口分批调整，逐批验证业务与日志。
基本信息
| 识别条件 | 源目的对象相同、服务相近、动作一致的连续策略 |
|---|---|
| 基本原则 | 先分析命中再合并，保留日志与审计要求 |
| 验证方法 | 合并后对比策略命中，确认行为无变化 |
| 实施方式 | 分批在低峰窗口调整，逐批验证 |
典型使用场景
- 策略数量膨胀：长期累积后需要系统性精简
- 对象组改造：把重复的地址与服务整合为对象组
- 性能优化：策略过多影响匹配效率与可读性
- 审计整改：清理长期零命中且无业务依据的历史策略
- 迁移规划：迁到新设备前先做一次策略整理
处理思路
处理思路
# 1. 导出策略分析与命中数据，标注长期零命中的策略
# 2. 找出可合并组：对象组化、服务整合，动作与日志要求一致
# 3. 在低峰窗口分批调整，一次只动一组
# 4. 逐批验证业务与日志，出现异常立即回退
# 5. 清理结果与依据归档，供下次审计引用可合并与不可合并
| 情况 | 是否可合并 | 原因 |
|---|---|---|
| 源目的相同、动作相同、日志要求相同 | 可合并 | 行为等价，维护成本下降 |
| 动作不同（允许与拒绝） | 不可合并 | 合并会改变安全语义 |
| 日志要求不同 | 不可合并 | 合并后审计要求落空 |
| 带时间或用户条件 | 谨慎处理 | 条件不同时行为随时间或身份变化 |
合并能减少条目数量，但不一定降低风险：不同日志级别的策略强行合并，会让审计要求无法满足。