大数据安全: Hadoop安全模型的演进
敏感信息的安全和保護是當今人們最關心的問題之一。進入大數據時代,很多組織都在從各種源頭收集數據,進行分析,并基于對海量數據集的分析做出決策,因此這一過程中的安全問題變得愈發重要。與此同時,HIPAA和其他隱私保護法之類的法律法規也要求組織加強對這些數據集的訪問控制和隱私限制。來自內部和外部攻擊者的網絡安全漏洞與日俱增,通常都要數月之后才能發現,而那些受此影響的人正在為此付出代價。沒能對他們的數據做出恰當訪問控制的組織將受到起訴,出現在負面報道中,并將面臨監管機構的罰款。
請想一想下面這些讓人大開眼界的統計數據:
? ?- 賽門鐵克和Ponemon研究所今年公布的一項研究表明,一個安全漏洞在美國的平均組織化成本是540萬美元1。另據最近一項研究表明,僅僅網絡犯罪在美國造成的損失每年就有140億美元之多。
- 2011年索尼游戲機網絡中出現的漏洞可以算是近代最大的安全漏洞之一,專家們估計索尼與該漏洞相關的損失大約在27億到240億美元之間(范圍很大,但這個漏洞太大了,所以幾乎難以對其進行量化)。2
- Netflix和AOL已經因為其管理的大量數據和對個人信息的保護而受到金額達數百萬美元的起訴(某些已經立案),盡管他們已經對這些數據做了“匿名化”處理并且是為了研究才公布的。3
- 跟安全漏洞相關的除了可量化的成本(客戶和業務合作伙伴的損失,訴訟,監管罰款),經歷此類事件的組織的可信度和聲譽還會受到影響,甚至可能會導致公司歇業。4
簡而言之,如果沒有恰當的安全控制,大數據很容易變成花費巨大的大問題。
對于處理大數據的組織來說這意味著什么?意味著你擁有的數據越多,對數據的保護就越重要。意味著不僅要安全有效地控制離開自有網絡的數據,還必須做好網絡內部的數據訪問控制。依據數據的敏感程度,我們可能要確保數據分析師能看到的數據是可以讓他們分析的數據,并且必須明白發布這些數據及其分析結果可能產生的后果。僅Netflix數據泄漏一個案例就足以表明,即使已經試圖對數據做了“匿名化”處理,也可能會發布一些意料之外的信息——一些在差異化隱私領域標明的東西。
Apache Hadoop是最流行的大數據處理平臺之一。盡管最初設計Hadoop時根本沒考慮安全問題,但它的安全模型在不斷地演進。Hadoop的興起也招致了很多批判,并且隨著安全專家不斷指出其潛在的安全漏洞及大數據的安全風險,使得Hadoop一直在改進其安全性。“Hadoop安全”市場曾出現過爆炸性的增長,很多廠商都發布了“安全加強”版的Hadoop和對Hadoop的安全加以補充的解決方案。這類產品有Cloudera Sentry、?IBM InfoSphere Optim Data Masking、?英特爾的安全版Hadoop、DataStax企業版、?DataGuise for Hadoop、用于Hadoop的Protegrity大數據保護器、Revelytix Loom、Zettaset 安全數據倉庫,此外還有很多,這里就不再一一列舉了。與此同時,Apache也有?Apache Accumulo這樣的項目,為使用Hapdoop提供了添加額外安全措施的機制。最終還出現了?Knox網關?(由HortonWorks貢獻)和Rhino項目(由英特爾貢獻)這樣的開源項目,承諾要讓Hadoop本身發生重大改變。
?要讓Hadoop達到安全性要求的巨大需求使得Hadoop一直在發生著變化,這也是我要在本文中重點討論的內容。
Hadoop安全(簡)史
Doug Cutting和Mike Cafarella最初為Nutch項目開發Hadoop時并沒有考慮安全因素,這是眾所周知的事實。因為Hadoop的最初用例都是圍繞著如何管理大量的公共web數據,無需考慮保密性。按照Hadoop最初的設想,它假定集群總是處于可信的環境中,由可信用戶使用的相互協作的可信計算機組成。
最初的Hadoop中并沒有安全模型,它不對用戶或服務進行驗證,也沒有數據隱私。因為Hadoop被設計成在分布式的設備集群上執行代碼,任何人都能提交代碼并得到執行。盡管在較早的版本中實現了審計和授權控制(HDFS文件許可),然而這種訪問控制很容易避開,因為任何用戶只需要做一個命令行切換就可以模擬成其他任何用戶。這種模擬行為非常普遍,大多數用戶都會這么干,所以這一已有的安全控制其實沒起到什么作用。
在當時,考慮到安全問題的組織把Hadoop隔離在專有網絡中,只有經過授權的用戶才能訪問。然而由于Hadoop內部幾乎沒有安全控制,在這樣的環境中也會出現很多意外和安全事故。善意的用戶可能會犯錯(比如用一個分布式刪除在幾秒內就會刪除大量數據)。所有用戶和程序員對集群內的所有數據都有相同的訪問權限,所有任務都能訪問集群內的任何數據,并且所有用戶都可能會去讀取任何數據集。因為MapReduce沒有認證或授權的概念,某個頑劣的用戶可能為了讓自己的任務更快完成而降低其他Hadoop任務的優先級,甚至更壞,直接殺掉其他任務。
隨著Hadoop在數據分析和處理平臺中的地位日益凸顯,安全專家們開始關心來自Hadoop集群內部的惡意用戶的威脅。惡意開發人員能輕易寫出假冒其他用戶Hadoop服務的代碼來(比如寫一個新的TaskTracker并將其注冊為Hapdoop服務,或者冒充hdfs或mapred用戶,把HDFS里的東西全刪掉等等)。因為DataNode沒有訪問控制,惡意用戶可以繞過訪問控制從DataNode中讀取任意數據塊,或將垃圾數據寫到DataNode中破壞目標分析數據的完整性。所有人都能向JobTracker提交任務,并可以任意執行。
因為這些安全問題,Hadoop社區意識到他們需要更加健壯的安全控制,因此,雅虎的一個團隊決定重點解決認證問題,選擇Kerberos作為Hadoop的認證機制,這在他們2009年的白皮書上有記錄。
在Hadoop發布.20.20x版本時他們實現了自己的目標,該版本采用了下面這些機制:
- 用Kerberos RPC (SASL/GSSAPI)?在RPC連接上做相互認證——用SASL/GSSAPI來實現Kerberos及RPC連接上的用戶、進程及Hadoop服務的相互認證。
- 為HTTP Web控制臺提供“即插即用”的認證——也就是說web應用和web控制臺的實現者可以為HTTP連接實現自己的認證機制。包括(但不限于)HTTP SPNEGO認證。
- 強制執行HDFS的文件許可——可以通過NameNode根據文件許可(用戶及組的訪問控制列表(ACLs))強制執行對HDFS中文件的訪問控制。
- 用于后續認證檢查的代理令牌——為了降低性能開銷和Kerberos KDC上的負載,可以在各種客戶端和服務經過初始的用戶認證后使用代理令牌。具體來說,代理令牌用于跟NameNode之間的通訊,在無需Kerberos服務器參與的情況下完成后續的認證后訪問。
- 用于數據塊訪問控制的塊訪問令牌——當需要訪問數據塊時,NameNode會根據HDFS的文件許可做出訪問控制決策,并發出一個塊訪問令牌(用HMAC-SHA1),可以把這個令牌交給DataNode用于塊訪問請求。因為DataNode沒有文件或訪問許可的概念,所以必須在HDFS許可和數據塊的訪問之間建立對接。
- 用作業令牌強制任務授權——作業令牌是由JobTracker創建的,傳給TaskTracker,確保Task只能做交給他們去做的作業。也可以把Task配置成當用戶提交作業時才運行,簡化訪問控制檢查。
- 把這些整合到一起讓Hadoop向前邁出了一大步。自那之后,又實現了一些值得稱道的修改:
- 從“即插即用的認證”到HTTP SPNEGO認證——盡管2009年的Hadoop安全設計重點是即插即用的認證,但因為RPC連接(用戶、應用和Hadoop服務)已經采用了Kerberos認證,所以Hadoop開發者社區覺得如果能跟Kerberos保持一致更好。現在Hadoop web控制臺被配置成使用HTTP SPNEGO這一用于web控制臺的Kerberos實現。這樣可以部分滿足Hadoop亟需的一致性。
- 網絡加密——采用了SASL的連接可以配置成使用機密保護質量(QoP),在網絡層強制加密,包括使用Kerberos RPC的連接和使用代理令牌的后續認證。Web控制臺和MapReduce隨機操作可以配置成使用SSL進行加密。HDFS文件傳輸器也能配置為加密的。
自對安全性進行重新設計以來,Hadoop的安全模型大體上沒發生什么變化。隨著時間的推移,Hadoop體系中的一些組件在Hadoop之上構建了自己的安全層,比如Apache Accumulo,提供單元級的授權,而HBase提供列和族系一級的訪問控制。
Hadoop當前所面臨的安全挑戰
組織在保證Hadoop的安全性時會面臨一些安全方面的挑戰,在我和Boris Lublinsky 及 Alexey Yakubovich寫的新書中,我們用了兩章的篇幅集中討論Hadoop的安全問題,其中一章的重點是Hadoop本身的安全能力,另外一章的重點是對Hadoop的安全性進行補充的策略。
常見的安全問題有:
- 如何強制所有類型的客戶端(比如web控制臺和進程)上的用戶及應用進行驗證?
- 如何確保服務不是流氓服務冒充的(比如流氓TaskTracker和Task,未經授權的進程向 DataNode 出示ID 以訪問數據塊等?)
- 如何根據已有的訪問控制策略和用戶憑據強制數據的訪問控制?
- 如何實現基于屬性的訪問控制(ABAC)或基于角色的訪問控制(RBAC)?
- 怎么才能將Hadoop跟已有的企業安全服務集成到一起?
- 如何控制誰被授權可以訪問、修改和停止MapReduce作業?
- 怎么才能加密傳輸中的數據?
- 如何加密靜態數據?
- 如何對事件進行跟蹤和審計,如何跟蹤數據的出處?
- 對于架設在網絡上的Hadoop集群,通過網絡途徑保護它的最好辦法是什么?
這其中很多問題都能靠Hadoop自身的能力解決,但也有很多是Hadoop所無能為力的,所以行業內涌現出了很多Hadoop安全補充工具。廠商們發布安全產品來彌補Hadoop的不足有幾個原因:
如果Hadoop如今還不具備實現者所要求的安全能力,那么他們只能轉而集成第三方工具,或使用某個廠商提供的安全加強版Hadoop,或采用其他有創造性的辦法。
即將發生的大變化
2013年開端之際,英特爾發起了一個開源項目Rhino,以提升Hadoop及其整個體系的安全能力,并將代碼貢獻給了Apache。這有望顯著加強Hadoop當前的貢獻。這一開源項目的總體目標是要支持加密和密鑰管理,一個超越Hadoop當前提供的用戶及群組ACL的通用授權框架,一個基于認證框架的通用令牌,改善HBase的安全性,改善安全審計。這些任務都被記錄在Hadoop、 MapReduce、HBase 和 Zookeeper的JIRA中,擇重點摘錄如下:
- 加密的靜態數據——JIRA 任務?HADOOP-9331?(Hadoop加密編碼解碼器框架及加密編碼解碼器的實現) 和?MAPREDUCE-5025?(支持MapReduce中的加密編碼解碼器的密鑰發行和管理) 有直接的關系。第一個側重于創建一個加密框架及其實現,以支持對HDFS上文件的加密和解密;第二個側重于為MapReduce提供密鑰發行和管理框架,以便能在MapReduce操作過程中對數據加密和解密。為此向Hadoop中引入了一個可分割AES編碼解碼器的實現,可以對磁盤上分散的數據加密和解密。密鑰發行和管理框架可以在MapReduce操作過程中解析密鑰的上下文,因此MapReduce作業能夠進行加解密操作。他們已經發展出的需求包括MapReduce作業不同階段的不同選項,并且要支持靈活的密鑰獲取辦法。在一些相關的任務中,ZOOKEEPER-1688將提供透明的快照加密能力,并在硬盤記錄日志,防止敏感信息從靜態文件中泄漏出去。
- 基于令牌的認證及統一授權框架——JIRA 任務?HADOOP-9392?(基于令牌的認證及單點登錄) 和?HADOOP-9466?(統一授權框架) 也是相互關聯的。第一項任務展示了一個跟Kerberos耦合不是那么緊密的基于令牌的認證框架。第二項任務會用基于令牌的框架支持靈活的授權強制引擎,以取代(但能向后兼容)當前的ACL式訪問控制。對基于令牌的認證框架,第一項任務計劃支持多種認證機制的令牌,比如LDAP 用戶名/密碼認證,Kerberos,X.509證書認證,SQL認證(基于SQL數據庫的用戶名/密碼認證)和SAML。第二項任務要支持一個先進的授權模型,側重于基于屬性的訪問控制(ABAC)和XACML標準。
- 提升HBase的安全性——JIRA 任務?HBASE-6222?(增加每-鍵值安全) 向HBase添加Apache Accumulo具備但HBase還沒有的單元級授權。開發出構建在加密框架上的HBASE-7544?,把它擴展到HBase,提供透明的表加密。
這些就是Hadoop的主要變化,但有望解決有這些安全需求的組織的安全問題。
結論
在我們這個步履匆匆而又相互關聯的世界里,大數據就是王道,在我們對海量數據進行處理和分析時,明白安全的重要性至關重要。這要從弄懂數據及相關的安全策略開始,也要明白組織的安全策略,并知道如何強制執行。本文介紹了Hadoop的安全簡史,重點講了常見的安全問題,并介紹了Rhino項目,給出了一個未來的快照。
總結
以上是生活随笔為你收集整理的大数据安全: Hadoop安全模型的演进的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 一文带你从Vue2.x大迈步走进Vue.
- 下一篇: EA-IRMS操作(以MAT253 pl