本期作者

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。

其中，數(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)：

?2.2 5A方法論

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

其中：

• 身份認證（Authentication）：用戶主體是誰

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

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

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

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

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

其中：

• 身份認證

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)歷了幾次重大變更。

數(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

權(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

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

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

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

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

3. 工作空間賬號：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)定可靠：

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

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

3. 基于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)能夠兼容：

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

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

3. 保留權(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)限不合理

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

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

• 存在技術(shù)問題

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

   
   

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

   
   

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

   
   

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

   
   

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

最后我們放棄了將原權(quán)限全部展開到個人的方案，而是采用分析HDFS元倉，通過用戶的歷史訪問行為來添加相應(yīng)權(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)限存在擴大風(fēng)險，用戶申請的權(quán)限過期后，因為有訪問記錄，因此權(quán)限0中依然會給到權(quán)限，但考慮到多數(shù)情況下個人賬號并不運行ETL任務(wù)，風(fēng)險可控

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

?3.3 工作空間推進

3.3.1?背景

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

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

3.3.2 工作空間模型

可以看到：

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

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

• 數(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 推進過程

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

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

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

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

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

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

4. 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)部處理流程如下：

可以看到，權(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)：

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)：

可以看到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)限策略的源碼：

可以看到，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)品對于的最佳實踐，同時也確認我們的產(chǎn)品還屬于較初級階段，依然有大量功能需要去完善。

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