湯定一 韓偉力

(復旦大學軟件學院 上海 200433)

0 引 言

據(jù)IDC估計，到2025年每年將產(chǎn)生163 ZB的數(shù)據(jù)[1]。企業(yè)可以通過數(shù)據(jù)分析得到有價值的信息。例如，大型互聯(lián)網(wǎng)公司收集海量的用戶行為信息用于發(fā)現(xiàn)客戶需求進而提供有針對性的營銷；金融企業(yè)根據(jù)海量歷史交易數(shù)據(jù)訓練欺詐檢測模型以控制風險；醫(yī)療機構(gòu)收集健康數(shù)據(jù)用于生成更好的診療模型。

隨著數(shù)據(jù)在數(shù)量、種類和產(chǎn)生速度方面的增長，需要面向大數(shù)據(jù)的數(shù)據(jù)分析工具。Apache Hive作為基于Apache Hadoop[2]的數(shù)據(jù)倉庫服務(wù)，提供與SQL查詢語言類似的HQL查詢語言，用于方便高效地對海量數(shù)據(jù)進行分析。Hive構(gòu)建在Hadoop 2.x核心組件(Hadoop通用，Hadoop分布式文件系統(tǒng)(HDFS)，MapReduce和YARN)之上，為用戶提供了挖掘數(shù)據(jù)價值的能力。

為保護存儲的數(shù)據(jù)安全，當前Hive訪問控制模型包括以下三種：基于存儲的授權(quán)、基于SQL標準的授權(quán)和Hive默認授權(quán)。(1) 基于存儲的授權(quán)通過HDFS提供一種自主訪問控制模型，雖然能夠保護元數(shù)據(jù)不被惡意用戶破壞，但是沒有提供細粒度的訪問控制。(2) 基于SQL標準的授權(quán)提供了一種基于角色的訪問控制模型。通過SQL語句，可以創(chuàng)建角色，給用戶賦予角色和給角色賦予操作數(shù)據(jù)的權(quán)限。但該模型需要確保用戶僅通過hiveserver2訪問Hive服務(wù)，且必須限制用戶執(zhí)行非SQL語句。(3) Hive默認授權(quán)的設(shè)計目的僅為防止用戶誤操作，而非防止惡意用戶訪問未被授權(quán)的數(shù)據(jù)。

SELinux采用強制訪問控制(MAC)解決自主訪問控制安全性不足的缺陷。Linux自帶的自主訪問控制(DAC)依據(jù)程序擁有者與文件的讀、寫和運行權(quán)限來決定是否允許訪問。使用DAC存在兩個主要問題：(1) root具有最高權(quán)限，文件擁有者可以變更文件讀寫權(quán)限。如果惡意用戶獲取了root權(quán)限，那么他就能對所有數(shù)據(jù)進行惡意操作。(2) 文件擁有者如果錯誤地將文件配置為任何人可讀寫，那么非常容易遭到惡意用戶的攻擊。使用MAC可以解決這兩個問題，通過針對特定程序與特定文件進行權(quán)限管理，使得以root身份運行的程序也不能任意訪問文件，即使文件所有者錯誤地分配了權(quán)限仍可能確保安全，因為每個主體只能根據(jù)域與類型的對應關(guān)系訪問客體。

大數(shù)據(jù)中通常包含大量個人隱私數(shù)據(jù)，例如私人金融賬戶和交易信息、健康診療報告信息等。在處理包含隱私信息的數(shù)據(jù)時，如果在沒有額外保護的情況下將其存放在集群中，將會使所有用戶都能訪問它，從而造成隱私泄露的風險。因此，如果要對隱私數(shù)據(jù)進行分析，必須進行身份驗證和訪問控制。

現(xiàn)有開源工具，如Apache Ranger[3],Apache Sentry[4]，用于提供對包括Hive在內(nèi)的Hadoop生態(tài)系統(tǒng)的細粒度訪問。

Sentry可為存儲在Apache Hadoop集群上的數(shù)據(jù)和元數(shù)據(jù)提供基于角色的細粒度授權(quán)。它的特點是對于每個數(shù)據(jù)庫或框架策略是獨立的，且具有由獨立的管理員維護的能力。它將權(quán)限分配給角色，再將角色分配給組，這樣間接通過組將角色分配給成員用戶。Ranger提供基于訪問策略的授權(quán)模型，由允許訪問控制列表(Allow ACL)和拒絕訪問控制列表(Deny ACL)來描述訪問控制。它的特點是提供了一個可統(tǒng)一控制整個Hadoop集群安全性的管理控制臺。它支持直接將權(quán)限賦予用戶和組。

文獻[5]概括性地將Hadoop原有授權(quán)模型、Apache Ranger和Sentry使用的模型總結(jié)為Hadoop生態(tài)系統(tǒng)訪問控制模型HeAC。該模型直接或間接通過組和角色向用戶分配不同的權(quán)限。在HeAC的基礎(chǔ)上提出了將屬性加入RBAC模型以實現(xiàn)更細粒度的權(quán)限管理[6]。該擴展將屬性引入用戶、組、服務(wù)和數(shù)據(jù)對象。同時，該模型也引入了組層次結(jié)構(gòu)，根據(jù)組上定義的偏序關(guān)系，高級組從低級組繼承角色。文獻[7]也對基礎(chǔ)RBAC模型進行了擴展，在HDFS文件層次結(jié)構(gòu)中抽象出了數(shù)據(jù)組的概念，通過定義不同的數(shù)據(jù)組和其上的繼承關(guān)系，用于簡化多源異構(gòu)數(shù)據(jù)的管理。這些工作和文獻[8-9]均為基于RBAC模型的擴展。

文獻[10]將ABAC模型與原生Hadoop相結(jié)合，提出了一個純ABAC訪問控制模型。通過主體、對象、環(huán)境或上下文來進行訪問控制決策，滿足多個用戶在不同時間、位置和條件下以不同粒度訪問數(shù)據(jù)的安全需求。文獻[11-12]也將ABAC模型及其擴展應用到Hadoop平臺。

綜上所述，現(xiàn)有工作通常都是在RBAC模型和ABAC模型的基礎(chǔ)上進行擴展。然而，在金融和醫(yī)療等對于隱私數(shù)據(jù)的保護有更高安全性要求的行業(yè)中，現(xiàn)有工作沒有給出較好的解決方案。因此，我們提出了Hive上基于類型增強的強制訪問控制模型(TE-MAC)。該模型機制與SELinux[13]采用的類型增強訪問控制機制類似，解決了Hive自帶的DAC模型安全性不足的問題，最大限度地減小用戶可訪問資源的范圍，實現(xiàn)了最小特權(quán)原則。TE-MAC將訪問主體與域關(guān)聯(lián)，數(shù)據(jù)對象與類型關(guān)聯(lián)，授權(quán)規(guī)則由策略文件中域與類型的允許訪問規(guī)則組成。同時，引入了用戶組層次關(guān)系，使得數(shù)據(jù)組擁有的域可以通過偏序關(guān)系繼承，便于結(jié)構(gòu)化管理權(quán)限。

1 SEHive訪問控制模型：TE-MAC

本文提出了在Hive上的類型增強訪問控制模型TE-MAC。此模型將域分配給用戶和組，將類型分配給對象，通過域和類型之間的規(guī)則進行訪問控制。其概念模型如圖1所示。

圖1 TE-MAC模型對象間關(guān)系圖

TE-MAC的基本組件包括：用戶(U)、組(G)、會話(S)、域(D)、類型(T)、數(shù)據(jù)對象(OB)和對象上的操作(OP)。用戶是使用Beeline客戶端通過連接到hiveserver2進行交互以訪問Hive服務(wù)和數(shù)據(jù)對象的人員。組是系統(tǒng)中具有相似組織職權(quán)的用戶的集合。域和類型對應著訪問的主體和客體，域與用戶和組關(guān)聯(lián)，類型與數(shù)據(jù)對象關(guān)聯(lián)。在TE-MAC模型中，制定域到類型允許操作的規(guī)則，以實現(xiàn)類型增強的強制訪問控制。

一個用戶可以屬于由directUG函數(shù)定義的多個組。根據(jù)directUT，用戶可以擁有多個域。同理，根據(jù)directGT，組也可以擁有多個域。OBJECT-PRMS是數(shù)據(jù)對象權(quán)限的集合，它是數(shù)據(jù)對象和操作的叉積的集合。

從用戶到其擁有的權(quán)限可由如下方法得到。首先，用戶通過直接擁有的域或間接通過所屬組擁有的域得到了擁有的域的集合。其次，通過域與類型之間的允許訪問規(guī)則得到了域擁有的OBJECT-PRMS的集合。最后，通過用戶通過域和類型，間接得到了擁有的OBJECT-PRMS的集合。這與基于存儲的Hive授權(quán)不同，其OBJECT-PRMS直接被分配給用戶和組。也與基于RBAC的Hive授權(quán)模型不同，其中通過授予或撤銷用戶角色來給用戶分配或刪除權(quán)限。這反映了TE-MAC模型的優(yōu)勢，可以更靈活地修改用戶擁有的域、數(shù)據(jù)對象對應的類型，同時支持域和類型之間訪問規(guī)則的修改，這對于靈活多變的數(shù)據(jù)組織形式更為方便。

在TE-MAC模型中，域可以直接分配給用戶，也可以分配給組，相比現(xiàn)有的RBAC模型只支持給組分配角色更靈活。組層次結(jié)構(gòu)(TH)被引入系統(tǒng)，G上定義了偏序關(guān)系，寫為≥G。組的繼承關(guān)系從低到高。比如，g1≥gg2表示g1組繼承g(shù)2組擁有的域。在這個例子中，稱g1是資深組，g2是初級組。在組層次結(jié)構(gòu)(GH)中，組的有效域是直接分配給該組的域與其所有初級組的有效域的并集。該定義是遞歸的，其中最初級的組具有相同的直接分配的域和有效域。用戶的有效域是用戶擁有的有效域和用戶所屬組擁有的有效域的并集。

用戶創(chuàng)建的會話(Session)具有用戶的全部權(quán)限。會話需要具有多種權(quán)限，以訪問所需的Hadoop以及Hive中的服務(wù)和對象，但會話對于服務(wù)如Yarn管理器的訪問權(quán)限不在TE-MAC模型的討論范圍。TE-MAC模型的主要優(yōu)點是解決了Hive自帶的DAC模型安全性不足的問題，最大限度地減小用戶可訪問資源的范圍，實現(xiàn)了最小特權(quán)原則。此外，它引入了組層次結(jié)構(gòu)的概念，該概念使得組可以繼承擁有的域并減輕安全管理員的負擔。

1.1 基礎(chǔ)對象和對象間關(guān)系

(1) 用戶(U)表示具有合法訪問Hive服務(wù)的用戶。組(G)表示Hadoop或輕量級目錄訪問協(xié)議(LDAP)中的用戶組。會話S表示通過Beeline客戶端訪問hiveserver2的連接，會話與用戶之間是多對一關(guān)系，即每個用戶可以發(fā)起多個會話，而每個會話對應一個用戶。

(2) 數(shù)據(jù)對象(OB)表示Hive中的數(shù)據(jù)庫、表、列等對象。

(3) 用戶操作(OP)表示Hive中對數(shù)據(jù)對象的操作，包括增、刪、查詢等。

(4) 域(D)可以直接分配給用戶和組，再間接通過用戶和組分配給會話。會話與域之間是多對多關(guān)系，即一個會話可以擁有多個域，一個域也可以被多個會話擁有。類型(T)與數(shù)據(jù)對象是一對多關(guān)系，類型可以對應多個數(shù)據(jù)對象，每個數(shù)據(jù)對象唯一對應一個類型。

(5) 用戶與組的關(guān)系directUG:U→2G，等價地，UGA?U×G。

(6) 用戶與域的關(guān)系directUD:U→2D，等價地，UDA?U×D。

(7) 組與域的關(guān)系directGD:G→2D，等價地，GDA?G×D。

(8) 用戶組的層次關(guān)系GH∈G×G，組的偏序關(guān)系使用≥g表示。令gi和gj為兩個組，如果gi≥ggj成立，則gi繼承g(shù)j的權(quán)限。

(9) 數(shù)據(jù)對象與類型之間的關(guān)系directOBT:OB→T，表示每個數(shù)據(jù)對象與一個類型對應。

1.2 用戶和組的有效域

(1) 組的有效域代表組擁有的域的集合，由組直接擁有與間接通過偏序關(guān)系繼承的域構(gòu)成。定義為：

(2) 用戶的有效域代表用戶擁有的域的集合，由用戶直接擁有與間接通過組擁有的域構(gòu)成。定義為：

1.3 會話的有效域和權(quán)限

(1) 用戶與會話的關(guān)系userSession:S→U。

(2) 會話的有效域effectiveD:S→2D，等價地：effectiveD(s)?effectiveUD(userSession(s))。

(3) 權(quán)限判斷規(guī)則：Authorization(d,t,ops)(s:S,ob:OB,op:OP)=(d∈effectiveD(s))∧(directOBT(ob)=t)∧(op∈ops)。

策略文件中定義的規(guī)則為(d:D,t:T,ops:2OP)三元組，表示允許域以給定的操作方式訪問類型，其中ops表示操作的集合。權(quán)限判斷過程分為兩步：首先得到會話擁有的域集合，以及數(shù)據(jù)對象的類型。其次，在規(guī)則中進行匹配，是否存在這樣一條規(guī)則，使得域d屬于effectiveD(S)，且類型t與數(shù)據(jù)對象的類型directOBT(ob)一致，且該請求的操作op在給定的操作方式集合ops當中。

2 TE-MAC模型的實現(xiàn)

在開源安全工具Apache Sentry的基礎(chǔ)上進行擴展，實現(xiàn)了本文提出的TE-MAC模型。Sentry的主要組件是策略引擎，策略提供器和插件。策略引擎用于根據(jù)策略控制所有對服務(wù)和數(shù)據(jù)對象的訪問。策略提供器用于解析和存儲策略，支持基于文件和基于數(shù)據(jù)庫的策略提供器。插件是綁定到Hive服務(wù)的組件。當產(chǎn)生訪問數(shù)據(jù)對象的請求時，插件將會調(diào)用策略引擎，該引擎將根據(jù)策略提供器中定義的策略對請求進行評估然后做出判斷。如何基于Sentry實現(xiàn)強制訪問控制機制面臨三個主要挑戰(zhàn)：1) 如何使得用戶在訪問時通過TE-MAC機制，而非Sentry原有RBAC策略，這需要系統(tǒng)化的實現(xiàn)。2) 策略如何存儲和維護，Sentry維護的是RBAC的策略，而TE-MAC模型需要維護和提供MAC策略查詢。3) 如何實現(xiàn)SEHive的鑒權(quán)。

對于第1個挑戰(zhàn)，本文在插件組件中重新實現(xiàn)Hive會話鉤子接口以配置訪問控制所需要的屬性。實現(xiàn)Hive權(quán)限驗證接口以重新定義權(quán)限判斷機制和返回結(jié)果過濾機制。對于第2個挑戰(zhàn)，本文在策略提供器中實現(xiàn)提供器后臺接口類，用于加載和解析策略文件。實現(xiàn)列出權(quán)限方法以返回緩存的權(quán)限。對于第3個挑戰(zhàn)，本文在策略引擎組件中，實現(xiàn)策略引擎接口類，用于控制訪問請求。

模型在運行時分為兩個階段，第一個階段是策略制定和加載。安全管理員使用策略文件來制定安全策略，由策略提供器解析策略文件，將策略進行緩存。

第二個階段是鑒權(quán)階段，如圖2所示。當在Beeline上鍵入一個連接到hiveserver2的命令時。該命令經(jīng)過解析器階段和語義分析器階段。然后進入SEHive授權(quán)框架階段。通過在hive-site.xml文件中配置的綁定層(Hive插件)探測到這次請求，將這次訪問的主體和客體傳遞給SEHive策略引擎。策略引擎獲取參數(shù)，從策略提供器中查找與之相關(guān)的規(guī)則，然后判斷主體能否訪問客體。

圖2 HiveQL查詢流程

2.1 插 件

首先配置Hive的會話鉤子(Session Hook)屬性，該鉤子函數(shù)會在用戶通過Beeline客戶端連接到hiveserver2的初始化階段調(diào)用，用于配置授權(quán)所需準備工作。通過實現(xiàn)HiveSessionHook接口類來進行配置。在鉤子函數(shù)中，實現(xiàn)了以下9個操作。1) 開啟Hive授權(quán)驗證，使得每次訪問都經(jīng)過圖2中所示鑒權(quán)流程。2) 配置SemanticAnalizerHook，指定該會話在提交HiveQL請求時調(diào)用的鑒權(quán)方法。3) 設(shè)置DoAS參數(shù)，該參數(shù)決定以會話用戶身份或是運行Hive服務(wù)的用戶身份訪問HDFS。同時，需要相應地在Hadoop配置文件中進行修改以決定是否允許代理。4) 設(shè)置權(quán)限將表的所有權(quán)限賦予數(shù)據(jù)所有者。5) 設(shè)置安全命令的白名單，僅允許用戶訪問安全命令，其中白名單設(shè)置與Sentry相同。6) 對于每個連接用戶，創(chuàng)建一個HDFS暫存目錄，設(shè)置其目錄的權(quán)限為700，即只有會話用戶擁有該目錄全部權(quán)限。7) 配置屬性限制列表，確保安全屬性不被用戶修改。8) 設(shè)置會話用戶，為之后的鑒權(quán)方法做準備。9) 配置作業(yè)屬性為會話用戶，使得Map Reduce任務(wù)的訪問控制列表(ACL)為會話用戶。

其次，實現(xiàn)SemanticAnalizerHook指定的鑒權(quán)方法。這就需要實現(xiàn)HiveAuthorizationValidator接口類中的checkPrivileges方法和filterListCmdObjects方法。其中checkPrivileges方法用于檢查會話用戶是否有在給定的輸入和輸出對象上執(zhí)行給定的操作類型的權(quán)限。filterListCmdObjects方法用于根據(jù)當前用戶的權(quán)限對結(jié)果選擇過濾。首先通過將操作映射到權(quán)限的預定義映射表，將操作轉(zhuǎn)換為對應權(quán)限。然后樹形遍歷訪問列表中的數(shù)據(jù)庫和表，將可訪問的數(shù)據(jù)庫或表作為結(jié)果返回。如果沒有訪問權(quán)限或訪問列表為空將通過拋出錯誤來拒絕訪問。

2.2 策略提供器

策略提供器負責從策略文件中加載和解析策略，然后在數(shù)據(jù)結(jié)構(gòu)中進行緩存，并提供其他模塊可以獲取權(quán)限的方法。需要實現(xiàn)ProviderBackend接口類。其中包含用于獲取域到類型訪問規(guī)則的getPrivileges方法，以及用于獲取用戶所擁有域和數(shù)據(jù)對象所擁有類型的getTypeEnforcement方法。實現(xiàn)PolicyFiles類用于加載和解析基于TE-MAC模型的策略文件。

2.3 策略引擎

策略引擎主要提供判斷訪問是否被允許的方法。根據(jù)傳入的主體，客體和操作所需權(quán)限。首先根據(jù)主體請求策略提供器，得到會話的有效域集合effectiveD(s)。其次，得到客體的類型。最后，在訪問規(guī)則中進行匹配，判斷是否允許訪問。通過實現(xiàn)PolicyEngine接口類的validatePolicy方法，同時該類需要維護ProviderBackend的對象用于獲取權(quán)限。

2.4 策略文件

策略文件共分為4個部分。第一部分描述用戶與域的映射和組與域的映射。它們是多對多的關(guān)系。第二部分描述不同組之間的偏序關(guān)系。組的層次結(jié)構(gòu)可以視為有向無環(huán)圖，每個偏序關(guān)系為圖中的一條有向邊。第三部分描述數(shù)據(jù)對象與類型之間的關(guān)系，每個數(shù)據(jù)對象對應一個類型。第四部分描述訪問規(guī)則，一條規(guī)則包括由域，類型和允許的操作組成的三元組，表示允許域以給定的操作方式訪問類型。

3 SEHive的實現(xiàn)

本節(jié)將Hive置于Hadoop生態(tài)中，站在整體的層面來分析。圖3展示了多層訪問控制決策和執(zhí)行點，用于對包括Apache Hive和HDFS之類的服務(wù)中的資源進行授權(quán)訪問。該架構(gòu)描繪了幾個Apache項目如何協(xié)同以實現(xiàn)SEHive。

圖3 Hadoop整體安全機制架構(gòu)

首先，Kerberos可用于用戶和身份管理以提供身份驗證。

用戶通過身份驗證后，第一層訪問控制機制為服務(wù)層面的授權(quán)。該層控制對Hive等Hadoop生態(tài)系統(tǒng)服務(wù)的訪問，遠早于訪問Hive服務(wù)所提供的數(shù)據(jù)。它還檢查是否允許用戶訪問Hadoop守護程序(例如Hadoop NameNode，YARN資源管理器)以提交任務(wù)或查詢狀態(tài)。

通過服務(wù)層授權(quán)之后，當用戶嘗試通過Apache Hive數(shù)據(jù)服務(wù)發(fā)出HiveQL命令時，被SEHive模型在Hive中配置的插件檢測到，調(diào)用TE-MAC模型中的策略引擎進行鑒權(quán)操作，這是第三層訪問控制機制。由于Hive中的數(shù)據(jù)對象存儲在HDFS中，可以根據(jù)需求配置為兩種模式，其區(qū)別在于用戶是否需要具有HDFS中對象的訪問權(quán)限。因此第四層訪問控制機制為HDFS層面的授權(quán)。

我們通過實際應用場景對這兩種模式進行討論。在模式一中，數(shù)據(jù)分析師可以通過Apache Hive使用HiveQL訪問數(shù)據(jù)，但可能不允許通過MapReduce作業(yè)訪問HDFS中相應的數(shù)據(jù)文件。在這種情況下，發(fā)出HiveQL命令的用戶被更改為運行Apache Hive服務(wù)的用戶。在模式二中，審計員可能需要同時具有Apache Hive和HDFS中對應數(shù)據(jù)訪問權(quán)限。通過配置SEHive的插件組件中DoAS屬性來滿足這兩個用例的需求。假設(shè)Alice是通過會話訪問Apache Hive的用戶，而Bob是運行Apache Hive服務(wù)的用戶。將DoAS設(shè)為false，運行HiveQL的用戶是Bob。對于DoAS為true，Alice在Hive和HDFS上都必須具有訪問數(shù)據(jù)的權(quán)限。

發(fā)出HiveQL命令時，如果SEHive中的DoAS屬性為true，還需要用戶具有訪問YARN隊列的權(quán)限，因為該命令會導致MapReduce或Tez任務(wù)，該任務(wù)也將提交給YARN隊列。由于這些任務(wù)將訪問HDFS中的數(shù)據(jù)，因此用戶也應具有HDFS文件的權(quán)限。

通過這四層安全機制，SEHive通過與其他安全機制集成，能夠?qū)崿F(xiàn)用戶在發(fā)出HiveQL命令時得到保護。確保從身份驗證到訪問Hive服務(wù)授權(quán)，再到訪問Hive中提供的數(shù)據(jù)和HDFS中存儲的數(shù)據(jù)，以及執(zhí)行MapReduce任務(wù)的Yarn隊列在訪問數(shù)據(jù)時的安全。

4 SEHive的評估

本節(jié)通過實驗來說明模型的有效性。實驗在一臺CPU配置為Intel(R)i7- 4790 CPU @ 3.60 GHz，具有32 GB RAM，安裝64位Windows系統(tǒng)的計算機上進行。使用VMware軟件構(gòu)建了3臺Ubuntu 16.04虛擬機，每個虛擬機具有4 GB RAM和單核CPU。每個虛擬機中安裝Hadoop 2.8.1，構(gòu)成一個由三個節(jié)點組成的Hadoop集群，其中一個是主節(jié)點，另外兩個是從節(jié)點。Apache Hive 2.1.1安裝在主節(jié)點上。

4.1 用 例

考慮以下應用場景，Hadoop集群中有三個用戶Alice、Bob和Manager。這三個用戶以不同的權(quán)限訪問同一Hadoop集群中的數(shù)據(jù)。它們都能使用Beeline客戶端訪問Hive服務(wù)。Bob允許查看car database下customer表中的數(shù)據(jù)，以及car database下facilities表中的數(shù)據(jù)，但不能對這兩張表進行修改操作。僅允許Alice訪問car database下customer表中的數(shù)據(jù)，同時可修改該表中的數(shù)據(jù)。但facilities表對其不可見。而他們共同的上級Manager同時擁有他們的權(quán)限。

定義組sale、analyst和manager。其中manager≥gsale，manager≥ganalyst。sale組包含的域為sale_t，analyst組包含的域為analyst_t。根據(jù)組的偏序關(guān)系，manager組包含salt_t和analyst_t域。customer表對應的類型為customer_t，facilities表對應的類型為facilities_t。

權(quán)限定義如下：

策略1：Allowsale_tcustomer_t{getattrreadwrite}

策略2：Allowanalyst_tcustomer_t{getattrread}

策略3：Allowanalyst_tfacilities_t{getattrread}

根據(jù)策略1可知，擁有sale_t域的用戶擁有類型為customer_t的數(shù)據(jù)對象的查看、讀和寫權(quán)限。根據(jù)策略2和策略3可知，擁有analyst_t域的用戶擁有類型為customer_t和facilites_t的數(shù)據(jù)對象的查看和讀權(quán)限。通過組層次結(jié)構(gòu)，簡化了域的分配。

下面通過實驗來驗證模型的有效性。首先在策略文件中配置組的偏序關(guān)系、用戶和組與域的對應關(guān)系、數(shù)據(jù)對象與類型的對應關(guān)系，以及訪問策略。當Hive服務(wù)啟動時，插件從本地策略文件加載策略。

依次使用Alice、Bob、Manager和任意其他用戶，通過Beeline訪問hiveserver2。使用select * from customer和select * from facilities選擇數(shù)據(jù)，其中select需要read權(quán)限。使用load data local inpath’/tmp/tmp_file’ into table customer向customer表中寫入數(shù)據(jù)，其中l(wèi)oad需要write權(quán)限。各用戶執(zhí)行命令成功與否的狀態(tài)如表1所示。實驗表明，TE-MAC能夠最大限度地減小用戶可訪問資源的范圍，實現(xiàn)了最小特權(quán)原則。

表1 各用戶對于表的訪問權(quán)限

4.2 性能評估

本文通過衡量SEHive模型在訪問控制階段所需時間隨訪問控制策略數(shù)量的變化來進行性能評估。

如圖4所示，SEHive模型在訪問控制階段的耗時隨策略數(shù)量增加呈增長趨勢。耗時的增加主要是由于在更多的策略中進行檢索所帶來的。當策略數(shù)量在1 000以內(nèi)時，SEHive耗時在3 ms以內(nèi)。當策略數(shù)量達到10 000條時，耗時20 ms。當策略數(shù)量達到100 000條時，TE-MAC耗時356 ms。而HiveQL查詢耗時通常在秒級別或者更多，因此TE-MAC在訪問控制階段的耗時對查詢總耗時影響較小。

圖4 訪問控制階段時間隨策略數(shù)量變化

5 結(jié) 語

本文針對Hive中如何實現(xiàn)強制訪問控制，提出了TE-MAC模型。該模型采用了與SELinux中類似的類型增強的強制訪問控制機制，將主體與域關(guān)聯(lián)，客體與類型關(guān)聯(lián)，根據(jù)域和類型之間的訪問規(guī)則控制訪問，最大限度地減小用戶可訪問資源的范圍，實現(xiàn)了最小特權(quán)原則。同時，引入了組的層次結(jié)構(gòu)，通過偏序關(guān)系繼承域，便于結(jié)構(gòu)化的權(quán)限管理。本文在Apache Sentry的基礎(chǔ)上實現(xiàn)了SEHive模型。同時，將Hive置于Hadoop中，通過多層訪問控制實現(xiàn)了SEHive。最后，通過實驗分析驗證了模型的有效性，實驗說明SEHive在訪問控制階段的耗時對HiveQL查詢影響較小。