嗶哩嗶哩大資料平臺建設之路——資料安全篇

　　 1.序言

　　Berserker是B站一站式資料開發及治理平臺，基於常用大資料生態元件構建，滿足公司內資料查詢、資料分析、日常報表、資料整合、資料開發、實時計算和資料治理等各種業務場景。在B站，我們一般將Berserker簡寫為BSK。　　

圖1. Berserker的整體架構　　

圖2. Berserker主頁

　　其中，資料安全是Berserker平臺中重要的一部分，它將為公司內部 Hive、Kafka、ClickHouse、ETL任務等各種資產進行統一的資料安全管理，併為資料平臺部內部的資料開發、資料分析、資料包表、資料治理等各種資料類產品進行統一的功能安全管控。

　　本文將重點介紹Berserker資料安全的建設過程。

　　 2.資料安全建設

　　2.1 安全目標

　　我們安全建設的目標是：保障資訊資產的保密性(Confidentiality)、完整性(Integrity)、可用性(Availability)：　　

圖3. CIA三要素

　　2.2 5A方法論

　　我們將根據資料安全5A方法論，打造一個完整的安全產品，並在每個主要流程都分別提供了相應的產品和服務，實現安全閉環。　　

圖4. 資料安全5A方法論

　　其中：

　　身份認證（Authentication）：使用者主體是誰

　　授權（Authorization）：授予某些使用者主體允許或拒絕訪問客體的許可權

　　訪問控制（Access Control）：控制措施以及是否放行的執行者

　　資產保護（Asset Protection）：資產的保密性、完整性、可用性保障

　　可審計（Auditable）：形成可供追溯的操作日誌

　　2.3 資料安全架構　　

圖5. 整體框架

　　其中：

　　身份認證

　　Berserker接入了公司統一身份認證，在新建賬號時，將同步賬號到公司AD域控管理，大資料元件透過Kerberos進行身份認證。

　　授權

　　一般使用者在Berserker平臺進行資料安全變更操作（如：許可權申請），授權結果記錄在資料安全。資料安全將授權結果同步到Ranger和ClickHouse等。

　　訪問控制

　　Berserker、資料開發等服務透過資料安全服務進行鑑權。

　　Hive、Spark、Flink等計算引擎透過Ranger進行鑑權。

　　資產保護

　　我們按不同的資料安全等級制定不同的資料保護策略，並採取下載限制、資料脫敏、安全水印、溯源等多種措施現在資料保護

　　審計

　　記錄使用者或系統的操作，並用於事件追溯。BSK系統中多資料服務已經接入審計，同時也透過HDFS元倉（基於FsImage和HDFS AuditLog構建）進行資料訪問分析。

　　2.4 里程碑

　　2020年7月資料安全的第一個服務許可權系統從Berserker平臺獨立出，2022年7月，資料安全升級到2.0，中間經歷了幾次重大變更。　　

圖6. 主要時間節點

　　資料安全2.0於2021年8月開始規劃，2021年11月開始前期開發工作，於2022年7月上線，其最大的變化為有兩點：

　　重新設計了一套許可權管理系統

　　產品形態上引入了工作空間

　　 3.遇到的問題

　　3.1 許可權變更

　　本質上，許可權主要包含三個部分：賬號、資源和許可權型別。相比於1.0，許可權2.0對這三塊在設計上較大改變，主要體現在：

　　簡化了賬號體系

　　標準化了資源模型

　　豐富了許可權型別

　　3.1.1 許可權1.0　　

圖7. 許可權1.0模型圖

　　許可權系統1.0有以下特點：

　　許可權系統基於使用者進行許可權管理

　　並沒有區分資料許可權和產品功能許可權

　　有各種不同的賬號型別，許可權可以來自於個人、部門、使用者組和角色等

　　ETL任務是以個人身份執行

　　許可權只有讀、寫、DDL三種，而且存在包含關係

　　Hive表可以繼承Hive庫許可權

　　由此帶來了很多問題：

　　許可權來源過於豐富，賬號、資源、許可權型別三者都存在繼承或包含關係，以至在多數情況下難以定位某使用者為何擁有某個資源的某一許可權

　　部門變更困難，因個人繼承了部門許可權，使用者變更部門可能會造成其負責的任務無法正常執行

　　許可權型別太少，且難以擴充套件，已經不能滿足各種不同的業務場景

　　資料級許可權和功能級許可權沒有分離，難以做到精細化運營。如管理員應該只擁有功能許可權，但卻擁有所有的資料許可權

　　我們對上述問題進行了詳細評估，確認在原有許可權體系下都很難解決，於是設計了一套新許可權體系。

　　3.1.2 許可權2.0　　

圖8. 許可權模型

　　相比於1.0，許可權2.0的做了較大調整：

　　進行了賬號調整，並拆分三種賬號型別以滿足多種場景

　　個人賬號：認證公司員工，可以獲取資源許可權

　　系統賬號：對接服務平臺，不可獲取資源許可權

　　工作空間賬號：ETL任務的執行賬號，可以獲得資源許可權

　　功能許可權和資料許可權進行了分離

　　資料許可權沒有繼承關係

　　功能許可權只能來自於角色，個人繼承角色許可權，角色間沒有包含關係

　　刪除了使用者組，刪除了部門許可權

　　擴充套件了許可權型別，並可按不資源型別的不可設定不同的許可權型別

　　如：Hive表為：hive:select、hive:update、hive:alter、hive:drop等許可權

　　統一了資源定義，並在berserker各子業務間通用

　　3.1.3 升級過程

　　因為許可權2.0和許可權1.0存在較地差異，升級過程中，為保證穩定性，減少使用者體驗上的差異，我們主要採取瞭如下推進措施：

　　前期小範圍驗證

　　在許可權2.0大規模推廣前我們先進行了小範圍的驗證，以保證系統的穩定可靠：

　　實現2.0-alpha版，並接入專案的協作管理，但該版本的設計存在一些缺陷，與最終版本存在較大的差異，但為後續改進提供了寶貴的經驗。目前專案的協作管理已經按最終方案進行了調整

　　實現2.0-beta版，並接入ClickHouse表許可權管理。該版本為許可權2.0的原型

　　基於2.0-beta進行完善，小步快跑，多次迭代，形成完善的許可權系統

　　許可權系統的相容

　　資料安全是berserker的基礎服務，為大量的服務提供安全支援。同時資料安全改造無法做到一蹴而就，在推進過程中，存在部分業務使用1.0，部分業務使用2.0，為此我們需要保證系統能夠相容：

　　保留並維護許可權1.0資料，並實現許可權資料雙寫，如：使用者賬戶、資源等資料需要實現雙寫，許可權2.0的資料同步寫回1.0中

　　保留許可權1.0相關介面，但不維護該介面，並標誌該介面為廢棄，業務呼叫時將列印呼叫方資訊，透過收集呼叫日誌，找到推動呼叫方使用新介面

　　保留許可權1.0資料入倉，以相容原有數倉業務，同時推動數倉相關業務使用新許可權資料

　　資料的遷移

　　資料遷移包括歷史全量資料遷移和增量資料遷移，在下面會講到。

　　3.2 許可權遷移

　　3.2.1 背景

　　為減少使用者困擾，保證業務的正確執行，我們需要做到無縫許可權資料遷移，包含：資料許可權遷移和功能許可權遷移。

　　在做資料遷移時也遇到了一些問題，尤其是Hive表的許可權資料遷移。

　　3.2.2 Hive表遷移

　　需要全量遷移的資料許可權有：Hive表、Hive庫、資料來源、Topic、ETL任務等。以下我們將重點介紹Hive表許可權資料遷移過程。

　　我們原計劃將部門、角色、使用者組等Hive表許可權全部展開個人，但透過計算發現，如將所有許可權全部展開，最後許可權記錄將超過2億條，這明視訊記憶體在問題：

　　許可權不合理

　　部門擁有資料許可權也不合理，一個部門內可能僅有少數同學使用BSK平臺，而其他同學可能都不知道BSK是什麼

　　系統管理員可能只是用來審批或管理某些功能，並不使用資料，但依然擁有所有表的許可權

　　存在技術問題

　　資料量太大，很難同步到Ranger

　　許可權系統和Ranger資料庫在不調整結構的情況也無法儲存如此大的資料量

　　獲取有許可權的Hive表列表較常見的功能也難以實現

　　許可權系統內部也難以載入並處理如此多的資料。

　　在引入工作空間後，任務將以工作空間賬號執行，也必須為工作空間賬號新增正確的許可權。

　　最後我們放棄了將原許可權全部展開到個人的方案，而是採用分析HDFS元倉，透過使用者的歷史訪問行為來新增相應許可權。　　

圖9. Hive表許可權同步流程

　　我們透過ETL任務來實現Hive表全量資料遷移，主要流程有：

　　透過查詢近半年的HDFS 元倉資料，獲取使用者Hive表使用記錄，並根據操作型別的不同為使用新增讀或寫的許可權

　　表的責任人為授權 select、update、alter許可權

　　個人申請的許可權，新系統依然保留該許可權

　　使用者組的許可權展開到個人

　　表歸屬工作空間授予該表Select、update、alter許可權

　　表的產出任務所在工作空間授予該表Select、update、alter許可權

　　透過上述大幅度的降低了許可權策略數。同時許可權2.0上線後，也未發現因Hive表遷移而產生的許可權問題。

　　3.2.3 不足

　　Hive表許可權依然存在一些不足，需要後期運營處理：

　　只透過近半年的元倉資料，可能會遺漏部分年任務的訪問記錄，造成相關許可權缺失

　　使用者許可權存在擴大風險，使用者申請的許可權過期後，因為有訪問記錄，因此許可權0中依然會給到許可權，但考慮到多數情況下個人賬號並不執行ETL任務，風險可控

　　部分使用者依然保有寫許可權。主要為相容部分第三方任務（非BSK平臺上提交的任務），該任務可能未及時改用工作空間賬號、而依舊使用個人賬號執行

　　3.3 工作空間推進

　　3.3.1 背景

　　資料平臺的使用者的增長及業務的豐富，基於使用者的資料安全模型體系難以支撐各種靈活多變業務需求，主要體現在：　　

圖10. 基於使用者的安全體系存在的問題

　　我們重新規劃資料安全體系，並參考了業內的主流方案，引入工作空間，並將其作為管理資產、任務、成員、角色和許可權管理的基本組織單元。

　　3.3.2 工作空間模型　　

圖11. 工作空間模型

　　可以看到：

　　一個空間只能屬於一個部門，一個部門可以擁有多個空間

　　使用者可以加入到多個工作空間

　　資料資產歸屬於工作空間

　　空間內的角色只對當前空間有效

　　引入工作空間將涉及到各方改造，包括而不限於：資料安全、資料開發、資料整合、資料質量、資料治理、數倉以及各類資料應用等。為此，我們制定嚴格的推進策略

　　3.3.3 推進過程

　　工作空間整體推進改造過程主要分為四個階段：　　

圖12. 工作空間推進過程

　　工作空間後續工作則按專案正常迭代進行。

　　引入工作空間後，不管是功能層面還是技術層面都有較大的改造，為減少使用者的理解成本，我們在推進過程中採用了一些策略：

　　不向使用者暴露工作空間賬號，而是先個人申請許可權，提交ETL任務時，透過ETL任務的血緣將個人許可權授予工作空間賬號

　　因為改動較大、涉及涉及業務方較多，也為了減少升級引起的不確定性，我們選擇在週六進行統一升級，減少對使用者的打擾

　　為每個一級部門引入預設工作空間，同時每個部門成員將預設加入到該空間，保證推進過程中使用者無需要做任何操作依然可以工作空間內的功能

　　ETL任務歸屬空間後，該ETL的Owner及擁有該任務協作許可權的使用者也將作為工作空間的開發加入到該空間，以保證使用者操作的一致性

　　3.4 Casbin最佳化

　　3.4.1 背景

　　Casbin 是一個強大的、高效的開源訪問控制框架，其許可權管理機制支援多種訪問控制模型。許可權系統內部使用Casbin進行許可權管理。

　　Taishan是一款B站自研的分佈KV資料庫。

　　許可權系統使用Taishan快取許可權策略，以減少服務和資料庫的壓力，許可權系統內部處理流程如下：　　

圖13. 許可權系統內部授權/鑑權流程

　　可以看到，許可權系統內部處理的主要流程：

　　授權：使用者授權操作直接寫入資料庫

　　同步Casbin：透過監聽資料庫最後修改時間，非同步同步許可權策略到Casbin

　　同步Taishan：透過訊息佇列非同步同步許可權策略到Taishan，期間使用Casbin進行鑑權

　　鑑權：正常情況下都將使用Taishan進行鑑權，但當Taishan資料異常時將降級到使用Casbin鑑權。

　　我們在實施過程中也發現了一些問題：

　　時間時延。Casbin是採用非同步載入的方式，難以保證順序一致。我們要求許可權策略表延時5秒載入，以保證資產後設資料處理完成。

　　Taishan記錄最後一次資料修改時間，記憶體中也記錄最後一次資料修改時間，當兩時間超時30秒，表示Taishan時間不可用

　　Casbin的效能問題

　　3.4.2 Casbin新增許可權效能調優

　　我們做許可權遷移時，需要在Casbin中載入所有的許可權策略，我們發現，Casbin載入效能很低，透過Debug後將問題定位在hasPolicy的實現上。

　　下面是hasPolicy和policy的實現：　　

圖14. Casbin判斷策略是否存在的原始碼　　

圖15. policy定義原始碼

　　hasPolicy函式判斷相同策略是否已經存在，並且每次新增新策略時都將呼叫該函式進行判斷，其時間複雜度為O(n^2)，其中策略條數為n，當策略到達一定規模後，效能急劇下降。

　　我們對Casbin做了最佳化，新增一個Set集合（SetpolicySet）用於記錄已經載入過的策略，hasPolicy中判斷該Set中是否包含該策略，效能得到了大幅度提供。

　　值得一提的事，Casbin 1.25.0之後的版本修復該BUG。相應地，我們也恢復使用開源版本。

　　Casbin 1.25.0中的實現：　　

圖16. Casbin新增策略的最佳化

　　可以看到Casbin1.25.0之後的版本中新增了policyIndex用於最佳化hasPolicy。

　　3.4.3 Casbin回收許可權效能調優

　　許可權大量回收操作較少見，主要發生在如下場景：

　　資源治理，做批次Hive表刪除，需要刪除相應的許可權策略

　　BSK平臺的重度使用者轉崗或離職，需要做資產交接，進而刪除其許可權

　　工作空間治理，下線工作空間，需要刪除工作空間賬號的許可權

　　在大批次的回收許可權時，Casbin也會出現卡死，透過Debug後將問題定位在policy和policyIndex的維護上。

　　下面是Casbin刪除許可權策略的原始碼：　　

圖17. Casbin策略刪除的原始碼

　　可以看到，Casbin刪除許可權策略的步驟如下：

　　透過policyIndex找到許可權對應的index

　　透過呼叫remove刪除policy中的元素

　　重新更新受影響的policyIndex

　　Casbin回收許可權的時間複雜度也為O(n^2)，效能較低。

　　處理該問題時，我們沒有直接修改Casbin原始碼，而是類似於資料庫，引入了標誌刪除：

　　在許可權策略中新增deleted標誌，標記該策略是否已刪除， 鑑權時新增deleted判斷

　　回收許可權時將刪除改為更新操作許可權策略中deleted標誌的值

　　使用雙快取，定期清理過期許可權

　　即定時建立新Casbin模型，並載入未刪除的許可權策略，完成後替換原Casbin模型，從而實現對回收許可權的清理。

　　目前Casbin的刪除效能也得到了極大的提升

　　3.5 更多問題

　　除了上面所提到的問題，我們在資料安全建設過程中還有很多問題，如：

　　HDFS路徑的許可權問題，包括路徑許可權的繼承問題

　　使用Flink CDC或Hudi的任務中間表的歸屬及許可權問題

　　如何預防工作空間賬號許可權一直擴大的問題

　　非分割槽Hive表全量更新時刪除Hive表所在目錄的問題

　　 4.未來展望

　　在Berserker資料安全建設過程中，我們參考了很多公司和商業產品對於的優秀實踐，同時也確認我們的產品還屬於較初級階段，依然有大量功能需要去完善。

　　未來我們的建設路線將主要在幾個方面：覆蓋全生命週期的資料安全保障，更精細化的許可權管理，敏感資料保護及風險評估等方面。