隔离策略该归安全团队还是网络团队

结论先行：微隔离项目做完，技术上线往往顺利，真正卡住的是后续的日常运行——策略归谁管。安全团队关注暴露面与合规，网络团队关注连通性与业务影响，两边都合理，于是每次变更都要协调，每次事故都在界定责任。可行的切分不是把所有权判给某一方，而是把三件事分别署名：谁定规则、谁改规则、出了故障谁先兜。

本文只谈微隔离策略在组织内的归属与流转，不谈策略本身怎么写、隔离范围该画多大，也不谈产品怎么选型。

为什么「归安全」与「归网络」两条路都走不通

归安全团队，最常见的结果是策略越来越严，然后业务不通的工单堆到网络团队那里，网络团队没有改的权限，只能转单回去。一轮下来，业务方记住了「找安全改策略很慢」。

归网络团队，结果是策略跟着网络运维的节奏走：变更优先级永远排在业务开通之后，暴露面收敛这类「没有立刻报错」的工作持续被往后推。半年后回头看，策略库的形态基本和刚上线那天一样。

两种归属都会失败，因为它们是同一个错误的两面：把「谁负责」理解成「归谁所有」，而实际需要的是「谁在哪个动作上负责」。

把三件事分开署名

三行分开之后，很多争执会自动消失：安全团队不再需要判断某条策略会不会影响业务（那不是它的信息优势），网络团队也不再需要判断某条规则该不该收紧（那不是它的职责范围）。

流转里最容易断的一环：例外

真正消耗精力的不是常规策略，是例外。业务方要求临时放通、某个系统要跨区访问、某台新上线的机器不在现有分组里——这些都不在模板内，都要人判断。

例外如果没有统一入口，会以三种方式出现，每一种都留下痕迹问题：在群里喊一声就改、在给某个业务开绿色通道时顺手放开一条、以及为了赶上线先把策略调成全通，之后忘了调回来。第三种最危险，因为它不会报错。

可落地的约束是给例外设三个字段：谁批的、放通到什么时间、到期后是收紧还是续期。第三个字段是关键——临时放通不带期限，等于永久开放。这件事靠人记不住，得靠到期自动收紧的机制。

怎么判断这套切分跑起来了

三个观察点，都不需要额外建系统。

• 变更单上有没有「规则依据」一栏，写着引用哪个模板或哪次例外审批。空着也能改的，说明定规则这一行没有真正落位。
• 例外的平均存活时间是多少天。这个数持续变长的，说明到期收紧没在跑。
• 事故复盘时，能不能说清是规则定错了、执行错了、还是例外没收回。三种原因的改法完全不同。

三个点里，第二个最直观。微隔离的暴露面不是被攻击撑大的，是被一条条没有到期的临时放通撑大的。

边界与前提

三点说明。其一，本文提出的三件事切分是组织协作视角的参考做法，不同单位的团队设置与授权体系差别很大，落地时应按自身职责划分调整。其二，涉及跨部门授权的具体安排须经本单位管理流程确认，本文不作为制度依据。其三，文中提到的观察指标为参考口径，取值区间需结合业务规模与变更频度确定。

深圳市奇摩计算机有限公司在微隔离项目交付时，会把这三件事的署名作为交付材料的一部分，跟策略模板一起交给客户——技术上线的同一天，归属也要定下来，否则三个月后一定要再谈一次。预约咨询，可以按你现在的团队分工把这三行填一遍。