文 | 群演 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 的邏輯。基於同樣的方法，我們實現了字段血緣的追溯，從而可以進行字段的敏感等級傳遞。
五、未來展望
大數據平臺的安全建設並不是一項孤立的工作，而是隨著大數據平臺支持的業務量和業務種類越來越多，與大數據平臺本身的進化而一起發展的。隨著有贊實時數倉的建設、機器學習平臺的構建等等新業務的發展，安全建設仍有很長的路要走。