结论先行：微隔离策略不应该逐条手写。可行做法是先让系统在观察期内学习真实的访问关系，再按选定的治理粒度自动生成白名单策略，最后在只记录不阻断的状态下验证一段时间。治理粒度是其中的关键变量，它决定了生成出来的策略有多细：粒度越粗，条数越少、误阻断风险越低，但收敛效果也越弱；粒度越细则相反。选哪一档，取决于当前业务梳理的完整程度。
为什么手工编策略走不通
- 规模不匹配。数千个工作负载之间的访问关系以万计，逐条编写和持续维护都不现实。
- 关系不透明。没人能凭记忆说清所有业务依赖，靠拍脑袋写的策略要么过宽失去意义，要么过紧影响业务。
- 变化持续发生。业务上线、扩容、迁移不断改变访问关系，人工维护永远滞后一步。
- 试错代价高。一次误阻断就可能造成业务中断，团队因此倾向于放宽策略，最终又回到默认全通。
策略生成依赖的四类输入
| 输入 | 说明 | 质量要求 |
|---|---|---|
| 资产身份标签 | 用位置、环境、应用、角色四类标签定义工作负载身份 | 覆盖率越高，生成结果越可用 |
| 访问关系基线 | 观察期内采集到的实际连接记录 | 需覆盖完整业务周期 |
| 服务与端口定义 | 各服务对外提供与依赖的端口 | 需与业务方确认 |
| 例外清单 | 运维通道、堡垒机、备份等必须放行的访问 | 必须在生成前预置 |
其中观察周期最容易被压缩。只学习三五天就生成策略，会漏掉周结、月结、季度批处理这类低频但关键的业务访问，而这些恰恰是最容易在防护态下被误阻断的部分。
治理粒度怎么选
| 粒度 | 策略组织方式 | 策略条数 | 适用场景 |
|---|---|---|---|
| 较粗 | 按工作组之间放行，组内默认互通 | 少 | 试点阶段、业务关系尚未梳理清楚 |
| 中等 | 工作组之间按角色放行，组内也按角色约束 | 中 | 多数生产环境的常态选择 |
| 较细 | 按单个工作负载之间的访问关系放行 | 多 | 核心业务区、合规要求高的区域 |
判断依据不是"越细越好"，而是业务梳理做到了什么程度。在标签体系还不完整时强行使用细粒度，生成出来的策略会充满噪音，反而拖慢治理进度。
生成之后的三步验证
- 覆盖率检查。生成的策略覆盖了多少观察到的访问关系，未被覆盖的部分是否有合理解释。
- 冗余与冲突检查。同级策略中是否存在相互包含或相互矛盾的条目，合并后再进入下一步。
- 观察态验证。以只记录不阻断的方式运行一到两周，核对预阻断日志，把被遗漏的正常访问补回白名单。
第三步不能省。它能在不影响业务的前提下暴露策略缺陷，跳过它直接上防护，一次误阻断就足以让整个项目停滞。
从粗到细的推进节奏
建议分三轮推进：第一轮用较粗粒度完成全域覆盖，让所有业务都进入受控状态，先拿到基线；第二轮对重要性高的业务区细化到中等粒度；第三轮针对核心系统与合规重点区域，再细化到工作负载级。每轮之间保留观察窗口，确认无误后进入下一轮。
这样推进的好处是收益前置——第一轮结束就已经收敛了大部分跨域暴露面，后续细化只是加深，不会因为追求精细而长期拿不到成果。
奇摩在多个微隔离项目中观察到，策略能否长期保持有效，取决于生成与验证是否形成了固定节奏，而不是首轮配置得多精细。若您希望评估当前业务关系的梳理程度适合哪一档治理粒度，欢迎预约咨询。