结论先行：微隔离上线半年后内部暴露面又变大，追查下来大多是例外与临时策略堆出来的。治理办法是把"例外"当成有生命周期的对象来管理：申请时必须写明原因与到期时间并进入例外台账；到期前自动提醒责任人复核；超期未确认的自动失效或降级处理；每季度统计例外数量与占比，超过阈值就启动一轮专项清理。没有这套机制，最小权限的成果会被一条条临时放行慢慢侵蚀。
例外是怎么产生的
- 迁移过渡期。系统搬迁、上云期间地址不稳，先按宽口径放行保证业务，迁移结束后忘了收回。
- 老旧系统无法标签化。没有明确归属、跑在老旧平台上的系统，只能用地址对象兜底。
- 应急放行。故障排查时为省事临时开放，问题解决后没人回收。
- 外部合作方地址不确定。对端地址经常变化，索性放宽范围省得反复改。
- 无法安装客户端的特殊资产。只能靠网络侧或边界设备做替代管控。
这些场景本身都有合理性，问题不在"有没有例外"，而在例外有没有期限、有没有责任人、有没有退出路径。
一条例外策略必备的四类字段
| 字段 | 内容 | 为什么必须 |
|---|---|---|
| 原因与工单号 | 为什么开、谁申请的、关联哪个变更 | 没有原因的策略，后期没人敢删，也没人能判断影响 |
| 访问范围 | 源、目的、端口与协议 | 范围写不清，复核时无法判断能不能收窄 |
| 到期时间 | 明确到日期，必要时绑定事件 | 没有到期时间的临时放行，事实上就是永久放行 |
| 责任人与复核记录 | 业务责任人、复核时间与结论 | 责任人离职或转岗后，例外会变成无人认领的敞口 |
三步闭环
- 申请即带期限。把"到期时间"设为必填项，无到期时间的临时策略不予受理；期限按业务实际需要给，最长不超过一个复核周期。
- 到期前提醒与复核。到期前自动提醒责任人：是续期、转为正式策略，还是直接关闭。续期必须重新说明理由，不能一键延期。
- 到期退出。到期未确认的策略自动失效或降级为只记录不阻断，观察一段时间确认无影响后再删除；确实无法收敛的进入例外台账，并注明替代管控措施。
怎么判断例外是否失控
建议用四个可自动采集的指标做季度体检。
- 例外策略数量与占比。占比持续上升，说明策略编制质量在下降，正常业务访问没有被写进正式策略。
- 超期未复核条数。这是最能说明机制是否运转的指标，长期不为零就说明提醒与复核流于形式。
- 例外中的宽口径条数。全端口、跨安全域、大网段放行，风险等级应单独标注并优先收敛。
- 季度新增与关闭的比值。新增长期大于关闭，说明例外在净增长，需要启动专项清理。
四个常见坑
- 临时放行不挂到期时间。最典型也最普遍，一次应急变成长期敞口。
- 责任人写部门不写人。部门是一个集合，实际没人认领，提醒发出来也没人处理。
- 例外不做范围限制。图省事直接放开整个网段或全端口，一条例外抵消掉一批治理成果。
- 只清理不追责。每轮清理都清，但下一轮照样新增，根因是申请环节没有约束。
和策略质量的关系
例外数量其实是策略质量的反向指标：正式策略写得越准，需要开的例外就越少。如果发现例外在快速膨胀，先不要急着清理，回头看看策略编制环节——是不是匹配条件只用到了地址和端口，是不是业务标签没有覆盖到这部分资产，是不是观察期太短把低频访问漏掉了。把源头补上，例外的增长自然会停下来。奇摩在实施内网隔离项目时，通常把例外台账与到期提醒作为一期必备机制，与策略发布审批同步上线。
如果您正在为临时策略与遗留敞口发愁，欢迎 预约咨询，奇摩技术团队可协助设计例外管理流程与季度复核机制。