龙蜥衍生版 KerarchOS数据安全、RDT等实践应用|龙蜥大讲堂105期
内容介绍:
一、数据安全趋势
二、基于可信根的全盘加密
三、下一步计划
四、Intel QAT/RDT概述
五、KeyarchOS基于QAT的场景化实践
六、KeyarchOS基于RDT的场景化实践
现在主要介绍我们浪潮信息KeyarchOS在数据安全方面的解决方案,主要是如何基于可信根在做全盘加密。
首先说一个简单的背景。
一、数据安全趋势
在马克翔博士的介绍中,可以看到数据安全事件层出不穷,而且数据安全也已经影响到了我们每一个人,包括影响到我们国家的安全,下至普通老百姓的日常生活,上至我们国家安全战略,因此在新一代的信息基础设施建设的过程中,我们发现安全防护的建设已经转向为以数据安全为中心的建设。
发现信息安全的能力至关重要。让KeyarchOS作为操作系统,也作为完善信息设施的一个关键枢纽,它也提供了全面的安全服务。除了刚才所介绍的数据使用时的经济预算的一个服务,以及包括我们数据传输时的服务,也在数据存储时也做了一系列的探索。数据存储一个方面是传统磁盘、网盘以及各种场景下的加密,另外还有各种各样的加密机、加密卡的使用。同时发现在边缘场景的特殊条件下,单纯依靠密码机、密码卡高成本的方法其实并不合适。这时发现有一个U安全,还有廉价的一个方式,就是基于可细分的加密。
我们首先以一个实操来给大家介绍一下实践。首先在这个例子,我们创立磁盘文件,在创建空文件以后,磁盘里面的信息是可以通过一系列的磁盘或者文件的解析工具来识别到这个文件,其实它没有所谓的安全性可言。
二、基于可信根的全盘加密
基于KeyarchOS的方式创建一个硬盘,基于KeyarchOS的方式来去加密,会首先加密一个卷,再把这个劵挂上来,去创建一个文件,然后在下一个文件里面写进一些内容。下载以后我们再去查看这个文件,会发现查看不到这个文件和写在里面的内容,这样就达到了保护的一个措施。但是这里面有个问题,我们要在边缘的场景下单独的靠人去记这个口令,其实并不安全也不可行,这时需要我们有一种安全措施去把密码的可信根,把磁盘口令保存起来,而且能够应用。
用可信根去存储加密口令,相当于口令是在一个业界的芯片里面,在我们编辑服务器或者一个小盒子、一个芯片里面,安全性可能会更强一些。但是会出现一个问题,可信根也可以通过介质或是一些命令去破坏卷,或拿到可信根的一些特定权限去拿到密码或者口令,然后进一步去拿到我们保密数据,这时我们知道可信根有一个能力,是把平台完整性的状态记录,把可信根口令的使用和平台完整性状态去绑定时,就会发现刚才的安全问题就不复存在。
使用方式:首先会创建一个口令,创建一个加密的磁盘文件,但是磁盘文件加密的方式是和这个平台的状态配置系统去绑定,绑定之后就会发现我们正常的去加密解密使用的时候是没有问题的,如果平台完整性被破坏,有一些加密文件无法打开。
所以要防止两种情况,一种情况就是有人恶意去破坏磁盘,比如说把磁盘从一个边缘的设备商拔掉,或者另外一个设备上去划分起来,或者说启动的时候通过系统进行一些命令来去拿到可信根的一些权限,然后去拿到它的一些口令去解密。
但有一个问题,就是当我们将这种密钥使用和平台完整性状态去绑定的时候,我们会发现安全策略脆性问题,我们在与加密设备或者可信根去使用的时候经常遇到的一个问题。我们平台上面有很多组件,尤其是我们操作系统,比如说我们操作系统的这个内核,我们的一些系统组件,包括我们的部件,包括我们平台的部件,也会经常去升级,升级以后它的平台完整性状态务必就会发生变化。
但是如果说单纯以PCR去绑定的方式来去构建安全系统会发现每次升级以后都会非常繁琐。很有可能因为工作人员的误操作,导致策略不可回购,数据就永远没法解密了。我们采用了在可信根里面的另外一个能力,就是基于签名的方式,首先创建一个密钥利用我们这个PCR策略去签名,将这个用来签名PCR策略的这个公钥与口令去绑定。
这样我们所信任的是这个密钥,这个密钥去使用之前,我们首先会去验证平台的完整性状态,然后再去使用这个密钥,这样我们就可以有效的去解决密码策略的脆性问题。刚才所说的场景非常适合在边缘、终端的一些场景去使用一些解决方案。
三、下一步计划
浪潮在数据安全建设的方面会在做更多的探索。刚才所介绍的这种能力在很多操作上也具备,但是我们的右翼人员或者操作的使用人员,包括我们一部分开发人员很少去意识到能力使用,也会去开发更多类似的案例去帮助我们的客户,帮助开发人员识别或挖掘QS里面一些既好用又安全又易用的安全服务能力。与此同时,也会面向国内商业的、合规的需求去构建全栈商密的方案,这也是我们下一步的计划。
以上是我的一些分享,感谢大家。
大家好,我是浪潮信息集团外研部的高旭林,非常开心今天能给大家分享我们浪潮信息的操作系统。KeyarchOS在基于RDT技术还有QAT的场景化实践。
四、Intel QAT/RDT概述
本次主要从以下三个方面给大家介绍,首先对于RDT技术和QAT技术进行一个简要的叙述。接下来会介绍基于这两个技术在KeyarchOS上进行的场景化实践。
关于我们的操作系统KeyarchOS,最早是通过数10年的积累,最后成功开发出来一款系统,包括迁移方案,迁移工具。大家如果感兴趣的话,在我们的线下展区也有现场演示。
简单介绍一下QAT技术,英特尔的QAT技术全称是英特尔数据保护与压缩加速技术,它主要是通过将这些比较吃CPU资源的一些操作给卸载到硬件加速卡上,从而帮助完成加速向TRS的加解密操作,还有数据压缩和数据解压缩。通过这些操作可以减少我们的CPU资源消耗,英特尔的QAT技术的整体架构如图所示,在这个内核空间上,它提供了一个驱动程序,来负责跟底层的硬件设备进行交互。在用户空间上,它提供了依赖库来向上层应用提供接口来调用。而目前QAT的技术应用也很广,像各种云计算,存储,网络边缘等服务都会用到。
RDT技术,是一个对于共享资源的调控和监控技术,主要是为了帮助减少noisy neighbor问题,是在虚拟化场景中,由于我们数组机上的资源有很多都是共享的,比如像缓存,包括内存带宽,这些资源对于整个虚拟化环境中是共享的。如果有一个应用占用了大量的 l3缓存,或者说它占用了大量内存带宽,因此对于其他的虚拟机来说,业务性能就会受到影响。RDT资源调配技术主要通过硬件上的CPU指令,来帮助用户对CPU的 L3缓存,以及内存带宽进行资源的分配。因为RDT技术是需要硬件设备支持的,所以像CPU基本上就是英特尔的第3代,第4代自强,包括它的灵动。在内核空间上,RDT的主要分类,因为包括监控和缓存技术,总体来说它的功能有5个,分别是缓存的监控、缓存的分配、内存的监控、内存的分配、以及cdp,是缓存分配技术的拓展,对于代码层面的数据能够提供一个优先级的分配,在用户层内核通过这个rest接口,可以将rest control挂载在资源控制系统。通过挂载方式去控制RDT的相对功能,整个技术的使用是通过它的clos、MID和现成的监控,通过在CPU上的寄存器的操作。
操作平台KeyarchOS对QAT的场景化时间上的应用,对于QAT的运用,主要用在https访问上, https访问在握手阶段需要签名的加解密验证,而加解密验证通常非常消耗CPU的资源。而在这种场景下,如果我们能够降低CPU资源的消耗,就能够释放更多的CPU的计算资源,去提高我们服务器的处理能力。也就是说,可以帮助我们提高服务器的网络性能。
五、KeyarchOS基于QAT的场景化实践
整体QAT技术的软件架构包括4个。首先是 Nginx,是作为服务器应用比较广。另外openssl作为签名的加解密操作的提供方,QAT的引擎和QAT的驱动负责于底层的硬件进行交互。对openssl需要1.1以上的版本,因为在这个版本以上,openssl新增了异步调用的特性,同时还支持引擎特性,QAT设备在用户层面是作为一个第三方的插件提供给用户的,通过openssl去调用这个第三方插件来支持对底层QAT家族的调用,Nginx的英特尔官方提供打了异步补丁,它可以支持openssl的异步模式。
总体来说QAT引擎作为整个QAT技术最核心的部分,成了一个承上启下作用,向上会提供一个API来供用户调用,向下通过驱动程序,QAT driver与底层的中间计算资源来互动。
具体的加速流程会看的比较复杂,在网络握手阶段,主任务在发起握手后,openssl通过异步工作模式,将整个任务分开来。将握手任务,执行签名的时候卸载到QAT的硬件设备上,同时再通过调用自己的内置函数,将工作切切换回到主任务。此时CPU的计算和签名的计算是并行的,比如说CPU资源会交给其他的计算任务,而签名的任务会交给QAT来计算。当底层的QAT完成签名的计算后,它会主动的去通知主任务。这时主任务会切换到之前的暂停状态,切换到这个握手任务中,完成握手后再次切换回主任务。
目前在QAT做了不同的性能测试,首先是单纯的对于加解密的一个测试。通过这个图上的数据,对于签名的操作,不管是签名还是验证,它的性能提升都很高。同时对于CPU资源的占用也降低了有51%。这是在性能提升的情况下,它对于资源的利用还降低了。而在网络请求方面,目前的测试根据我们不同的并发访问量的测试,网络请求的提升幅度至少是三倍。
然后Nginx是可以作为一个多进程的服务器来进行配置。我们测试了在不同进程下使用QAT前后对它的加速效果。可以看到这个提升的幅度都可以说是比较大的,至少也是在三四倍以上,然后同时对于CPU资源的利用率随着进程的数量增加,而在降低到越来越多。
我们为了验证QAT的最高的加速,能提升多少的网络请求量。目前对于单个的QAT设备在高并发的情况下,我们的网络请求连接数能达到15.2倍。
介绍完QAT的应用,下面介绍我们在基于RDT技术的长期化实践。前面讲到RDT技术主要是用于资源的调配和监控,在K8S的场景上,K8S上面有部署的很多种容器,作为虚拟化场景,不同容器间对于系统的资源占用肯定是不同的,我们要保证核心业务容器,比如以数据库为核心业务,要保证资源整体的技术方案是通过CRI-RM加上RDT技术来进行实现的,通过对容器last level cach和内存带宽的控制,实现对于数据库核心业务的保护,CRI-RM是英特尔开源的一个容器,运行时的代理组件,主要是通过自己的策略算法去调用RDT技术,然后通过RDT来决定如何将资源的分配给分配到不同的容器中。
六、KeyarchOS基于RDT的场景化实践
目前我们的测试方法是以redis,这个比较常用的数据库来作为我们的核心业务,同时通过Ycsb个压力测试软件去调用数据库服务,来进行压测和做干扰,然后分别验证在开启RDT和不开启的情况下,我们redis的性能到底是有何变化?
图中的蓝色柱状体是在不开启干扰,也不开启任何保护措施情况下redis的图集性能。下面的数字分别代表的服务数量,橘色的柱状体是代表在干扰的情况下redis的性能到底有多少。从图中看到,在存在干扰情况下,它的性能下降,会随着这个数量增长而降低。而在开启RDT这个保护措施后,基本的保护就是redis的性能,相比之前下降20%多,现在只下降了不到5%,在RDT这个技术上,可以保护我们的核心业务能力,不受更多的其他业务对它的影响。