一、Apache Ranger介紹

1、總體介紹

Apache Ranger是Hadoop生態中的一個安全解決方案，它通過在各個組件中集成Ranger 的插件，用中心化的 Ranger Admin來控制所有的policy，插件通過同步policy到本地緩存來提供鑒權的能力。

上方右圖是Ranger 的能力列表?？梢钥吹?Ranger 的各種能力，包括管理行級權限，tag base policy，列級權限，列級過濾，列級脫敏等等能力。

接下來看一下Apache Ranger的優勢在哪里。

安全體系的5A 理論中， Ranger可以解決其中訪問控制、監察審計以及鑒權授權這三塊，解決起來的核心優勢有四點：

第一個優勢是它集成了多個大數據組件鑒權插件，比如Hive、Spark、Presto 等等一大批主流引擎的鑒權的插件。插件對組件做了非常多的適配。如果使用Ranger，可以把所有引擎的鑒權收攏由安全團隊統一負責管理。如果不用Ranger，大概率是每個團隊獨自管理各個組件鑒權邏輯，這樣比較分散，也會增加團隊之間溝通的成本。

第二個優勢是它有較好的鑒權性能，Ranger針對policy緩存構建了大量的索引，可以很好到應對 NN 這種實時性要求高的服務。對于NN來說鑒權幾毫秒和幾百毫秒會有很大差距。

第三個優勢是它有非常靈活的鑒權能力，除了 RBAC以外，還提供 ABAC 的能力。同時還有 deny、exclude語義，鑒權非常靈活，支持的權限模型也比較多。

第四個優勢也是最關鍵的一點，是我們調研發現，業內的 CDP 7.0 之后，整體的權限方案都切換為Ranger，包括業內的一些存儲引擎，比如alluxio等等也都在集成Ranger。因此我們有了一個基本的判斷，就是在大數據的生態， Ranger已經基本成為一個事實上的標準或者是一個業內主流的發展方向了。為了以后社區安全的新功能更好的集成，我們需要去緊跟Ranger。

左圖可以看到Ranger對所有 policy 的資源都做了一個壓縮的字典樹的索引，極大地提高了針對policy的查詢效率。在我們內部的實踐中，在5~6萬 policy 的情況下，namenode 鑒權依然可以達到毫秒級，性能非常高。

另外Ranger 同時支持 RBAC 和ABAC 兩種模型。

這里簡單介紹一下兩種模型：

RBAC 模型是一個最常用的通過角色來管理資源的權限管理模型，這種模型比較簡單，也比較常用。ABAC模型是用戶資源以及上下文都會帶有屬性，最終的權限根據屬性計算得來，這種模式比較靈活。深入觀察可以發現 RBAC 其實是 ABAC的一種特殊情況，因為可以把角色當成一種特殊的屬性。ABAC的優勢在于可以讓權限做得更精準，比如可以允許所有網易員工早上9點到10點之間訪問某個資源，或者是一個IP 段在某個時間點可以訪問某個資源。這都是Ranger所支持的一些能力。所以我們可以看到Ranger的能力還是比較強大的。

2、整體評估

前文介紹了Ranger的優勢，不過僅用Ranger是無法完全解決企業中的大數據安全的問題。一個好的安全平臺需要做到五點。

• 第一點是安全性，我們需要的是既防君子、也防小人的安全平臺，它不同于一般的業務平臺主要考慮易用性，還要考慮被惡意攻擊或者繞開的問題。
• 第二點是精準性，也就是最小權限原則，能不能給一個用戶最小權限，這個權限既不放大也不縮小。權限放大指的是，比如本來不需要給用戶某個權限，但是系統架構導致不得不給他額外的授權才能去訪問權限。權限縮小一般都是鑒權邏輯導致的問題，比如本來只需要 a 資源權限，但是鑒權邏輯或者權限體系有問題，導致還鑒了另外一個資源的權限，這個時候就得 a 和 b 一起申請才能用。權限系統設計越精準，權限管控越有效。
• 第三點是管理性，是否有利于管理員對整體的企業內部權限有全方位的了解。比如想知道一個資源有哪些人能訪問，或者是想知道一個用戶能訪問什么資源，或者想知道權限快到期的資源有哪些等等。能夠支持檢索的維度越多, 管理性越強，管理員的權限管控體驗越好。
• 第四點是效率，比如管理員授權操作鏈路是否復雜，有大量用戶需要授權時是否高效，是否需要專人管理賦權，普通用戶能否快速獲取到需要的權限等。效率過低，會大大增加管理員的成本，且普通用戶也會感覺這套體系很難用，從而拖慢開發的節奏，最終不得不通過犧牲精準性來提高效率。
• 第五點是性能，即鑒權要占用多少資源，要耗費多少時間等等。增加權限后對于整個系統的性能一定是有所下降的，關鍵看這種影響的程度。

我們來一一對照，看看 Ranger 在這五點上面的表現如何。

第一點安全性。整體而言Ranger 的安全性是比較好的，因為 Ranger 是一個內存鑒權的機制，同時Ranger 的服務端集成了SSL認證。假設操作系統、Kerberos認證、網絡都是安全的，那么我們認為Ranger是很難被繞過的，即使繞過，成本也是非常高的。當然原生Ranger對Spark權限的管理是比較弱的，后面會詳細分析。

第二點是精準性。Ranger 的權限生命周期落在 policy 上面，每條 policy 可能會包含非常多的對象，不同的對象可能生命周期又是不同的。使用Ranger這套體系時policy 的生命周期只能按照下面所有授權對象中最大的生命周期來算，否則就會有權限縮小的問題。這種情況導致精準性有所欠缺。另外ranger對于HDFS 刪除權限包含在寫權限中，沒法只授權寫而不授權刪除。而刪除比一般的寫風險更大所以刪除權限應該要比寫權限或者創建權更高，因此可以認為ranger在這點上的精準性也有缺陷。

第三點是可管理性。這一點上Ranger的表現是比較差的。Ranger 的一個特點是，只能根據資源去搜policy，在 policy 中可以搜出它的訪問控制列表，但是用其它維度搜索很困難。如果要搜索一個用戶所擁有的權限，就必須先把相關所有的 policy 搜出來，再從 policy 中解析出需要的信息。在policy 數量非常大的時候，這種分頁查詢會受到諸多的限制。再如脫敏的時候，Ranger 的脫敏規則是，policy根據優先級排列，排在前面的優先，排在后面的優先級依次降低。我們很難推斷一個用戶對某個資源的脫敏規則，因為角色非常多，很難去分析脫敏的整體情況。

第四點效率性。Ranger 也是相對較差的，因為Ranger的體系是依賴于管理員來進行操作的，普通用戶是沒有任何入口的。Ranger的體系整體上是一個管理員視角的工具，如果用戶需要一個權限，只能通過管理員登錄Ranger搜索并修改policy。而Ranger 頁面搜索性能很低，搜索結果還要再編輯，整體授權鏈路是很長的。如果一天有很多用戶需要申請權限，會非常低效，尤其是團隊擴大的時候，低效更加明顯。

第五點性能。 前面分析過Ranger 的鑒權性能非常好，但 Ranger policy 對內存占用是較大的，因為 Ranger 是全量的緩存policy，內存占用大的情況不僅僅是絕對的數值比較大，由于 Ranger 的policy的生命周期比較短的，10 秒、15 秒到 30 秒會全量更新一次，會形成非常多短生命周期的內存。比如1G 的內存雖然不算太大，但是1G內存每 10 秒鐘都會被全量更新一次，這種情況就會對內存的壓力以及 JVM調優產生較大的影響（ranger 2.x之后提供了增量更新，但是還不太成熟容易漏policy）。

從以上分析可以看到 Ranger 的優勢以及不足。眾所周知，安全性、精準性與管理性、效率、性能必然是矛盾的，如果做得很安全，很精準，那么往往會導致管理性、效率和性能的下降。而管理性、效率、性能很優秀的時候，又必然對安全性和精準性有一定的損失。我們要做的是把這五方面統籌起來，尋找到一個平衡點。

二、大數據安全中心整體解決方案

1、平臺歷程

前文中介紹了 Ranger 的優缺點，接下來將介紹網易內部是如何解決這些問題的。首先整體介紹一下網易內部大數據平臺安全的發展歷程，它主要經歷了三個階段，具體如下圖。

（1）階段一

第一個階段是 2009 年到 2014 年的一個初始階段。在這一階段是采用 Ranger 加 kerberos 加 ldap 去管理權限。Ranger 直接當產品使用，就在Ranger頁面上去管理Hadoop集群的權限，其整體就是一個Hadoop的權限工具。

（2）階段二

第二個階段是 2014 年到 2021 年，這個階段的安全管理是數據中臺的一個權限模塊。這個階段數據中臺對接了Ranger，進行了一些角色用戶到中臺資源的映射，也構建了一些資源多租戶隔離的權限管理方案。這個階段 Ranger 基本上跟數據中臺有了一定的聯動，效率得到了一定的提升，但還是存在一些問題。

（3）階段三

第三個階段是 2021 年到現在，我們構建了一個獨立的一站式權限管理平臺。它不僅僅是權限管理平臺，更是一個安全管理平臺，擁有權限脫敏、審計監控、數據掃描識別等多種功能，包括以后的加解密等等。同時我們還做了一個大動作，就是把內部的Ranger從 0. 5 版本升級到 2. 1 版本。

2、整體方案

下圖是整體的產品方案圖。

可以看到我們的產品基本上覆蓋了安全生命周期中的所有流程，還有一些權限申請、操作審計、行為識別、權限轉移、權限釋放、數據脫敏、數據加密、白名單等等功能。最后面我們對數據和操作進行了分類分級。下圖是一個整體的技術架構，這也是本文要重點分享的。

我們的技術架構基本上分為三層，最下面一層為Hadoop集群，采用多Hadoop集群的模式，各個集群之間網絡都可能是隔離的。中間是服務層，數據平臺就構建在這一層，主要包括安全中心、Ranger和一些插件。最上面一層是業務層，包括了剛才產品中提到的授權審批、白名單、凍結目錄以及一些定時任務等功能。

這套體系中比較重要的一個點就是對客戶端的鑒權，比如Spark和Hive的鑒權，采用了自研的plugin。plugin把內存的鑒權轉成了網絡請求，這樣就不用再去緩存過多的內存。同時增加了hive metastore 插件，去根據ddl同步進行Ranger中的權限變更。

對于 Hive server， Impala 以及 namenode，我們基本上采用的是原生的方案，因為對于一個服務來說，內存稍微大并不會產生太大影響。但是Ranger的插件也是經過一些優化的。中間這一層首先對 Ranger admin 進行了一個垂直拆分，比如一個Ranger可能管理若干個集群，且有多個Ranger，這種模式安全中心會將集群路由到指定的Ranger，同時安全中心也會緩存一份policy來做一些鑒權的操作。對于頂層，是一些業務邏輯和提供的能力。

這套架構有四個核心的思路。

（1）低耦合

首先，對 Ranger 的開發，一定要是低耦合的開發。因為過度耦合在軟件工程層面會削弱變更的穩定性。我們不依賴Ranger的policy格式和弱字段做業務邏輯。只能依賴 policy 的語義，只要Policy的語義是一樣的，上層的邏輯就必須是一樣的。比如Ranger的一個 policy 有三個 item另外一個policy有兩個item，但是兩條policy表達的含義是一樣的，此時上層的邏輯也必須是一樣的。另外policy 中有些弱字段，比如policy描述字段description，這種描述字段不能用它去做強邏輯，只能做展示邏輯。這是我們總結出來的一個比較重要的經驗。

這么做的目的首先是不搞約定式的邏輯能夠讓代碼在多個人之間更好維護。同時Ranger admin也可以獨立使用，以達到低耦合。否則如果過度耦合，Ranger admin 就相當于變成了一個類似于數據庫的存儲服務，也就無法對用戶暴露出來，只能用我們的平臺去管理權限。在我們的實踐中，尤其是ToB商業化的過程中，這種情況是不現實的，有些用戶對ranger理解可能比較深入，就不期望這樣。

（2）低侵入

第二個就是低侵入，就是盡量不去修改Ranger 本身的代碼，原因之一是 Ranger 服務端代碼是比較老舊的， Ranger采用的還是jpa的一些數據庫框架，包括Spring版本都是很老的，這些老舊框架對研發效率的折損是較為嚴重的，我們現在的微服務等后端技術框架日新月異，如果還用這種老的框架，會導致整體的研發效率大打折扣。其二，如果我們把大量業務邏輯注入在Ranger中，會導致Ranger很難升級，尤其是大版本的升級,比如剛才談到的，從0. 5版本升級到2. 1版本，成本將非常高。

（3）流量分攤

第三個是一定要做好流量的分攤，不能把所有的流量都打到 Ranger admin 上面，因為Ranger admin 的接口內部有一些緩存更新機制，這些機制都是會加鎖的，在流量增大的時候，鎖沖突就會非常嚴重，這時Ranger admin的性能降低，會導致上層業務超時等問題影響客戶使用，所以我們要遵循一個核心思路，讀的請求盡量不要直接打到Ranger admin上面，盡量做一些額外的緩存策略或者是一些索引策略。Ranger本身其實可查詢的維度也不夠豐富，如果把所有數據都放到內存里面再去慢慢查，內存消耗將過大。

（4）一致性保證

最后一點就是要保證一致性，比如中臺和Ranger之間先調用了中臺去存儲一個權限，然后再去將權限存儲到Ranger的時候失敗了，這樣就可能導致中臺與Ranger的數據不一致，體現到用戶視角就是在中臺中看到有權限， Ranger中卻沒有權限。因此一致性是一定要考慮到的，不能只考慮中臺操作和ranger同時成功的情況，還要考慮部分成功，部分失敗的情況，這樣才可以保證系統可用性，提高用戶體驗。

三、關鍵技術解析

接下來將介紹10個比較有特色的設計細節。

1、統一權限檢索問題

上文討論的Ranger的資源，其原生的權限模型有很多優勢，但是也存在一些劣勢。比如我想知道一個人具備哪些權限，一個脫敏算法到底被哪些地方用到了，這些都是沒法搜索的，用戶粒度的權限生命周期也沒法設置。針對這個問題，網易內部搭建了一層權限檢索模型，如下圖。

權限檢索模型是一個純粹只讀的視圖，基于Ranger的 change log進行一個變更的同步，比如 30 秒進行一個變更的同步，同步過來后，會把policy 解析成我們需要的搜索維度和格式存放到在我們的權限模型中，所有的查詢接口都通過我們的權限模型，Ranger admin只做寫的入口。比如業務層要授權，要申請審批，之后權限調整，修改脫敏規則等等這些修改的操作都只會操作Ranger admin ,保證是單寫的，不會去先在中臺寫一份，Ranger再寫一份。從而避免上文說的雙寫不一致的問題。通過這種異步的同步機制，雖然查詢可能會有 30 秒的延遲，但是可以保證最終的一致性。

Ranger change log 是2.x版本才推出的一個特性，它記錄了所有的policy增刪改查的事件，這些變更日志存在一個數據庫里面，通過一個接口去拉取。通過這套方案既能保證最終一致性，又能在此基礎上極大地提高查詢性能，而靈活的查詢又使得產品體驗提升。各個維度的權限數據用戶都可以去檢索，前面舉例提到的，一個人有哪些權限、哪些權限要到期了等等問題，都可以便捷搜索到結果，管理員對權限整體上有很全面的了解，體驗非常好。同時權限生命周期也使用這套權限模型來實現，可以達到精細化的設置權限生命周期的目的。

2、鑒權優化&多集群

我們在實踐中發現1萬條 policy 基本上占用內存在 100- 200 M之間，如果有幾萬條，甚至上 10 萬條，量就非常大。再加上，Ranger admin緩存了一份全量的policy，導致policy 多的時候GC會有一個很長的停頓時間。另外在 client 模式下，一臺機器可能會起多個client，每一個 client 如果按照Ranger的原生模式，都會緩存一份 全量policy 到內存,這種情況下內存的損耗在多個client中是疊加的，我們的解決方案是做一個內存轉網絡的鑒權方案，統一把這種 client 模式的鑒權轉成了網絡的方式，如下圖。

第二個改進是，我們對Ranger進行了垂直拆分。以前一個Ranger管理了多個集群，Ranger中一個 service 對應的就是一個集群，一個service其實就是對應一套元數據，一套元數據約等價于一套擁有唯一的Hive metastore的hadoop集群。我們對Ranger進行了垂直拆分，比如我們內部現在有九個集群，有三個Ranger來支撐，一個Ranger只管三個集群，這樣單個Ranger的 policy 數量就下降了，GC 時間就得到了控制，Ranger admin 的性能也得到了保障。

這兩個思路其實都不復雜，但是我們實踐中還是遇到了不少的小問題。比如第一個問題是內存轉網絡的時候，如果服務端不可用，任務會不會受到影響，這涉及到高可用的問題。第二個問題是請求的性能問題，同機房的調用在我們的實踐中基本上就是幾毫秒，但是我們在對外商業化的過程中遇到了一個情況，存在有跨國的機房，甚至跨洲的機房，比如印度機房調用中國的機房，或者是歐洲的機房調用中國的機房。這種跨洲調用過程中，網絡的延遲就會非常明顯。我們之前是每一列都會去調用的，現在發現調用次數還是比較影響性能的，多個請求必須要壓縮成一次調用，需要去優化，尤其是對于Spark，由于執行計劃優化的不同周期中沒有通信所以容易存在重復鑒權的情況。

3、鑒權請求報文體優化

我們是把Ranger插件改造成了遠程鑒權的模型，大部分的修改是基于以前ranger插件代碼去修改的。改造過程中如果圖省事，可能直接把以前內存的一些參數轉成網絡的參數，但這會帶來很大的性能問題。因為Ranger鑒權內存參數很大，一個報文體可能就有幾Mb，如果并發QPS有幾百上千的時候，內存消耗非常快，實踐中發現一個大寬表可能對應鑒權報文有4-5Mb。對這種報文體是必須要進行優化的，如果還是用 Ranger原生的內存鑒權報文就會太大，對性能損耗也會很大。

4、凍結目錄

2019 年，我們內部一些重要庫的 HDFS 路徑被誤刪。雖然誤刪之后，因為HDFS有一些垃圾回收站等機制，最終數據還是能恢復過來，但恢復的過程非常吃力，另外恢復過程中基本數據是不可用的，對業務的可用性影響很大。

除了組織上權限管理的問題以外，前面也提到過我們認為Ranger最大的一個缺陷就是它對目錄的delete、 rename 這種刪除、重命名操作的權限是含在其寫的權限中的。這就可能存在一些隱患，因為刪除權限級別本身應該是高于寫的。我們的解決方案比較簡單，就是把 HDFS 中的delete、 rename 這兩個 action 單獨抽離出來進行鑒權，不合在寫的權限里面，最終我們的實現效果也是明顯的。內部的核心庫得到保護，路徑不會再被誤刪。

5、動態脫敏

為什么要增強ranger的動態脫敏？這里舉了兩個例子。第一個是如果一個數倉中有 100 列都是電話號碼，開始是把電話號碼全部配成了遮蓋脫敏，突然需要電話號碼把前三位露出來，只對后面的幾位數字脫敏，這種情況下，原生的脫敏規則管理員可能就要改 100 次，成本很高。如果下次又要把電話號碼的前四位露出來，又需要改 100 次。第二個是 Ranger 的policy沒法作用在一個范圍上（只能作用在具體的列上），導致無法配置對指定庫不脫敏，如果需要配置管理員角色對一批庫不脫敏，在原生的Ranger，至少 2. 1 版本的Ranger中是沒法做到的。

我們認為第一個問題的主要原因是Ranger沒有對規則的泛化能力必須指定一個具體的UDF函數。我們對Ranger 插件進行了優化，它不再依賴于一個具體的 UDF 函數，而是依賴一個泛化脫敏規則。比如我的一個脫敏規則就叫「電話號碼脫敏」，它是一個泛化的規則，具體如何脫敏不確定。對電話號碼的列，就配置為「電話號碼脫敏」，具體對應的脫敏的UDF細節是可變的。脫敏的時候插件首先通過policy找到對應脫敏規則的ID，然后去服務端請求把 ID 換成具體的脫敏實例。最終吐給計算引擎的時候，再把它轉成一個具體 UDF 的格式，這樣就可以達到上文描述的效果。

第二個問題，我們認為Ranger的脫敏規則管理是有一定缺陷的。上圖的左邊可以看到Ranger原生的管理是通過優先級進行管理的，一列可有多個優先級不同的脫敏規則，排在最上面的優先級最高，比如角色a用規則1脫敏優先級最高，角色b用規則2脫敏優先級其次，當然這樣是很靈活，但是管理成本也是非常高的，尤其是當用戶在多個角色中的時候實際走到的是哪條規則情況就較為復雜。

我們的方案是把它轉成了一種白名單的方式，比如配置a、b、c用戶是白名單，不需要脫敏，對其余所有的用戶都是用規則1脫敏這張表，這樣我們只用去管理白名單的機制就可以了，用戶也可以去獨立申請白名單。

此時白名單只有兩層優先級的概念了。白名單優先級是大于脫敏的，只要在白名單中，肯定不脫敏，退出白名單，肯定會脫敏。這樣邏輯就簡單化了，雖然可能略微喪失一定的靈活性例如不同角色有分級的脫敏規則，但是實踐中發現該方案才是產品中實際能被用起來的一種方案，為了實現該目地需要修改對應的ranger 插件中脫敏policy匹配相關代碼，加入范圍的脫敏規則（例如配置在庫.*下的規則）匹配，以便實現在一個范圍下配置白名單效果。

我們優化的最終效果就是脫敏的易用性得到了提升，同時掃描和脫敏是一體化的，從圖右邊可以看到，掃描任務可以自動地把掃出來的敏感類型推到脫敏里面去。掃描脫敏的一體化能夠使得產品體驗得到很好的提升，這也是單一ranger做不到的。

6、審計和治理

這其實對于權限管理是一個老生常談的問題了，做過權限的同學可能都會遇到一個問題就是用戶突然找過來說：“我之前有權限，怎么突然就沒有了，你幫我加一下”。這個時候可能研發只能幫用戶把權限補上去了，但是也不知道什么原因。第二個問題是有多少權限是無效權限？權限授了，系統里面很多權限也沒什么問題，但是到底有多少有用，很難判斷。Ranger 也不好解決這兩個問題，因為它沒有一個全資源視角的審計，對 policy 變更的審計，只能是 policy 的視角，在 policy 刪除重建等操作時就審計不到。同時它也沒有一個 item 視角的層級，具體一個人到底是通過角色還是通過個人權限訪問的資源是無法審計到的。

我們的解決方案就是針對這個問題，首先把權限模型和用戶角色變更同步一份到數倉里去分析追蹤。同時我們在Ranger審計插件的審計模塊中做了一些改動,首先把 policy 鑒權過程中的命中信息發送到 Kafka 中去進行維度的補充，跟中臺的維度進行了打通，這樣我們審計可以提供所有的權限變化追蹤，同時我們還補了一個角色命中的信息，通過什么角色去訪問的信息也很重要。在治理中，通過維度的補充這個過程，我們就可以把它細化到具體的人或角色了，根據它給我們的原始數據的policy id，我們會把它拆成具體用戶是通過哪一條item，哪一個具體的權限去訪問的一個表，我們的細粒度就可以解決這個問題。

方案的最終效果明顯，我們在內部定位發現，用戶經常刪表重建，重建后的表就沒了訪問權限，我們就清楚了這個問題的答案。同時我們發現內部有 70% 的權限是半年都沒有用過的權限，這個比例是非常大的。但是無效權限或者冗余權限能不能直接回收，這是另外一個問題，可能冗余權限不一定就完全可以直接回收，我們還在實踐過程中。

7、權限的ownership

Ownership指的是表的負責人自動對表有所有權限，而不需要額外用 policy來授權。我們經常遇到的一個問題是用戶反饋我建的表為什么不能刪除，但Ranger原生的ownership機制并不完備，因為社區的 Hive 4.0 之后才集成了Ranger原生的 ownership，而Impala 應該是在較早的版本就集成了。所以 ownership 是一個比較棘手的問題。

我們的解決方案是基于元數據中心的 owner 的補充。我們會從鑒權的時候，去請求一個元數據中心，也就是內部的元數據系統，補充 owner 的信息，然后再走 Ranger原生的ownership鑒權邏輯。

為什么要走元數據中心，不能從底層組件把 owner 帶過來？因為我們遇到過，低版本的Spark尤其是 2.3 版本以下，會對表 owner 的元數據進行污染。Hive meta store 里面的 owner 字段會被低版本的 Spark 污染。因此從上層來解決能夠提供更好的兼容性。

同時還有一個困難點是 HDFS 的 owner 問題。原生的 HDFS owner權限其實不包含遞歸屬性，但是表的 owner 對表的路徑應該是有遞歸的權限的，否則表下面的分區就不一定能訪問，但是原生的 HDFS 的權限（acl）或者原生Ranger，都沒法支持路徑的遞歸的owner語義。

針對這個問題，我們對NN的鑒權插件進行了一個擴展，可以看到上圖圖左下面，上面 owner 是原生的owner，下面 recursive owner 是我們在Ranger上面新增的owner。recursive owner的含義就是這個路徑的 owner對這個路徑具有遞歸的訪問權限。

實現的方案略微有點復雜。鑒權請求中的路徑首先命中了一條 policy 之后，把所有的「請求路徑」到「policy資源路徑」之間的「祖先」owner 算出來，例如上圖右圖中的user2、user3、user4為「祖先」owner。然后通過「祖先」 owner 去跟當前請求的被鑒權用戶匹配，如果「祖先」 owner包含被鑒權用戶則命中item中的recursive owner占位符，然后再看recursive owner 的item有什么權限就返回相應的結果。要對 Ranger 的插件進行一些修改，主要是NN的插件進行修改。通過這些手段我們就達成了一套很完備的owner語義。同時我們的表負責人對路徑的權限也得到了增強，不存在表負責人對表路徑只有非遞歸的權限了，目錄下的子目錄的權限都可以被繼承。

最后一個點是Ranger的 policy 數量也會下降，因為以前的這種體系沒有 owner 語義。其實我們每張表是有一條 policy 去表征其owner 的權限。在表的數量大的時候， policy 數量也很大。有了 owner 語義后，一條 policy 就可以表示出來所有的 owner 都有對應表的權限。

8、Spark權限/脫敏

Ranger原生是不支持 Spark 的，我們通過一些介入 Spark 的執行計劃的過程來實現權限脫敏。首先是 Spark 的執行計劃有四個階段，在解析這個階段又分為 analyzed執行計劃和 optimized 執行計劃，我們的動態脫敏和行級權限，其原理就是去修改 analyzed 執行計劃，在該analyzed階段中添加 filter 和脫敏函數，其實就是添加UDF。

鑒權是通過 optimized 階段執行計劃的一個輸入輸出提取去鑒權。但是在這種思路下有一些難點需要去處理，比如Spark每一個優化的階段是反復執行的，不是一次優化就結束的。所以該思路存在階段通信的問題，比如此階段已經執行過脫敏了，下一個階段再進 analyzed 的時候，就不能再脫敏了。權限其實也是一樣的，只需要鑒權一次。這種階段之間通信需要一個溝通或者通信的機制。其次就是視圖的處理，Spark視圖權限整體是比較復雜的，需要單獨處理。

最后一個要點是這三者之間的優先級關系，行級權限和脫敏的優先級，到底是先脫敏之后再走行級權限，還是用原文去走行列權限再脫敏，這些都是實踐中會遇到的一些問題。當然，目前問題我們也都已經解決了?？梢钥磮D右邊的執行計劃代碼。其中紅色的部分是一個脫敏的執行計劃修改，藍色的部分是一個行級權限的執行計劃修改，橙色的部分是我們插入用來階段之間溝通的虛擬節點，只要遇到這個節點，就認為執行計劃已經被處理過了。可以看到我們是把行級權限放在最下面的，所以我們是要先過行級權限再過脫敏的，這樣也是比較合理的。我們的最終效果是Spark 與 Hive以及Impala 權限脫敏實現統一管理，不再需要多次授權。這樣，便利性和安全性都得到了提升。

9、Ranger社區優化

可能做Ranger的同學會比較感興趣，如果深入去做產品化會發現Ranger 的小 bug 其實挺多的。這里我分享兩個，也是相對是隱藏得比較深的、解決耗時比較久的兩個bug。

第一個 bug 是Ranger2. 0 以后的版本中 RangerPolicyResponsitory 這個類用了finalize去釋放內存。Java 的 finalize 關鍵字風險是很高的，因此用了以后，內存的釋放很慢，本質上的原因是Responsitory與enricher的生命周期不同，Responsitory短于它所依賴的enricher的生命周期。Ranger開發者的解決方法是用 finalize 去釋放。

但是這可能不是一個很好的方案，因為我們實踐中發現，我們NN上線之后， fullGC 很頻繁，基本上30-40分鐘一次 fullGC，因為policy是全量內存緩存，尤其是Ranger policy 多的時候，內存可能有1-2G，釋放太慢，每次又是全量更新，積累下來很快就 fullGC 了。我們知道 NN 是實時性很強的服務，一次 fullGC 對業務的影響是非常大的，所以我們線上不得不立即全量回滾，直到后面才解決這個問題。我們解決完之后，現在我們的NN的QPS 基本上4w+，峰值可能5w，基本上鑒權毫秒級還是非常穩定的。

第二個主要是右圖代碼所示的部分。

右圖其實是兩個并發不安全的問題，第一個問題，原生的Ranger可能對并發修改稍微有點薄弱,圖中可以看到原生Ranger首先是拿到policy當前的一個版本號，在第二步里面，它就去把版本號+1，再去設置成新的版本號。1和2之間是沒有任何加鎖和互斥的，這肯定是不安全的，兩個請求并發進1和2之間，會導致線程不安全，版本號肯定是會錯位的。

第二個問題，如圖所示，我們可以看到Ranger的緩存更新操作，在更新緩存的時候，首先是設置到當前緩存的版本號，再去設置緩存的內容，如果在步驟1和2之間有讀請求進來會比較麻煩，這可能就會發生一次臟讀，這也是不安全的，因為版本號已經上去了，但是policy內容還沒更新好，讀出來的就是一個新的版本號，但是 policy 內容是舊的，如果后面繼續增量更新，就會基于一個錯誤視圖去更新，就會永遠漏掉一些policy。

10、商業化

最后，分享網易數帆遇到的一個特殊的場景。

網易數帆也是一個 ToB 商業化的平臺，我們不光要解決網易內部的安全問題，也致力于解決企業級服務的大數據安全問題。在大范圍內鋪開過程中，我們遇到了兩個問題，第一個是依賴關系有點復雜，可以看到圖中橘色的部分是我們安全團隊負責，但是藍色的部分，這些計算引擎又是其他底層團隊負責的。我們兩個團隊之間的依賴變成了犬牙交錯的狀態。

這種犬牙交錯的狀態會帶來一個問題，就是我們對外多環境部署的時候，配置依賴比較復雜，同時我們版本升級變更頻繁的時候，變更順序也比較復雜，容易出現升級出問題或者配置丟失的情況。因此在版本上必須要做好協同管理。同時我們安全中心也做好了兼容性保證，比如底層引擎沒升級，安全中心即橘色部分會去兼容一些場景。

圖右邊是想說明這樣一個問題，我們這套解決方案由于商業化場景客戶的多種多樣，我們底層 Hadoop 不一定是我們自己的Hadoop，有可能是用戶自己提供的一套Hadoop，也有可能是CDH、CDP，什么都有可能。在這種情況下，我們的功能也是可以實現的，因為我們的解決方案是一套相對通用的數據安全解決方案。當然如果在用戶使用自己Hadoop 的情況下，也會損失一部分能力，但是我們安全的核心能力還是可以保證的。

這兩個點其實就要求我們的安全中心要做一個抽象，需要把不變的東西抽出來，從而隨機應變，這對設計會有一定的要求。我們現在在做的30來個環境整體上部署變更都比較敏捷。其中很大比例也采用了對接模式，即用戶使用自己的Hadoop，我們也都能順利承擔。

四、成果

最后簡單分享一下我們的成果。

內部主要應用在網易云音樂、網易嚴選等，更多的是外部商業化。我們方案的穩定性和產品的易用性都已得到了很好的驗證。