歡迎您光臨本站 註冊首頁

大數據安全: Hadoop安全模型的演進

←手機掃碼閱讀     火星人 @ 2014-03-04 , reply:0

大數據安全: Hadoop安全模型的演進

  
http://pub.chinaunix.net//uploadfile/201311/20131106101419510.jpg
敏感信息的安全和保護是當今人們最關心的問題之一。進入大數據時代,很多組織都在從各種源頭收集數據,進行分析,並基於對海量數據集的分析做出決策,因此這一過程中的安全問題變得愈發重要。與此同時,HIPAA和其他隱私保護法之類的法律法規也要求組織加強對這些數據集的訪問控制和隱私限制。來自內部和外部攻擊者的網路安全漏洞與日俱增,通常都要數月之後才能發現,而那些受此影響的人正在為此付出代價。沒能對他們的數據做出恰當訪問控制的組織將受到起訴,出現在負面報道中,並將面臨監管機構的罰款。
請想一想下面這些讓人大開眼界的統計數據:


[*]賽門鐵克和Ponemon研究所今年公布的一項研究表明,一個安全漏洞在美國的平均組織化成本是540萬美元1。另據最近一項研究表明,僅僅網路犯罪在美國造成的損失每年就有140億美元之多。
[*]2011年索尼遊戲機網路中出現的漏洞可以算是近代最大的安全漏洞之一,專家們估計索尼與該漏洞相關的損失大約在27億到240億美元之間(範圍很大,但這個漏洞太大了,所以幾乎難以對其進行量化)。
[*]Netflix和AOL已經因為其管理的大量數據和對個人信息的保護而受到金額達數百萬美元的起訴(某些已經立案),儘管他們已經對這些數據做了「匿名化」處理並且是為了研究才公布的。
[*]跟安全漏洞相關的除了可量化的成本(客戶和業務合作夥伴的損失,訴訟,監管罰款),經歷此類事件的組織的可信度和聲譽還會受到影響,甚至可能會導致公司歇業。

簡而言之,如果沒有恰當的安全控制,大數據很容易變成花費巨大的大問題。
對於處理大數據的組織來說這意味著什麼?意味著你擁有的數據越多,對數據的保護就越重要。意味著不僅要安全有效地控制離開自有網路的數據,還必須做好網路內部的數據訪問控制。依據數據的敏感程度,我們可能要確保數據分析師能看到的數據是可以讓他們分析的數據,並且必須明白髮布這些數據及其分析結果可能產生的後果。僅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的不足有幾個原因:
   沒有「靜態數據」加密。目前HDFS上的靜態數據沒有加密。那些對Hadoop集群中的數據加密有嚴格安全要求的組織,被迫使用第三方工具實現HDFS硬碟層面的加密,或安全性經過加強的Hadoop版本(比如今年早些時候英特爾發布的版本)。
   以 Kerberos為中心的方式——Hadoop依靠 Kerberos做認證。對於採用了其他方式的組織而言,這意味著他們要單獨搭建一套認證系統。
   有限的授權能力——儘管Hadoop能基於用戶及群組許可和訪問控制列表(ACL)進行授權,但對於有些組織來說這樣是不夠的。很多組織基於XACML和基於屬性的訪問控制使用靈活動態的訪問控制策略。儘管肯定可以用Accumulo執行這些層面的授權過濾器,但Hadoop的授權憑證作用是有限的。
   安全模型和配置的複雜性。 Hadoop的認證有幾個相關的數據流,用於應用程序和Hadoop服務的Kerberos RPC認證,用於web控制台的HTTP SPNEGO認證,以及使用代理令牌、塊令牌、作業令牌。對於網路加密,也必須配置三種加密機制,用於SASL機制的保護質量,用於web控制台的SSL,HDFS數據傳輸加密。所有這些設置都要分別進行配置,並且很容易出錯。
如果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項目,給出了一個未來的快照。
關於作者
http://pub.chinaunix.net//uploadfile/201311/20131106101419150.jpg
凱文T.史密斯是Novetta解決方案應用任務方案分部的技術方案及推廣指導,他負責向客戶提供戰略性的技術領導力,開發具有創新性的、數據為本並且高度安全的解決方案。他經常在各種技術會議上演講,發表過很多技術文章,還編寫過許多技術書籍,包括即將出版的《專業Hadoop解決方案》,以及《應用SOA:面向服務的架構及設計策略》,《語義Web:XML,Web服務及知識管理的未來發展指南》等等。可以通過KSmith@Novetta.com聯繫到他。

致謝
特別感謝Stella Aquilina, Boris Lublinsky, Joe Pantella, Ralph Perko, Praveena Raavicharla, Frank Tyler 和 Brian Uri 對本文的審閱和部分內容的評論。 此外還要感謝克里斯·貝利製作了不斷發展的Hadoop大象之「艾比路」這幅插圖。
1 Ponemon 研究所, 2013數據泄露的成本研究:全球分析,2013年5月
2 商業內幕,PlayStation網路危機可能讓索尼花費了數十億
3 請參見「CNN/Money –5數據泄露 - 從尷尬到致命」,及維基百科上關於 AOL在匿名化記錄上泄漏的研究數據的頁面
4 Ponemon 研究所, 「你的公司為大數據泄漏做好準備了嗎?」, 2013年3月
查看英文原文:Big Data Security: The Evolution of Hadoop』s Security Model
轉自 http://www.infoq.com/cn/articles/HadoopSecurityModel

本文來自ChinaUnix新聞頻道,如果查看原文請點:http://news.chinaunix.net/opensource/2013/1106/3004044.shtml
《解決方案》

安全無處不在

[火星人 ] 大數據安全: Hadoop安全模型的演進已經有369次圍觀

http://coctec.com/docs/service/show-post-3884.html