Hadoop平臺的安全加固方案

丁祥武,張東輝

(東華大學 計算機科學與技術學院,上海 201620)

0 概述

21世紀是數據信息高速發展的時代,利用大數據平臺存儲與分析海量數據已經成為一種趨勢,開源式分布框架Hadoop作為大數據平臺的標準解決方案,被廣大企業、科研機構以及個人所認可。然而,由于在最初設計Hadoop時并未考慮安全問題,隨著其使用量的增加以及使用形式的豐富,如使用Hadoop構建云存儲、云計算平臺,相比于傳統環境,在云平臺中木馬病毒、拒絕服務、身份偽造、數據竊取、信息泄露等一系列安全問題尤為突出[1],這使得Hadoop集群上的安全漏洞日益增多,進而導致安全隱患問題日益凸顯,逐漸演變為阻礙Hadoop在云應用相關領域發展的重要因素之一[2-3]。由此,云存儲、云計算平臺的安全問題成為近年來學術界以及工業界的一個研究熱點。

目前,在最新的Hadoop 3.0.0-alpha3-SNAPSHOT版本中,使用Kerberos認證體系作為其安全機制的基礎,用于在Hadoop平臺中提供用戶認證、節點認證以及服務認證,從而解決Hadoop平臺中可能出現的冒充威脅;使用服務等級協議SLA將指定的Hadoop服務授權給特定的合法用戶,從而更加規范化、安全地管理、存儲和計算資源;使用安全套接層協議SSL提供數據傳輸加密,防止數據在網絡傳送過程中被監聽、盜取和篡改,保護瀏覽器、服務器以及節點間網絡數據傳輸的安全性和完整性;使用KMS實現Hadoop分布式文件系統(Hadoop Distribute File System,HDFS)在多租戶環境下的數據隔離能力,KMS還提供了數據以密文形式存儲到磁盤的功能,有效地防止了當節點被黑客攻擊后,后者直接從硬盤中獲取集群隱私數據的威脅;使用類Unix/Linux的權限控制機制決定Hadoop集群中文件的可訪問用戶及組,進而提供豐富的文件級訪問控制策略。

但是,目前Hadoop在有些安全方面仍存在缺陷,如:Hadoop集群用戶及權限管理復雜[4];Kerberos認證服務器單點失效[5];HDFS中缺乏面向數據字段的細粒度訪問控制策略[6];缺乏Hadoop集群專有的評價體系,不便于及時監控并評測Hadoop集群的健康狀況等。針對以上問題,本文設計了相應的Hadoop平臺安全加固方案,主要包括企業安全系統與Hadoop集群集成、字段級訪問控制以及健康評價體系。

1 企業安全系統集成

1.1 Windows AD與Hadoop集成

Windows AD認證協議有2種:NTLM(NT LAN Manager)以及Kerberos[7]。前者主要應用于Windows NT和Windows Server 2005及之后的工作組環境,而后者主要應用于Windows Server 2000及之后的域環境。Hadoop使用Kerberos來實現用戶認證,因此本文選取Kerberos作為認證協議,Hadoop集成后的整體架構如圖1所示。

圖1 Hadoop集成Kerberos認證架構

Hadoop集成Kerberos的主要步驟為:

1) 搭建Windows AD服務器,并創建AD域。

2) 配置Hadoop集群中的節點,并加入AD域。

3) 統一Hadoop與AD對票據的加密算法。

4) 在AD中配置管理Hadoop用戶憑據。

5) 用指定加密方式生成keytab文件,并做相應配置。

1.2 認證高可用與負載均衡

Hadoop集群中可能會同時具有數以萬計的任務,如果每個任務均需要進行Kerberos認證,就可能導致在一個很短的時間段內由于存在大量的認證請求而造成AD服務器超負載,從而形成整個集群的瓶頸,最終影響到Hadoop集群的正常運行[8]。為此,本文提出配置具有負載均衡能力的AD架構[9],其可提高AD的可用性,又可持續提供身份驗證及其他使用Kerberos的服務。由于AD和管理服務器需要主體數據庫的可讀寫拷貝來完成所需的修改,因此需要用LDAP服務器來存儲Kerberos數據[10-11],具有負載均衡能力的認證系統架構如圖2所示。

圖2 負載均衡拓撲

客戶端默認以輪詢方式訪問不同的AD服務器,因而提供了AD服務器的負載均衡,既可以降低AD的負載又可以消除單點故障。在使用LDAP時,一種常見的配置是使用一個LDAP主服務器和另外幾個LDAP副本服務器,這種配置可以實現存儲數據的負載均衡和高可用性。本文配置了多臺認證機器并多次使用負載均衡,使得該架構能夠提供持續且高效的認證服務。雖然本文配置方式需要額外的機器且配置復雜,增加了部署復雜度、管理復雜度及成本,但典型的Kerberos生產環境卻常常結合使用上述2種配置方式。在企業的實際生產應用中,如果僅僅有一臺AD服務器是十分危險的,且AD上存儲的數據十分重要,一旦丟失后果不堪設想。除此之外,企業的所有運行環境,如Hadoop集群、郵件系統、辦公系統等,都使用統一的認證服務,這樣AD負載很容易達到其瓶頸,而一旦AD性能下降或崩潰將會影響整個企業的正常運轉。因此,本文配置方式的弊端在企業的可承受范圍之內。

1.3 實驗驗證

1.3.1 實驗環境

實驗環境為2臺Windows AD服務器、2臺Linux LDAP主服務器、3臺LDAP副本服務器以及3臺測試機,上述10臺服務器的硬件配置完全相同,主要的硬件配置如表1所示。

表1 實驗的硬件配置

2臺AD服務器的操作系統為Windows Server 2012,其他服務器的操作系統均為CentOS-6.4_64,程序開發環境為Eclipse-Luna,JDK版本為1.8.0_11。

1.3.2 實驗數據

實驗以adtest[12]標準測試集為例,生成20個3層結構的組織單元,每個組織單元生成5 000位用戶信息,共產生100 000位用戶信息。

1.3.3 測試與結果分析

實驗使用adtest測試集生成的用戶,對單節點Windows AD以及Windows AD負載均衡2種架構,結合多線程以及定時任務,分別對其進行壓力測試。實驗測試數據如表2所示。

表2 實驗測試數據

在每臺測試主機上的測試程序開啟100、200、400、800、1 600個線程,同時發起認證請求,單節點Windows AD實驗結果如圖3所示。當認證用戶數量達到1 200時,單節點的Windows AD基本已經達到其認證的最大的負載(成功認證用戶數量/認證所需時間,700/s),當再次成倍提升認證用戶數量時,成功認證的用戶數量波動不大,而失敗的用戶數量大幅上升。從圖3的耗時曲線可知,在AD負載達到最大時,每次對用戶認證所消耗的時間增長率也急速提升。

圖3 單節點Windows AD實驗結果

顯然,使用單節點Windows AD提供認證服務并不能滿足企業生產環境下的需求。因此,本文提出以集群方式為Windows AD認證服務提供高可用與負載均衡特性,在集群環境下的Windows AD認證性能將成倍提升,實驗結果如圖4所示。

圖4 Windows AD負載均衡實驗結果

在使用負載均衡架構的認證服務后,Windows AD提供的認證性能大幅提升,認證服務的最大負載(3 400/s)大約是單節點AD的4.8倍,對比圖3的耗時曲線,可以看到在未達到最大負載時(測試用例1～測試用例4),成倍增長的認證用戶所需消耗的時間相比于單節點大約降低了4.2倍。除此之外,在達到最大負載時,雖然每次對用戶認證所消耗的時間增長率仍急速提升,但相比于單節點認證用戶所消耗時間仍提升了3.4倍左右。綜合上述對比實驗可以得出,在企業中使用具有負載均衡能力的認證架構是有必要的,且該架構帶來的成本代價是可以接受的。

2 字段級訪問控制

2.1 字段級訪問控制策略

數據的訪問控制是數據防泄漏[13]的重要前提,尤其是在Hadoop集群中,隨著集群中隱私數據量的不斷增大以及數據分析與處理方式的不斷豐富,傳統基于用戶、用戶組及訪問控制列表的粗粒度訪問控制策略已經不能滿足需求。針對上述問題,借助于對訪問控制模型以及Hadoop中安全組件源碼的分析與研究,本文提出在其開源框架內,增加面向字段的細粒度訪問控制流程,以在保障其他功能(如認證、數據靜態加密、傳輸加密等)不受影響的前提下,實現面向數據字段的細粒度訪問控制,進而提升用戶對數據管理的靈活性。在保留原有文件訪問控制的前提下,本文增加面向字段的訪問控制流程,數據擁有者可同時對文件以及文件中具體的字段設置對應的訪問控制列表項。當用戶請求獲取數據時,需要同時具有文件以及具體字段的讀取權限,應用字段級訪問控制策略后,文件上傳及下載的流程如圖5所示。

圖5 HDFS文件上傳下載流程

改進后的文件上傳及下載流程與傳統Hadoop文件上傳流程相比,主要增加了Schema解析、權限操作以及格式轉換3個過程。

2.1.1 Schema文件

Schema文件為待上傳文件的說明,該文件以JSON格式保存,相比XML、JSON的數據格式比較簡單且占用寬帶小,易于解析。Schema文件內配置了待上傳文件的字段名稱、字段類型、以及字段的訪問控制列表,Schema文件中存儲的字段信息結構及描述如表3所示。

表3 Schema文件字段信息結構組成

Schema文件示例如下:

text:

n_nationkey|n_name|n_regionkey|n_comment

0|ALGERIA|0|hanggle.carefully final deposits

1|ETHIOPIA|0|ven packages wake quickly.regu

2|FRANCE|3|refully final requests.Regular,ironi

3|JAPAN|2|ously.final,express gifts cajole a

schema:

{

“fields”:[

{“name”:”n_nationkey”,”type”:”int”,”acl”:”rw-r--r--”},

{“name”:”n_name”,”type”:”String”,”acl”:”rw-rw-rw-”},

{“name”:”n_regionkey”,”type”:”int”,”acl”:”rw--w-r--”},

{“name”:”n_comment”,”type”:”String”,”acl”:”r--r--r--”}

]

}

其中,待上傳文件的內容如示例text部分所示,包含n_nationkey、n_name、n_regionkey、n_comment 4個字段。其對應的Schema說明文件如前文Schema描述所示,fields中每條記錄均由字段名稱、字段類型(Java中的基本數據類型)、字段訪問控制列表組成,而每條記錄均是原始文件中某一字段的說明,這樣Schema文件就能完全描述待上傳文件的字段訪問控制信息。

2.1.2 文件上傳

為使Hadoop支持面向字段的訪問控制策略,本文擴展了Hadoop的文件上傳命令。當用戶使用本文方式上傳數據文件時,程序將根據用戶定義的Schema文件對原始數據文件進行解析,然后NameNode提取Schema中的內容,并在NameNode的內存中保存該字段的訪問控制列表,最后將相關信息寫入到EditsLog中。具體實現步驟如下:

1) 對原有的hdfs dfs -put [-f] [-p] [-l] [-d] …命令進行擴展,擴展后的命令格式為:hdfs dfs -put [-f] [-p] [-l] [-d] [-fs -s ] …。其中,-fs用來指定字段間的分隔符,-s用來指定Schema文件的物理存儲地址。

2) HDFS客戶端向NameNode發起文件上傳請求以獲取用于存儲數據的數據塊輸入流。由于字段級訪問控制實現的依據是Schema中存儲的信息,因此需要在原有PRC向NameNode傳遞信息的基礎上增加Schema字段,用來向NameNode發送Schema信息。

3) NameNode獲取到Schema字段內容后,將其作為文件的元屬性寫入對應NameNode的內存中,最后將此信息寫入EditsLog進行持久化,以便于NameNode重啟后仍能加載文件的字段訪問控制列表到內存中。

4) 建立DataNode數據塊的數據輸出流后,程序通過動態代理方式截獲所有的數據輸出流,并將數據以[(,< name,value>,…)]格式重新寫入數據輸入流中。使用該格式進行存儲的目的是在后續文件下載過程中,程序能夠通過截獲數據輸出流對數據流中的字段進行權限判定及過濾。

5) 修改FsImage與EditsLog合并的源碼,并增加合并相關元信息到FsImage的功能。

2.1.3 文件下載

為保障用戶的使用習慣,本文未對文件的下載命令進行擴展,而是通過程序判定的方式,對待讀取文件是否啟用本文的下載流程進行判斷,具體實現步驟如下:

1) 獲取待下載分布式文件的元信息,若其存在則說明用戶正在讀取支持字段級訪問控制的文件,若其不存在則說明用戶讀取的是普通文件。

2) 驗證用戶是否具有對該文件的讀權限,若具有則允許讀取該文件。然后,判斷用戶讀取的文件類型,若用戶讀取的是普通文件,則進入普通文件下載的處理流程;若用戶讀取的文件已配置字段級訪問控制策略,則繼續下述步驟。

3) NameNode提取待下載文件在DataNode中存儲的數據塊并為數據塊創建數據塊輸入流,然后程序將截獲所有的數據輸入流,并根據元信息將數據解析為[(,< name,value>,…)]格式。

4) 程序通過元信息中存儲的訪問控制列表并結合當前用戶基本信息,即可對數據輸入流中的字段進行權限判定,并將該用戶不具備讀權限的字段進行濾除。

5) 將數據的格式還原為文件上傳前的存儲格式。

2.1.4 權限操作

文件共享主體數量的增加以及數據文件共享方式的豐富,要求必須為用戶提供查詢及修改指定文件訪問控制列表的功能,具體實現步驟如下:

1) 擴展hdfs命令,提供字段的查看以及修改功能,擴展后字段權限相關的命令列表如表4所示。

表4 字段權限相關命令

2) NameNode接收用戶通過HDFS客戶端發送RPC請求后,判斷當前用戶是否是該文件的擁有者,進而決定是否提供該文件字段訪問控制列表的修改以及查看功能。

3) 若用戶是該數據文件的擁有者,且所指定的字段及控制列表權限符合本文提出的規則,則將更新后的元信息寫入EditsLog并更新內存中的訪問控制列表信息。對于查詢操作,若具有權限則直接返回相關的元信息。

4) 若用戶不是該文件的擁有者,則返回未授權。

2.2 實驗驗證

2.2.1 實驗環境

實驗采用Hadoop開源框架中提供的測試環境MiniDFSCluster,程序開發環境為Eclipse-Luna,JDK版本為1.8.0_11,所有的進程均在測試主機中運行。實驗過程中分別啟動NameNode、StandbyNameNode以及2個DataNode。這4個進程共享測試主機內存、CPU以及磁盤,測試機的主要配置如表5所示。

表5 實驗的硬件配置

在Hadoop集群模式下,數據的存儲與網絡等因素密切相關,而采用MiniDFSCluster測試環境可消除由于網絡不穩定而造成實驗結果數據失真的情況。除此之外,采用MiniDFSCluster測試環境,還可消除因軟硬件性能不同等各種差異帶來的影響,從而能夠產生最精確的對比數據。

2.2.2 實驗數據

為探索文件大小對上傳耗時的影響,本文借助于隨機生成器分別生成10 MB、40 MB、160 MB、640 MB、1 280 MB的數據文件。

為探索文件字段數量對上傳速率的影響,本文借助于隨機算法分別生成字段數量為3、6、12、24、48,大小為640 MB的數據文件。

2.2.3 測試與結果分析

本文字段級訪問控制與傳統Hadoop文件上傳方法對比實驗如下:

1) 文件大小與性能關系,本次實驗用于驗證文件大小對上傳耗時的影響。為降低偶然因素帶來的干擾,本文對相同文件上傳30次,每次重新上傳文件之前,均格式化測試集群。實驗將最終統計結果中上傳速率最快及最慢的2項去除,取剩余數據的平均值,實驗結果如圖6所示。

圖6 上傳消耗時間與文件大小的關系

本文方法在對原始數據流處理后,需要額外增加字段空間,導致實際上傳文件所占空間大于待上傳文件所占空間,因此帶來額外的上傳時間消耗。假設10 MB文件帶來的額外字段所占空間為10 KB,則40 MB文件需要40 KB的額外空間。盡管所需額外空間呈線性增長,然而由于直線斜率較低,對于較大的文件,該額外空間上傳的時間消耗在可接受的范圍內。

2) 文件字段數量與性能關系,本次實驗用于驗證文件大小相同,字段數量不同對上傳速率的影響。同樣,為了降低偶然因素帶來的影響,本文對相同文件上傳30次,每次重新上傳文件之前,均格式化測試集群。實驗將最終統計結果中上傳速率最快及最慢的2項去除,取剩余數據的平均值,實驗結果如圖7所示。

圖7 上傳消耗時間與字段數量的關系

本文方法對原始數據流的處理是以行為最小處理單位,在文件大小不變的前提下,字段數量的增多會減少處理次數,因此便可提升處理效率。盡管字段數量會影響文件的上傳速率,但從圖7可以看出,該模型文件上傳消耗時間相比于整體的消耗時間可以忽略不計,且當字段成倍增加時,文件上傳消耗時間逐步加速趨近于傳統上傳方式。

綜合上述對比實驗可以得出,本文提出的字段級訪問控制在效率上的降低在可容忍范圍之內,且在加固后的系統中使用傳統上傳方式,效率也幾乎沒有發生變化,由此可得本文字段級訪問控制具有可行性。

3 健康評價體系

隨著企業數據量的增加以及業務的拓展,Hadoop集群規模也在不斷擴大,這導致維護集群的復雜度呈直線上升,目前的Hadoop集群中仍然存在大量的軟件錯誤和硬件故障,要求系統7×24 h不間斷運行,因此對于這些系統的持續監控就至關重要。目前對于Hadoop集群尚無一個評價體系可以體現集群的健康走勢,這導致管理者很難及時發現并定位集群中潛在的隱患。為此,本文提出建立基于集群資源的健康評價體系,以對集群的健康狀態進行把控,進而為整個Hadoop集群的安全運行提供保障,提高集群的健壯性。

3.1 基于熵值法的集群健康評價

集群健康是一個相對概念,需要建立基準點即健康狀態下的集群系統,并在對比的基礎上進行集群健康狀況的評估。集群健康的不可確定性及復雜性,導致集群健康狀態的評判不可避免地帶有人為主觀性,而對資源狀態進行評判時,常常采用主觀賦權的方法來確定各個指標的影響因子。主觀賦權是指專家根據各個指標的重要性來確定權重,其容易受專家主觀意識的影響而帶來偏差,并且不能反映各指標統計數據的相互關系[14-15]。在信息論中,信息熵是系統無序程度的度量。信息熵越小,信息的效用值越大,反之信息熵越大,信息的效用值越小[16]。熵值法在確定屬性權重方面克服了主觀意識等因素帶來的影響,對于集群的健康評價體系,本文提出基于熵值法的集群健康評價算法,選取某段時間序列,將序列中的指標進行歸一化,然后借助信息熵值法計算各個指標的熵權[17],其具體計算步驟如下:

1)收集集群健康狀態的評價指標。通過Linux腳本收集節點健康狀態的評價指標,如內存大小、HDFS使用率、內存使用率、CPU使用率、CPU溫度、節點數量、MapReduce任務數量、網絡時延、網絡IO、磁盤IO。

2)構建決策矩陣。設X={x1,x2,…,xm}為集群評價指標記錄的集合,U={u1,u2,…,un}為集群評價指標集合。對于記錄xi,按指標uj進行測度,得到xi關于uj的指標aij,從而構成決策矩陣A={aij}m×n。

3.2 健康評價體系模型

在使用基于熵值法的集群健康評價算法計算集群的健康走勢之前,首先需要無間斷地從集群中各個節點收集指標數據并對數據進行統一處理;然后,將處理后的數據交由評分計算流程,對集群各個時間點的健康狀態進行評分;最后,根據得出的各個時間點的評分繪制健康走勢圖。健康評價體系模型詳細設計流程如圖8所示。

圖8 健康評價體系詳細設計流程

健康評價體系模型的計算過程主要分為5個步驟:

1) 收集指標,程序在運行中可以動態設置是否開啟集群健康評價體系監控,若開啟,首先判斷用戶是否已經設置需要清空數據(默認不清空);然后通過Linux腳本收集節點健康狀態的評價指標,如內存、HDFS使用率、內存使用率、CPU使用率、CPU溫度、節點數量、MapReduce任務數量、網絡IO、磁盤IO。

2) 異常提醒,在收集數據過程中,一旦發現某個節點的某項指標低于或者高于預定義閾值,則直接向管理員發送異常警告。

3) 數據存儲,數據由各個節點收集并發送到分析服務器,分析服務器將傳輸的數據取均值后存儲于內存中。

4) 熵值法計算,通過定時器或管理員手動觸發的方式,利用熵值法計算集群健康評分流程。

5) 圖形展示,根據計算的結果以時間為線索繪制集群健康走勢圖。

3.3 實驗驗證

3.3.1 實驗環境

實驗使用了7臺物理機器,這7臺機器配置完全相同且在同一個局域網中,主要的軟硬件配置如表6所示。其中,包括一臺NameNode節點、一臺StandbyNameNode節點,其余均為DataNode節點。同時,這些節點還運行了Yarn服務。

表6 實驗的軟硬件配置

3.3.2 實驗數據

實驗每隔20 s對集群的評價指標進行收集,將其作為一個單位時間,最終計算集群的歷史健康評分,繪制集群健康曲線走勢圖。在監控的過程中,實驗通過模擬軟硬件故障,如網絡時延、磁盤故障、CPU使用率高、HDFS使用率持續上升、MapReduce任務運行等情況分析該模型的實用性。

3.3.3 測試與結果分析

本文健康評價體系模型在單一評價指標與多個評價指標情況下的實驗如下:

1)單一評價指標

實驗使用Linux系統下的開源流量控制工具TC[18]模擬網絡阻塞,編寫Linux定時任務周期性地將網絡時延由200 ms逐步增加至1 800 ms,程序在無間斷情況下運行1 h,并最終繪制健康走勢圖,實驗結果如圖9所示。

圖9 單一評價指標下集群健康走勢

在內存利用率、CPU使用率、磁盤I/O等因素波動不大的前提下,集群健康指數可近似看作隨著網絡I/O時延的增加而線性減小。由此可見,該模型能夠有效檢測集群評價指標的變化,并能夠正確反映到集群健康走勢圖中。

2)多個評價指標

Hadoop集群環境相對比較復雜,僅單一指標發生變化的情況比較少見,因此實驗通過運行Hadoop WordCount基準測試程序模擬生產環境,進而驗證本文模型的實用性。實驗數據使用搜狐新聞數據歷史版本2008版完整版,解壓后數據大小為2.95 G。實驗使用的中文分詞工具是基于Lucene的IKAnalyzer Java版本(http://code.google.com/p/ik-analyzer/),結果如圖10所示。

圖10 多個評價指標下集群健康走勢

MapReduce作業調度運行后,根據文件的切分將生成多個Map以及Reduce任務,而任務的運行需要消耗大量的集群資源,比如CPU、內存、網絡I/O等,如圖10所示。從圖10可以看出,在0～120個單位時間內,由于Map以及Reduce任務的不斷增加、任務的調度、數據的讀取、Shuffle過程中數據的存儲以及數據的移動,使得集群的健康指數不斷下降;在120個～170個單位時間內絕大部分Map子任務執行階段結束,由于該階段使用分詞工具對中文進行分詞,因此占用了大量的內存以及CPU等主機資源,雖然Reduce任務仍在運行,但由于只是做簡單的統計工作,對內存以及CPU等資源的需求并不是很高,由此集群資源開始回收,集群健康指數提升;在170個單位時間之后,Reduce子任務執行階段結束,標志MapReduce作業的完成,集群健康指數快速回升。通過分析可知,該模型在生產環境下能夠有效檢測集群評價指標的變化,并能夠正確反映到集群健康走勢圖中。

由實驗結果可以得出,本文提出的健康評價體系能夠在指定時間段內準確反映集群的健康走勢,管理員通過集群健康走勢圖可對集群的整體情況進行把控,大幅提升了工作效率,并且為整個Hadoop集群的持續健康運行提供了有效保障。

4 結束語

針對Hadoop集群中的安全隱患,本文設計了相應的安全加固方案,主要包括企業安全系統與Hadoop集群集成、字段級訪問控制以及健康評價體系,并通過實驗驗證該方案的可行性與有效性。下一步將對健康評價體系的核心算法進行優化,以期更加精確地反映集群的健康狀態,并結合機器學習為其提供預測能力。另外,由于版本的迭代,Hadoop的安全問題會不斷發生變化,下一步將繼續研究Hadoop平臺中的安全問題,并提出相應新的安全加固方案。