结论先行：任何管控手段都有边界，微隔离的边界是"工作负载之间通过网络发起的访问"。这句话之外至少还有四类通道它管不到：加密流量里的内容、同一台主机内进程之间的通信、不走 IP 的链路、以及以人为载体的传递。把这些提前写进验收文件，比事后解释为什么还是出了事有用得多。
本文只谈这类方案的能力边界该怎么说清楚，不谈策略该怎么配、也不谈部署形态怎么选——前者是编制方法，后者是架构问题。
先把管控的对象说准
微隔离做的事情，抽象地说是一句话：给每一台工作负载（物理机、虚拟机、容器）贴上业务身份，然后规定谁能访问谁、用什么协议、什么端口。它管控的对象是"访问关系"。
这个定义里有个关键前提常被忽略：访问必须发生在工作负载之间，而且要经过网络协议栈。所有建立在这个前提上的能力——标签化策略、跨环境的统一策略、策略跟随身份迁移、访问关系可视化、暴露面统计——都成立得很好。
但只要跳出这个前提，能力边界就出现了。下面四类通道，不是产品的缺陷，是这类技术路线的天然范围。
其一：加密流量里的内容
策略放行一个端口，放行的是这条通道，不是通道里传的东西。一条被允许的 443 连接里，可能是正常的接口调用，也可能是把一批文件分段外传——从策略视角看，两者完全一样。
这不是微隔离一家的局限，所有基于五元组做判定的手段都一样。要看到内容，只能靠另外两类东西：一是流量侧的深度解析，二是端点侧的行为检测。前者依赖能否解密，后者依赖主机上的采集能力。
这个边界带来的实际影响是：策略收敛得再好，也挡不住"用被允许的通道做不被允许的事"。所以策略设计里有一类规则特别值得单独讨论——那些"为了业务方便而放得比较宽"的端口，它们的风险不在连通性，在承载内容的不可见。
其二：同一台主机内进程之间的通信
一台服务器上的两个进程通过本机回环地址通信，数据不出网卡，也不经过任何交换设备。这类通信在基于网络层的管控里看不到，因为它在管控点的下方发生了。
这一点在多租户或共享部署的场景里会变成真问题：同一台机器上跑着两个不同业务方的组件，它们之间的调用关系不受东西向策略约束。要管住这一层，需要的是主机侧的内核级能力——系统调用拦截、进程级访问控制那一类，属于另一个技术层次。
实践中常见的误判是把「每台机器都装了组件」当成「全覆盖」。纳管率高只说明每台机器上都装了管控组件，不代表机器内部的调用关系被管住了。
其三：不走 IP 的链路
串口、USB、工业总线、存储网络、带外的管理通道，这些链路上跑的流量不经过 IP 协议栈，微隔离无从下手。工控环境里这类链路占比不小，办公环境里也有——比如一些专用外设的连接。
这类通道的管控手段完全不同：物理隔离、单向传输设备、端口管控、外设白名单。它们和微隔离是并列关系，不是替代关系。一个常见的错误是拿微隔离的覆盖范围去回答"我们生产网的安全隔离做到什么程度"，而生产网里真正要紧的往往恰好是那几条不走 IP 的链路。
其四：以人为载体的传递
截屏、拍照、口述、把数据抄在纸上带走。这些不在网络里发生，任何网络层的管控都覆盖不到。
这一层要靠终端侧的控制（截屏水印、外设管控、剪贴板策略）和管理制度去接。日志与审计的作用是事后可追，不是事前可挡。把这几层的关系摆清楚，才能回答一个很实际的问题：东西如果还是出去了，走的是哪条路。
验收时该把边界写成什么样
边界不需要写成免责声明，写成一份范围说明更好用。它至少应当包含三部分内容：
- 管控对象：明确写"工作负载之间的网络访问"，写清纳管的资产范围与协议范围。
- 不在范围内的通道：把上面四类逐条列出，并注明由什么手段接管。这一栏写得越具体，后续扯皮越少。
- 不可见的具体情形：加密内容、非纳管资产、纳管但组件失效的资产，各自的发现办法是什么。
这三部分写完之后，还会顺带解决另一个问题：暴露面的数字怎么解释。暴露面统计的是"有开放端口且被访问"的工作负载，它是管控范围内的度量，不能等同于企业整体攻击面。汇报时如果把两者混用，数字会很好看，但结论经不起追问。
边界之外，该补的还是要补
承认边界的目的不是把责任推开，而是把该补的地方补上。四类通道各自有对应的手段，而且多数单位已经在用，只是没有和微隔离放在一张图上对齐过：
加密内容要靠端点侧的行为检测和流量侧的解析去接；主机内通信要靠内核级访问控制；不走 IP 的链路要靠物理与端口层面的隔离；人的传递要靠终端管控与制度。这四件事各自独立，不会因为微隔离上线而自动变好，也不会因为它没上线而更难做。
深圳市奇摩计算机有限公司在交付这类项目时，通常会在验收文档里附一份范围说明，把四类通道逐条标注由谁负责。客户方拿到这份东西，往后无论是做汇报还是应对检查，都不必再靠回忆来解释"这套系统到底管到哪儿"。
如果您正在评估现网的东西向管控覆盖到什么程度，或者想核一核手上那份验收文件里的范围写得够不够清楚，欢迎预约咨询，我们可以按上面这四类通道逐条过一遍。