在《零信任安全,从微分段做起》这篇文章中,我们介绍了如何通过微分段技术实现超融合环境下的“零信任”安全策略。同时,日趋显著的“东西向”安全威胁和“等保 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 的安全管理智能化和自动化

结语

企业建设数据中心的目的是为了提高数字化应用的服务质量和效率,部署相应的安全措施也是为了保障数字化服务的连续性。在外部和内部网络安全威胁越来越严重的情势下,如果仅仅是简单地累加安全设备的种类和数量,有可能适得其反——不合理的安全措施会降低数据中心的效率、弹性、敏捷性和业务处理能力。

SmartX 基于自主研发的超融合系统,通过在数据中心的虚拟机之间部署分布式微分段安全机制,帮助用户减轻、消除数据中心内部的东西向安全威胁,在运行效率和安全保障之间很好地实现了平衡,特别适合于符合以下特点的虚拟化环境:

  • 虚拟化比例高,虚拟机数量大,是应用的主要载体形式。
  • 多业务 / 应用 / 部门混用的虚拟化集群。
  • 面向外部用户提供服务的虚拟化集群(DMZ 区)。
  • DevSecOps 方法论驱动的自动化流程。
  • 需要通过等保 2.0 测评。

参考文章:

1. 信息安全技术 网络安全等级保护基本要求
http://gxxxzx.gxzf.gov.cn/szjcss/wlyxxaq/P020200429546812083554.pdf 

点击了解 SMTX OS 如何通过微分段构建零信任安全