爲什麼 Cloudera 要創建 Hadoop 安全組件 Sentry ？
| [日期：2015-02-04] | 來源：明略數據 作者：徐安華 | [字體：大 中 小] |
1. 大數據的安全體系
要說清楚這個問題，還得從大數據平臺安全體系的四個層次說起：外圍安全、數據安全、訪問安全以及訪問行爲監控；如下圖所示；
外圍安全技術多指傳統意義上提到的網絡安全技術，如防火牆，登陸認證等；
數據安全從狹義上說包括對用戶數據的加解密，又可細分爲存儲加密和傳輸加密；還包括用戶數據的脫敏，脫敏可以看做“輕量級”的數據加密。如某人的生日爲“2014-12-12”，脫敏後的數據爲“2014-x-x”。數據的輪廓依然存在，但已無法精確定位數值。脫敏的程度越高數據可辨認度越低。上述的例子還可脫敏爲“x-x-x”，相當於完全對外屏蔽該信息。
訪問安全主要是對用戶的授權進行管理。Linux/Unix系統中用戶-組的讀、寫、執行權限管理堪稱其中的經典模型。HDFS對這一概念進行了擴充，形成了更加完備的ACL體系；另外隨着大數據的應用的普及和深入，文件內部數據訪問權限差異化的需求也變得越來越重要；
訪問行爲監控多指記錄用戶對系統的訪問行爲：如查看哪個文件；運行了哪些SQL查詢；訪問行爲監控一方面爲了進行實時報警，迅速處置非法或者危險的訪問行爲；另一方面爲了事後調查取證，從長期的數據訪問行爲中分析定位特定的目的。
在這四個安全的層次中，第三層同上層業務的關係最爲直接：應用程序的多租戶，分權限訪問控制都直接依賴這一層的技術實現。
2. HDFS的授權體系
在上述的第三層中，Hadoop生態圈長久以來一直沿用Linux/Unix系統的授權管理模型，將文件的訪問權限分爲讀-寫兩種權限（HDFS上沒有可執行文件的概念），將權限的所有者劃分爲三個大類：擁有者（owner），所在組（group），以及其他人（other）。這種模型限制權限的所有者只能有三類。如果試圖增加一個新的“組”，並設定該組的用戶擁有不同於owner，group或other的權限，現有的Linux/Unix授權模型是無法優雅地解決這個問題的。
舉例來說明上述狀況：假設有一個銷售部門，部門經理manager具有修改銷售數據sales_data的權利；銷售部門的成員具有查看sales_data的權利，銷售部門以外的人無法看到銷售數據sales_data。那麼對於銷售數據sales_data的授權如下所示：
- -rw-r----- 3 manager sales 0 2015-01-25 18:51 sales_data
後來該銷售部門擴充了人員，又來兩個銷售經理，一個叫manager1，另一個叫manager2。這兩個銷售經理也被允許修改銷售數據。這種情況下，manager1和manager2只能使用一個新賬號manager_account，然後使該賬號能夠使用setuid對sales_data進行修改。這使得對同一份數據的權限管理變得複雜而不容易維護。
由於上述問題的存在，Hadoop2.4.0中添加了對HDFS ACL（Access Control Lists）的支持。這一新特性很好地解決了上述的問題。然而隨着Hadoop在企業中廣泛地應用，越來越多的業務場景要求大數據訪問控制的粒度也不再侷限在文件級別，而是更加細緻地約束文件內部的數據哪些能被讀寫，哪些只能被讀，哪些完全不允許被訪問。對於基於SQL的大數據引擎來說，數據訪問不止要到表粒度，更要精確到行列級別。
3. Hiveserver2的授權
Hive是早期將高級查詢語言SQL引入Hadoop平臺的引擎之一，早期的Hive服務器進程被稱作Hiveserver1；Hiveserver1既不支持處理並行的多個連接，又不支持訪問授權控制；後來這兩個問題在Hiveserver2上被解決，Hiveserver2能夠使用grant/revoke語句來限制用戶對數據庫、表、視圖的訪問權限，行列權限的控制是通過生成視圖來實現的；但Hiveserver2的授權管理體系被認爲存在問題，那就是任何通過認證登陸的用戶都能夠爲自己增加對任何資源的訪問權限。也就是說Hiveserver2提供的不是一種安全的授權體系，Hiveserver2的授權體系是爲防止正常用戶誤操作而提供保障機制；不是爲保護敏感數據的安全性而設計的。然而這些更多的是某些公司的說辭，事實上Hiveserver2自身的安全體系也在逐步完善，上述問題也在快速修復中。
但授權管理其實不止是Hive需要，其他的查詢引擎也迫切需要這些技術來完善和規範應用程序對數據的訪問。對於細粒度授權管理的實現，很大一部分功能在各引擎之間是可以公用的，因此獨立實現的授權管理工具是非常必要的。
4. Sentry提供的安全授權管理
在這樣的背景下，Cloudera公司的一些開發者利用Hiveserver2中現有的授權管理模型，擴展並細化了很多細節，完成了一個相對具有使用價值的授權管理工具Sentry，下圖是Sentry與Hiveserver2中的授權管理模型的對比：
Sentry的很多基本模型和設計思路都來源於Hiveserver2，但在其基礎之上加強了RBAC的概念。在Sentry中，所有的權限都只能授予角色，當角色被掛載到用戶組的時候，該組內的用戶才具有相應的權限。權限à角色à用戶組à用戶，這一條線的映射關係在Sentry中顯得尤爲清晰，這條線的映射顯示了一條權限如何能最後被一個用戶所擁有；從權限到角色，再到用戶組都是通過grant/revoke的SQL語句來授予的。從“用戶組”到能夠影響“用戶”是通過Hadoop自身的用戶-組映射來實現的。Hadoop提供兩種映射：一種是本地服務器上的Linux/Unix用戶到所在組的映射；另一種是通過LDAP實現的用戶到所屬組的映射；後者對於大型系統而言更加適用，因爲具有集中配置，易於修改的好處。
Sentry將Hiveserver2中支持的數據對象從數據庫/表/視圖擴展到了服務器，URI以及列粒度。雖然列的權限控制可以用視圖來實現，但是對於多用戶，表數量巨大的情況，視圖的方法會使得給視圖命名變得異常複雜；而且用戶原先寫的針對原表的查詢語句，這時就無法直接使用，因爲視圖的名字可能與原表完全不同。
目前Sentry1.4能夠支持的授權級別還侷限於SELECT，INSERT，ALL這三個級別，但後續版本中已經能夠支持到與Hiveserver2現有的水平。Sentry來源於Hiveserver2中的授權管理模型，但卻不侷限於只管理Hive，而希望能管理Impala, Solr等其他需要授權管理的查詢引擎，Sentry的架構圖如下所示：
Sentry的體系結構中有三個重要的組件：一是Binding；二是Policy Engine；三是Policy Provider。
Binding實現了對不同的查詢引擎授權，Sentry將自己的Hook函數插入到各SQL引擎的編譯、執行的不同階段。這些Hook函數起兩大作用：一是起過濾器的作用，只放行具有相應數據對象訪問權限的SQL查詢；二是起授權接管的作用，使用了Sentry之後，grant/revoke管理的權限完全被Sentry接管，grant/revoke的執行也完全在Sentry中實現；對於所有引擎的授權信息也存儲在由Sentry設定的統一的數據庫中。這樣所有引擎的權限就實現了集中管理。
Policy Engine判定輸入的權限要求與已保存的權限描述是否匹配，Policy Provider負責從文件或者數據庫中讀取出原先設定的訪問權限。Policy Engine以及Policy Provider其實對於任何授權體系來說都是必須的，因此是公共模塊，後續還可服務於別的查詢引擎。
5. 小結
大數據平臺上細粒度的訪問權限控制各家都在做，當然平臺廠商方面主導的還是Cloudera和Hortonworks兩家，Cloudera主推Sentry爲核心的授權體系；Hortonwork一方面靠對開源社區走向得把控，另一方面靠收購的XA Secure。無論今後兩家公司對大數據平臺市場的影響力如何變化，大數據平臺上的細粒度授權訪問都值得我們去學習。
6. 引用
- http://zh.hortonworks.com/blog/hdfs-acls-fine-grained-permissions-hdfs-files-hadoop/
- https://cwiki.apache.org/confluence/display/Hive/SQL+Standard+Based+Hive+Authorization
更多Hadoop相關信息見Hadoop 專題頁面 http://www.linuxidc.com/topicnews.aspx?tid=13
來源：明略數據 原文：http://www.mininglamp.com 作者： 明略數據科學家 徐安華