3. 微分段策略模型：基于身份、标签与应用层

策略模型这东西，说白了就是回答三个问题：谁能访问什么，以及怎么访问。微分段不像传统防火墙那样只看 IP 五元组，它给了你更多维度的控制手段。我个人习惯把这三种模型串起来用，效果比单打独斗好得多。

3.1 基于身份的策略

先聊身份。传统网络里，你只能靠 IP 地址判断流量来源。但虚拟化环境里，VM 漂移、容器启停，IP 说变就变。这时候基于身份的策略就派上用场了。

身份可以是：

• 用户身份：AD/LDAP 里的用户或用户组
• 设备身份：虚拟机 UUID、容器 ID、物理机序列号
• 服务身份：服务账户、SPN（服务主体名称）

我在项目中遇到过一件事：某金融客户做零信任改造，一开始坚持用 IP 写策略。结果每周都有 VM 迁移导致策略失效，运维团队叫苦连天。后来换成基于 VM 身份的策略，迁移后策略自动跟随，再也没出过问题。

3.2 基于标签的策略

标签策略是我个人最喜欢的方式。它灵活，而且特别适合动态环境。你想想看，容器环境下 Pod 的 IP 随时变，但标签（Label）是稳定的。

标签策略的核心逻辑是：

1. 给资源打标签（比如 env=prod, app=web, tier=frontend）
2. 基于标签组合写策略（比如允许 env=prod 且 app=web 的流量访问 env=prod 且 app=api）
3. 新资源加入时自动继承标签，策略自动生效

举个例子，在 Kubernetes 里用 NetworkPolicy：

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

这段策略的意思是：只有带 app: web 标签的 Pod，才能访问带 app: api 标签的 Pod 的 8080 端口。IP 变了？没关系，标签没变就行。

3.3 基于应用层的策略

前两种策略管的是“谁访问谁”，但管不了“访问的内容是什么”。应用层策略就是解决这个问题的。它基于 L7 协议（HTTP、gRPC、SQL 等）做精细化控制。

举个例子：

• 允许前端访问后端的 /api/v1/orders 路径
• 禁止前端访问后端的 /admin 路径
• 只允许 GET 请求，拒绝 POST 请求

我记得有一次帮客户排查安全事件。他们用了基于身份和标签的策略，但攻击者还是通过 SQL 注入拿到了数据。为什么？因为策略只允许 Web 访问 DB，但没限制 SQL 语句的内容。后来加了应用层策略，只允许预编译的 SELECT 语句通过，注入攻击才被彻底堵住。

应用层策略的实现方式：

技术	适用场景	优势	劣势
服务网格 Sidecar	Kubernetes 环境	细粒度 L7 控制，可观测性强	性能开销稍大
API 网关	南北向流量	集中管理，易于审计	东西向流量覆盖不足
主机防火墙 L7 模块	传统虚拟化环境	性能好，兼容性强	配置复杂

3.4 三种策略的协同模型

实际生产环境里，这三种策略是配合使用的。我画了一张图来说明它们的关系：

从图上你能看到，这三层是自下而上叠加的。身份策略先过滤“谁”，标签策略再限定“去哪”，应用层策略最后控制“做什么”。少一层，策略就不完整。

3.5 避坑指南

做策略模型设计时，有几个坑我踩过，分享给你：

• 策略膨胀：我曾经见过一个客户，半年写了 3000 条策略。结果没人敢动，一改就出问题。建议定期清理无效策略，能用标签聚合的就别写多条。
• 默认拒绝缺失：很多人只写允许策略，忘了加默认拒绝。结果新服务上线后，流量不受控地乱跑。记住：微分段的基石是“白名单模式”。
• 日志不记录：策略配好了，但不记录日志。出问题时根本不知道是被策略拦截了，还是应用本身挂了。一定要开启策略日志，至少保留 90 天。