洞察策略风险,用自然语言提问策略问题。 申请演示 →
Published:
微分段与网络分段:每个安全团队最终都会面对的问题
by FireMon
扁平网络已无法防御。每家企业迟早都会走到同一个转折点:我们需要分段,但要哪一种?这个问题常常被表述为一道选择题:网络分段与微分段之争。而实际上,只要您的环境稍具复杂度,这种表述方式就会失效。当今大多数企业的运行环境涵盖:
- 多家防火墙厂商
- 混合数据中心与云环境
- AWS、Azure 或 Kubernetes 中的工作负载级管控
- 新兴的 Zero Trust 访问层
在这样的环境中,分段不是一次性的决定,而是一整套执行层的叠加。由此带来真正的挑战:问题不在于选择哪种分段类型,而在于如何在每一个执行层之上治理策略意图。
什么是网络分段
网络分段通过以下方式将您的环境划分为若干大的安全区域:
- VLAN
- 子网
- 路由器
- 访问控制列表(ACL)
- 防火墙
可以想到以下常见构造:
- DMZ
- 内部网络
- 访客网络
- PCI 区域
- OT/IT 隔离
主要目标
管控南北向流量(进出各区域的流量),并缩小整体攻击面。
优势
- 技术成熟,广为理解
- 对合规框架(PCI、HIPAA 等)行之有效
- 在较小规模下运维开销更低
- 建立清晰的安全边界
其失效之处
传统网络分段本质上是粗粒度的。流量一旦进入某个区域:
- 其移动往往不受限制
- 东西向可见性有限
- 横向移动变得更加容易
再叠加现实环境中的复杂性:
- Check Point 的规则不同于 Palo Alto 的规则
- 云安全组的行为方式与防火墙不同
- 各平台上的策略各自独立演进
若缺少统一层,策略漂移会立刻开始。
什么是微分段
微分段在工作负载、应用或终端层面实施安全策略。它管控的不是区域之间的流量,而是区域内部的流量。
实施方式
- 基于主机的代理(例如 Illumio)
- 虚拟机监控程序层面的管控(例如 VMware NSX)
- 云原生管控(AWS Security Groups、Kubernetes Network Policies)
重要区别:云原生管控提供工作负载级的策略执行,但它们并非完整的微分段平台。
主要目标
管控东西向流量,并在工作负载之间实施最小权限访问。
优势
- 阻止横向移动(对勒索软件遏制至关重要)
- 支持 Zero Trust 分段
- 分段策略跟随工作负载,而非 IP 地址
- 可随动态云环境扩展
其难点所在
微分段会带来:
- 高复杂度
- 依赖关系梳理方面的挑战
- 未经验证即变更而导致应用中断的风险
- 跨多个平台的分布式策略执行
每个平台对策略的建模方式各不相同。真正的问题由此开始:预期策略与实际执行策略之间的差距会迅速扩大。
微分段与网络分段的核心差异
类别
网络分段
微分段
范围
区域(子网、VLAN)
工作负载、应用、终端
流量重点
南北向
东西向
执行方式
防火墙、路由器
代理、虚拟机管理程序、云原生控制
策略锚点
IP、子网
身份、标签、标记
粒度
粗粒度
细粒度
变更频率
相对稳定
高度动态
所需成熟度
低至中等
中等至高
主要用途
合规、边界管控
阻止横向移动、Zero Trust
真正关键的因素
这一对比很有用,但并不完整。因为两种方法都会:
- 生成策略
- 执行策略
- 运行在不同平台上
而这些平台之间并不互相治理。风险正是在此累积。
何时使用网络分段(以及何时它已足够)
网络分段通常是正确的起点。
适用的典型场景
- 合规分区(PCI、HIPAA)
- OT 与 IT 分离
- 访客网络与企业网络隔离
- 安全成熟度处于早期阶段
表明它可能已足够的迹象
- 东西向流量风险有限
- 应用环境稳定
- 云环境复杂度极低
- 防火墙厂商种类较少
如果您的环境相对静态,网络分段可以发挥很大作用。
何时使用微分段
当横向移动风险上升时,微分段就变得至关重要。
适用的典型微分段场景
- 勒索软件遏制
- 保护核心关键应用
- 混合云与多云环境
- 医疗设备隔离
- 金融服务应用分段
表明您需要它的迹象
- 东西向流量密集
- 敏感应用共处同一区域
- 云工作负载快速变化
- 已部署多个策略执行平台
一项重要提醒
请勿在缺乏规范的情况下直接上马微分段。如果在验证策略行为之前就实施细粒度管控,您将面临以下风险:
- 导致应用中断
- 造成运营摩擦
- 项目陷入“试点炼狱”而停滞不前
在缺乏治理的情况下实施微分段并不能降低风险,反而往往会放大风险。
两者如何协同:分层分段模型
现代环境不会二选一,而是将两者分层组合。可以这样简单理解:
- 网络分段 = 建筑物的外墙
- 微分段 = 每个房间内部上锁的门
- ZTNA/SASE(例如 Zscaler)= 入口处的安全检查站
- 治理 = 确保每扇门都与设计图纸一致的总钥匙系统
每一层以不同方式降低风险:
- 宏观边界缩小攻击面
- 微分段阻断横向移动
- 访问层控制用户到应用的连接
但问题在于:执行发生在各处,而策略意图必须在某处得到统一治理。申请演示,了解统一策略治理如何在这些层面之间运作。
真正的挑战:在每个执行层面治理分段意图
大多数分段战略忽视的问题在于:
- 防火墙执行网络分段
- 微分段平台执行工作负载策略
- 云端控制执行特定环境的规则
- ZTNA/SASE 平台执行用户访问控制
每个系统:
- 拥有各自的策略模型
- 独立演进
- 无法看到其他系统的情况
随着时间推移会发生什么
- 规则不断新增
- 例外不断累积
- 标签发生变化
- 云环境持续扩展
- 团队无法再掌握实际有效的访问权限
结果如何?您预期的分段模型会逐渐偏离实际情况。数据也印证了这一点:60% 的企业防火墙在首次评估时未能通过高严重性合规检查。这不是工具问题,而是治理问题。如果没有控制平面:
- 团队对实际放行的流量失去信心
- 审计过程变得艰难
- 风险变得不可见
- Zero Trust 项目在投入生产之前就陷入停滞
FireMon 如何统一网络分段与微分段治理
防火墙、微分段平台和云端控制负责执行策略。FireMon 位于这些之上,作为云网络安全策略治理的控制平面运行。
这在实践中意味着什么
- 跨平台规范化策略。FireMon 将防火墙规则、云端控制和微分段策略纳入统一模型,涵盖 Illumio 和 VMware NSX 等平台,并可查看 Zscaler 等相邻层面的情况
- 持续验证意图与执行的一致性。确保分段在每个环境中的行为都与设计完全一致
- 及早发现偏移与暴露面。在过度宽松的访问、违规和不一致演变为安全事件之前将其识别出来
这弥合了以下两者之间的差距:
- 您所设定的意图
- 实际执行的结果
而大多数风险正存在于这一差距之中。进一步了解Zero Trust 微分段治理。
选择您的分段战略
如果您正在评估分段方案,请从几个关键问题入手:
- 您处于成熟度曲线的哪个阶段?
- 您的主要风险是边界被攻破,还是横向移动?
- 您的环境动态变化程度如何?
- 涉及多少个执行平台?
- 您能否有把握地在所有这些平台上验证策略意图?
切实可行的推进路径
1. 从网络分段入手 2. 针对高价值资产叠加微分段 3. 引入控制平面,统一治理所有执行层的策略 进一步了解网络分段最佳实践。
接下来该怎么做
对大多数企业而言,微分段与网络分段之争本身就是个错误的问题。您无需二选一,而是要在多个平台、多家厂商和多种环境中同时运行两者。真正的差异不在于分段技术,而在于您能否对所有执行策略的组件统一治理策略意图。如果做不到:
- 策略会发生偏移
- 风险会不断累积
- Zero Trust 会陷入停滞
如果做到了:
- 风险可以衡量
- 访问得到控制
- 安全真正落地运营
申请演示,了解 FireMon 如何在您的混合、多厂商环境中治理分段。
常见问题
网络分段利用 VLAN、子网和防火墙将网络划分为大的区域,在边界处控制南北向流量。微分段则在工作负载或应用层面实施精细策略,控制这些区域内部的东西向流量,在系统之间落实最小权限,这是微分段与网络分段的一个关键区别。
不能。微分段是对网络分段的补充,而非替代。网络分段确立宏观边界并缩小攻击面,微分段则控制这些边界之内的网络流量。大多数企业会在分层安全架构中同时采用这两种方法。
微分段可以独立部署,但它是 Zero Trust 的核心组成部分。它通过限制工作负载之间的横向移动,帮助落实最小权限访问并遵循“假定已被入侵”的原则。Zero Trust 在此基础上进一步引入身份、上下文和持续验证。
专用平台包括用于基于主机分段的 Illumio 和用于虚拟机管理程序层控制的 VMware NSX。AWS Security Groups 和 Kubernetes Network Policies 等云原生工具可在工作负载层面实施控制,但并非完整的微分段平台。Zscaler 属于 ZTNA/SASE 层,而非微分段。
具备条件意味着已有稳定的网络分段、清晰的策略卫生状况,以及对应用依赖关系的可见性。团队还应能在实施策略之前验证实际访问路径。缺少这些条件,微分段工作往往会中断应用并陷入停滞。
FireMon 充当各类执行技术之上的控制平面。它在防火墙、云端控制以及 Illumio 和 VMware NSX 等微分段平台之间治理策略意图,并对 Zscaler 等相邻层保持可见性。这可确保预期策略与实际执行策略持续保持一致。
大多数失败发生在团队未经验证就实施策略,以及多个执行平台缺乏统一治理各自为政之时。这会导致策略偏移、应用中断,并因对实际访问缺乏信心而使 Zero Trust 计划陷入停滞。