導讀 本次分享主題為網易基于Apache Ranger建構大資料安全中心的實踐。
主要内容包括以下幾大部分：
1. Apache Ranger介紹
2. 大資料安全中心整體解決方案
3. 關鍵技術分析
4. 成果&規劃
分享嘉賓｜吳俣 網易數帆 資深開發工程師
編輯整理｜唐洪超 hotata
出品社群｜DataFun
01 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 的優勢以及不足。衆所周知，安全性、精準性與管理性、效率、性能必然是沖突的，如果做得很安全，很精準，那麼往往會導緻管理性、效率和性能的下降。而管理性、效率、性能很優秀的時候，又必然對安全性和精準性有一定的損失。我們要做的是把這五方面統籌起來，尋找到一個平衡點。
02 大資料安全中心整體解決方案
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同時成功的情況，還要考慮部分成功，部分失敗的情況，這樣才可以保證系統可用性，提高使用者體驗。
03 關鍵技術解析
接下來将介紹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視圖權限整體是比較複雜的，需要單獨處理。
最後一個要點是這三者之間的優先級關系，行級權限和脫敏的優先級，到底是先脫敏之後再走行級權限，還是用原文去走行列權限再脫敏，這些都是實踐中會遇到的一些問題。當然，目前問題我們也都已經解決了。可以看圖右邊的執行計劃代碼。其中紅色的部分是一個脫敏的執行計劃修改，藍色的部分是一個行級權限的執行計劃修改，橙色的部分是我們插入用來階段之間溝通的虛拟節點，隻要遇到這個節點，就認為執行計劃已經被處理過了。可以看到我們是把行級權限放在最下面的，是以我們是要先過行級權限再過脫敏的，這樣也是比較合理的。我們的最終效果是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，我們也都能順利承擔。
04 成果
最後簡單分享一下我們的成果。
内部主要應用在網易雲音樂、網易嚴選等，更多的是外部商業化。我們方案的穩定性和産品的易用性都已得到了很好的驗證。
特别說明：本文僅用于學術交流，如有侵權請背景聯系小編删除。
- END -
轉載來源：DataFunTalk
轉載編輯：劉聰穎
稽核：肖志清 李長庭 何帥 楊瑾