快手大數據安全治理實踐
快手成立于 2011 年,致力于成為全球最癡迷于為客戶創造價值的公司。公司在 2022 年 Q4 時,整體的日活用戶達到了 3.66 億,月活用戶達到 6.4 億。為了支撐快手如此大的規模體量,背后有很多數據相關的建設。
快手的數據平臺旨在提升決策效率和業績。該平臺通過數據中臺構建數據倉庫和數據服務,包括分析決策、實驗決策、AB 測試和核心資產服務等。目前,快手的數據量已達到萬億級,總數據量達到 EB 級。
本次分享聚焦于數據安全,將分享快手在大數據安全治理方面的實踐。
一、背景介紹
1. 快手大數據安全平臺定位
作為上市公司,快手對于數據安全非常關注??焓执髷祿踩脚_的主要職責是為大數據全鏈路、全生命周期保駕護航,保障數據安全。這里的全鏈路包含幾個層面:
- 在數倉建設階段,數據開發人員可利用平臺提供的開發能力進行數據倉庫建設,如基于 ODS 創建數據集市和維表。其中數據平臺有完善的數據權限申請管控機制,防止機密數據泄露。
- 在數據采集階段,數據平臺會識別敏感數據,進行數據加密、脫敏等操作,在數據入倉時進行安全管控。
- 在數據應用階段,數據平臺也采取了安全措施,在數據服務或應用上對用戶鑒權,確保數據資產的安全。
2. 快手大數據安全面臨的挑戰
在構建數據平臺過程中,面臨多項挑戰:
- 通用性:系統覆蓋范圍廣泛,涉及 30+ 系統,需具備較強的通用性。
- 精細化管控:分為三個層面,首先是資源精細化,涵蓋報表、數據集、指標、維度庫表等異構資源;第二是操作類型精細化,包含讀寫操作;第三是賬號精細化,包含個人賬號和多租戶體系賬號,需做好權限管控和隔離。
- 高可用:認證和鑒權處于數據服務核心鏈路,一旦異常影響范圍非常大,因此對安全要求極高。
- 擴展性:業務需求靈活多變,需滿足多種業務線的權限管控要求,對擴展性提出了較高要求。
3. 快手大數據安全建設思路
為了應對數據平臺建設面臨的挑戰,快手的建設思路圍繞著幾個方向展開:
- 首先是組織規范,快手成立了數據委員會、信息安全委員會等虛擬組織,制定了數據分類分級規范、數據權限規范、數據安全隱私打標規范等,還建立了專門的安全平臺組,負責落地這些規范。
- 其次,建設原則兼顧安全與效率,制定了分級審批流程,并建立了協調機制。既要保證安全,又要提高效率。
- 最后,在安全原則方面,遵循相關法律法規,并遵循最小權限原則。
二、平臺建設
1. 發展歷程
大數據安全平臺的發展歷程可分為四個階段:
- 原始階段,數據平臺主要是圍繞報表平臺建設,當時落地了初級的權限管理;權限模型基于 RBAC;安全能力處于 2A 級,包括鑒權、申請權限等,整體相對原始。
- 發展階段,引入了 RPAC 權限模型,增強了權限控制,并擴展系統覆蓋,涵蓋了引擎類系統(如 Hive)。
- 精細化建設階段,引入了行級權限(PRBC),實現了更精細的權限控制;加強租戶數據隔離,保障數據安全;迭代安全能力,達到 4A 級別,完善了認證體系以及全鏈路審計。
- 數據合規建設階段,聚焦隱私數據保護,引入加解密脫敏、安全隔離艙等能力,實現了 5A 級能力;系統覆蓋擴展至 Druid、CK、Kafka、HDFS 等平臺;持續推進數據合規建設,保障數據安全。
2. 建設思路
安全平臺建設思路圍繞以下三個方面展開:
- 全域覆蓋,涵蓋存儲引擎、中臺系統(如生產平臺、分析平臺)、分析決策平臺等系統。
- 全能力建設,基于 5A 方法論,構建認證、授權、訪問控制、資源保護、審計等全方位安全能力。
- 全生命周期管控,事前重點關注隱私數據合規性,通過數據安全打標、隱私數據打標等措施,加強數據加密和權限控制;事中關注認證鑒權穩定性;事后基于審計日志,構建安全態勢感知能力,識別異常訪問行為,制定風險策略,保障數據安全。
3. 系統架構
系統采用多層架構,包括:
- 應用層:面向用戶,提供應用服務。
- 安全平臺核心層:包含插件層、接口層、服務層和存儲層。
- 依賴層:提供外部依賴,如租戶賬號體系和資源體系。
核心層包含以下模塊:
- 插件層:滿足不同引擎的特點,實現權限鑒權。
- 接口層:提供 HTTP 和 RPC 接口,面向中臺應用和開發平臺。
- 服務層:統一接入資源和賬號,提供權限授予和管理服務。
- 存儲層:自動緩存和加速數據,提高訪問效率。
為保障系統高可用和高性能,該系統提供了完善的監控、告警、降級、容錯預案、演練限流等保障措施。
4. 關鍵技術 – 認證體系
認證體系旨在驗證用戶的身份。在設計認證體系時,我們面臨以下挑戰:
- 輕量化:避免對現有系統造成較大影響。
- 本地化:與組織體系相結合。
- 易演化:滿足未來國際化探索等新的業務需求。
我們借鑒業界成熟方案,自研了一套基于三方無密鑰傳輸的認證體系。認證過程包含三次網絡通信:客戶端身份驗證、獲取有效期內訪問令牌、后臺服務令牌驗證。認證體系包含以下關鍵點:
- 賬號體系:包括個人賬號和組賬號。
- 令牌類型:包括常規訪問令牌、代理訪問令牌和降級令牌。
- 降級令牌機制:確保在密鑰分發中心異常時,不影響當前訪問。
5. 關鍵技術 – 權限模型
權限模型用于控制用戶對資源的訪問權限。業界常見的權限模型包括:
- 訪問控制列表 (ACL):直接建立用戶和資源之間的關系,每次訪問時檢查用戶是否有權限。
- 基于角色的訪問控制 (RBAC):引入角色的概念,角色與資源綁定,用戶通過加入角色繼承權限。
- 基于策略的訪問控制 (PBAC):引入策略概念,根據主體的屬性、環境或客體的屬性綜合判斷訪問權限。
- 基于屬性的訪問控制 (ABAC):與 PBAC 類似,但更強調屬性在訪問控制中的作用。
快手由于資源復雜、賬號體系本地化等特點,結合 RBAC 和 PBAC 自研了基于策略的角色訪問控制 (PRBAC) 模型。PRBAC 模型以策略為核心,涵蓋以下四個方面:
- 主體:自定義用戶組、租戶賬號。
- 資源:統一標識符 (UIN),由公司域、資源域和唯一 ID 組成。
- 動作:讀、寫等常見動作。
- 條件:行級權限的關鍵所在,根據 SQL 查詢中的 WHERE 條件判斷訪問權限。
6. 關鍵技術 – 統一鑒權
鑒權體系可分為兩類:
- 應用系統類:QPS 較低,延遲容忍度較高,與快手體系結合良好,可直接集成中間件框架和訪問遠程鑒權服務。
- 大數據引擎類:與大數據框架結合較少,基于開源引擎改造,提供鑒權插件,根據引擎特性選擇本地或遠程鑒權模式。
對于鑒權核心服務,包括:
- 自動化刷新器:增量或全量加載數據。
- 本地數據緩存:異常后快速恢復。
- 鑒權引擎:權限模型和策略規則計算,從而實現靈活的鑒權規則判斷。
7. 關鍵技術 – 全鏈路審計日志
全鏈路審計旨在追蹤數據泄露的源頭,包括生產系統、應用系統、Hive 引擎、HDFS Server 等環節。審計基于上游數據源,實時收集資產操作日志、訪問日志和下載日志。審計日志經過轉換處理,例如展開 Hive 上下文,便于后續審計。審計日志用于清查和策略構建,如審批日志策略。全鏈路審計的特點包括:
- 全鏈路覆蓋
- 融合血緣信息
- 審計格式統一
- 支持實時風險告警
三、治理實踐
接下來將具體介紹快手數據治理實踐中的重點問題和解決方案。
1. 數據分類分級
首先要介紹的是分類分級。分類分級旨在將數據按敏感性劃分為不同級別,優先處理高敏感數據。
- 分類:原先融合在一起的數據現已區分開,隱私數據單獨列出。通用數據和隱私數據均按公開級別分級,通用數據分為 C1 至 C4 級(公開級、內部級、機密級、原密級),隱私數據分為 P1 至 P4 級。
- 分級:分級后,不同敏感級別的數據將采取不同的保護措施。例如,C4 級和 P4 級數據將采用更嚴格的審批流程,涉及部門負責人和二級部門負責人審批。此外,這些數據在存儲時將采取加密或脫敏等保護措施。
數據分類分級遵循以下原則:
- 升級原則:如果表中存在敏感信息,則整表按最高標準處理。
- 降級原則:數據脫敏或匿名化后,可降低其敏感級別。
數據分類分級流程分為三個階段:
- 元數據采集:通過元數據中臺自動采集外部平臺的數據源、數據表變更信息,并存儲至元數據中心和圖庫中。
- 基于元數據,采用以下三種方式進行自動化識別,其中,血緣識別:分析表血緣、任務血緣等,識別敏感字段并進行打標。算法檢測:使用算法檢測特定數據類型,如銀行卡號。規則模板匹配:匹配內置的個人信息識別規則模板,如姓名、手機號、銀行卡號等。
- 數據大盤分析,識別后,將數據推送給用戶進行二次確認和打標。同時,提供事后資產大盤,幫助用戶從個人、組織、部門等視角審查資產分布情況。
2. 數據引擎安全
數據引擎安全存在以下問題:
- 內部規范方面:早期缺乏賬號體系和租戶賬號體系;資產歸屬不明確,安全責任不清。
- 安全能力方面:缺乏身份認證信息,缺少安全審計和溯源能力,權限管控缺失。
- 運營治理方面:無法定位真實訪問用戶,阻礙推動工作;多個團隊使用多個平臺,協作困難。
針對數據引擎安全問題,我們制定了以下解決方案:
- 規范方面:落實賬號體系和認證體系。明確管理角色職責,包括租戶管理員和安全接口人的審批權限。
- 工具方面:引入精細化權限管控,如行列級權限。優化鑒權模式,根據引擎層級進行分層認證。
- 治理方面:成立專門工作組,針對每個引擎推進治理工作。采用二八原則,重點關注頭部平臺。采取靈活的封禁策略,逐步推進平臺改造。
3. 敏感數據保護
敏感數據保護治理面臨以下挑戰:
- 法律法規差異:不同國家對敏感數據的要求不盡相同,需要仔細研究相關法律法規。
- 集中管控:敏感數據應與通用數據分開管理,以便于安全管理和風險預警。
- 成本與效率:將敏感數據從通用數據中分離會涉及不同鏈路的改造,需要綜合考慮成本和效率。
各改造的成本和效率存在差異,需要綜合考量。改造涉及以下方面:
- 數據入倉:加強識別和自動脫敏。
- 數據加工:注重敏感數據審批。
在敏感數據保護解決方案中,為解決敏感數據保護挑戰,我們重點引入了安全隔離倉的概念:
- 安全隔離倉:虛擬概念,用于隔離包含敏感信息的外部數據源。
- 加密和隔離:識別包含敏感信息的外部數據源后,自動加密并將其放置在安全隔離倉中。
此外,我們還采取了以下措施:
- 規范建設:研究不同國家法律法規,定義敏感信息類型、脫敏方式和要求。
- 工具建設:開發數據識別、文件字段加密和脫敏工具。
- 數據保護措施:實施字段級權限管控、嚴格審批流程等數據保護措施。
- 增量處理:定期掃描識別新出現的敏感信息,推動用戶治理和落地。
通過上述措施,我們建立了全面的敏感數據保護體系,確保敏感數據得到有效保護。
四、成果和規劃
1. 成果總結
自建設以來,快手大數據安全體系已在 30 余個系統中落地實施,資源規模達到千萬級,日均申請量達到千級,覆蓋了 C2 至 C4 及 P4 等審批流。應用范圍涵蓋多個層面,包括 Web 系統、認證鑒權等服務。整體運行穩定,未出現重大故障。有效保障了數據安全,提升了數據治理水平。
2. 未來規劃
未來規劃主要包括以下幾個方面:
- 覆蓋度提升:推動底層引擎使用方 100% 接入認證和鑒權;完善 HDFS 上層使用方的認證和鑒權接入。
- 態勢感知增強:分析數據資產分布和敏感數據訪問行為;檢測數據異常行為。
- 新技術探索:探索增強型數據保護技術,如增強隱私數據保護、多方安全檢測等;研究 data fabric 等新思路,實現數據可用但不可見。
- 智能化提升:利用大模型和機器學習算法提升數據分類分級和敏感數據識別準確性;探索智能化數據治理手段。
通過以上工作,保障敏感數據的保護,為企業數據安全保駕護航。
五、問答環節
Q1:關于令牌化數據入湖處理:如何處理已令牌化的實時數據庫數據入湖?
A1:入湖時,識別令牌化數據的敏感性。如果數據僅用于建模,則無需額外處理。否則,根據數據脫敏規范進行脫敏處理,確保數據安全。
Q2:關于跨部門數據權限申請:快手如何劃分數據權責歸屬?
A2:權限申請分為不同級別:
- 普通數據:權限負責人審批。
- 重要數據(如 C4):權限負責人、二級部門負責人審批。
- 非常重要數據:權限負責人、二級部門負責人、一級部門負責人審批。
申請方式包括個人名義和組名義,權限有效期過后可續簽或升級。
Q3:關于大數據平臺行級記錄刪除:快手如何支持隱私合規下的行級記錄刪除?
A3:全鏈路刪除數據,包括業務庫和下游數據。Hive 分區文件:不適合行級刪除,成本高。建議采用 Hudi 引擎:支持行級增刪改,性能較好。其刪除的具體流程如下:
- 用戶提出數據刪除請求。
- 系統驗證請求合法性。
- 啟動全鏈路數據刪除流程。
- 業務庫刪除對應數據。
- Hudi 引擎刪除對應行級數據。
- 其他下游系統同步刪除對應數據。