查看原文
其他

金融客户基于超融合信创平台构建微分段防护的实践及验证

构建零信任安全的 志凌海纳SmartX
2024-11-01

Everoute 是 SmartX 面向云原生和 SMTX OS 虚拟化的网络与安全产品,可以为虚拟机和容器创建符合 “零信任” 要求的微隔离环境,并通过集中的策略管理平台,减轻虚拟化和安全管理员繁重的日常操作。近期,SmartX 与某头部券商共同开展了《基于 SmartX 超融合信创平台构建微分段防护》的实践及验证课题,并由 SmartX 解决方案架构师金鑫分享了该课题的验证成果。


点击观看课题分享

欲了解更多金融行业基础架构应用场景评测,扫描下方二维码,下载《SmartX 金融核心生产业务场景探索文章合集》,探索 TA 注册登记、O32 投资交易、BI 报表等诸多金融关键应用场景在超融合平台的性能表现。





以下为根据视频整理的文字内容


为什么要基于虚拟化层进行“微分段/微隔离”


在分享之前,我们先介绍一下微分段,以及 SmartX 基于零信任技术的网络产品的功能和模型。


如下图所示,可以看到,在传统的虚拟化架构下,虚拟机之间实际上是基于一个比较开放、没有任何安全防护的网络架构。



如果想要虚拟机之间有一些安全的隔离手段,可能需要借助物理网络,或者在虚拟机里安装 Agent 来实现一些安全控制,这些都可以帮助我们解决虚拟机之间的访问控制,或者是东西向的流量管理问题。这就是我们这次分享的一个出发点:如何把整个虚拟化环境里的流量管理起来。


为什么要进行这样的实践?这里会有多方面的因素:


  • 合规性:等保 2.0 “第一级安全防护”中,对虚拟化或者云化环境的业务系统或虚拟机的安全防护有明确要求。因此从合规角度,虚拟机间必须部署安全防护。

  • 虚拟化层级的优势:虚拟机的建构和生命周期管理基于底层 Hypervisor 平台,是一种原生的支持。如果将流量从虚拟化环境中引到物理网络之中,效率不高,且会增加整个网络的延时和流量压力。因此与借助物理网络的方式相比,在虚拟化环境中,在 Hypervisor 层级实现虚拟机保护应该是最优解。



当今软件定义网络技术路线


基于此,我们再看一下,当今基于云化环境的数据中心,或者是在云化的虚拟化集群里构建这种安全防护体系有几种方法。



第一种(上图最左边)我们称之为虚拟化技术派,指的是谁提供 Hypervisor,谁就去实现虚拟机间安全防护,所以这就叫原生支持。SmartX 产品 Everoute 网络与安全解决方案就是在这样的分支下。


第二种是硬件交换派,像 Cisco、华为等传统硬件交换厂家会主导这种方案,即把网络安全防护与他们物理的安全设备或交换设备关联起来。这也是一种方向。


第三种是纯软件派,可以理解为供应商只提供安全防护功能,它与硬件和 Hypervisor 都没有任何关系。这一方案的特点就是充分解耦,既解耦了交换机,也解耦了 Hypervisor。但它的弊端就是一定要在所有的虚拟机里安装 Agent,或者说侵入到不同的 Hypervisor,才能跟 Hypervisor 内部的虚拟交换组件进行联动。所以不管是侵入 Hypervisor 还是侵入虚拟机,安装、部署、实施都会有一些复杂。


某头部券商基于 SmartX 超融合信创平台构建微分段防护的实践及验证


下面就进入这次课题的内容分享。我们在去年跟一个头部券商做了一个联合课题:基于信创环境,通过微分段防护实现虚拟化环境安全等级的加固。


课题背景


客户考虑到未来的业务系统要逐渐信创化,包括投行、经济、风控业务等。但这些业务在虚拟化集群里是共用资源的,都是以虚拟机的方式构建的,虚拟机之间往往没有安全防护手段。所以这次课题首要希望解决如何有效隔离、如何提高安全防护手段的问题。


其次,由于云化环境里虚拟机的位置是不固定的,虚拟机日常会发生云计算节点的位置迁移,不管是计划内还是计划外。所以对于虚拟机的安全策略,如何保证安全策略可智能跟随,提高安全运维效率和安全防护能力,这也是课题的一个验证目标。


第三个想要研究的问题是我们在做策略或者是 ACL 的时候该怎么做。传统网络安全都是基于五元组,即 Source IP、Source 端口、Destination IP、Destination 端口和 Protocol 协议。有没有一些其他的方式?其实虚拟化给出了一种更好的视角,就是以虚拟机为对象,而不再以 IP 地址为对象做访问控制。以虚拟机为对象,这也是原生 Hypervisor 实现东西向流量控制的一个优势体现。


最后一个目标就是不借助物理设备(不改变物理网络结构的前提下)跟物理交换或安全设备进行解耦,实现应用业务的“最后一公里保护”。


这就是这个课题最初的设计和定义,基于这 4 个需求,后面我们通过 SmartX 超融合产品、功能来实践并充分验证这些能力。


环境拓扑



项目基于三台鲲鹏芯片架构服务器构建了一个测试集群。这个测试集群上,因为要结合业务进行实践验证,所以提前部署一套信创版登记结算系统(TA6)。整个服务器配置和拓扑结构如上图所示。


可视化工具


第一步,我们要进行流量可视化的工作。因为想要了解网络中都有什么,怎么去加策略,其实是有一个先后关系的。我们不能盲目地加策略,首先需要知道网络中都跑了什么流量,哪些是我们允许的,哪些是我们不知道的,或是非法流量,我们需要对流量先进行识别。这也是课题研究的一个比较重要的基础。目前,Everoute 具备流量可视化能力,这是实践的开始。



SmartX 超融合流量可视化功能


可以看到,Everoute 的流量可视化功能可以将整个业务之间的流量识别出来,业务之间的流量的上下文是什么样,谁来访问谁,这种关系拓扑也可以被展示出来。基于此,我们先明确业务之间的访问关系,基于观测到的访问关系,我们就开始进行课题的各个实践及验证。


验证 1:微分段访问控制


第一个验证是核心微分段防护功能。因为整个平台上运行 TA6 系统,涉及到 3 个中间件 VM、2 个数据库 VM,我们需要验证在开启微分段防护下,业务跑批可正常执行,非规则允许的流程将被阻止通信。


验证过程


  1. 执行 TA6 的整个的跑批任务。这是在没有加载任何安全策略的情况下运行的,即所有状态均允许通过。

  2. 在跑批过程中,学习 TA 各组件间的通讯端口和流向,并加载安全防护策略(控制流入、流出、开放的协议及端口等)。配置界面如下图所示。

  3. 在具有安全防护下,再次执行并完成 TA 跑批流程,以验证不符合策略的数据包是否被丢弃,以及加载的安全防护控制是否影响到跑批。


安全防护策略配置界面


验证结论


通过验证。在开启微分段防护后,非规则允许的流程被阻止通信,且业务跑批可正常执


验证 2:安全攻击防护


第二个实验我们要模拟一些真正的攻击行为,来判断设置的安全防护是不是真正起到作用了,即有效拦截探测和攻击行为。


测试环境


我们在整个环境中部署了一个诱饵 VM,打开一些漏洞和服务的暴露端口,在外部通过部署的扫描工具(Zenmap)进行探测。


验证过程


  1. 在不进行安全防护下,通过 Zenmap 探测系统中的业务应用。我们设置了 10 个内部蜜罐,通过扫描可以发现这些问题是什么。例如开启了 Telnet,还运行了 1 个数据库,还有 SSH 是不是被打开、有没有弱口令等等。可以看到,扫描攻击可以很轻松地把这些信息都拿到。

  2. 然后我们开启安全防护,在扫描工具和蜜罐之间增加 policy,再次验证非正常的探测行为是否可以被拦截和阻断。可以发现,开启防护后,所有的尝试性连接都被阻断了,这也就证明了设置的策略已经生效了,而且真正地保护了业务的服务,并没有被有意的攻击者嗅探出来。


开启安全防护前后对比


验证结论


通过验证。在开启微分段防护后,策略生效,非正常的探测行为可以被有效拦截和阻断。


验证 3:网络性能


第三个实验需要进行性能测试。增加了安全策略,其实就增加了控制手段,它一定或多或少会影响到整个网络的吞吐。其实客户也是非常关注这一部分的,我们认为,对于金融机构,在保证足够的性能要求下,提高安全管控能力应优先考虑。因此我们通过这个实验,测试有没有策略和加载 2000 条策略时,超融合平台的性能表现是什么样子(即“开启/关闭”安全防护下的网络吐吞和延时性能指标)。


测试环境


在测试集群不同物理节点,分别部署 2 个 VM, 并安装好 iperf 和 netperf 性能压测工具。


验证过程


  1. 不增加任何安全策略情况下,进行网络吞吐和延时测试。结果见下图。

  2. 开启安全防护(约 10 条),再次进行网络吞吐和延时测试。可以看到整个性能稍微有一些下降,但整体表现可以接受。

  3. 将策略增加到 2000 条,再次进行网络吞吐和延时测试。这些策略是通过一个脚本随机生成的,尽可能地模拟真实场景。为什么是 2000 条?我们是这样评估的:如果一个集群内有 200 个虚拟机,我们给每一个虚拟机增加 10 条策略,这样总数就是 2000 条 policy。结果总体来看,从吞吐到延时都在一个正常范围内,从体验角度来看没有太大的变化。



验证结论


SmartX 微分段防护可以在进行虚拟环境安全加固的同时,保证足够低的网络吞吐和网络性能损耗。


后续验证:架构可靠性、策略导入导出、策略跟随、升级维护


架构可靠性


微分段或软件定义的网络安全防护解决方案,实际上控制平面和数据平面是分离的,也就是说,控制平面只负责管理,包括策略的下发,但并不负责策略的执行。


因此我们在这里验证,把所有的控制平面全部 down 掉,策略是否可以正常执行。下图可以看到,三个控制面全部异常时,整个策略的执行还是在正常进行,在这种极端情况下,我们的架构依旧具备可靠性。



策略导入导出


这里我们从运维视角切入。因为运维人员可能会构建很多策略,如果因为一些原因,我们需要做策略导入导出,还是需要一个灵活的运维管理方式。例如在导入的时候,我们可以在这里选择要导入的某几条或者是全部策略,这样的设计给了运维人员一个灵活的操作体验。



策略跟随


策略跟随是我们最早期定义的目标,即整个虚拟机所在位置是非固定的状态,我们要保证虚拟机的策略可以跟着虚拟机一起移动,不管移到哪个节点,它的整个策略是实时且始终生效的。所以这个测试中,我们一边迁移虚拟机位置,一边判断策略加载的效果(如下图)。



升级维护


升级维护也是运维中比较重要的任务,我们在最后也增加了这样一个测试:在策略执行的过程中,我们对整个控制平面的软件版本进行了 update,在 update 的过程中,我们可以看到整个策略执行也是正常的。其实这个动作和我们模拟所有控制节点离线,实际上效果是差不多的,都证明了控制平面在进行计划内的一些维护动作时,不会影响整个数据平面的执行动作。



课题总结


这个课题有几个突出的亮点:


  • 安全策略分布在信创云环境中的每个物理主机节点中执行,不需要在虚拟机中安装软件,因为它是一个零代理的技术,完全在 Hypervisor 实现安全防护。我们也不依赖物理交换机特殊的功能或配置,对物理交换机、物理安全防火墙、IPS/IDS 其实都没有依赖,也无需将虚拟机流量引导至特定设备,引起不必要的网络架构调整和性能瓶颈。安全策略跟随等功能也能更好地支持虚拟机迁移云特性。

  • 满足并实现对“等保 2.0 网络安全等级保护要求”中安全计算环境章节对虚拟机访问控制策略要求。

  • 白名单策略模型,这也是 SmartX 网络与安全产品的一个特点,它跟传统的安全设备还是有一些区别的:传统的安全设备是通过增加一条策略,基于五元组的方式来实现网络安全的策略控制。SmartX 是基于白名单,也就是默认情况下,不允许所有流量通过,通过流量的学习给各个业务打标签,以及打开相应的策略端口来实现策略管控。白名单也是零信任(新一代网络安全防护理念)的一种实现方式。




更多金融行业场景实践,请阅读:


点击原文,下载《SmartX 金融核心生产业务场景探索文章合集》,探索 TA 注册登记、O32 投资交易、BI 报表等诸多金融关键应用场景在超融合平台的性能表现。


继续滑动看下一个
志凌海纳SmartX
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存