星環大數據安全組件Guardian與hadoop自帶的安全組件區別
在進行講解之前，先帶大家學習下hadoop關於hdfs自己的安全如何實現的---------------------------
名詞：
ACL-訪問控制列表（Access Control List，ACL）
ARBAC-基於角色的權限訪問控制（Role-Based Access Control）
所有安全體系的了解，大數據平臺安全體系的四個層次說起：外圍安全、數據安全、訪問安全以及訪問行為監控，如下圖所示；
- 外圍安全技術多指傳統意義上提到的網絡安全技術，如防火墻，登陸認證等；
- 數據安全從狹義上說包括對用戶數據的加解密，又可細分為存儲加密和傳輸加密；還包括用戶數據的脫敏，脫敏可以看做“輕量級”的數據加密。如某人的生日為“2014-12-12”，脫敏後的數據為“2014-x-x”。數據的輪廓依然存在，但已無法精確定位數值。脫敏的程度越高數據可辨認度越低。上述的例子還可脫敏為“x-x-x”，相當於完全對外屏蔽該信息。
- 訪問安全主要是對用戶的授權進行管理。Linux/Unix系統中用戶-組的讀、寫、執行權限管理堪稱其中的經典模型。HDFS對這一概念進行了擴充，形成了更加完備的ACL體系；另外隨著大數據的應用的普及和深入，文件內部數據訪問權限差異化的需求也變得越來越重要；
- 訪問行為監控多指記錄用戶對系統的訪問行為：如查看哪個文件；運行了哪些SQL查詢；訪問行為監控一方面為了進行實時報警，迅速處置非法或者危險的訪問行為；另一方面為了事後調查取證，從長期的數據訪問行為中分析定位特定的目的。
在這四個安全的層次中，第三層同上層業務的關系最為直接：應用程序的多租戶，分權限訪問控制都直接依賴這一層的技術實現。
HDFS的權限管理
普通Hadoop集群中的各個組件通常使用不同模型進行權限管理。
- 例如HDFS使用類似POSIX ACL的權限模型，用HDFS shell授權；
- Hive使用基於角色的RBAC模型，用SQL授權；
- 而HBase使用的是基於組的RBAC權限模型，使用HBase shell授權。
這就意味著為三個組件授權需要登錄三個系統，使用三種不同的模型授權，為權限運維造成不小的難度。基本上就是訪問安全，並沒有其他安全的防護。。。。
問題背景：
Hadoop在企業中廣泛地應用，越來越多的業務場景要求大數據訪問控制的粒度也不再局限在文件級別，而是更加細致地約束文件內部的數據哪些
CDH的安全組件
安全組件的來源背景：
Hive是早期將高級查詢語言SQL引入Hadoop平臺的引擎之一，早期的Hive服務器進程被稱作Hiveserver1；Hiveserver1既不支持處理並行的多個連接，又不支持訪問授權控制；後來這兩個問題在Hiveserver2上被解決，Hiveserver2能夠使用grant/revoke語句來限制用戶對數據庫、表、視圖的訪問權限，行列權限的控制是通過生成視圖來實現的；但Hiveserver2的授權管理體系被認為存在問題，那就是任何通過認證登陸的用戶都能夠為自己增加對任何資源的訪問權限。也就是說Hiveserver2提供的不是一種安全的授權體系，Hiveserver2的授權體系是為防止正常用戶誤操作而提供保障機制；不是為保護敏感數據的安全性而設計的。然而這些更多的是某些公司的說辭，事實上Hiveserver2自身的安全體系也在逐步完善，上述問題也在快速修復中。
但授權管理其實不止是Hive需要，其他的查詢引擎也迫切需要這些技術來完善和規範應用程序對數據的訪問。對於細粒度授權管理的實現，很大一部分功能在各引擎之間是可以公用的，因此獨立實現的授權管理工具是非常必要的。
在這樣的背景下，Cloudera公司的一些開發者利用Hiveserver2中現有使用價值的授權管理工具Sentry，下圖是Sentry與Hiveserver2中的授權管理模型的對比：
Sentry的很多基本模型和設計思路都來源於Hiveserver2，但在其基礎之上加強了RBAC的概念。在Sentry中，所有相應的權限。權限à角色à用戶組à用戶，這一條線的映射關系在Sentry中顯得尤為清晰，這條線的映射顯示了一條權限如何能最後被一個用戶所擁Hadoop自身的用戶-組映射來實現的。有集中配置，易於修改的好處。
Sentry將Hiveserver2中支持的數據對象從數據庫/表/視圖擴展到了服務器，URI以及列粒度。雖然列的權限控制可以用視圖來實現，但是對於多用戶，表數量巨大的情況，視圖的方法會使得給視圖命名變得異常復雜；而且用戶原先寫的針對原表的查詢語句，這時就無法直接使用，因為視圖的名字可能與原表完全不同。
目前Sentry1.4能夠支持的授權級別還局限於SELECT，INSERT，ALL這三個級別，但後續版本中已經能夠支持到與Hiveserver2現有三個重要的組件：一是Binding；二是Policy Engine；三是Policy Provider。
Binding實現了對不同的查詢引擎授權，Sentry將自己的Hook函數插入到各SQL引擎的編譯、執行的不同階段。這些Hook函數起兩大作用：一是起過濾器的作用，只放行具有引擎的授權信息也存儲在由Sentry設定的統一的數據庫中。這樣所有引擎的權限就實現了集中管理。
Policy Engine判定輸入的權限要求與已保存的權限描述是否匹配，Policy Provider負責從文件或者數據庫中讀取出原先設定的訪問權限。Policy Engine以及Policy Provider其實對於任何授權體系來說都是必須的，因此是公共模塊，後續還可服務於別的查詢引擎。
Transwarp Guardian保障HDFS安全
Guardian 5.0在原有安全解決方案的基礎上提供了更加完整的功能以及方便的操作，包括用戶認證、授權、配額管理以及資源控制。用戶認證通過LDAP以及KERBEROS協議，確保只有經過身份甄別的用戶才能訪問系統，授權保證只有被賦予權限的用戶才可以訪問系統資源，配額管理與資源負責控制用戶使用的資源大小，三個部分一同保證TDH平臺大數據安全。
- Guardian 5.0的底層用改進的Guardian Directory Service代替OpenLDAP+Kerberos的方案，用同一套用戶統一了LDAP/Kerberos認證方式，避免了OpenLDAP使用Kerberos認證，提高了LDAP認證效率。
- 第二層是獨立的服務Guardian Server，實現了對完整ARBAC（Administrative Role-Based Access Control）模型的支持，提供REST API，用戶友好的Web UI，密碼策略等，並實現JWT Token機制服務於SSO。此外，Guardian Server實現了用戶認證授權的統一化，使得從Web服務，如Workflow，Rubik到Hadoop底層都可以使用同一套用戶，同一套機制實現授權；同時也開放了LDAP接口、REST API和LoginService以供第三方應用使用Guardian用戶進行認證和授權的整合。
- Guardian在第三層以插件的形式，為TDH各個組件提供了認證、授權、組映射以及配額管理，使得Hadoop組件可以使用統一的用戶、組和權限管理模型。
星環大數據安全組件Guardian與hadoop自帶的安全組件區別