引言： 加密和密碼技術(shù)形式多樣，從一開始加密并沒有構(gòu)建到Apache Hadoop中，而是隨著時(shí)間的推移才加入并在組件中實(shí)施的。如今，加密技術(shù)已經(jīng)成為一種保護(hù)金融機(jī)構(gòu)、電信公司、醫(yī)療機(jī)構(gòu)、政府機(jī)構(gòu)的大數(shù)據(jù)的常用方法。

密碼技術(shù)形式多樣，在很早的時(shí)候甚至在計(jì)算機(jī)發(fā)明之前就已出現(xiàn)。即便如此，從一開始加密技術(shù)并沒有構(gòu)建到Apache Hadoop中，而是隨著時(shí)間的推移才加入并在組件中實(shí)施的。如今加密技術(shù)已經(jīng)成為一種保護(hù)金融機(jī)構(gòu)、電信公司、醫(yī)療機(jī)構(gòu)、政府機(jī)構(gòu)大數(shù)據(jù)的常用方法。

Hadoop分布式文件系統(tǒng)加密

Hadoop分布式文件系統(tǒng)加密支持通過一種稱為加密區(qū)域（Each Encryption）的機(jī)制來支持本地的數(shù)據(jù)加密。一個(gè)加密區(qū)域從基本說就是一個(gè)與加密密鑰有關(guān)聯(lián)的Hadoop分布式文件系統(tǒng)加密目錄。一旦目錄與加密密鑰有了關(guān)聯(lián)，此目錄及其子目錄中的所有文件都會(huì)被自動(dòng)加密。

在使用Hadoop分布式文件系統(tǒng)加密時(shí)，并非Hadoop分布式文件系統(tǒng)加密中的所有數(shù)據(jù)都需要加密，可對(duì)非敏感數(shù)據(jù)以明文存放和處理，而對(duì)敏感數(shù)據(jù)進(jìn)行加密。Hadoop用戶可以用其自己的加密區(qū)域來保護(hù)來自其他用戶的數(shù)據(jù)。

關(guān)于Hadoop分布式文件系統(tǒng)加密的一個(gè)常見的錯(cuò)誤觀念是：在數(shù)據(jù)被寫到數(shù)據(jù)節(jié)點(diǎn)上的磁盤上時(shí)才被加密。事實(shí)上，在數(shù)據(jù)被發(fā)送到數(shù)據(jù)節(jié)點(diǎn)之前就被加密了。由此，數(shù)據(jù)在傳送過程中也受到了保護(hù)，而且這種架構(gòu)還可以防止在存放數(shù)據(jù)的數(shù)據(jù)節(jié)點(diǎn)上泄露密鑰。

用于加密Hadoop分布式文件系統(tǒng)加密數(shù)據(jù)的加密算法是行業(yè)中普遍認(rèn)可的AES。默認(rèn)的是AES-128，但是對(duì)于已經(jīng)普遍實(shí)施了更強(qiáng)健的AES-256的企業(yè)來說，此算法還是可以配置的。加密區(qū)域中的每個(gè)文件都被分配了一個(gè)隨機(jī)生成的密鑰。這是一種很不錯(cuò)的做法，因?yàn)橐坏┮粋€(gè)密鑰被破壞，其后果將只影響到單個(gè)文件。

但是對(duì)于Hadoop分布式文件系統(tǒng)加密的話，筆者要提出一些警告：

首先，人們無法在一個(gè)非空的目錄上創(chuàng)建加密區(qū)域。換言之，如果期望對(duì)一個(gè)已有的包含數(shù)據(jù)的目錄建立加密區(qū)域進(jìn)行加密是無法實(shí)現(xiàn)的。其工作方式不允許這樣做。此時(shí)需要一個(gè)空目錄才能創(chuàng)建加密區(qū)域。在此空目錄中可以使用Distcp命令從當(dāng)前目錄將所有數(shù)據(jù)復(fù)制到新建立的空的加密目錄中，然后再刪除舊的文件。

其次，無法使整個(gè)“/”根目錄成為一個(gè)加密區(qū)域。

第三，嵌套加密的區(qū)域目錄并未得到支持，但已準(zhǔn)備列入計(jì)劃。用戶可能希望將整個(gè)目錄或用戶目錄作為一個(gè)加密區(qū)域，并允許用戶創(chuàng)建自己的嵌套加密區(qū)域，但目前此想法并未得到支持。

第四，測(cè)試應(yīng)用程序。在很多情況下，由于用戶對(duì)加密密鑰的許可會(huì)造成應(yīng)用程序崩潰，而對(duì)于文件從加密區(qū)域中的移動(dòng)和復(fù)制也存在一些限制。

Hadoop密鑰管理服務(wù)器（KMS）

加密的關(guān)鍵是加密密鑰的管理。每個(gè)加密區(qū)域都有其自己唯一的密鑰和相關(guān)的使用此密鑰的用戶許可。每個(gè)獨(dú)立的文件都有其自己唯一的隨機(jī)生成的密鑰。那么，如何存儲(chǔ)、管理、保護(hù)這些密鑰，正是Hadoop 密鑰管理服務(wù)器展示拳腳所在。Apache Hadoop 密鑰管理服務(wù)器是一個(gè)“三面玲瓏”的密鑰管理服務(wù)：為加密區(qū)域生成和存儲(chǔ)密鑰；生成、加密、解密文件的密鑰；保護(hù)和管理訪問這些密鑰的許可。

密鑰管理服務(wù)器是一種獨(dú)立于Hadoop集群而運(yùn)行的服務(wù)，它是由信息案例團(tuán)隊(duì)管理，而非Hadoop管理員。非常重要的一點(diǎn)是，在涉及到管理訪問這些加密密鑰的許可時(shí)，創(chuàng)建責(zé)任分離是很重要的。Hadoop管理員可以訪問Hadoop分布式文件系統(tǒng)加密用戶和所有的數(shù)據(jù)，但不能訪問密鑰。

對(duì)密鑰的訪問許可在密鑰管理服務(wù)器中被定義為訪問控制列表（ACL）。這些ACL許可定義了哪些用戶和組可以訪問加密密鑰，也稱為白名單。創(chuàng)建ACL還可以定義哪些用戶或組不能訪問密鑰，即所謂的黑名單。使用ACL，用戶們就可以阻止特權(quán)和管理員用戶（如Hadoop分布式文件系統(tǒng)加密用戶）訪問用戶數(shù)據(jù)。

密鑰管理服務(wù)器默認(rèn)情況下通過JKS（Java KeyStore）來實(shí)施。JKS將機(jī)密存放在文件中，此文件一般僅由文件系統(tǒng)的許可機(jī)制來保護(hù)。但JKS的實(shí)施有其弊端，由于安全性問題筆者不建議在生產(chǎn)系統(tǒng)中使用。用戶可以將一個(gè)口令放在JKS文件上，但是，問題是將這個(gè)口令放在服務(wù)器上文本文件的哪里呢？還有可擴(kuò)展性和可用性的問題；JKS沒有內(nèi)置的針對(duì)JKS文件的復(fù)制、冗余、備份機(jī)制。

本文中筆者僅僅涉及了靜態(tài)數(shù)據(jù)和密鑰的Hadoop分布式文件系統(tǒng)的加密，但并非所有的數(shù)據(jù)都位于Hadoop分布式文件系統(tǒng)的加密中。還有一些位于該系統(tǒng)加密范圍之外的敏感數(shù)據(jù)，也有臨時(shí)文件，還有傳輸中的數(shù)據(jù)。