有贊大資料平臺安全建設實踐

語言: CN / TW / HK

一、概述

在大資料平臺建設初期,安全也許並不是被重點關注的一環。大資料平臺的定位主要是服務資料開發人員,提高資料開發效率,提供便捷的開發流程,有效支援數倉建設。大資料平臺的使用者都是公司內部人員。資料本身的安全性已經由公司層面的網路及物理機房的隔離來得到保證。那麼資料平臺建設過程中,需要考慮哪些安全性方面的問題?

環境隔離,資料開發人員應當只需關注自己相關業務域的資料,也應該只能訪問這一部分資料。從資料的角度,減小了被接觸面,降低了被誤操作的可能。從資料開發人員的角度,只能訪問自己業務域的資料,在資料開發的過程中,可以減少干擾項,提高效率。

資料脫敏,有些敏感資料即使是公司內部的資料開發人員,也需要限制其直接訪問的許可權。

明晰權責,各業務域資料都有相應的負責人,對自己的資料負責。同時,所有資料訪問與操作都有審計資訊記錄,對資料的轉化與流動有據可查。

最後,大資料平臺的目標是賦能資料開發人員,提高資料開發效率,而安全管理必然會降低資料平臺的便利性。如何平衡安全和便利性的關係,尤為重要。

有贊大資料平臺安全建設是在大資料平臺本身的發展以及數倉元資料建設的過程中不斷演進的。概括起來可以分為三個階段。

二、基於 ranger +元件 plugin 的許可權控制

在大資料平臺剛開始構建的時候,我們重點關注的是基礎服務、任務排程、監控預警等方面。資料安全這一塊,只有有限的幾個數倉同學有資料讀寫許可權,而各業務組的同學都只有讀許可權。隨著公司的發展,業務量的提升,按業務進行資料隔離的需求開始變的強烈。

當時,我們對各方需求進行了梳理,主要為以下幾點。將資料按業務域劃分,資料開發人員只能訪問相關業務域的資料,粒度為表或欄位級別。業務域可以和公司組織架構相對應,相關部門預設有相應許可權。可以方便的進行許可權申請與審批。調研對比各種實現方案之後,我們選擇了 ranger +元件 plugin 的許可權管理方案。其中 ranger+ hiveServer2 plugin 的架構圖如下( ranger + spark thrift server plugin 類似):

image

所有資料訪問在 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 互動。架構圖如下:

image

所有資料訪問直接在資料平臺這個入口,通過許可權管理服務進行鑑權。支援許可權一鍵申請及一鍵審批。還可以支援臨時許可權等特殊請求。資料管理人員也不用在 ranger 中配置策略,而是通過許可權管理頁面直接進行資料業務域配置,然後自動對映為 ranger 中的策略。另外,我們還在這一階段建立了完整的審計體系,做到了所有資料訪問與操作有據可查。

四、基於 column masking 的資料脫敏

隨著公司業務的進一步增長,對敏感資料的脫敏需求變的更加強烈。我們需要將各種手機號、郵箱地址之類的敏感欄位進行脫敏處理,例如手機號只顯示後四位。ranger 雖然支援 column masking,但是我們在第二階段已經將 ranger 與執行引擎進行解耦。因此,我們需要在資料平臺層面,對資料進行脫敏。我們採用的方案是 SQL 重寫。架構圖如下:

image

SQL Engine Proposer 是我們開發的一個智慧執行引擎選擇服務,可以根據查詢的特徵以及當前叢集中的佇列狀態為 SQL 查詢選擇合適的執行引擎。資料平臺向某個執行引擎提交查詢之前,會先訪問智慧執行引擎選擇服務。在選定合適的執行引擎之後,通過敏感欄位重寫模組改寫 SQL 查詢,將其中的敏感欄位根據隱藏策略(如只顯示後四位)進行替換。而敏感欄位的隱藏策略儲存在 ranger 中,資料管理人員可以在許可權管理服務頁面設定各種欄位的敏感等級,敏感等級會自動對映為 ranger 中的隱藏策略。例如表 ods.xxx 中的列 acct_no 的敏感等級為 2,那麼對映為 ranger 中的策略如下:

image

當某個查詢語句為

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 的邏輯。基於同樣的方法,我們實現了欄位血緣的追溯,從而可以進行欄位的敏感等級傳遞。

五、未來展望

大資料平臺的安全建設並不是一項孤立的工作,而是隨著大資料平臺支援的業務量和業務種類越來越多,與大資料平臺本身的進化而一起發展的。隨著有贊實時數倉的建設、機器學習平臺的構建等等新業務的發展,安全建設仍有很長的路要走。

分享到: