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. 引用