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數據安全建設過程中，我們參考了很多公司和商業產品對于的優秀實踐，同時也確認我們的產品還屬于較初級階段，依然有大量功能需要去完善。

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