基于Hadoop的云計(jì)算數(shù)據(jù)主動(dòng)銷毀研究

楊 榆， 雷 敏， 周椿入， 呂瀚森， 何佳羲

(1.北京郵電大學(xué)信息安全中心，北京100876;2.災(zāi)備技術(shù)國(guó)家工程實(shí)驗(yàn)室，北京100876)

0 引言

隨著云計(jì)算飛速發(fā)展，云安全成為當(dāng)前云計(jì)算研究的重點(diǎn)方向。用戶將個(gè)人的隱私數(shù)據(jù)存放到云存儲(chǔ)集群中，用戶雖然能夠在本地對(duì)遠(yuǎn)程云服務(wù)器上的數(shù)據(jù)進(jìn)行增刪改查的操作，但卻不能像本地存儲(chǔ)一樣擁有對(duì)數(shù)據(jù)的完全控制權(quán)限。當(dāng)用戶刪除云端數(shù)據(jù)后，并不能徹底刪除用戶數(shù)據(jù)，導(dǎo)致用戶數(shù)據(jù)殘留。如果用戶的數(shù)據(jù)涉及用戶隱私或機(jī)密，殘留數(shù)據(jù)留在云端服務(wù)器的介質(zhì)中，一旦用戶的殘留數(shù)據(jù)被惡意恢復(fù)利用，將損害用戶利益甚至造成更加重大的危害［1］。

針對(duì)云存儲(chǔ)服務(wù)器端用戶數(shù)據(jù)刪除后的數(shù)據(jù)殘留問(wèn)題，提出通過(guò)修改Hadoop源碼中的Block刪除行為，即在Block刪除之前先進(jìn)行數(shù)據(jù)覆寫，達(dá)到銷毀數(shù)據(jù)殘留目的主動(dòng)銷毀機(jī)制(Active Data Deletion，ADD)。經(jīng)過(guò)仿真驗(yàn)證，修改后的Hadoop系統(tǒng)可以有效地覆寫B(tài)lock文件，達(dá)到徹底銷毀原始數(shù)據(jù)的目標(biāo)。同時(shí)針對(duì)不同的安全需求采用不同復(fù)雜度的覆寫算法，并測(cè)試不同復(fù)雜度的覆寫算法的性能。

1 HDFS數(shù)據(jù)殘留問(wèn)題分析

Hadoop是目前使用最為廣泛的云計(jì)算系統(tǒng)，大部分商用云計(jì)算系統(tǒng)都是基于Hadoop的二次開發(fā)。Hadoop分布式文件系統(tǒng)HDFS(Hadoop Distributed File System)作為Hadoop的核心模塊，為系統(tǒng)所有業(yè)務(wù)提供分布式存儲(chǔ)服務(wù)。設(shè)計(jì)目的是提供一個(gè)高容錯(cuò)，且能部署在廉價(jià)硬件上的分布式系統(tǒng);同時(shí)，能支持高吞吐量，適合大規(guī)模數(shù)據(jù)集應(yīng)用［2］。

Hadoop基于Linux系統(tǒng)搭建，一般由一個(gè)主節(jié)點(diǎn)和若干個(gè)從節(jié)點(diǎn)組成。HDFS主要由Name Node(名字節(jié)點(diǎn))和DataNode(數(shù)據(jù)節(jié)點(diǎn))組成，文件存儲(chǔ)時(shí)，Name Node將其分成若干個(gè)數(shù)據(jù)塊Block作為本地文件存儲(chǔ)在不同的DataNode上。當(dāng)文件刪除時(shí)，DataNode刪除操作調(diào)用Java的File類對(duì)象的f.delete方法刪除。因此HDFS的文件刪除機(jī)制和普通本地Linux操作系統(tǒng)下的文件刪除機(jī)制相同，并不會(huì)在對(duì)數(shù)據(jù)執(zhí)行刪除操作之前對(duì)數(shù)據(jù)塊文件進(jìn)行任何覆寫或內(nèi)容銷毀處理［3］。在Linux文件系統(tǒng)中，文件刪除操作不會(huì)徹底銷毀已刪除數(shù)據(jù)，在新的內(nèi)容寫入磁盤之前，殘留的數(shù)據(jù)內(nèi)容還將繼續(xù)存儲(chǔ)在磁盤中。所以，HDFS中的數(shù)據(jù)并沒有被實(shí)際銷毀。在云系統(tǒng)的環(huán)境下，數(shù)據(jù)的所有權(quán)和控制權(quán)分離，用戶不能完全掌控自己存儲(chǔ)在云端的數(shù)據(jù)。只要利用數(shù)據(jù)恢復(fù)技術(shù)，惡意的用戶或云服務(wù)提供商都可能恢復(fù)普通用戶已經(jīng)刪除的數(shù)據(jù)，存在很大的安全隱患。

搭建一個(gè)仿真Hadoop平臺(tái)，采用遠(yuǎn)程登錄方式訪問(wèn)Hadoop云計(jì)算系統(tǒng)，上傳圖片和文本文件，隨后對(duì)上傳的圖片和文本文件進(jìn)行刪除。利用二進(jìn)制工具Hexedit可查看到相關(guān)block文件在磁盤中并未被徹底刪除，并且可以恢復(fù)。通過(guò)仿真實(shí)驗(yàn)驗(yàn)證Hadoop分布式文件系統(tǒng)HDFS確實(shí)存在數(shù)據(jù)殘留問(wèn)題，而Hadoop系統(tǒng)對(duì)此并未采取任何防范措施。

2 主動(dòng)銷毀方案設(shè)計(jì)

要完成數(shù)據(jù)主動(dòng)銷毀的目標(biāo)，結(jié)合數(shù)據(jù)覆寫算法，可選的方案有兩種。第一種方案是監(jiān)控文件索引表，在文件刪除后對(duì)相應(yīng)磁盤位置進(jìn)行數(shù)據(jù)覆寫;第二種方案是在文件刪除之前先進(jìn)行覆寫，銷毀數(shù)據(jù)之后再進(jìn)行刪除。

對(duì)于第一種方案，通過(guò)對(duì)磁盤操作的研究和分析，在文件刪除后覆寫磁盤對(duì)應(yīng)位置是可行的，但是要區(qū)分正常刪除的文件和需要覆寫刪除的文件非常困難。在云計(jì)算系統(tǒng)中，除用戶上傳下載的文件以Block的形式存儲(chǔ)之外，還有諸多系統(tǒng)文件和其他應(yīng)該受到保護(hù)的文件，如果監(jiān)控文件索引表，對(duì)所有刪除文件都進(jìn)行覆寫銷毀，此方法不可行。

對(duì)于第二種方案，在文件刪除之前先進(jìn)行覆寫，只需要找到所有Block的存儲(chǔ)位置即可，通過(guò)分析和修改Hadoop源碼可以找到所有Block的存儲(chǔ)位置;另一方面，因?yàn)橹粚?duì)Block文件進(jìn)行覆寫，并且由Hadoop自主完成而非節(jié)點(diǎn)主機(jī)上的其他程序完成覆寫，這就避免方案一中可能出現(xiàn)的文件區(qū)分的問(wèn)題。

經(jīng)過(guò)方案比較后，采取方案二作為主動(dòng)銷毀方案的切入點(diǎn)，從用戶客戶端和云服務(wù)器端兩方面分析與考慮，提出主動(dòng)銷毀的方案，下面對(duì)這兩種方案進(jìn)行分析。

2．1 用戶客戶端主動(dòng)銷毀

由于用戶在客戶端無(wú)法獲取文件在HDFS上的具體存儲(chǔ)情況，所以不能像處理本地文件一樣操作HDFS中的文件，需要通過(guò)Hadoop提供的API進(jìn)行文件讀寫處理。

對(duì)于文件的寫入操作，Hadoop提供create和append方法，分別表示創(chuàng)建和追加文件:create創(chuàng)建一個(gè)新的文件，并根據(jù)大小分配Block;append在原文件的基礎(chǔ)上從末尾追加數(shù)據(jù)，不可更改原文件中已有的數(shù)據(jù)。使用create創(chuàng)建與原文件同名的覆寫文件覆蓋。

在客戶端，對(duì)用戶來(lái)說(shuō)覆寫文件確實(shí)替換了原有的文件。但事實(shí)上，新添加的文件并沒有覆蓋原來(lái)的文件數(shù)據(jù)。整個(gè)過(guò)程在Hadoop中可以理解為:首先檢測(cè)到要?jiǎng)?chuàng)建的新文件與原文件同名，則先對(duì)原文件正常刪除，再創(chuàng)建新的同名文件，而原文件在磁盤中并未被替換。創(chuàng)建新文件之后，可以看到Block編號(hào)已經(jīng)增加，利用Hexedit也可查看到原磁盤位置存儲(chǔ)的數(shù)據(jù)并沒有發(fā)生改變，由此可得知，利用Hadoop所提供的API在客戶端無(wú)法達(dá)到修改文件的目的，不能完成數(shù)據(jù)的主動(dòng)銷毀。

2．2 服務(wù)器端主動(dòng)銷毀

通過(guò)實(shí)踐證明無(wú)法在客戶端完成文件主動(dòng)銷毀，則只有從服務(wù)器端入手，分析Hadoop源碼得知任何文件的操作的最終對(duì)象都是Block，文件刪除也不例外。當(dāng)DataNode接收到刪除文件的指令后，先檢查文件名驗(yàn)證是否存在，接著從Name Node獲取對(duì)應(yīng)的Block信息，包括編號(hào)，存儲(chǔ)位置等，最后調(diào)用Java的File類方法delete刪除Block文件。設(shè)計(jì)思路就是在刪除Block之前調(diào)用數(shù)據(jù)覆寫算法將文件覆寫，在破壞原有的數(shù)據(jù)后再執(zhí)行刪除操作，就可以完成數(shù)據(jù)的主動(dòng)銷毀，從而保護(hù)數(shù)據(jù)安全。

基于以上分析，提出的ADD數(shù)據(jù)主動(dòng)銷毀策略，具體流程如圖1所示。

圖1 ADD主動(dòng)銷毀流程

當(dāng)需要?jiǎng)h除數(shù)據(jù)時(shí)，Hadoop系統(tǒng)向刪除任務(wù)函數(shù)傳遞Block參數(shù)，ADD主動(dòng)銷毀機(jī)制獲取到Block相關(guān)信息后，打開即將刪除的Block文件，調(diào)用數(shù)據(jù)覆寫算法覆寫后保存并關(guān)閉文件，然后返回到刪除任務(wù)函數(shù)，正常執(zhí)行完刪除操作，從而可以破壞原有數(shù)據(jù)，從而防止用戶存留在服務(wù)器上的數(shù)據(jù)被惡意恢復(fù)。

3 仿真測(cè)試

采用Hadoop對(duì)系統(tǒng)進(jìn)行仿真，仿真的環(huán)境為Hadoop-2.6.0版本。仿真測(cè)試的過(guò)程為:

(1)通過(guò)遠(yuǎn)程登錄訪問(wèn)Hadoop集群，上傳文件到HDFS中存儲(chǔ)。

(2)在DataNode節(jié)點(diǎn)使用二進(jìn)制工具查看磁盤，尋找相應(yīng)的Block文件信息并作記錄。

(3)用戶端遠(yuǎn)程刪除上傳的文件，再次在DataN-ode節(jié)點(diǎn)上使用二進(jìn)制工具查看磁盤，尋址到記錄的相同位置，對(duì)比前后的數(shù)據(jù)是否相同并嘗試恢復(fù)。

(4)如果相同且能夠恢復(fù)，則表示覆寫失敗，主動(dòng)銷毀并沒有實(shí)現(xiàn);如果不同則表示覆寫成功，嘗試恢復(fù)為新文件，能恢復(fù)但恢復(fù)后的文件不能有效辨認(rèn)信息或根本無(wú)法恢復(fù)，則表示主動(dòng)銷毀數(shù)據(jù)成功。

3．1 仿真步驟

仿真步驟如下:

(1)修改Hadoop源代碼，將作者編寫的主動(dòng)數(shù)據(jù)銷毀算法集成到Hadoop代碼中，利用修改并編譯后的安裝包重新搭建部署Hadoop集群。

(2)上傳測(cè)試圖片文件pngtest.png到HDFS，并檢查和記錄blk編號(hào)。

(3)在slave1節(jié)點(diǎn)使用Hexedit查看磁盤信息，尋找到 blk_1073741835，其存儲(chǔ)位置起始于 sector:26792072，結(jié)束于26792140，如圖2所示。

圖2 blk對(duì)應(yīng)磁盤位置信息

(4)執(zhí)行刪除指令，再次查看磁盤信息，除了刪除的日志信息外，無(wú)法找到之前的文件內(nèi)容信息，根據(jù)日志可以看出，覆寫算法已經(jīng)被調(diào)用，說(shuō)明覆寫成功，如圖3所示。

圖3 blk刪除日志

(5)上傳文本文件 txttest.txt，重復(fù)(1)～(4)步驟，再次驗(yàn)證覆寫成功。

3．2 仿真結(jié)果與有效性分析

通過(guò)上述仿真步驟可以看出，優(yōu)化后的Hadoop系統(tǒng)實(shí)現(xiàn)了對(duì)block文件的覆寫和刪除操作，并且檢查磁盤數(shù)據(jù)并未發(fā)現(xiàn)殘留，證明整個(gè)數(shù)據(jù)覆寫刪除機(jī)制的有效性，算法可以滿足普通用戶的隱私安全需要。

圖4為測(cè)試文本文件在未刪除之前，覆寫前后的文件內(nèi)容比較。

圖4 文件覆寫前后對(duì)比

仿真實(shí)驗(yàn)僅對(duì)數(shù)據(jù)進(jìn)行一次覆寫，對(duì)安全級(jí)別要求更高的數(shù)據(jù)，可以采用多次覆寫的方法以達(dá)到更高安全級(jí)別要求。目前比較常用的全零覆寫、DOD5220.22-M、DOD5220.22-M7等算法等都是應(yīng)用廣泛和成熟的算法。這些成熟的數(shù)據(jù)覆寫算法經(jīng)過(guò)檢驗(yàn)，可以保證數(shù)據(jù)銷毀的效果。

3．3 性能分析

為測(cè)試本算法的性能。覆寫相同大小的文本文件采取全零覆寫、隨機(jī)一次性覆寫、DOD5220.22-M和DOD5220.22-M7等4種覆寫算法進(jìn)行性能測(cè)試。實(shí)驗(yàn)環(huán)境CPU型號(hào)為Intel Core i3-4150@3.50 GHz雙核，硬盤為希捷ST1000DM003 1ER162 1TB/7200轉(zhuǎn)/分硬盤，文本文件大小為71586816 Byte約為70 MB。具體性能測(cè)試的信息如圖5所示。

圖5 覆寫算法性能分析

由圖5可以看出，全零覆寫所需時(shí)間最短，DOD5220.22-M7所需時(shí)間越長(zhǎng)，即隨著覆寫算法的復(fù)雜度增加，覆寫時(shí)間相應(yīng)增加。另一方面，數(shù)據(jù)量越大，各算法所需的時(shí)間差距也就越大。

在實(shí)際應(yīng)用環(huán)境中，不同數(shù)據(jù)塊Block分布在不同DataNode上，在對(duì)一個(gè)文件進(jìn)行覆寫銷毀時(shí)，不同DataNode對(duì)所相關(guān)的Block并行覆寫效率更高。例如一個(gè)10 GB大文件，除去備份大約有160個(gè)Block分布在不同的DataNode上，假設(shè)集群中有10個(gè)DataNode節(jié)點(diǎn)，那么每個(gè)節(jié)點(diǎn)平均有16個(gè)Block。采用全零覆寫算法覆寫銷毀這個(gè)10 GB的文件，按照10個(gè)節(jié)點(diǎn)并行覆寫，那么覆寫的時(shí)間消耗為23到24秒。上述時(shí)間是在實(shí)驗(yàn)環(huán)境下的估算，在真實(shí)的大集群環(huán)境中速度顯然會(huì)更快，而且采用其他如多線程等并行技術(shù)，還可以進(jìn)一步提高覆寫操作的性能。

4 結(jié)束語(yǔ)

云存儲(chǔ)的特點(diǎn)是存儲(chǔ)即服務(wù)，但普通用戶無(wú)法接觸和完全控制存儲(chǔ)在云端的個(gè)人數(shù)據(jù)，一旦用戶存儲(chǔ)在云端的數(shù)據(jù)刪除后被惡意恢復(fù)利用，將侵犯用戶的隱私。針對(duì)云存儲(chǔ)系統(tǒng)的數(shù)據(jù)殘留問(wèn)題，改進(jìn)原云計(jì)算系統(tǒng)的刪除行為，提出一種數(shù)據(jù)主動(dòng)銷毀的策略——ADD機(jī)制，即對(duì)云端數(shù)據(jù)塊采取“先覆寫后刪除”策略徹底刪除，并基于Hadoop的分布式文件系統(tǒng)HDFS按照此機(jī)制修改了源代碼，搭建全分布式集群測(cè)試了策略的確是有效且可行的;在此之后，對(duì)比了不同數(shù)據(jù)覆寫算法的性能，分析出在實(shí)際應(yīng)用中，文中提出的ADD機(jī)制也是有效且可行的。

［1］ 潘富斌.基于Hadoop的安全云存儲(chǔ)系統(tǒng)研究與實(shí)現(xiàn)［D］.成都:電子科技大學(xué)，2013.

［2］ Garry Turkington.張治起，譯.Hadoop基礎(chǔ)教程(Hadoop beginner＇s guide)［M］.北京:人民郵電出版社，2014.

［3］ 鄧謙.基于Hadoop的云計(jì)算安全機(jī)制研究［D］.南京:南京郵電大學(xué)，2013.

［4］ 李寧，王東亮等.Hadoop云計(jì)算一體機(jī)實(shí)踐指南［M］.北京:機(jī)械工業(yè)出版社，2013.

［5］ 馬媛.基于Hadoop的云計(jì)算平臺(tái)安全機(jī)制研究［J］.信息安全與通信保密，2012，(6).

［6］ 張逢吉吉，陳進(jìn)，陳海波，等.云計(jì)算中的數(shù)據(jù)隱私性保護(hù)與自我銷毀［J］.計(jì)算機(jī)研究與發(fā)展，2011.48(7):1155-1167.

［7］ 成靜靜.基于Hadoop的分布式云計(jì)算/云存儲(chǔ)方案的研究與設(shè)計(jì)［J］.數(shù)據(jù)通信，2012，(5):14-16.

［8］ Wang L，Von laszewski g，Younge a，etal.Cloud computing:a perspective study［J］.New Generation Computing，2010，28(2):137-146.

［9］ LV Chengtong，LI Qing，LEI Zhou，et al.PaaS:a revolution for information technology platforms［C］.ICENT 2010-2010 International Conference on Educational and Network Technology，2010:346-349.

［10］ LEE B S，YAN Shixing，MA Ding，et al.Aggregating IaaS service［C］.Proceedings-2011 Annual SRII Global Conference，SRII 2011，2011:335-338.