文 | 群演 on 大資料
一、概述
在大資料平台建設初期，安全也許并不是被重點關注的一環。大資料平台的定位主要是服務資料開發人員，提高資料開發效率，提供便捷的開發流程，有效支援數倉建設。大資料平台的使用者都是公司内部人員。資料本身的安全性已經由公司層面的網絡及實體機房的隔離來得到保證。那麼資料平台建設過程中，需要考慮哪些安全性方面的問題？
環境隔離，資料開發人員應當隻需關注自己相關業務域的資料，也應該隻能通路這一部分資料。從資料的角度，減小了被接觸面，降低了被誤操作的可能。從資料開發人員的角度，隻能通路自己業務域的資料，在資料開發的過程中，可以減少幹擾項，提高效率。
資料脫敏，有些敏感資料即使是公司内部的資料開發人員，也需要限制其直接通路的權限。
明晰權責，各業務域資料都有相應的負責人，對自己的資料負責。同時，所有資料通路與操作都有審計資訊記錄，對資料的轉化與流動有據可查。
最後，大資料平台的目标是賦能資料開發人員，提高資料開發效率，而安全管理必然會降低資料平台的便利性。如何平衡安全和便利性的關系，尤為重要。
有贊大資料平台安全建設是在大資料平台本身的發展以及數倉中繼資料建設的過程中不斷演進的。概括起來可以分為三個階段。
二、基于 ranger +元件 plugin 的權限控制
在大資料平台剛開始建構的時候，我們重點關注的是基礎服務、任務排程、監控預警等方面。資料安全這一塊，隻有有限的幾個數倉同學有資料讀寫權限，而各業務組的同學都隻有讀權限。随着公司的發展，業務量的提升，按業務進行資料隔離的需求開始變的強烈。
當時，我們對各方需求進行了梳理，主要為以下幾點。将資料按業務域劃分，資料開發人員隻能通路相關業務域的資料，粒度為表或字段級别。業務域可以和公司組織架構相對應，相關部門預設有相應權限。可以友善的進行權限申請與審批。調研對比各種實作方案之後，我們選擇了 ranger +元件 plugin 的權限管理方案。其中 ranger+ hiveServer2 plugin 的架構圖如下( ranger + spark thrift server plugin 類似)：
所有資料通路在 Hive Server 中進行鑒權，通過公司的 LDAP 服務進行使用者認證。當時的入口有 hue、資料平台和 beeline，隻有 beeline 的使用者需要進行 LDAP 認證，而 hue 和資料平台的使用者已經認證過了，隻要傳 proxy user 過來進行鑒權即可。為了支援業務域與公司組織架構相對應，需要從公司的 OA 系統将部門組織資訊分别導入 ranger 以及 hadoop 進行使用者組的映射。另外，擴充 hue 增加了一個權限申請與審批的子產品。
這樣的方案基本滿足了業務資料隔離的需求。但是在使用者使用過程中，還是收到了很多不滿的回報，主要原因就是阻礙了使用者使用的便利性。資料開發人員可能在資料平台進行資料查詢，發現沒有資料通路權限之後，需要到 hue 上申請權限。權限審批人員收到申請通知之後，需要登入 ranger web UI，進行權限配置。資料管理人員需要直接在 ranger 中配置初始權限。這些都是很不友善的點。另外，ranger 支援的查詢引擎有限，想要增加查詢引擎(如 presto)就需要定制化開發。是以，這種 ranger + plugin 的做法，執行引擎的可擴充性并不好。由此，我們進入了安全建設的第二階段。
三、基于 ranger 的權限管理服務
為了提高使用者使用的便利性，我們需要收斂資料平台的入口，下線 hue，所有的資料通路及權限申請與審批都直接可在資料平台上完成。并且，當使用者通路到某個無權限的資料時，可以直接一鍵申請。為了提升執行引擎可擴充的能力，我們需要将 ranger 與執行引擎解耦，執行引擎可以不用鑒權。是以，我們在中繼資料系統中增加了權限管理服務子產品，通過 Restful 接口與 ranger 互動。架構圖如下：
所有資料通路直接在資料平台這個入口，通過權限管理服務進行鑒權。支援權限一鍵申請及一鍵審批。還可以支援臨時權限等特殊請求。資料管理人員也不用在 ranger 中配置政策，而是通過權限管理頁面直接進行資料業務域配置，然後自動映射為 ranger 中的政策。另外，我們還在這一階段建立了完整的審計體系，做到了所有資料通路與操作有據可查。
四、基于 column masking 的資料脫敏
随着公司業務的進一步增長，對敏感資料的脫敏需求變的更加強烈。我們需要将各種手機号、郵箱位址之類的敏感字段進行脫敏處理，例如手機号隻顯示後四位。ranger 雖然支援 column masking，但是我們在第二階段已經将 ranger 與執行引擎進行解耦。是以，我們需要在資料平台層面，對資料進行脫敏。我們采用的方案是 SQL 重寫。架構圖如下：
SQL Engine Proposer 是我們開發的一個智能執行引擎選擇服務，可以根據查詢的特征以及目前叢集中的隊列狀态為 SQL 查詢選擇合适的執行引擎。資料平台向某個執行引擎送出查詢之前，會先通路智能執行引擎選擇服務。在標明合适的執行引擎之後，通過敏感字段重寫子產品改寫 SQL 查詢，将其中的敏感字段根據隐藏政策(如隻顯示後四位)進行替換。而敏感字段的隐藏政策存儲在 ranger 中，資料管理人員可以在權限管理服務頁面設定各種字段的敏感等級，敏感等級會自動映射為 ranger 中的隐藏政策。例如表 ods.xxx 中的列 acct_no 的敏感等級為 2，那麼映射為 ranger 中的政策如下：
當某個查詢語句為
select acct_no from ods.xxx where par='20181128' limit 10; 經過脫敏重寫，最終執行的查詢語句為
SELECT acct_noFROM (SELECT `par`, `id`, CAST(mask_show_last_n(acct_no, 4, 'x', 'x', 'x', -1, '1') AS bigint) AS `acct_no`, `kdt_id`, `water_no` , `target_id`, `remark`, `create_time`, `sub_target_id` FROM `ods`.`xxx` ) `xxx`WHERE par = '20181128'LIMIT 10; 我們使用 antlr4 來處理執行引擎的文法檔案，實作 SQL 重寫。其中，spark 和 presto 都是使用的 antlr4，是以他們的文法檔案直接拿過來用即可。由于 hive 目前使用的是 antlr3 的版本，我們将 hive 的文法檔案使用 antlr4 的文法重寫了一遍。之是以要全部用 antlr4，是為了最大程度的重用 visitor 的邏輯。基于同樣的方法，我們實作了字段血緣的追溯，進而可以進行字段的敏感等級傳遞。
五、未來展望
大資料平台的安全建設并不是一項孤立的工作，而是随着大資料平台支援的業務量和業務種類越來越多，與大資料平台本身的進化而一起發展的。随着有贊實時數倉的建設、機器學習平台的建構等等新業務的發展，安全建設仍有很長的路要走。