嗶哩嗶哩大數(shù)據(jù)平臺建設(shè)之路——數(shù)據(jù)安全篇

　　1.序言

　　Berserker是B站一站式數(shù)據(jù)開發(fā)及治理平臺，基于常用大數(shù)據(jù)生態(tài)組件構(gòu)建，滿足公司內(nèi)數(shù)據(jù)查詢、數(shù)據(jù)分析、日常報表、數(shù)據(jù)集成、數(shù)據(jù)開發(fā)、實時計算和數(shù)據(jù)治理等各種業(yè)務(wù)場景。在B站，我們一般將Berserker簡寫為BSK。

　　圖1. Berserker的整體架構(gòu)

　　圖2. Berserker主頁

　　其中，數(shù)據(jù)安全是Berserker平臺中重要的一部分，它將為公司內(nèi)部 Hive、Kafka、ClickHouse、ETL任務(wù)等各種資產(chǎn)進行統(tǒng)一的數(shù)據(jù)安全管理，并為數(shù)據(jù)平臺部內(nèi)部的數(shù)據(jù)開發(fā)、數(shù)據(jù)分析、數(shù)據(jù)報表、數(shù)據(jù)治理等各種數(shù)據(jù)類產(chǎn)品進行統(tǒng)一的功能安全管控。

　　本文將重點介紹Berserker數(shù)據(jù)安全的建設(shè)過程。

　　2.數(shù)據(jù)安全建設(shè)

　　2.1 安全目標

　　我們安全建設(shè)的目標是：保障信息資產(chǎn)的保密性(Confidentiality)、完整性(Integrity)、可用性(Availability)：

　　圖3. CIA三要素

　　2.2 5A方法論

　　我們將根據(jù)數(shù)據(jù)安全5A方法論，打造一個完整的安全產(chǎn)品，并在每個主要流程都分別提供了相應(yīng)的產(chǎn)品和服務(wù)，實現(xiàn)安全閉環(huán)。

　　圖4. 數(shù)據(jù)安全5A方法論

　　其中：

　　身份認證(Authentication)：用戶主體是誰

　　授權(quán)(Authorization)：授予某些用戶主體允許或拒絕訪問客體的權(quán)限

　　訪問控制(Access Control)：控制措施以及是否放行的執(zhí)行者

　　資產(chǎn)保護(Asset Protection)：資產(chǎn)的保密性、完整性、可用性保障

　　可審計(Auditable)：形成可供追溯的操作日志

　　2.3 數(shù)據(jù)安全架構(gòu)

　　圖5. 整體框架

　　其中：

　　身份認證

　　Berserker接入了公司統(tǒng)一身份認證，在新建賬號時，將同步賬號到公司AD域控管理，大數(shù)據(jù)組件通過Kerberos進行身份認證。

　　授權(quán)

　　一般用戶在Berserker平臺進行數(shù)據(jù)安全變更操作(如：權(quán)限申請)，授權(quán)結(jié)果記錄在數(shù)據(jù)安全。數(shù)據(jù)安全將授權(quán)結(jié)果同步到Ranger和ClickHouse等。

　　訪問控制

　　Berserker、數(shù)據(jù)開發(fā)等服務(wù)通過數(shù)據(jù)安全服務(wù)進行鑒權(quán)。

　　Hive、Spark、Flink等計算引擎通過Ranger進行鑒權(quán)。

　　資產(chǎn)保護

　　我們按不同的數(shù)據(jù)安全等級制定不同的數(shù)據(jù)保護策略，并采取下載限制、數(shù)據(jù)脫敏、安全水印、溯源等多種措施現(xiàn)在數(shù)據(jù)保護

　　審計

　　記錄用戶或系統(tǒng)的操作，并用于事件追溯。BSK系統(tǒng)中多數(shù)據(jù)服務(wù)已經(jīng)接入審計，同時也通過HDFS元倉(基于FsImage和HDFS AuditLog構(gòu)建)進行數(shù)據(jù)訪問分析。

　　2.4 里程碑

　　2020年7月數(shù)據(jù)安全的第一個服務(wù)權(quán)限系統(tǒng)從Berserker平臺獨立出，2022年7月，數(shù)據(jù)安全升級到2.0，中間經(jīng)歷了幾次重大變更。

　　圖6. 主要時間節(jié)點

　　數(shù)據(jù)安全2.0于2021年8月開始規(guī)劃，2021年11月開始前期開發(fā)工作，于2022年7月上線，其最大的變化為有兩點：

　　重新設(shè)計了一套權(quán)限管理系統(tǒng)

　　產(chǎn)品形態(tài)上引入了工作空間

　　3.遇到的問題

　　3.1 權(quán)限變更

　　本質(zhì)上，權(quán)限主要包含三個部分：賬號、資源和權(quán)限類型。相比于1.0，權(quán)限2.0對這三塊在設(shè)計上較大改變，主要體現(xiàn)在：

　　簡化了賬號體系

　　標準化了資源模型

　　豐富了權(quán)限類型

　　3.1.1 權(quán)限1.0

　　圖7. 權(quán)限1.0模型圖

　　權(quán)限系統(tǒng)1.0有以下特點：

　　權(quán)限系統(tǒng)基于用戶進行權(quán)限管理

　　并沒有區(qū)分數(shù)據(jù)權(quán)限和產(chǎn)品功能權(quán)限

　　有各種不同的賬號類型，權(quán)限可以來自于個人、部門、用戶組和角色等

　　ETL任務(wù)是以個人身份運行

　　權(quán)限只有讀、寫、DDL三種，而且存在包含關(guān)系

　　Hive表可以繼承Hive庫權(quán)限

　　由此帶來了很多問題：

　　權(quán)限來源過于豐富，賬號、資源、權(quán)限類型三者都存在繼承或包含關(guān)系，以至在多數(shù)情況下難以定位某用戶為何擁有某個資源的某一權(quán)限

　　部門變更困難，因個人繼承了部門權(quán)限，用戶變更部門可能會造成其負責的任務(wù)無法正常運行

　　權(quán)限類型太少，且難以擴展，已經(jīng)不能滿足各種不同的業(yè)務(wù)場景

　　數(shù)據(jù)級權(quán)限和功能級權(quán)限沒有分離，難以做到精細化運營。如管理員應(yīng)該只擁有功能權(quán)限，但卻擁有所有的數(shù)據(jù)權(quán)限

　　我們對上述問題進行了詳細評估，確認在原有權(quán)限體系下都很難解決，于是設(shè)計了一套新權(quán)限體系。

　　3.1.2 權(quán)限2.0

　　圖8. 權(quán)限模型

　　相比于1.0，權(quán)限2.0的做了較大調(diào)整：

　　進行了賬號調(diào)整，并拆分三種賬號類型以滿足多種場景

　　個人賬號：認證公司員工，可以獲取資源權(quán)限

　　系統(tǒng)賬號：對接服務(wù)平臺，不可獲取資源權(quán)限

　　工作空間賬號：ETL任務(wù)的運行賬號，可以獲得資源權(quán)限

　　功能權(quán)限和數(shù)據(jù)權(quán)限進行了分離

　　數(shù)據(jù)權(quán)限沒有繼承關(guān)系

　　功能權(quán)限只能來自于角色，個人繼承角色權(quán)限，角色間沒有包含關(guān)系

　　刪除了用戶組，刪除了部門權(quán)限

　　擴展了權(quán)限類型，并可按不資源類型的不可設(shè)置不同的權(quán)限類型

　　如：Hive表為：hive:select、hive:update、hive:alter、hive:drop等權(quán)限

　　統(tǒng)一了資源定義，并在berserker各子業(yè)務(wù)間通用

　　3.1.3 升級過程

　　因為權(quán)限2.0和權(quán)限1.0存在較地差異，升級過程中，為保證穩(wěn)定性，減少用戶體驗上的差異，我們主要采取了如下推進措施：

　　前期小范圍驗證

　　在權(quán)限2.0大規(guī)模推廣前我們先進行了小范圍的驗證，以保證系統(tǒng)的穩(wěn)定可靠：

　　實現(xiàn)2.0-alpha版，并接入項目的協(xié)作管理，但該版本的設(shè)計存在一些缺陷，與最終版本存在較大的差異，但為后續(xù)改進提供了寶貴的經(jīng)驗。目前項目的協(xié)作管理已經(jīng)按最終方案進行了調(diào)整

　　實現(xiàn)2.0-beta版，并接入ClickHouse表權(quán)限管理。該版本為權(quán)限2.0的原型

　　基于2.0-beta進行完善，小步快跑，多次迭代，形成完善的權(quán)限系統(tǒng)

　　權(quán)限系統(tǒng)的兼容

　　數(shù)據(jù)安全是berserker的基礎(chǔ)服務(wù)，為大量的服務(wù)提供安全支持。同時數(shù)據(jù)安全改造無法做到一蹴而就，在推進過程中，存在部分業(yè)務(wù)使用1.0，部分業(yè)務(wù)使用2.0，為此我們需要保證系統(tǒng)能夠兼容：

　　保留并維護權(quán)限1.0數(shù)據(jù)，并實現(xiàn)權(quán)限數(shù)據(jù)雙寫，如：用戶賬戶、資源等數(shù)據(jù)需要實現(xiàn)雙寫，權(quán)限2.0的數(shù)據(jù)同步寫回1.0中

　　保留權(quán)限1.0相關(guān)接口，但不維護該接口，并標志該接口為廢棄，業(yè)務(wù)調(diào)用時將打印調(diào)用方信息，通過收集調(diào)用日志，找到推動調(diào)用方使用新接口

　　保留權(quán)限1.0數(shù)據(jù)入倉，以兼容原有數(shù)倉業(yè)務(wù)，同時推動數(shù)倉相關(guān)業(yè)務(wù)使用新權(quán)限數(shù)據(jù)

　　數(shù)據(jù)的遷移

　　數(shù)據(jù)遷移包括歷史全量數(shù)據(jù)遷移和增量數(shù)據(jù)遷移，在下面會講到。

　　3.2 權(quán)限遷移

　　3.2.1 背景

　　為減少用戶困擾，保證業(yè)務(wù)的正確運行，我們需要做到無縫權(quán)限數(shù)據(jù)遷移，包含：數(shù)據(jù)權(quán)限遷移和功能權(quán)限遷移。

　　在做數(shù)據(jù)遷移時也遇到了一些問題，尤其是Hive表的權(quán)限數(shù)據(jù)遷移。

　　3.2.2 Hive表遷移

　　需要全量遷移的數(shù)據(jù)權(quán)限有：Hive表、Hive庫、數(shù)據(jù)源、Topic、ETL任務(wù)等。以下我們將重點介紹Hive表權(quán)限數(shù)據(jù)遷移過程。

　　我們原計劃將部門、角色、用戶組等Hive表權(quán)限全部展開個人，但通過計算發(fā)現(xiàn)，如將所有權(quán)限全部展開，最后權(quán)限記錄將超過2億條，這明顯存在問題：

　　權(quán)限不合理

　　部門擁有數(shù)據(jù)權(quán)限也不合理，一個部門內(nèi)可能僅有少數(shù)同學使用BSK平臺，而其他同學可能都不知道BSK是什么

　　系統(tǒng)管理員可能只是用來審批或管理某些功能，并不使用數(shù)據(jù)，但依然擁有所有表的權(quán)限

　　存在技術(shù)問題

　　數(shù)據(jù)量太大，很難同步到Ranger

　　權(quán)限系統(tǒng)和Ranger數(shù)據(jù)庫在不調(diào)整結(jié)構(gòu)的情況也無法存儲如此大的數(shù)據(jù)量

　　獲取有權(quán)限的Hive表列表較常見的功能也難以實現(xiàn)

　　權(quán)限系統(tǒng)內(nèi)部也難以加載并處理如此多的數(shù)據(jù)。

　　在引入工作空間后，任務(wù)將以工作空間賬號運行，也必須為工作空間賬號添加正確的權(quán)限。

　　最后我們放棄了將原權(quán)限全部展開到個人的方案，而是采用分析HDFS元倉，通過用戶的歷史訪問行為來添加相應(yīng)權(quán)限。

　　圖9. Hive表權(quán)限同步流程

　　我們通過ETL任務(wù)來實現(xiàn)Hive表全量數(shù)據(jù)遷移，主要流程有：

　　通過查詢近半年的HDFS 元倉數(shù)據(jù)，獲取用戶Hive表使用記錄，并根據(jù)操作類型的不同為使用添加讀或?qū)懙臋?quán)限

　　表的責任人為授權(quán) select、update、alter權(quán)限

　　個人申請的權(quán)限，新系統(tǒng)依然保留該權(quán)限

　　用戶組的權(quán)限展開到個人

　　表歸屬工作空間授予該表Select、update、alter權(quán)限

　　表的產(chǎn)出任務(wù)所在工作空間授予該表Select、update、alter權(quán)限

　　通過上述大幅度的降低了權(quán)限策略數(shù)。同時權(quán)限2.0上線后，也未發(fā)現(xiàn)因Hive表遷移而產(chǎn)生的權(quán)限問題。

　　3.2.3 不足

　　Hive表權(quán)限依然存在一些不足，需要后期運營處理：

　　只通過近半年的元倉數(shù)據(jù)，可能會遺漏部分年任務(wù)的訪問記錄，造成相關(guān)權(quán)限缺失

　　用戶權(quán)限存在擴大風險，用戶申請的權(quán)限過期后，因為有訪問記錄，因此權(quán)限0中依然會給到權(quán)限，但考慮到多數(shù)情況下個人賬號并不運行ETL任務(wù)，風險可控

　　部分用戶依然保有寫權(quán)限。主要為兼容部分第三方任務(wù)(非BSK平臺上提交的任務(wù))，該任務(wù)可能未及時改用工作空間賬號、而依舊使用個人賬號運行

　　3.3 工作空間推進

　　3.3.1 背景

　　數(shù)據(jù)平臺的用戶的增長及業(yè)務(wù)的豐富，基于用戶的數(shù)據(jù)安全模型體系難以支撐各種靈活多變業(yè)務(wù)需求，主要體現(xiàn)在：

　　圖10. 基于用戶的安全體系存在的問題

　　我們重新規(guī)劃數(shù)據(jù)安全體系，并參考了業(yè)內(nèi)的主流方案，引入工作空間，并將其作為管理資產(chǎn)、任務(wù)、成員、角色和權(quán)限管理的基本組織單元。

　　3.3.2 工作空間模型

　　圖11. 工作空間模型

　　可以看到：

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

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

　　數(shù)據(jù)資產(chǎn)歸屬于工作空間

　　空間內(nèi)的角色只對當前空間有效

　　引入工作空間將涉及到各方改造，包括而不限于：數(shù)據(jù)安全、數(shù)據(jù)開發(fā)、數(shù)據(jù)集成、數(shù)據(jù)質(zhì)量、數(shù)據(jù)治理、數(shù)倉以及各類數(shù)據(jù)應(yīng)用等。為此，我們制定嚴格的推進策略

　　3.3.3 推進過程

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

　　圖12. 工作空間推進過程

　　工作空間后續(xù)工作則按項目正常迭代進行。

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

　　不向用戶暴露工作空間賬號，而是先個人申請權(quán)限，提交ETL任務(wù)時，通過ETL任務(wù)的血緣將個人權(quán)限授予工作空間賬號

　　因為改動較大、涉及涉及業(yè)務(wù)方較多，也為了減少升級引起的不確定性，我們選擇在周六進行統(tǒng)一升級，減少對用戶的打擾

　　為每個一級部門引入默認工作空間，同時每個部門成員將默認加入到該空間，保證推進過程中用戶無需要做任何操作依然可以工作空間內(nèi)的功能

　　ETL任務(wù)歸屬空間后，該ETL的Owner及擁有該任務(wù)協(xié)作權(quán)限的用戶也將作為工作空間的開發(fā)加入到該空間，以保證用戶操作的一致性

　　3.4 Casbin優(yōu)化

　　3.4.1 背景

　　Casbin 是一個強大的、高效的開源訪問控制框架，其權(quán)限管理機制支持多種訪問控制模型。權(quán)限系統(tǒng)內(nèi)部使用Casbin進行權(quán)限管理。

　　Taishan是一款B站自研的分布KV數(shù)據(jù)庫。

　　權(quán)限系統(tǒng)使用Taishan緩存權(quán)限策略，以減少服務(wù)和數(shù)據(jù)庫的壓力，權(quán)限系統(tǒng)內(nèi)部處理流程如下：

　　圖13. 權(quán)限系統(tǒng)內(nèi)部授權(quán)/鑒權(quán)流程

　　可以看到，權(quán)限系統(tǒng)內(nèi)部處理的主要流程：

　　授權(quán)：用戶授權(quán)操作直接寫入數(shù)據(jù)庫

　　同步Casbin：通過監(jiān)聽數(shù)據(jù)庫最后修改時間，異步同步權(quán)限策略到Casbin

　　同步Taishan：通過消息隊列異步同步權(quán)限策略到Taishan，期間使用Casbin進行鑒權(quán)

　　鑒權(quán)：正常情況下都將使用Taishan進行鑒權(quán)，但當Taishan數(shù)據(jù)異常時將降級到使用Casbin鑒權(quán)。

　　我們在實施過程中也發(fā)現(xiàn)了一些問題：

　　時間時延。Casbin是采用異步加載的方式，難以保證順序一致。我們要求權(quán)限策略表延時5秒加載，以保證資產(chǎn)元數(shù)據(jù)處理完成。

　　Taishan記錄最后一次數(shù)據(jù)修改時間，內(nèi)存中也記錄最后一次數(shù)據(jù)修改時間，當兩時間超時30秒，表示Taishan時間不可用

　　Casbin的性能問題

　　3.4.2 Casbin添加權(quán)限性能調(diào)優(yōu)

　　我們做權(quán)限遷移時，需要在Casbin中加載所有的權(quán)限策略，我們發(fā)現(xiàn)，Casbin加載性能很低，通過Debug后將問題定位在hasPolicy的實現(xiàn)上。

　　下面是hasPolicy和policy的實現(xiàn)：

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

　　圖15. policy定義源碼

　　hasPolicy函數(shù)判斷相同策略是否已經(jīng)存在，并且每次添加新策略時都將調(diào)用該函數(shù)進行判斷，其時間復(fù)雜度為O(n^2)，其中策略條數(shù)為n，當策略到達一定規(guī)模后，性能急劇下降。

　　我們對Casbin做了優(yōu)化，添加一個Set集合(SetpolicySet)用于記錄已經(jīng)加載過的策略，hasPolicy中判斷該Set中是否包含該策略，性能得到了大幅度提供。

　　值得一提的事，Casbin 1.25.0之后的版本修復(fù)該BUG。相應(yīng)地，我們也恢復(fù)使用開源版本。

　　Casbin 1.25.0中的實現(xiàn)：

　　圖16. Casbin添加策略的優(yōu)化

　　可以看到Casbin1.25.0之后的版本中添加了policyIndex用于優(yōu)化hasPolicy。

　　3.4.3 Casbin回收權(quán)限性能調(diào)優(yōu)

　　權(quán)限大量回收操作較少見，主要發(fā)生在如下場景：

　　資源治理，做批量Hive表刪除，需要刪除相應(yīng)的權(quán)限策略

　　BSK平臺的重度用戶轉(zhuǎn)崗或離職，需要做資產(chǎn)交接，進而刪除其權(quán)限

　　工作空間治理，下線工作空間，需要刪除工作空間賬號的權(quán)限

　　在大批量的回收權(quán)限時，Casbin也會出現(xiàn)卡死，通過Debug后將問題定位在policy和policyIndex的維護上。

　　下面是Casbin刪除權(quán)限策略的源碼：

　　圖17. Casbin策略刪除的源碼

　　可以看到，Casbin刪除權(quán)限策略的步驟如下：

　　通過policyIndex找到權(quán)限對應(yīng)的index

　　通過調(diào)用remove刪除policy中的元素

　　重新更新受影響的policyIndex

　　Casbin回收權(quán)限的時間復(fù)雜度也為O(n^2)，性能較低。

　　處理該問題時，我們沒有直接修改Casbin源碼，而是類似于數(shù)據(jù)庫，引入了標志刪除：

　　在權(quán)限策略中添加deleted標志，標記該策略是否已刪除， 鑒權(quán)時添加deleted判斷

　　回收權(quán)限時將刪除改為更新操作權(quán)限策略中deleted標志的值

　　使用雙緩存，定期清理過期權(quán)限

　　即定時創(chuàng)建新Casbin模型，并加載未刪除的權(quán)限策略，完成后替換原Casbin模型，從而實現(xiàn)對回收權(quán)限的清理。

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

　　3.5 更多問題

　　除了上面所提到的問題，我們在數(shù)據(jù)安全建設(shè)過程中還有很多問題，如：

　　HDFS路徑的權(quán)限問題，包括路徑權(quán)限的繼承問題

　　使用Flink CDC或Hudi的任務(wù)中間表的歸屬及權(quán)限問題

　　如何預(yù)防工作空間賬號權(quán)限一直擴大的問題

　　非分區(qū)Hive表全量更新時刪除Hive表所在目錄的問題

　　4.未來展望

　　在Berserker數(shù)據(jù)安全建設(shè)過程中，我們參考了很多公司和商業(yè)產(chǎn)品對于的優(yōu)秀實踐，同時也確認我們的產(chǎn)品還屬于較初級階段，依然有大量功能需要去完善。

　　未來我們的建設(shè)路線將主要在幾個方面：覆蓋全生命周期的數(shù)據(jù)安全保障，更精細化的權(quán)限管理，敏感數(shù)據(jù)保護及風險評估等方面。