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

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

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

零信任安全，从微分段做起
很多网络安全从业人员早上起床后的第一个念头是:在我睡觉的几个小时内,世界上又有新的威胁或攻击出现了吗? 根据<CyberEdge Group 2021 网络威胁防御报告>,86.2% 的受 ...
一文介绍备机重建各种方法的实现机制
摘要:本文将介绍备机重建各种方法的实现机制,并结合应用场景分析,以及对新增参数的使用建议,以期获得最佳应用效果. 本文分享自华为云社区<先码再看,一文介绍备机重建各种方法的实现机制>,原文 ...
【OS学习笔记】三十保护模式九：段页式内存管理机制概述
上几篇文章学习了任务切换相关知识,如下: [OS学习笔记]二十六保护模式八:任务门-任务切换 [OS学习笔记]二十七保护模式八:任务切换的方法之----jmp与call的区别以及任务的中断嵌套今 ...
玩转华为ENSP模拟器系列 | 配置多段拼接场景下的伪线BFD示例
素材来源:华为路由器配置指南一边学习一边整理试验笔记,并与大家分享,侵权即删,谢谢支持! 附上汇总贴:玩转华为ENSP模拟器系列 | 合集_COCOgsta的博客-CSDN博客_ensp实验大全目 ...
响应“十三五”汽车工业发展规划意见，景联文提供自动驾驶全场景定制化数据采集标注服务
"汽车智能化.网联化是未来发展的重要趋势,发展自动驾驶可以帮助用户解决出行的相关痛点,有效提升交通效率,对促进国家科技.经济.社会.生活.安全及综合国力均有着重大意义.景联文科技提供自动驾驶 ...
好文推荐 | MySQL binlog应用场景与原理深度剖析
作者:田守枝来自:田守枝的博客(公众号) 本文深入介绍Mysql Binlog的应用场景,以及如何与MQ.elasticsearch.redis等组件的保持数据最终一致.最后通过案例深入分析binl ...
一文读懂 IoT 物联网场景 5G 专网技术
5G专用网络(private 5G network)是一种局域网(LAN),它将使用5G技术创建具有统一连接性.优化服务和特定区域内安全通信方式的专用网络 .此前,机构曾预测2020年全球5G专网市场 ...
一文读懂哈希时间锁的合约机制、改进方向与应用场景
哈希时间锁起源于闪电网络,而后应用到 Interledger.雷电网络.Sprites 通道等. 撰文:钱柏均,就职于 HashKey Capital Research 审校:邹传伟,万向区块链.Pl ...
景联文科技助力AI技术场景化落地|数据标注
"当前以机器学习为主的人工智能技术的高速发展主要依赖于底层数据的多样性.作为AI基础层,数据标注有着无法替代的重要性.景联文科技作为专业的数据标注公司,支持数据标注相关业务." 随 ...

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

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

最新文章

热门文章