结论先行：微隔离的策略不直接写在工作负载上，而是写在"工作组"上。组划错了，策略要么覆盖不全，要么条数暴涨，后面每一轮收敛都要返工。四种常见划法——按业务系统、按环境、按分层角色、按物理站点——实践中通常组合使用；判断标准不是划得越细越好，而是"这批资产出问题时，能不能一句话说清归谁负责"。
四种划法对比
| 划法 | 适用情形 | 优势 | 需要注意 |
|---|---|---|---|
| 按业务系统 | 系统边界清晰、有独立责任人 | 与业务责任一致，策略解释成本低 | 跨系统调用多时，组间策略数量增长快 |
| 按环境 | 生产、测试、预发需要严格隔离 | 一两条策略即可阻断跨环境访问 | 组内仍然全通，还需第二维继续细分 |
| 按分层角色 | 接入层、应用层、数据层职责分明 | 策略条数少，便于快速建立基线 | 同一层的不同业务之间互访不受约束 |
| 按站点或机房 | 多数据中心、两地三中心 | 与运维边界和容灾边界一致 | 同一业务跨站点时会被拆散，跨域规则增多 |
三个判断标准
- 责任可归属。这批资产一旦发生安全事件，谁需要响应。找不到责任人，说明分组方式与组织架构脱节。
- 变更节奏一致。一起扩容、一起发布、一起下线的资产放在同一组，策略才能随业务变化自动跟随。
- 访问关系稳定。高频且稳定的互访放在组内，偶发互访用单独策略描述，不要为了省几条策略把两个不相干的系统并成一组。
四个常见错误
- 按网段划。云环境下地址会漂移、会被回收，按网段划出的组边界很快失效，策略指向错误资产。
- 按部门划。一个部门往往运行多个系统，组内默认互通等于把隔离粒度退回网段级。
- 划得过细。每个应用一个组甚至每台主机一个组，策略条数会回到手工维护 IP 规则的数量级，失去标签化的意义。
- 划完不维护。业务拆分或下线后，旧组仍然保留，策略指向已不存在的资产，台账与实际逐渐脱节。
落地清单
- 先按业务系统出初稿，再用环境作为第二维，控制单组规模在可解释的范围内。
- 每个组指定责任人与复核周期，写进资产台账而不是留在文档里。
- 新业务上线时由交付流程自动归入既有组，减少人工判断造成的口径漂移。
- 按季度复核一次，合并长期无成员的组，拆分规模明显膨胀的组。
分组这件事没有标准答案，但有明确的失败信号：当策略评审会上反复出现"这条规则到底归谁确认"时，通常不是策略写得不对，而是组划得不对。奇摩在为金融与制造企业做微隔离落地时，通常把资产分组与标签设计放在策略编制之前完成，先定身份再定规则。