1、概述
在大數據平臺建設初期，安全也許並非被重點關注的一環。大數據平臺的定位主要是服務數據開發人員，提升數據開發效率，提供便捷的開發流程，有效支持數倉建設。大數據平臺的用戶都是公司內部人員。數據自己的安全性已經由公司層面的網絡及物理機房的隔離來獲得保證。那麼數據平臺建設過程當中，須要考慮哪些安全性方面的問題？web
環境隔離，數據開發人員應當只需關注本身相關業務域的數據，也應該只能訪問這一部分數據。從數據的角度，減少了被接觸面，下降了被誤操做的可能。從數據開發人員的角度，只能訪問本身業務域的數據，在數據開發的過程當中，能夠減小干擾項，提升效率。安全
數據脫敏，有些敏感數據即便是公司內部的數據開發人員，也須要限制其直接訪問的權限。網絡
明晰權責，各業務域數據都有相應的負責人，對本身的數據負責。同時，全部數據訪問與操做都有審計信息記錄，對數據的轉化與流動有據可查。架構
最後，大數據平臺的目標是賦能數據開發人員，提升數據開發效率，而安全管理必然會下降數據平臺的便利性。如何平衡安全和便利性的關係，尤其重要。機器學習
有贊大數據平臺安全建設是在大數據平臺自己的發展以及數倉元數據建設的過程當中不斷演進的。歸納起來能夠分爲三個階段。oop
2、基於 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 增長了一個權限申請與審批的模塊。spa
這樣的方案基本知足了業務數據隔離的需求。可是在用戶使用過程當中，仍是收到了不少不滿的反饋，主要緣由就是阻礙了用戶使用的便利性。數據開發人員可能在數據平臺進行數據查詢，發現沒有數據訪問權限以後，須要到 hue 上申請權限。權限審批人員收到申請通知以後，須要登陸 ranger web UI，進行權限配置。數據管理人員須要直接在 ranger 中配置初始權限。這些都是很不方便的點。另外，ranger 支持的查詢引擎有限，想要增長查詢引擎(如 presto)就須要定製化開發。所以，這種 ranger + plugin 的作法，執行引擎的可擴展性並很差。由此，咱們進入了安全建設的第二階段。rest
3、基於 ranger 的權限管理服務
爲了提升用戶使用的便利性，咱們須要收斂數據平臺的入口，下線 hue，全部的數據訪問及權限申請與審批都直接可在數據平臺上完成。而且，當用戶訪問到某個無權限的數據時，能夠直接一鍵申請。爲了提高執行引擎可擴展的能力，咱們須要將 ranger 與執行引擎解耦，執行引擎能夠不用鑑權。所以，咱們在元數據系統中增長了權限管理服務模塊，經過 Restful 接口與 ranger 交互。架構圖以下：
全部數據訪問直接在數據平臺這個入口，經過權限管理服務進行鑑權。支持權限一鍵申請及一鍵審批。還能夠支持臨時權限等特殊請求。數據管理人員也不用在 ranger 中配置策略，而是經過權限管理頁面直接進行數據業務域配置，而後自動映射爲 ranger 中的策略。另外，咱們還在這一階段創建了完整的審計體系，作到了全部數據訪問與操做有據可查。
4、基於 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 的邏輯。基於一樣的方法，咱們實現了字段血緣的追溯，從而能夠進行字段的敏感等級傳遞。
5、將來展望
大數據平臺的安全建設並非一項孤立的工做，而是隨着大數據平臺支持的業務量和業務種類愈來愈多，與大數據平臺自己的進化而一塊兒發展的。隨着有贊實時數倉的建設、機器學習平臺的構建等等新業務的發展，安全建設仍有很長的路要走。