2014, Vol. 31
伴随Internet快速发展，信息量呈爆炸性增长，数据存储逐渐成为企业发展的关键问题，在很多大数据存储解决方案[1]中，云存储成为存储大数据的主要方式.但数据安全问题已成为云存储面临的主要挑战[2]，根据IDC的调查显示，高达70%多的用户因担心数据的安全性拒绝使用云存储服务[3].
传统的云存储平台中，元数据由平台统一管理，云存储服务提供方(Cloud Service Providers, CSP)拥有用户数据完整的逻辑视图、物理视图及其之间的映射关系，用户隐私和数据完整性对平台暴露无遗，因此平台也成为内外部安全攻击的热点，如网络服务中断、网络安全漏洞等[4-7].其次，平台内部也会因管理方面的缺陷直接或间接威胁到用户数据的安全[8-10].针对云平台数据安全问题，许多研究人员提出了多种解决方案.Kevin D.Bowers提出一种可保障数据的完整性和可恢复性的分布式加密系统[11].Christain Cachin提出了一种基于加密工具保证数据完整性和一致性的方法[10]，Hakim Weatherspon设计了一种传统的、基于广域网的分布式存储系统，通过安全的日志接口保障数据的完整性、一致性以及持久性[11].
元数据的安全是云平台数据安全的核心，但上述提到的解决方案都是基于传统存储模型对存储和管理方法的改进，无法实现CPS透明化和用户自主化管理敏感数据.因此，本文阐述了一种敏感数据自主可控管理的云存储模型(Sensitive Information Self-Management Model，SISM)，用户通过VPN内部的元数据子服务器自主管理敏感信息，减少对CSP的依赖，而对于非敏感信息仍采用传统管理方式，并在SISM基础上提出了一种敏感信息元数据管理策略.
1 相关工作云存储由云计算延伸和发展而来，运用了分布式[12]、网格计算、进程异步通信[13]等技术.传统云存储平台是由独立元数据服务器和多个数据存储服务器构成的分布式系统[14]，如图 1所示.
|
图 1 云存储架构 Figure 1 The structure of cloud storage |
云存储中的每个大文件被分割成固定大小且有唯一标示ID的数据块[15].数据存储服务器主要功能包括根据指令读写数据、管理本地存储空间、更新数据块信息并根据安全备份策略在多台存储服务器上迁移、备份数据；同时，以周期性心跳方式向元数据服务器上传数据块信息，协助元数据服务器建立完整的文件视图及映射关系.
元数据服务器是整个文件系统中心，主要管理命名空间、访问控制信息、文件与文件块的映射关系、文件块与数据存储服务器的映射关系[15]等元数据.同时，还管理整个平台的物理存储空间、数据存储服务器间的数据迁移以及处理客户端和数据存储服务器的请求.平台客户端嵌入到应用客户程序中[13]，通过平台API接口与元数据服务器交互元数据，以数据流形式对数据存储服务器执行文件读写操作.
通过上述分析，传统云平台统一管理元数据，CPS或者第三方只要从元数据服务器得到文件元数据信息便可窃取甚至破坏用户数据，无法保证数据的安全.因此，本文提出了一种敏感数据自主可控管理的云存储元数据管理方法.将敏感信息的元数据从中心元数据服务器中分割出来由元数据子服务器自主管理，减少用户对传统平台的依赖，确保敏感信息的安全.
2 系统架构敏感数据自主可控管理云存储模型SISM如图 2所示.其核心思想是：将用户融入云平台并赋予对敏感数据逻辑视图管理权限，用户使用平台的同时也成为云平台的一部分.逻辑上Sub-MS和Sub-Client同时属于用户端和云平台，区别于图 1中的传统的云存储三级架构.SISM在企业VPN内部对敏感数据的管理机制类似于私有云，在满足平台安全防护最大化需求的同时，实现了用户对敏感数据的自主可控管理需求.对数据存储中心(Data Server, DS)的管理机制类似于公用云存储，充分利用了平台高性价比资源，节约数据存储成本.
|
图 2 SISM云存储体系架构 Figure 2 The structure of cloud storage for SISM |
为实现对敏感数据的自主管理，将敏感信息元数据以VPN范围分解，由用户所属VPN的Sub-MS对CMS透明化管理敏感信息的命名空间、文件到数据块的映射关系.而敏感信息的数据块到DS的映射关系由CMS根据DS的心跳信息实时维护和管理，Sub-MS采用按需询问同步机制将其映射关系维护到本地并服务于客户端请求，保证敏感信息元数据的稳定性、可靠性以及实时性，避免因元数据信息不同步导致读写异常甚至破坏平台数据.CMS除了维护敏感信息数据块到DS的映射关系外，还负责管理整个平台的逻辑存储空间、物理存储设备、普通文件的元数据以及维护全局统一视图.
Sub-Client端是云存储平台的入口.读写敏感数据时，Sub-Client从所属VNP内的Sub-MS读写文件元数据，否则将用户请求重定向到Core-Client，用传统云存储平台方式执行用户请求.平台的数据操作都是由Sub-Client或Core-Client直接与DS交互.
云存储需要在不同实体(进程)间通信，处理诸如消息的编解码、消息发送和接收等具体任务.在SISM元数据管理中采用了RPC机制实现敏感信息元数据的创建、更新、以及映射关系的同步.SISM系统中的RPC过程如图 3所示.
|
图 3 SISM的RPC机制 Figure 3 The RFC mechanism of SISM |
在SISM中，Sub-MS和CMS实现了多个远程方法调用，且支持多并发任务，通过Java动态代理和Java NIO技术使得Client访问Sub-MS和CMS的远程调用过程以及Sub-MS访问CMS的远程过程调用与本地过程调用类似，而服务器上被调用的代码又如同传统的本地调用.
Sub-MS是SISM系统实现敏感信息自主管理的核心，其管理内容主要包括两个方面：(1)管理敏感数据的命名空间、文件到数据块的映射关系、文件权限等，其具体操作将在3.1、3.2节分别从静态和动态的角度进行讨论；(2)确保数据块到DS的映射关系与CMS实时维护的映射关系一致，映射关系同步算法将在3.3节进行描述.
3 元数据管理元数据记录了文件属性和数据块的存储位置，实现文件系统的命名空间、权限管理[16]，最终控制对数据块的访问.
传统云存储系统由独立服务器统一维护元数据，虽然简化了系统设计和对元数据的管理，但用户无法自主管理敏感信息的元数据.SISM引入了Sub-MS实现本地化自主管理敏感信息的元数据，确保敏感信息的安全性，不仅有效降低了对CMS的依赖，还提高了文件读写效率，同时减轻了CMS的负载，避免单一的元数据服务器成为系统的性能瓶颈[17].
3.1 元数据定义元数据分为目录级元数据和文件级元数据.目录级元数据包括不同层次的命名空间和目录属性，文件级元数据包括文件属性以及文件与数据块的映射关系等.
Sub-MS在自主管理敏感信息的元数据同时，不仅需要CMS提供文件的物理存储信息协助管理敏感信息的元数据，还需对CMS透明化管理用户敏感数据.图 1中采用的元数据结构很显然无法满足元数据分离和透明化管理的要求，因此SISM结合分而治之思想，提出了不同的元数据结构.目录级元数据结构如图 4所示.
|
图 4 目录文件的元数据结构 Figure 4 The metadata's structure of directory |
文件级元数据结构除含有目录级元数据结构的信息外，还包含文件与数据块的映射关系，可采用数组方式实现.其中数据块的元数据结构主要有数据块ID、大小、访问时间以及数据块与数据节点的映射关系，如图 5所示.
|
图 5 数据块的元数据结构 Figure 5 The metadata's structure of data block |
图 5所示对象不仅包括数据块的基本属性，还保存了数据块与DS的映射关系：DS1、DS2、DS3，表示该数据块包含3个副本，分别放置在3个不同的数据服务器中，prev表示该数据块的前一个副本地址，next表示下一个副本地址.实际应用中可根据系统中不同副本数动态生成相应数量的映射关系三元组.
3.2 元数据提取Sub-MS自主管理VPN内用户敏感信息的元数据，普通元数据由CMS管理.Sub-MS的管理内容与传统元数据服务器类似，包括创建和维护敏感数据的命名空间、映射关系并支撑用户读写敏感数据操作.由于需要CMS提供敏感数据的物理存储空间信息，其创建和维护敏感信息的元数据以及对客户端的支撑过程则区别图 1中单一元数据服务器采用的方法.
因此，敏感信息的元数据提取是其他管理以及客户端读写数据的基础，并且元数据的其他管理方法均是创建过程部分镜像.同理，元数据创建逆过程便是删除操作.创建过程是从客户端所写敏感文件中提取出管理文件所需的元数据，Sub-MS提取元数据的过程如图 6所示.
|
图 6 Sub-MS提取元数据过程 Figure 6 The process of getting metadata |
文件与数据块的映射顺序使用冗余随机匹配算法，即存储一个10GB大小文件时，数据块大小以64MB为单位进行存储，CMS端则需分配160个数据块，则文件与数据块映射的关系大约有4.715×10284种不同的排列.同时，在数据块分配过程中结合冗余思想，Sub-MS端虚拟文件大小，当存储一个10GB文件时，Sub-MS端则向中心CMS申请大于10GB大小空间，多余空间用于下次文件存储，下次存储文件中采用相同方法迭代进行.因此，CMS或者第三方在未获取数据块与文件映射关系情况下无法还原用户信息，确保了用户敏感数据的安全可靠.
图 7给出了提取一个大小为5GB敏感信息文件mydata.txt的元数据的示例.
|
图 7 敏感信息元数据提取示例 Figure 7 The example to get metadata of sensitive information |
文件的元数据除了管理相关的基本信息外，更重要是体现了文件与数据块、数据块与数据存储节点间的映射关系，mydata.txt的blockList[]列表共有80项(通过每个数据块64MB进行分割)，并保存在Sub-MS中，其中每项的dataserver[]有3个数据项，表示该数据块在3个不同的数据节点存有备份，具体节点信息由DS与CMS通过心跳信息动态维护，Sub-MS采用按需同步机制将其维护在本地.
3.3 元数据同步SISM支持一个比较宽松且容易实现的敏感信息元数据一致性模型，这个模型能很好地支持高度分布式应用.SISM主要涉及到两方面元数据一致性：首先是DS和CMS之间关于数据块信息的一致性；其次是Sub-MS与CMS之间关于敏感信息的数据块到DS间映射关系的一致性.
DS与CMS的同步策略与传统云存储类似，CMS通过DS的周期性心跳信息除了实时维护数据块状态以及数据块到DS的映射关系，保持两端管理数据块的信息同步外，还监管DS的版本和注册信息，如果长时间没有收到某个DS的心跳信息，则认为该DS丢失，并重新备份该DS存储的数据.
考虑到Sub-MS与CMS之间是基于客户/服务器模型的实现，基于活动文档思想[18]提出了一种按需询问同步策略.图 8描述了Sub-MS与CMS对数据块到DS映射关系的同步策略.
|
图 8 敏感信息的元数据同步机制 Figure 8 The synchronization mechanism about metadata of sensitive information |
图 8中Sub-MS与CMS同步算法主要由Sub-MS的Synchronize()函数根据客户端的请求采用按需询问机制实现，函数定义如下：
Synchronize (filename)：
//获取文件属性
Metadata = GetMeta (filename);
//获取文件的数据块ID列表
Blocks_ID [] = GetBlocks(Metadata);
//判断是否需要同步
If (satisfy the condition of synchronization):
//通过RPC机制与CMS的同步接口，得到有更新的数据块信息
BlockInfo = IPCSynchronization (Blocks_ID);
//更新数据块到DS的映射关系
Updata (Metadata, BlockInfo);
Return Metadata.
4 原型系统实验的主要目的是为了考察SISM管理敏感信息的可用性、系统吞吐量，并验证SISM持久化用户数据的云存储服务能力.同时，将SISM和HDFS(Hadoop Distributed File System)从元数据、整体数据读写速度方面进行了对比测试.
4.1 测试环境测试环境由1台CoreMetadata服务器，1台Sub-Metadata服务器，16台数据存储服务器组成的集群，软硬件配置为：Intel Core i3-2130 @ 3.4GHz处理器，512MB内存，250G/5400 (r·min-1)硬盘，以及100Mb/s全双工以太网连接到一个百兆交换机，18台服务器都连接到一个交换机.模拟客户机连接到另一个交换机上，两个交换机用1Gb/s的线路连接.
4.2 实验测试对SISM集群分别在2.1TB，3.0TB，3.9TB 3种数据集情况下进行了元数据量的统计和数据读写速度测试，各个数据集由500MB以理的文件组成.
(1) 元数据测试
表 1列出了不同数量敏感信息文件的元数据存储情况.
|
表 1 元数据存储情况 Table 1 The Size of Metadata |
由表 1可知，在Sub-MS服务器和CMS服务器上平均每个文件的元数据在200字节以下，这与GFS的实验结论类似[12].SISM的Sub-MS和CMS的元数据总量略大于HDFS中NameNode保存的元数据量，这是由于Sub-MS为了提高数据的安全性，在管理文件与数据块映射关系时采用了冗余随机匹配算法以及部分数据块到数据节点的映射在Sub-MS和CMS都有存储.
因此，Sub-MS和CMS的内存在实际应用中不会成SISM系统容量的瓶颈，并且不同VPN用户群会有不同的元数据子服务器，一定程度上也解决了传统云存储单一服务器节点的性能问题.
(2) 读敏感数据的测试
多个客户端从SISM和HDFS文件系统并发读数据，每个客户端通过脚本随机从集群中读取4MB的内容，重复执行512次，因此每个客户机最终读取2GB的数据.在3个不同数据量环境下读速度测试结果如图 9所示.
|
图 9 不同数据集的读速度 Figure 9 The reading speed of different data sets |
图 9表明多个客户端从SISM文件系统与HDFS文件系统的读取效率.单个客户端可以达到9MB/s，而在100Mb/s网卡的饱和时的速度为12.5MB/s，即达到了饱和值的72%.在16个客户端情况下，整体的读取速度达到了86.5MB/s，是网络速度饱和值的69%，即每个客户端的读取速度为5.3MB/s，速度下降是因为多个客户端同时读取数据时读取同一个数据节点服务器的概率也随之增大，从而导致整体读取效率降低.SISM整体的读取速率比HDFS略低，其原因是在读数据开始Sub-MS需要与CMS同步元数据，导致读数据开始会存在一定延迟.
由于读数据只需要从Sub-MS查询并返回文件元数据，在此处的实现中应用了二分查找来提高效率.实验结果表明在硬件环境可以支撑的条件下不会影响读数据的速度，多个客户端在2.1TB、3.0TB、3.9TB数据集环境下体现的读速度差异很小，16个客户端总体的读速度分别为87.5MB/s、87.3MB/s、87.1MB/s.由于Sub-MS采用了按需同步和租约机制同步策略，不必频繁与CMS同步元数据，客户端在读取敏感信息元数据时直接从Sub-MS获取，不会产生较大延迟，因而读数据速度与HDFS没有太大悬殊，充分验证了设计的合理性.
(3) 写敏感数据测试
多个客户端同时向多个不同的文件中写入数据，每个客户端每次以2MB的速度连续写入1GB的数据，写数据的速度如图 10所示.
|
图 10 写数据的速度 Figure 10 The writing speed |
图 10显示了SISM的写入速度与HDFS的对比情况，由于SISM写数据过程中需要从CMS申请数据块，即两次提取元数据，单个客户端在当前的实验环境下可达5MB/s，16个客户端的总体写入速度达到了29.5MB/s，其整体写数据性能比HDFS低10%~17%.
由实验测试可知，SISM在用户自主管理敏感信息元数据，保障数据安全的情况下，集群的整体性能仍在可接纳的范围内，数据的正确读写也验证了系统的可用性.
5 结论SISM改进了传统云存储模型，满足了用户对敏感信息的自主可控管理的安全云存储需求.提取敏感信息元数据过程中采用文件与数据块的冗余随机匹配算法增强了文件存储安全性；基于心跳机制和按需询问同步策略不仅有效保障平台内部各模块元数据的一致性，还减轻了CMS的负载.但同时也存在一些不足之处，例如在Sub-MS的元数据日志备份与恢复时间较长，期间服务器会出现性能抖动，权限管理方面也还有优化的空间，这也是将来进一步研究的方向.
| [1] |
Sasidhar T, Illa P K, Kodukula S. A Generalized Cloud Storage Architecture with Backup Technology for any Cloud Storage Providers[J].
International journal of computer application, ISSN, 2012: 2250-1797.
|
| [2] |
傅颖勋, 罗圣美, 舒继武. 安全云存储系统与关键技术综述[J].
计算机研究与发展, 2013, 50(1): 136-144.
Fu Y X, Luo S M, Shu J W. Survey of secure cloud system and key Technologies[J]. Journal of Computer Research And Development, 2013, 50(1): 136-144. DOI: 10.7544/issn1000-1239.2013.20120698. |
| [3] |
Lin Z J, Lu P, Luo S M, et al. An on-demand security mechanism for cloud-based telecommunications service[J].
ZTE Communications, 2011, 9(1): 37-41.
|
| [4] |
Arrington M. Gmail disaster: reports of mass email deletions[EB/OL]. [2014-03-15]. http://www.techcrunch.com/2006/12/28/gmail-disasterreportsof-mass-email-deletions/, 2006.
|
| [5] |
Kincaid J. MediaMax/TheLinkup closes its doors[EB/OL]. [2014-03-16]. http://www.techcrunch.com/2008/07/10/mediamaxthelinkup-closesits-doors/, 2008.
|
| [6] |
Amazon. com. Amazon s3 Availability Event[EB/OL]. [2014-03-16]. http://status.aws.amazon.com/s3-20080720.html. 2008. 7.
|
| [7] |
吴基科, 凌捷. Linux系统缓冲区溢出攻击的机理分析[J].
广东工业大学学报, 2003, 20(2): 16-20.
Wu J K, Ling J. The principle of buffer overflow attack[J]. Journal of Gangdong university of Technology, 2003, 20(2): 16-20. |
| [8] |
Wang Q, Wang C, Ren K, et al. Enabling public auditability and data dynamics for storage security in cloud computing[J].
Parallel and Distributed Systems, IEEE Transactions on, 2011, 22(5): 847-859.
DOI: 10.1109/TPDS.2010.183. |
| [9] |
Ateniese G, Burns R, Curtmola R, et al. Provable Data Possession at Untrusted Stores[C]//Proc. 14th ACM Conf. Computer and Comm. Security(CCS'07). New York: ACM, 2007: 598-609.
|
| [10] |
Shah M A, Swaminathan R, Baker M. Privacy-preserving audit and extraction of digital contents[J].
IACR Cryptology ePrint Archive, 2008, 2008: 186.
|
| [11] |
Bowers K D, Juels A, Oprea A. HAIL: a high-availability and integrity layer for cloud storage[C]//Proceedings of the 16th ACM Conference on Computer and communications security. [s. l. ]: ACM, 2009: 187-198.
|
| [12] |
赵天慧, 张立臣. 一种分布式实时系统的资源管理体系结构[J].
广东工业大学学报, 2008, 25(1): 50-53.
Zhao T H, Zhang L C. A distributed real-time systems of resource management architecture[J]. Journal of Guangdong University of Technology, 2008, 25(1): 50-53. |
| [13] |
Shvachko K, Kuang H, Radia S, et al. The Hadoop Distributed File System[C]//Mass Storage Systems and Technologies (MSST), 2010 IEEE 26th Symposium on. Incline Village, NV: IEEE, 2010: 1-10.
|
| [14] |
Ghemawat S, Gobioff H, Leung S T. The Google file system[C]//ACM SIGOPS Operating Systems Review. New York: ACM, 2003, 37(5): 29-43.
|
| [15] |
易理林. HDFS文件系统中元数据的高可用性管理方法研究[D]. 广州: 华南理工大学计算机科学与工程学院, 2013.
http://cdmd.cnki.com.cn/Article/CDMD-10561-1013318315.htm
|
| [16] |
刘仲, 周兴铭. 基于目录路径的元数据管理方法[J].
软件学报, 2007, 18(2): 236-245.
Liu Z, Zhou X M. A metadata management method based on directory path[J]. Journal of Software, 2007, 18(2): 236-245. |
| [17] |
Li B, He Y, Xu K. Distributed metadata management scheme in cloud computing[C]//Pervasive Computing and Applications (ICPCA), 20116th International Conference on. Port Elizabeth: IEEE, 2011: 32-38.
|
| [18] |
Nam C K, Jang G S, Bae J H J. An XML-based active document for intelligent web applications[J].
Expert Systems with Applications, 2003, 25(2): 165-176.
DOI: 10.1016/S0957-4174(03)00044-7. |