大數(shù)據(jù)平臺上細(xì)粒度的訪問權(quán)限控制各家都在做,當(dāng)然平臺廠商方面主導(dǎo)的還是Cloudera和Hortonworks兩家,Cloudera主推Sentry為核心的授權(quán)體系;Hortonwork一方面靠對開源社區(qū)走向得把控,另一方面靠收購的XA Secure。無論今后兩家公司對大數(shù)據(jù)平臺市場的影響力如何變化,大數(shù)據(jù)平臺上的細(xì)粒度授權(quán)訪問都值得我們?nèi)W(xué)習(xí)。
1. 大數(shù)據(jù)的安全體系
要說清楚這個問題,還得從大數(shù)據(jù)平臺安全體系的四個層次說起:外圍安全、數(shù)據(jù)安全、訪問安全以及訪問行為監(jiān)控;如下圖所示;
數(shù)據(jù)安全從狹義上說包括對用戶數(shù)據(jù)的加解密,又可細(xì)分為存儲加密和傳輸加密;還包括用戶數(shù)據(jù)的脫敏,脫敏可以看做“輕量級”的數(shù)據(jù)加密。如某人的生日為“2014-12-12”,脫敏后的數(shù)據(jù)為“2014-x-x”。數(shù)據(jù)的輪廓依然存在,但已無法精確定位數(shù)值。脫敏的程度越高數(shù)據(jù)可辨認(rèn)度越低。上述的例子還可脫敏為“x-x-x”,相當(dāng)于完全對外屏蔽該信息。
訪問安全主要是對用戶的授權(quán)進(jìn)行管理。Linux/Unix系統(tǒng)中用戶-組的讀、寫、執(zhí)行權(quán)限管理堪稱其中的經(jīng)典模型。HDFS對這一概念進(jìn)行了擴充,形成了更加完備的ACL體系;另外隨著大數(shù)據(jù)的應(yīng)用的普及和深入,文件內(nèi)部數(shù)據(jù)訪問權(quán)限差異化的需求也變得越來越重要;
訪問行為監(jiān)控多指記錄用戶對系統(tǒng)的訪問行為:如查看哪個文件;運行了哪些SQL查詢;訪問行為監(jiān)控一方面為了進(jìn)行實時報警,迅速處置非法或者危險的訪問行為;另一方面為了事后調(diào)查取證,從長期的數(shù)據(jù)訪問行為中分析定位特定的目的。
在這四個安全的層次中,第三層同上層業(yè)務(wù)的關(guān)系最為直接:應(yīng)用程序的多租戶,分權(quán)限訪問控制都直接依賴這一層的技術(shù)實現(xiàn)。
2. HDFS的授權(quán)體系
在上述的第三層中,Hadoop生態(tài)圈長久以來一直沿用Linux/Unix系統(tǒng)的授權(quán)管理模型,將文件的訪問權(quán)限分為讀-寫兩種權(quán)限(HDFS上沒有可執(zhí)行文件的概念),將權(quán)限的所有者劃分為三個大類:擁有者(owner),所在組(group),以及其他人(other)。這種模型限制權(quán)限的所有者只能有三類。如果試圖增加一個新的“組”,并設(shè)定該組的用戶擁有不同于owner,group或other的權(quán)限,現(xiàn)有的Linux/Unix授權(quán)模型是無法優(yōu)雅地解決這個問題的。
舉例來說明上述狀況:假設(shè)有一個銷售部門,部門經(jīng)理manager具有修改銷售數(shù)據(jù)sales_data的權(quán)利;銷售部門的成員具有查看sales_data的權(quán)利,銷售部門以外的人無法看到銷售數(shù)據(jù)sales_data。那么對于銷售數(shù)據(jù)sales_data的授權(quán)如下所示:
后來該銷售部門擴充了人員,又來兩個銷售經(jīng)理,一個叫manager1,另一個叫manager2。這兩個銷售經(jīng)理也被允許修改銷售數(shù)據(jù)。這種情況下,manager1和manager2只能使用一個新賬號manager_account,然后使該賬號能夠使用setuid對sales_data進(jìn)行修改。這使得對同一份數(shù)據(jù)的權(quán)限管理變得復(fù)雜而不容易維護(hù)。
由于上述問題的存在,Hadoop2.4.0中添加了對HDFS ACL(Access Control Lists)的支持。這一新特性很好地解決了上述的問題。然而隨著Hadoop在企業(yè)中廣泛地應(yīng)用,越來越多的業(yè)務(wù)場景要求大數(shù)據(jù)訪問控制的粒度也不再局限在文件級別,而是更加細(xì)致地約束文件內(nèi)部的數(shù)據(jù)哪些能被讀寫,哪些只能被讀,哪些完全不允許被訪問。對于基于SQL的大數(shù)據(jù)引擎來說,數(shù)據(jù)訪問不止要到表粒度,更要精確到行列級別。
3. Hiveserver2的授權(quán)
Hive是早期將高級查詢語言SQL引入Hadoop平臺的引擎之一,早期的Hive服務(wù)器進(jìn)程被稱作Hiveserver1;Hiveserver1既不支持處理并行的多個連接,又不支持訪問授權(quán)控制;后來這兩個問題在Hiveserver2上被解決,Hiveserver2能夠使用grant/revoke語句來限制用戶對數(shù)據(jù)庫、表、視圖的訪問權(quán)限,行列權(quán)限的控制是通過生成視圖來實現(xiàn)的;但Hiveserver2的授權(quán)管理體系被認(rèn)為存在問題,那就是任何通過認(rèn)證登陸的用戶都能夠為自己增加對任何資源的訪問權(quán)限。也就是說Hiveserver2提供的不是一種安全的授權(quán)體系,Hiveserver2的授權(quán)體系是為防止正常用戶誤操作而提供保障機制;不是為保護(hù)敏感數(shù)據(jù)的安全性而設(shè)計的。然而這些更多的是某些公司的說辭,事實上Hiveserver2自身的安全體系也在逐步完善,上述問題也在快速修復(fù)中。
但授權(quán)管理其實不止是Hive需要,其他的查詢引擎也迫切需要這些技術(shù)來完善和規(guī)范應(yīng)用程序?qū)?shù)據(jù)的訪問。對于細(xì)粒度授權(quán)管理的實現(xiàn),很大一部分功能在各引擎之間是可以公用的,因此獨立實現(xiàn)的授權(quán)管理工具是非常必要的。
4. Sentry提供的安全授權(quán)管理
在這樣的背景下,Cloudera公司的一些開發(fā)者利用Hiveserver2中現(xiàn)有的授權(quán)管理模型,擴展并細(xì)化了很多細(xì)節(jié),完成了一個相對具有使用價值的授權(quán)管理工具Sentry,下圖是Sentry與Hiveserver2中的授權(quán)管理模型的對比:
Sentry的很多基本模型和設(shè)計思路都來源于Hiveserver2,但在其基礎(chǔ)之上加強了RBAC的概念。在Sentry中,所有的權(quán)限都只能授予角色,當(dāng)角色被掛載到用戶組的時候,該組內(nèi)的用戶才具有相應(yīng)的權(quán)限。權(quán)限à角色à用戶組à用戶,這一條線的映射關(guān)系在Sentry中顯得尤為清晰,這條線的映射顯示了一條權(quán)限如何能最后被一個用戶所擁有;從權(quán)限到角色,再到用戶組都是通過grant/revoke的SQL語句來授予的。從“用戶組”到能夠影響“用戶”是通過Hadoop自身的用戶-組映射來實現(xiàn)的。Hadoop提供兩種映射:一種是本地服務(wù)器上的Linux/Unix用戶到所在組的映射;另一種是通過LDAP實現(xiàn)的用戶到所屬組的映射;后者對于大型系統(tǒng)而言更加適用,因為具有集中配置,易于修改的好處。
Sentry將Hiveserver2中支持的數(shù)據(jù)對象從數(shù)據(jù)庫/表/視圖擴展到了服務(wù)器,URI以及列粒度。雖然列的權(quán)限控制可以用視圖來實現(xiàn),但是對于多用戶,表數(shù)量巨大的情況,視圖的方法會使得給視圖命名變得異常復(fù)雜;而且用戶原先寫的針對原表的查詢語句,這時就無法直接使用,因為視圖的名字可能與原表完全不同。
目前Sentry1.4能夠支持的授權(quán)級別還局限于SELECT,INSERT,ALL這三個級別,但后續(xù)版本中已經(jīng)能夠支持到與Hiveserver2現(xiàn)有的水平。Sentry來源于Hiveserver2中的授權(quán)管理模型,但卻不局限于只管理Hive,而希望能管理Impala, Solr等其他需要授權(quán)管理的查詢引擎,Sentry的架構(gòu)圖如下所示:
Sentry的體系結(jié)構(gòu)中有三個重要的組件:一是Binding;二是Policy Engine;三是Policy Provider。
Binding實現(xiàn)了對不同的查詢引擎授權(quán),Sentry將自己的Hook函數(shù)插入到各SQL引擎的編譯、執(zhí)行的不同階段。這些Hook函數(shù)起兩大作用:一是起過濾器的作用,只放行具有相應(yīng)數(shù)據(jù)對象訪問權(quán)限的SQL查詢;二是起授權(quán)接管的作用,使用了Sentry之后,grant/revoke管理的權(quán)限完全被Sentry接管,grant/revoke的執(zhí)行也完全在Sentry中實現(xiàn);對于所有引擎的授權(quán)信息也存儲在由Sentry設(shè)定的統(tǒng)一的數(shù)據(jù)庫中。這樣所有引擎的權(quán)限就實現(xiàn)了集中管理。
Policy Engine判定輸入的權(quán)限要求與已保存的權(quán)限描述是否匹配,Policy Provider負(fù)責(zé)從文件或者數(shù)據(jù)庫中讀取出原先設(shè)定的訪問權(quán)限。Policy Engine以及Policy Provider其實對于任何授權(quán)體系來說都是必須的,因此是公共模塊,后續(xù)還可服務(wù)于別的查詢引擎。
5. 小結(jié)
大數(shù)據(jù)平臺上細(xì)粒度的訪問權(quán)限控制各家都在做,當(dāng)然平臺廠商方面主導(dǎo)的還是Cloudera和Hortonworks兩家,Cloudera主推Sentry為核心的授權(quán)體系;Hortonwork一方面靠對開源社區(qū)走向得把控,另一方面靠收購的XA Secure。無論今后兩家公司對大數(shù)據(jù)平臺市場的影響力如何變化,大數(shù)據(jù)平臺上的細(xì)粒度授權(quán)訪問都值得我們?nèi)W(xué)習(xí)。
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