CN110598467A - 一种内存数据块完整性检验方法 - Google Patents

Abstract

本发明公开了一种内存数据块完整性检验方法，其步骤包括：1)对于收到客户端的一数据块验证请求，当Alluxio系统管理的空间没有所请求的数据块时，客户端将从UFS读取相应的数据块，并计算该数据块的Hash值，然后进行步骤2)；如果Alluxio系统管理的空间有所请求的数据块，则进行步骤3)；2)客户端将该数据块的Hash值传输至Alluxio系统的主节点进行存储；3)客户端对所读取到的数据块进行Hash值计算，然后与主节点通信确认所读取的数据块与真实数据块的一致性，如果不一致，则判定该数据块的完整性遭到破坏。本发明能够有效防护安全威胁，并且本发明在考虑安全的同时，兼顾了对性能的要求。

Description

一种内存数据块完整性检验方法

技术领域

本发明属于主流的大数据内存存储系统Alluxio，涉及Alluxio平台中关于数据完整性的安全问题，针对这种内存数据块完整性破坏的安全威胁设计了一种内存数据块完整性检验方法。

背景技术

近几年来，大数据技术的发展深深地影响和改变着人类社会。由各行各业产生的庞大的数据，成为了一种新的资源，蕴含着巨大的社会价值和商业价值。高效并安全地存储、管理、处理这些海量数据是大数据技术的关键问题。

随着技术的发展，计算与存储分离的架构成为主流，例如在计算层使用Spark，Flink等计算框架，存储层使用HDFS或者S3为代表的大数据存储系统。但是，受限于硬盘读写速度、网络传输时延等因素，传统的基于磁盘的大数据存储系统的读写速度和上层的计算处理速度不匹配，使得计算端的延迟增大；同时，生产环境使用不同的底层存储系统会造成了上层应用访问数据不方便；此外，不同的计算框架、不同的作业之间不支持数据共享，只能通过读写速度较慢的底层文件系统，使得读写效率低下。类似的这些问题使得大数据生态的面临着挑战。以Alluxio为代表的大数据内存文件系统的出现，优雅地解决了上述问题。这类系统不仅提供了内存级别的I/O速度和统一的数据访问接口，同时解决了大数据处理过程中的诸多问题，例如运行过程中由于应用崩溃或者机器宕机等引起的缓存数据丢失，不同应用间共享数据较慢，以及随着应用运行时间增长带来的垃圾回收过慢等问题。

本发明从安全的角度出发，针对Alluxio系统中缓存机制、数据短路读写机制和一致性检查机制存在的安全脆弱点，设计了实现了一种针对内存数据完整性的攻击，分析评估了这种攻击对集群的影响。该安全脆弱点如果被敌手利用，会对集群的安全造成严重的影响。

数据短路读写机制

数据短路读写来自于数据本地化特性的设计思想，当数据和应用位于相同的节点时，如果仍然采用建立网络连接进行数据读写，对于网络资源是一种不必要的浪费，同时也影响读写效率。于是，Alluxio Worker将数据块及该路径上的权限开放给应用，当应用需要读写数据时，通过RPC调用从Master端获取了数据块的元信息之后，Client判断数据块位于本地节点后，就能获得数据块的绝对路径，随后就可以直接使用绝对路径对数据块直接进行读写，从而避免通过TCP套接字来进行数据传输，改善了系统性能。数据短路读取是Alluxio中读取数据的最佳方式。官方的文档推荐用户尽量使用数据短路读写来提高数据访问速度。

Alluxio为了提高数据读写效率，当所访问的数据块在计算任务所在节点，可以通过数据短路读写机制直接读取内存映射的数据块，避免建立网络连接传输数据。在操作系统层面，计算任务进程和Alluxio进程的所属用户可能不同，所以内存数据块的访问权限为777。

一致性检查机制

Alluxio的一致性检查主要关注元数据层面。因为Alluxio可以挂载多个底层文件系统，元数据信息变更频繁，Alluxio需要维护与底层文件系统的一致性。Alluxio的FileSystemMaster组件提供了一致性检查机制。它的检查机制规则有如下几点：

(1)如果没有底层文件系统备份，则认为永远是一致性(因为无需维护与底层文件系统的一致)。

(2)一个没有遮盖底层存储中的对象的非持久化路径被认为是一致的。

(3)一个持久化的路径如果在底层文件系统相对应的路径有一个映射对象，并且Alluxio中的元数据信息和底层文件系统相对应的对象等价，则认为该路径是一致的。

Alluxio的一致性检查机制设计较为简单，目前的版本没有对数据块的内容做一致性检查，而是仅仅检查对元数据进行一致性检查，并且，目前也仅仅检查了数据块长度这一个元数据项的一致性。只要保持数据块长度不变，该数据块就可以通过一致性检查，其中的根本原因在被修改的数据块的文件长度与Alluxio系统中记录的元数据是一致的，所以系统仍然认为该数据块正常的。

缓存机制

Alluxio的缓存可以通过主动缓存和被动缓存来实现。主动缓存适用于有规律的计算需求，应用的执行者通过加载数据(load)，将计算所需的数据提前从底层文件系统加载至Alluxio内存，避免应用的冷读取，从而大大加快数据访问效率，提高上层计算的性能。被动缓存是指应用在某一个节点运行之后，会根据读类型(Read-type)和被动缓存选项(passive-cache)来决定是否将数据缓存在该节点内存，此时的数据来源可能有三种情况，来自底层文件系统、远程节点和本地非内存介质。如果读类型的配置不是NO_CACHE，passive-cache默认打开，则对于来自底层文件系统的数据，Alluxio会缓存一份全新的数据在Worker中，(默认为本节点，如果开启确定性哈希配置，会确定性地缓存到相应节点)。对于来自本地其他介质的数据，Alluxio会将其移动至内存层。对于来自Alluxio集群内远程节点的数据，将会生成一份副本缓存至本地节点内存。

针对数据完整性的安全威胁——目标文件篡改

本发明结合Alluxio的三种工作机制，即缓存机制、数据短路读写机制和一致性检查机制，可以实施目标文件篡改。首先，因为数据短路读写机制的需要，Alluxio的数据块权限被设置过大，虽然Alluxio文件接口没有提供文件修改接口，但是由于权限的问题，敌手可以绕过上层检查，直接在操作系统层对数据块进行修改。因为Alluxio的一致性检查机制设计较为简单，被修改的数据块只要保持长度不变，就可以通过一致性检查，被系统认为是正常的数据块。当上层计算任务需要读取某一个数据块时，它可以选择这一个数据块的任意一个副本。只要被选中的数据块副本长度保持不变，即使其内容已经遭到篡改，上层应用仍然会正常地读取，并且在Alluxio层不会有任何异常。所以敌手可能利用这种安全脆弱点来恶意篡改文件，使得计算任务的分析结果出现错误。

在该威胁中，本发明假设大数据集群内的用户并非全部可靠，如果某一个恶意用户的应用在某一个受害节点上执行，它就可以实施目标文件篡改攻击。

敌手实施目标文件篡改的攻击可以分为三个步骤：

步骤1如果目标文件不在受害节点，则敌手通过应用读取目标文件。通过缓存机制，受害节点的Worker进程将缓存目标文件于本节点内存。

步骤2敌手直接从操作系统的内存映射路径中修改目标文件数据块的内容，因为数据块的访问控制权限缺失，敌手可以很轻易地完成数据块的内容修改。

步骤3敌手保持修改前后的数据块长度不变。因为Alluxio没有坚持数据块内容的完整性，所以只要目标数据块的长度保持不变，就可以通过一致性检查。被篡改后的数据块依旧被系统当做是正确的数据块，仍然可以正常地读取。攻击示意图如图1所示。

目标文件篡改攻击在许多应用场景下会产生严重的问题，轻则使上层计算任务出现业务异常，停止工作，重则导致计算的结果出错，进而导致决策错误等。例如在商业分析业务中，分析的结果将被用于协助商业决策，敌手可以通过构造错误的数据，使得计算的结果出错，进而导致错误的商业决策。在机器学习领域，模型的好坏依赖于良好的训练样本，如果训练的数据被篡改了，那训练出来的模型效果一定不好，模型的准确率一定会大大降低。

实验结果。通过对比词频分析的结果，可以发现目标文件篡改可以使得分析在语义上出现完全不同的结果，如表1所示。在手写体数字识别中，对训练样本的数据块进行篡改，会让识别的准确率大大降低，并且随着错误副本被读取概率的提升，准确率会明显下降，如表2～5。其中表2表示在正常情况下(数据没有遭到篡改)，利用Spark示例代码中随机森林算法对手写体数字进行识别的整体准确率。表3表示集群中唯一的一个训练集数据块遭到篡改，模型训练后的识别整体准确率。表4表示集群中有两个相同的训练集数据块副本，其中一个数据块副本被篡改，模型训练后识别的整体准确率。表5表示集群中有三个相同训练集数据块副本，其中一个数据块副本被篡改，模型训练后识别的整体准确率。

表1为对比词频分析的结果

表2为正常情况下随机森林算法对手写体数字进行识别的整体准确率

表3为集群中唯一的一个训练集数据块遭到篡改，模型训练后的识别整体准确率

表4为两个相同的训练集数据块副本中一个被篡改，模型训练后识别的整体准确率

表5为三个相同的训练集数据块副本中一个被篡改，模型训练后识别的整体准确率

发明内容

有鉴于此，本发明所要解决的技术问题是针对这种内存数据块完整性破坏的安全威胁，设计实现一种内存数据块完整性检验方法，同时尽可能减小对性能的影响。

本发明针对上述的安全威胁提出防护方案，并基于开源Alluxio v1.7.1版本源码，设计实现了一种数据完整性检验方案。相应的防护方案均提供了配置选项可供用户进行选择。

本发明的技术方案为：

一种内存数据块完整性检验方法，其步骤包括：

1)对于收到客户端的一数据块验证请求，当Alluxio系统管理的空间没有所请求的数据块时，客户端将从UFS读取相应的数据块，并计算该数据块的Hash值，然后进行步骤2)；如果Alluxio系统管理的空间有所请求的数据块，则进行步骤3)；

2)客户端将该数据块的Hash值传输至Alluxio系统的主节点进行存储；

3)客户端对所读取到的数据块进行Hash值计算，然后与Alluxio系统的主节点通信确认所读取的数据块与真实数据块的一致性，如果不一致，则判定该数据块的完整性遭到破坏。

进一步的，在客户端与主节点之间增加一通信服务blockChecksumStore，客户端通过该通信服务blockChecksumStore将该数据块的Hash值传输至Alluxio系统的主节点进行存储。

进一步的，主节点存储Hash值的存储结构为Java中的CurrentHashMap。

进一步的，客户端与主节点之间增加一通信服务blockConsistencyCheck，客户端通过通信服务blockConsistencyCheck与主节点确认所读取的数据块与真实数据块的一致性。

进一步的，Alluxio系统提供异步和同步两种完整性检验方案，并通过配置参数提供给客户端进行选择。

进一步的，计算Hash值的算法为MD5、SHA-1或SHA-256。

内存数据块完整性检验方案。由于原有Alluxio系统对于内存数据块缺乏内容完整性检验，以及数据短路读写机制带来的权限缺失，使得该脆弱点容易被敌手利用进行目标文件篡改攻击。为此，本发明提出了内存数据块完整性检验方案，该方案不仅能抵御以普通用户身份的敌手攻击，也可以抵御获取Worker权限的敌手攻击。同时，该方案根据安全需要分别有同步与异步的两种方式。

方案的流程图如图2所示。具体的，第一步，Alluxio的客户端发起数据读取请求，当Alluxio管理的空间没有所请求的数据块时，Client将从底层文件系统(Under FileSystem)读取相应的数据块，本发明认为从底层存储系统读取的数据可信，所读取的数据块是没有经过篡改的，对该数据块的内容进行Hash值计算，具体的Hash算法是可选的，例如有MD5，SHA-1，SHA-256。第二步，Client将计算得到的数据块Hash传输至Master节点进行存储，该过程通过一个新增的Client和Master之间的服务blockChecksumStore进行通信，该服务使用的Hash算法是可选的，能够很方便地进行不同算法之间替换。传统的完整性检验方法均是针对以硬盘等持久化为介质，通常是将数据块的摘要计算结果以一个新的文件存放在和数据文件相同路径。本发明使用的数据跨内存完整性检验是针对内存存储介质的，传统的方式会有两个弊端，一是会增加存储开销，每一个数据块副本都必须增加一个摘要计算的附加文件，对于有限的内存资源来说无疑增加了存储开销。二是存储数据块的节点为普通的工作节点，其安全性往往更低，如果被攻击，则攻击者可以同时将数据块及数据块的摘要计算附加文件一起修改，使得数据块的完整性遭到破坏。于是，本发明中的blockChecksumStore服务将计算的摘要统一存放在集群的中心节点的内存(可定期持久化)，中心节点往往有更高的安全性与存储能力，并且只需要存储一份摘要计算值，通过这种设计，能够达到节约存储，以及提供更好的安全性(与集群的中心节点有相同的安全性)。第三步，Alluxio内有相应数据块后，Client对该数据块的读取一定不是通过UFS，数据来源一定是LOCAL或者REMOTE，此时，对所读取到的数据块进行Hash值计算。第四步，与Master通信确认所读取的数据块与真实数据块是一致的，该部分通过blockConsistencyCheck服务进行，如果发现不一致，则表示该数据块的完整性遭到破坏，blockConsistencyCheck服务通过对比数据块的摘要值是否一致来判断数据块的完整性，因为正确的数据块摘要计算值已经存储在中心节点的内存，存储结构为Java中的CurrentHashMap，所以摘要的比对时间复杂度只有O(1),开销较小。

由于计算Hash值需要一定的性能开销，考虑性能和安全的权衡，本发明提供异步和同步两种完整性检验方案，并通过配置参数提供给用户进行选择。

对文件安全性要求较高的用户可以采用同步方案，同步方案能阻止错误数据对于业务的入侵，这对于非幂等的业务十分重要。对于文件安全性有一定要求同时对性能要求也比较高的用户可以采用异步检验的方式，被精心篡改的数据会被作为上层应用作为输入数据使用，但是系统会对被篡改的数据块进行错误日志记录,通过日志警报通知用户和管理员，由于错误已经发生，这种方案归属于事后审计。

本部分需要定义两个客户端与服务端的通信服务,同样，本发明使用Thrift框架进行开发，两个新增服务的接口定义在block_master.thrift文件中，约定了RPC调用的接口字段，客户端在读取数据块时和主节点(Master)端的交互关系如图3所示。

本发明的有益效果

本发明设计实现的内存数据块完整性检验方法能够有效防护上述的安全威胁，并且本发明在考虑安全的同时，兼顾了对性能的要求。

在该方案中，本发明提供了同步和异步两种完整性检验方案，给予用户更加自主的选择，用户可以根据自身应用的安全与性能需求使用不同的方案。

附图说明

图1为目标文件篡改的攻击示意图，

(a)表示攻击前集群状态，(b)表示攻击后集群状态；

图2为数据块内容完整性检验方案的流程图；

图3为数据块内容完整性检验方案的类调用关系图；

图4为数据块内容完整性检验方案的性能对比图。

具体实施方式

本发明不仅对Alluxio平台的安全性进行了提高，同时对于性能的影响很小。

本部分实验的集群包含11个节点，其中一个主节点Master，10个从节点Worker，其中Worker1到Worker5部署在同一机架，Worker6到Worker10部署在同一机架，每一个节点安装64位Ubuntu 16.04操作系统，物理配置Inter Core i7处理器，主频3.4GHz，8GB的物理内存核256GB的硬盘存储。Spark版本为2.2.0作为上层计算框架，HDFS作为底层文件系统版本为2.8.1，JDK为Oracle-JDK8u121。实验集群处于同一个局域网环境。分别在集群上部署原生Alluxio系统和SE-Alluxio作为实验对比。每一个Alluxio Worker配置2GB内存存储，10GB硬盘存储。原生Alluxio的版本为1.7.1。

内存数据块完整性检验。本发明对比评测Alluxio系统、SE-Alluxio系统以及HDFS系统的性能。其中，SE-Alluxio系统分别测试了同步和异步两种方案，本发明分别选取大小为0.5GB、1GB、1.5GB和2GB文件作为输入数据，重复10次实验选取平均值。实验的结果如附图4所示。可以看出，无论是原生的Alluxio系统还是SE-Alluxio系统，均比HDFS的性能高非常多，其中，原生的Alluxio系统比HDFS的性能快上10倍到12倍以上，说明了Alluxio系统对于大数据集群的性能提升起了非常大的效果。对比SE-Alluxio与Alluxio，可以发现SE-Alluxio系统的异步完整性检验方案对于性能的损耗非常小，对于输入数据为1GB大小，性能损耗仅1.4％，从不同大小输入数据的结果来看，整体的性能损耗非常小。从0.5GB数据的读取时间可以看出，异步完整性检验方案仅仅比原生Alluxio多出0.14s。对于同步完整性检验方案，由于IO必须等待完整性检验，期间包含了复杂的Hash计算以及网络通信，需要耗费较多的时间。从整体的结果来看，同步完整性检验方案相比原生Alluxio系统(不做完整性检验)，性能下降了2到3倍，这是由于同步方案所带来的不可避免的延迟。不过，相比于HDFS的性能，同步SE-Alluxio还是比HDFS的性能高出4到5倍。

本发明不仅局限于上述具体实施方式，本领域一般技术人员根据本发明公开的内容，可以采用其它多种具体实施方式实施本发明，因此，凡是采用本发明的设计结构和思路，做一些简单的变化或更改的设计，都属于本发明的保护范围。

Claims (6)

1.一种内存数据块完整性检验方法，其步骤包括：

1)对于收到客户端的一数据块验证请求，当Alluxio系统管理的空间没有所请求的数据块时，客户端将从UFS读取相应的数据块，并计算该数据块的Hash值，然后进行步骤2)；如果Alluxio系统管理的空间有所请求的数据块，则进行步骤3)；

2)客户端将该数据块的Hash值传输至Alluxio系统的主节点进行存储；

3)客户端对所读取到的数据块进行Hash值计算，然后与Alluxio系统的主节点通信确认所读取的数据块与真实数据块的一致性，如果不一致，则判定该数据块的完整性遭到破坏。

2.如权利要求1所述的方法，其特征在于，在客户端与主节点之间增加一通信服务blockChecksumStore，客户端通过该通信服务blockChecksumStore将该数据块的Hash值传输至Alluxio系统的主节点进行存储。

3.如权利要求1或2所述的方法，其特征在于，主节点存储Hash值的存储结构为Java中的CurrentHashMap。

4.如权利要求1或2所述的方法，其特征在于，客户端与主节点之间增加一通信服务blockConsistencyCheck，客户端通过通信服务blockConsistencyCheck与主节点确认所读取的数据块与真实数据块的一致性。

5.如权利要求1所述的方法，其特征在于，Alluxio系统提供异步和同步两种完整性检验方案，并通过配置参数提供给客户端进行选择。

6.如权利要求1所述的方法，其特征在于，计算Hash值的算法为MD5、SHA-1或SHA-256。