4. 微隔离技术原理解析

微隔离（Microsegmentation）的核心目标，是把数据中心内部“东西向”流量从默认放通的扁平网络，改造成按工作负载身份与业务关系精细授权的可控网络。它并不是简单地把防火墙做小，而是把策略执行点从网络边界下沉到每一台主机、每一个容器或每一个工作负载旁边。理解微隔离，关键要看清四件事：执行点在哪里、策略用什么表达、身份如何确定、策略如何随工作负载迁移而保持一致。

一、执行机制：主机代理与网络策略的配合

微隔离最常见的落地形态是“主机代理 + 集中控制器”。每台服务器或虚拟机上安装一个轻量代理（Agent），代理通过内核模块、eBPF 或用户态钩子拦截本机的进出流量，并按控制器下发的规则决定放行、拒绝或记录。控制器负责策略编排、标签分发和状态汇总，代理负责本地执行。二者之间通常通过双向 TLS 通道通信，代理定期上报心跳、策略版本和连接日志。

代理的工作位置决定了它的能力边界。若代理工作在主机网络栈内，它能看到进程、端口、用户、容器 ID 等上下文；若只工作在虚拟交换机或网卡层，则只能看到 IP 和端口。因此，真正实现“身份驱动”的微隔离，通常要求代理能关联到进程级或容器级身份，而不仅是网络五元组。

网络策略的表达方式也不同于传统 ACL。以 Kubernetes NetworkPolicy 为例，策略以 Pod 选择器（label selector）和命名空间选择器描述对象，而不是写死 IP：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
      matchLabels:
        app: web
    ports:
    - protocol: TCP
      port: 8080

这段策略的含义是：在 prod 命名空间中，带有 app=api 标签的 Pod 只接受来自 app=web 标签 Pod 的 TCP 8080 入站流量。策略中没有任何 IP 地址，工作负载扩缩容或重新调度后，只要标签不变，策略依然有效。这就是标签驱动带来的可移植性。

二、标签驱动与身份驱动：策略如何“认识”工作负载

标签驱动是微隔离策略表达的基础。工作负载在注册时被打上若干标签，例如 env=prod、app=payment、tier=db、compliance=pci。策略引擎根据标签组合计算允许关系，代理根据本机标签匹配规则。标签体系设计得好，策略就能稳定复用；标签混乱，策略就会退化成难以维护的 IP 列表。

身份驱动则更进一步。它不只依赖静态标签，还结合工作负载的运行时身份，例如 SPIFFE ID、服务账户、证书指纹、容器镜像摘要或进程哈希。身份驱动的策略可以表达“只有持有 payment 服务账户且镜像摘要为 sha256:abc… 的工作负载才能访问数据库”，从而防止标签被冒用或镜像被替换后的横向移动。标签是“声明我是谁”，身份是“证明我是谁”，两者结合才能兼顾可管理性与安全性。

三、与传统防火墙的差异对比

传统防火墙以网络边界为中心，策略通常绑定 IP 地址、子网和端口，部署在南北向入口或区域边界。它的假设是“内网可信、外网不可信”，因此内网东西向流量往往默认放通。微隔离则假设内网同样存在风险，把每个工作负载视为独立信任域，默认拒绝所有未明确允许的连接。

从运维角度看，传统防火墙策略数量随区域和 IP 增长而膨胀，微隔离策略数量随应用关系增长，但通过标签复用可以显著降低维护成本。真正的难点不在技术本身，而在于标签体系和应用依赖关系的梳理。

四、落地时的关键判断

实施微隔离通常分三步：先以“监控模式”采集东西向流量，形成应用依赖图；再基于依赖图生成候选策略，在测试环境验证；最后逐步切换到“执行模式”，对未授权连接进行拒绝并告警。监控阶段要重点关注三类信号：高频但未授权的连接、跨环境（如 prod 与 dev）的异常访问、以及使用默认端口或明文协议的横向移动尝试。