在大資料平台建設初期，安全也許並不是被重點關注的一環。大資料平台的定位主要是服務資料開發人員，提高資料開發效率，提供便捷的開發流程，有效支援數倉建設。大資料平台的使用者都是公司內部人員。資料本身的安全性已經由公司層面的網路及物理機房的隔離來得到保證。那麼資料平台建設過程中，需要考慮哪些安全性方面的問題？
環境隔離，資料開發人員應當只需關注自己相關業務域的資料，也應該只能訪問這一部分資料。從資料的角度，減小了被接觸面，降低了被誤操作的可能。從資料開發人員的角度，只能訪問自己業務域的資料，在資料開發的過程中，可以減少干擾項，提高效率。
資料脫敏，有些敏感資料即使是公司內部的資料開發人員，也需要限制其直接訪問的許可權。
明晰權責，各業務域資料都有相應的負責人，對自己的資料負責。同時，所有資料訪問與操作都有審計資訊記錄，對資料的轉化與流動有據可查。
最後，大資料平台的目標是賦能資料開發人員，提高資料開發效率，而安全管理必然會降低資料平台的便利性。如何平衡安全和便利性的關係，尤為重要。
有讚大資料平台安全建設是在大資料平台本身的發展以及數倉元資料建設的過程中不斷演進的。概括起來可以分為三個階段。
在大資料平台剛開始構建的時候，我們重點關注的是基礎服務、任務排程、監控預警等方面。資料安全這一塊，只有有限的幾個數倉同學有資料讀寫許可權，而各業務組的同學都只有讀許可權。隨著公司的發展，業務量的提公升，按業務進行資料隔離的需求開始變的強烈。
當時，我們對各方需求進行了梳理，主要為以下幾點。將資料按業務域劃分，資料開發人員只能訪問相關業務域的資料，粒度為表或字段級別。業務域可以和公司組織架構相對應，相關部門預設有相應許可權。可以方便的進行許可權申請與審批。調研對比各種實現方案之後，我們選擇了 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 的做法，執行引擎的可擴充套件性並不好。由此，我們進入了安全建設的第二階段。
為了提高使用者使用的便利性，我們需要收斂資料平台的入口，下線 hue，所有的資料訪問及許可權申請與審批都直接可在資料平台上完成。並且，當使用者訪問到某個無許可權的資料時，可以直接一鍵申請。為了提公升執行引擎可擴充套件的能力，我們需要將 ranger 與執行引擎解耦，執行引擎可以不用鑑權。因此，我們在元資料系統中增加了許可權管理服務模組，通過 restful 介面與 ranger 互動。架構圖如下：
所有資料訪問直接在資料平台這個入口，通過許可權管理服務進行鑑權。支援許可權一鍵申請及一鍵審批。還可以支援臨時許可權等特殊請求。資料管理人員也不用在 ranger 中配置策略，而是通過許可權管理頁面直接進行資料業務域配置，然後自動對映為 ranger 中的策略。另外，我們還在這一階段建立了完整的審計體系，做到了所有資料訪問與操作有據可查。
隨著公司業務的進一步增長，對敏感資料的脫敏需求變的更加強烈。我們需要將各種手機號、郵箱位址之類的敏感字段進行脫敏處理，例如手機號只顯示後四位。ranger 雖然支援 column masking，但是我們在第二階段已經將 ranger 與執行引擎進行解耦。因此，我們需要在資料平台層面，對資料進行脫敏。我們採用的方案是 sql 重寫。架構圖如下：
sql engine proposer 是我們開發的乙個智慧型執行引擎選擇服務，可以根據查詢的特徵以及當前集群中的佇列狀態為 sql 查詢選擇合適的執行引擎。資料平台向某個執行引擎提交查詢之前，會先訪問智慧型執行引擎選擇服務。在選定合適的執行引擎之後，通過敏感字段重寫模組改寫 sql 查詢，將其中的敏感字段根據隱藏策略(如只顯示後四位)進行替換。而敏感欄位的隱藏策略儲存在 ranger 中，資料管理人員可以在許可權管理服務頁面設定各種欄位的敏感等級，敏感等級會自動對映為 ranger 中的隱藏策略。例如表 ods.*** 中的列 acct_no 的敏感等級為 2，那麼對映為 ranger 中的策略如下：
當某個查詢語句為
select acct_no from ods.*** where par='20181128' limit 10；from (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`.`***` ) `***`where par = '20181128'limit 10;大資料平台的安全建設並不是一項孤立的工作，而是隨著大資料平台支援的業務量和業務種類越來越多，與大資料平台本身的進化而一起發展的。隨著有讚實時數倉的建設、機器學習平台的構建等等新業務的發展，安全建設仍有很長的路要走。
作者簡介：大資料平台是有贊共享技術的核心團隊之一，該團隊主要由資料技術、資料產品、演算法挖掘、廣告平台四個小團隊組成，目前共有 34 位優秀的工程師組成。
有讚大資料平台安全建設實踐
在大資料平台建設初期，安全也許並不是被重點關注的一環。大資料平台的定位主要是服務資料開發人員，提高資料開發效率，提供便捷的開發流程，有效支援數倉建設。大資料平台的使用者都是公司內部人員。資料本身的安全性已經由公司層面的網路及物理機房的隔離來得到保證。那麼資料平台建設過程中，需要考慮哪些安全性方面的問...
大資料平台安全標準設計
從應用角度看，需大資料平台提供如下4項安全功能 邊界 訪問 透明 資料 1 邊界 限制只有合法使用者身份的使用者訪問大資料平台集群 1 使用者身份認證 關注於控制外部使用者或者第三方服務對集群的訪問過程中的身份鑑別，這是實施大資料平台安全架構的基礎 使用者在訪問啟用了安全認證的集群時，必須能通過服務...
大資料平台 整體建設思想
建設指導方針 建設思路 缺點 通用元件建設，組合支援業務的方式 缺點 打通上下游系統和業務流程的能力 服務口碑取決於服務最差的環節 服務越多支援的代價越高1.乙個系統服務難免會有 bug，也總會有不夠靈活的地方 提供的服務越多 越全面，日常維護的代價就越高 需求響應要疾如閃電，功能服務要天長地久1....