当前位置：网站首页>一文了解微分段应用场景与实现机制

一文了解微分段应用场景与实现机制

2022-07-03 14:01:00 【SmartX 超融合】

在《零信任安全，从微分段做起》这篇文章中，我们介绍了如何通过微分段技术实现超融合环境下的“零信任”安全策略。同时，日趋显著的“东西向”安全威胁和“等保 2.0”的落实都要求企业尽快在生产环境中实现虚拟机间的安全保护策略。那么，为什么企业需要将微分段纳入现有网络安全策略？如何通过微分段保护实际生产场景中的数据安全？本文将聚焦以上两个问题解读微分段的作用与应用。

为什么虚拟化环境中需要微分段？

1. 虚拟化环境的复杂性必然加大了安全管控的难度

在探讨微分段的作用之前，我们需要了解虚拟化环境为基础架构安全带来了哪些新的挑战。相较于基于物理服务器的传统架构，虚拟化环境中，一个物理服务器上会运行多个虚拟机，这就给数据中心内部构成带来了三个主要变化：

被管理对象总体上增多了——从若干台物理服务器增加为十倍以上数量的虚拟化服务器。
被管对象的位置不再是长期确定的——每一台虚拟机可能在不同的时间运行在不同的物理服务器上。
被管对象数量和属性的变动更快了——对虚拟机的创建 / 启动 / 关闭 / 删除等操作频率远远高于物理服务器。

这些变化不仅让虚拟化环境变得复杂，也给新形势下安全策略的编写和管理出了一道难题：

传统数据中心架构下，网络安全策略主要部署在数据中心的边界上，难以对数据中心内部的物理服务器之间、虚拟机之间的通信进行管控。
由于虚拟机数量相比物理服务器数量大幅增加，它们之间的访问控制策略数量必然随之“爆发式”增长，想要人为设置、管理十分困难。
常见的安全策略，是通过 IP 地址来标识被保护和被拒绝的通信对象，但由于虚拟机更加频繁地被创建、删除、关闭、启动，IP 地址的变动频率也更高了——这些都要求对应的安全策略必须及时更新。

2. “东西向”安全威胁已不再是“小题大做”

虚拟机间的安全管理，也就是常说的“东西向”防御，主要是在数据中心内部的服务器、虚拟服务器之间部署安全措施进行网络通信的管理。

数据中心的安全设计中，普遍会在“南北向”关键通路上设置防火墙、入侵检测 / 防御、病毒查杀、防 DDoS 等一系列安全设备和措施，来识别并拦截由数据中心外向内进行的攻击。然而，“未知安全威胁”的种类和数量正在不断增加，难免有些会因为技术或管理上的瑕疵而成功侵入某台服务器，随后更容易顺着防备薄弱的“东西向”通路快速扩散，造成数据中心内部的虚拟机 / 服务器连锁沦陷。Apache Log4j 的远程代码执行漏洞就是一个典型的例子：

2021 年 12 月，Apache Log4j 2 被发现存在远程代码执行漏洞，该漏洞允许攻击者在目标服务器上执行任意代码，可导致服务器被黑客控制，并可能以此为跳板，继续侵入并控制数据中心内部其他服务器——有些服务器不能从外网进行访问，忽视了安全防护措施，导致它们更容易从内网被侵入。

由此可见，虚拟化环境中的网络安全策略应充分保护“东西向”网络通信安全，避免安全威胁在数据中心内部横向扩散。

3. “等保 2.0”的客观要求

随着数据中心内部虚拟化比例越来越高，虚拟化环境安全风险越来越大，在 2019 年颁布并实施的《信息安全技术网络安全等级保护基本要求 GB/T 22239 — 2019》（以下简称为“等保 2.0”）中，也明确将“虚拟机之间的访问控制”列为所有安全级别都应满足的要求：

6.2.4.1 访问控制

本项要求包括：

a) 应保证当虚拟机迁移时，访问控制策略随其迁移；
b) 应允许云服务客户设置不同虚拟机之间的访问控制策略。

这就意味着，所有需要通过等保 2.0 的企业系统，都必须满足上述要求，来保障数据中心内部的通信安全。微分段，即在任意虚拟机之间都设置安全访问控制的技术，是虚拟化环境中有效的、必应采用的安全机制。

微分段在实际生产场景中如何应用？

知易行难！在 SmartX 超融合中，是如何对生产环境进行高效率的东西向微分段呢？

1. 从“默认允许”到“默认拒绝”的转变

现在经常采用的“明确拒绝、默认允许”安全策略（俗称“黑名单”模式），只能防御已知的攻击，却给未知安全威胁留了机会。而且，由于已知安全威胁数量不断增加，因此需要为阻拦这些具有潜在危险的通信制定很多安全策略。

而 SmartX 超融合环境下的安全策略基于“明确允许、默认拒绝”的逻辑（俗称“白名单”模式），这也是“等保 2.0”中对访问控制的明确要求。

6.1.3.2 访问控制

本项要求包括：

a) 应在网络边界根据访问控制策略设置访问控制规则，默认情况下除允许通信外受控接口拒绝所有通信。

在虚拟化环境中，物理服务器的功能逐渐被拆分到不同虚拟服务器上运行，每个虚拟服务器需要对外暴露的协议端口屈指可数——只需明确允许对这几个协议端口的访问，便可满足虚拟服务器正常工作的要求，而其他端口上的通信“默认拒绝”，就杜绝了来自未知安全漏洞的威胁——实现了“以最少数量的安全规则，最大限度保障通信安全”的目标。

以 WannaCry 蠕虫病毒举例，它利用 Windows 操作系统 445 端口存在的漏洞，主要在主机 / 虚拟机之间进行横向扩散，并具有自我复制、主动传播的特性，感染计算机后会向计算机中植入敲诈者病毒，导致电脑大量文件被加密。当时普遍认为 Windows 系统的 445 端口主要在内网使用，没什么风险，因此这个端口上的通信都被“默认允许”了；病毒一旦因某种偶然契机成功侵入了一台 Windows 系统，就可以借 445 端口在内网进行横向扩散，导致整个数据中心的 Windows 系统都被感染。

在启用了虚拟机之间的微分段机制之后，只有经过“明确允许”的数据流才能够到达虚拟机，不再“默认允许”。假设某台 Windows 虚拟机是用作网页和 FTP 服务器的，那么对它的安全规则只会包含“明确允许”这几种协议，其他所有通信（包括 445 端口）会被“默认拒绝”。这种安全配置模式下，不仅外部威胁通过未知端口上侵入到内网的概率将大大降低，也避免了偶发的安全漏洞在数据中心内部被放大。

所以，SmartX 微分段安全策略对虚拟机进行保护的基本原则就是“默认拒绝”，只有经过管理员指定的通信流可以到达 / 离开虚拟机。

2. 用“看得懂”的方式简化虚拟机之间安全策略

要实现安全策略模式的转变，为所有的虚拟机的网络通信制定“明确允许”的策略，这个工作量会不会太大？会不会导致安全管理过于复杂而无法运维？

上一小节的对比已经表明，对某一个虚拟服务器而言，采用“白名单”模式所需的安全规则数量，会远远少于“黑名单”模式。那么扩展到多个虚拟服务器、扩展到整个数据中心 / 多个数据中心呢？

我们试想一下为如下场景编写安全策略的工作量：

HR 部门的虚拟机需要能够访问 OA 系统的其他 5 种虚拟机服务器。
OA 系统包含至少 10 种服务器，使用者涉及到 20 多个部门。
除了 OA 系统，公司内部还有研发系统、生产系统、供应链系统、客户关系系统等等十余个系统。
以上涉及到的各种虚拟机、服务器的 IP 地址，会随着业务 / 应用 / 部门的调整而变化，不能保证来自连续的地址段。

这些部门、系统、应用之间的复杂业务联系，确实有可能导致基于 IP 地址的安全规则数量爆炸式增长（参考上文配图中的安全策略数量级），安全体系过于复杂而无法维护，亟需更好的方法对安全策略进行优化。

SmartX 超融合的微分段机制原生于自身的 ELF 虚拟化系统，允许管理员为每一个虚拟机设置自定义的“标签”。这个“标签”可以理解为虚拟机的“别名”，比如：“HR 部门的虚拟机”、“HR 专用文件服务器”等等。有了这些标签，制定出来的安全策略就大大简化了，就像是下面这样：

允许 “HR 部门的虚拟机”访问 “HR 专用文件服务器”

为虚拟机设置了标签（比如，“HR 部门的虚拟机” ），就意味着它遵循“默认拒绝”原则，除了这些被“明确允许”的行为以外，其他的网络通信都会被拒绝。

这样的策略基于业务场景，比起使用一串 IP 地址编写的安全规则更加容易被理解，而且规则条目也经过了汇总简化。今后，即便这个应用环境发生了一些变化，比如：

HR 部门的虚拟机数量增减或 IP 地址变化。
被访问的文件服务虚拟机数量增减或 IP 地址变化。
客户端虚拟机或服务器虚拟机，在不同物理服务器、不同机房之间发生了位置迁移。
……

以上这些场景下，每个虚拟机设置了“标签”就会和对应的安全策略自动关联，具有以下优点：

不单纯依赖边界安全设备。
不单纯依赖使用 IP 地址（段）作为安全策略的条件。
不必为虚拟机的每次变动而手动调整安全策略。

3. 对可疑虚拟机进行“一键式”隔离

对于运维人员而言，没有什么安全措施是万全的保障，必须提前备好在突发安全状态下的紧急预案，才能对“万一”发生的安全事件进行快速响应。SmartX 超融合的微分段功能，也包含了对于虚拟机进行紧急隔离的技术方法。

具体来说，当管理员或安全运维中心（SOC）发现某个虚拟机的行为异常，比如某个用作文件服务器的虚拟机上的收 / 发流量突增，但所有普通用户都无法连接到这个服务器，此时就可以：

立刻通过超融合管理界面或 API 将这台虚拟机置于“网络隔离”状态。
被“隔离”的虚拟机与周边的通信被完全切断，不会再影响到同一环境内的其他虚拟机，为管理员排除安全威胁或系统故障争取了时间。
如果排查 / 修复过程中，管理员需要临时与虚拟机进行通信（比如需要通过运维跳板机上传补丁文件、运行远程诊断程序），则可以通过设置“诊断隔离白名单”，允许被隔离虚拟机与特定目标之间的临时单点通信。
故障 / 安全漏洞修复后，还可以“一键式”恢复虚拟机的正常运行状态，隔离之前已经应用在这个虚拟机上的安全策略无需调整，重新生效。

我们可以将超融合系统中的安全机制总结为两个“常态”和一个“非常态”：

将“明确允许、默认拒绝”的安全模式常态化。
将“安全规则与虚拟机属性自动关联”常态化。
支持对“非常态”下的虚拟机进行快速隔离。

SmartX 微分段的内在机制

为什么 SmartX 超融合可以实现虚拟化环境安全机制的彻底转型？

1. “安全微分段”内生在超融合架构中

SmartX 的安全微分段内生于超融合操作系统，在每台主机上运行专用进程，对虚拟机之间的通信流量进行直接管理。要对一个或多个超融合集群启用安全微分段，仅需在集中管理器上将此功能与对应的虚拟交换机进行关联就可以。开启后，虚拟机之间的数据包被“允许”或“拒绝”动作，由集群上的每台主机分布式执行，优势体现为：

不装插件：不在虚拟机上安装任何代理或插件，虚拟机可以采用任何操作系统、运行任何应用程序。
不动网络：无需变更任何网络线路，无需修改物理网络上路由器、交换机、防火墙的任何配置。
没有瓶颈：安全功能分布在所有主机上，不会由于少数主机性能消耗过大而形成瓶颈。

这是对于整体架构影响最小的方式，也要求超融合系统具有过硬的自主核心技术才能实现。

2. CloudTower 实现统一安全管理

以上提到的虚拟机管理、标签管理、安全策略管理、虚拟机隔离等安全运维操作，都可以在 SmartX 超融合系统的“管理中心”—— CloudTower ——上完成。CloudTower 是 SmartX 自主研发的多集群管理软件，在同一个管理界面上即可对不同集群上的虚拟机、分布式存储和安全微分段进行配置。虚拟机即使发生了跨集群的迁移，也仍然在原有 CloudTower 管理范围内，虚拟机标签可以保持、与标签关联的安全策略也可以在不同集群上被执行。

CloudTower 的管理任务可以通过图形界面和 API 接口完成。管理员的人工操作主要在图形界面上完成；API 接口可以对接独立的“安全运维中心（SOC）”，按照 SOC 的指令完成超融合集群内部的配置调整。而且，由于安全微分段机制完全不需要变更任何物理线路、不需要配置任何物理网络设备，因此可以实现基于 API 的安全管理智能化和自动化。