快手成立于 2011 年，致力于成為全球最癡迷于為客戶創(chuàng)造價值的公司。公司在 2022 年 Q4 時，整體的日活用戶達到了 3.66 億，月活用戶達到 6.4 億。為了支撐快手如此大的規(guī)模體量，背后有很多數(shù)據(jù)相關(guān)的建設(shè)。

快手的數(shù)據(jù)平臺旨在提升決策效率和業(yè)績。該平臺通過數(shù)據(jù)中臺構(gòu)建數(shù)據(jù)倉庫和數(shù)據(jù)服務(wù)，包括分析決策、實驗決策、AB 測試和核心資產(chǎn)服務(wù)等。目前，快手的數(shù)據(jù)量已達到萬億級，總數(shù)據(jù)量達到 EB 級。

本次分享聚焦于數(shù)據(jù)安全，將分享快手在大數(shù)據(jù)安全治理方面的實踐。

一、背景介紹

1. 快手大數(shù)據(jù)安全平臺定位

作為上市公司，快手對于數(shù)據(jù)安全非常關(guān)注。快手大數(shù)據(jù)安全平臺的主要職責(zé)是為大數(shù)據(jù)全鏈路、全生命周期保駕護航，保障數(shù)據(jù)安全。這里的全鏈路包含幾個層面：

• 在數(shù)倉建設(shè)階段，數(shù)據(jù)開發(fā)人員可利用平臺提供的開發(fā)能力進行數(shù)據(jù)倉庫建設(shè)，如基于 ODS 創(chuàng)建數(shù)據(jù)集市和維表。其中數(shù)據(jù)平臺有完善的數(shù)據(jù)權(quán)限申請管控機制，防止機密數(shù)據(jù)泄露。
• 在數(shù)據(jù)采集階段，數(shù)據(jù)平臺會識別敏感數(shù)據(jù)，進行數(shù)據(jù)加密、脫敏等操作，在數(shù)據(jù)入倉時進行安全管控。
• 在數(shù)據(jù)應(yīng)用階段，數(shù)據(jù)平臺也采取了安全措施，在數(shù)據(jù)服務(wù)或應(yīng)用上對用戶鑒權(quán)，確保數(shù)據(jù)資產(chǎn)的安全。

2. 快手大數(shù)據(jù)安全面臨的挑戰(zhàn)

在構(gòu)建數(shù)據(jù)平臺過程中，面臨多項挑戰(zhàn)：

• 通用性：系統(tǒng)覆蓋范圍廣泛，涉及 30+ 系統(tǒng)，需具備較強的通用性。
• 精細化管控：分為三個層面，首先是資源精細化，涵蓋報表、數(shù)據(jù)集、指標(biāo)、維度庫表等異構(gòu)資源；第二是操作類型精細化，包含讀寫操作；第三是賬號精細化，包含個人賬號和多租戶體系賬號，需做好權(quán)限管控和隔離。
• 高可用：認證和鑒權(quán)處于數(shù)據(jù)服務(wù)核心鏈路，一旦異常影響范圍非常大，因此對安全要求極高。
• 擴展性：業(yè)務(wù)需求靈活多變，需滿足多種業(yè)務(wù)線的權(quán)限管控要求，對擴展性提出了較高要求。

3. 快手大數(shù)據(jù)安全建設(shè)思路

為了應(yīng)對數(shù)據(jù)平臺建設(shè)面臨的挑戰(zhàn)，快手的建設(shè)思路圍繞著幾個方向展開：

• 首先是組織規(guī)范，快手成立了數(shù)據(jù)委員會、信息安全委員會等虛擬組織，制定了數(shù)據(jù)分類分級規(guī)范、數(shù)據(jù)權(quán)限規(guī)范、數(shù)據(jù)安全隱私打標(biāo)規(guī)范等，還建立了專門的安全平臺組，負責(zé)落地這些規(guī)范。
• 其次，建設(shè)原則兼顧安全與效率，制定了分級審批流程，并建立了協(xié)調(diào)機制。既要保證安全，又要提高效率。
• 最后，在安全原則方面，遵循相關(guān)法律法規(guī)，并遵循最小權(quán)限原則。

二、平臺建設(shè)

1. 發(fā)展歷程

大數(shù)據(jù)安全平臺的發(fā)展歷程可分為四個階段：

• 原始階段，數(shù)據(jù)平臺主要是圍繞報表平臺建設(shè)，當(dāng)時落地了初級的權(quán)限管理；權(quán)限模型基于 RBAC；安全能力處于 2A 級，包括鑒權(quán)、申請權(quán)限等，整體相對原始。
• 發(fā)展階段，引入了 RPAC 權(quán)限模型，增強了權(quán)限控制，并擴展系統(tǒng)覆蓋，涵蓋了引擎類系統(tǒng)（如 Hive）。
• 精細化建設(shè)階段，引入了行級權(quán)限（PRBC），實現(xiàn)了更精細的權(quán)限控制；加強租戶數(shù)據(jù)隔離，保障數(shù)據(jù)安全；迭代安全能力，達到 4A 級別，完善了認證體系以及全鏈路審計。
• 數(shù)據(jù)合規(guī)建設(shè)階段，聚焦隱私數(shù)據(jù)保護，引入加解密脫敏、安全隔離艙等能力，實現(xiàn)了 5A 級能力；系統(tǒng)覆蓋擴展至 Druid、CK、Kafka、HDFS 等平臺；持續(xù)推進數(shù)據(jù)合規(guī)建設(shè)，保障數(shù)據(jù)安全。

2. 建設(shè)思路

安全平臺建設(shè)思路圍繞以下三個方面展開：

• 全域覆蓋，涵蓋存儲引擎、中臺系統(tǒng)（如生產(chǎn)平臺、分析平臺）、分析決策平臺等系統(tǒng)。
• 全能力建設(shè)，基于 5A 方法論，構(gòu)建認證、授權(quán)、訪問控制、資源保護、審計等全方位安全能力。
• 全生命周期管控，事前重點關(guān)注隱私數(shù)據(jù)合規(guī)性，通過數(shù)據(jù)安全打標(biāo)、隱私數(shù)據(jù)打標(biāo)等措施，加強數(shù)據(jù)加密和權(quán)限控制；事中關(guān)注認證鑒權(quán)穩(wěn)定性；事后基于審計日志，構(gòu)建安全態(tài)勢感知能力，識別異常訪問行為，制定風(fēng)險策略，保障數(shù)據(jù)安全。

3. 系統(tǒng)架構(gòu)

系統(tǒng)采用多層架構(gòu)，包括：

• 應(yīng)用層：面向用戶，提供應(yīng)用服務(wù)。
• 安全平臺核心層：包含插件層、接口層、服務(wù)層和存儲層。
• 依賴層：提供外部依賴，如租戶賬號體系和資源體系。

核心層包含以下模塊：

• 插件層：滿足不同引擎的特點，實現(xiàn)權(quán)限鑒權(quán)。
• 接口層：提供 HTTP 和 RPC 接口，面向中臺應(yīng)用和開發(fā)平臺。
• 服務(wù)層：統(tǒng)一接入資源和賬號，提供權(quán)限授予和管理服務(wù)。
• 存儲層：自動緩存和加速數(shù)據(jù)，提高訪問效率。

為保障系統(tǒng)高可用和高性能，該系統(tǒng)提供了完善的監(jiān)控、告警、降級、容錯預(yù)案、演練限流等保障措施。

4. 關(guān)鍵技術(shù) – 認證體系

認證體系旨在驗證用戶的身份。在設(shè)計認證體系時，我們面臨以下挑戰(zhàn)：

• 輕量化：避免對現(xiàn)有系統(tǒng)造成較大影響。
• 本地化：與組織體系相結(jié)合。
• 易演化：滿足未來國際化探索等新的業(yè)務(wù)需求。

我們借鑒業(yè)界成熟方案，自研了一套基于三方無密鑰傳輸?shù)恼J證體系。認證過程包含三次網(wǎng)絡(luò)通信：客戶端身份驗證、獲取有效期內(nèi)訪問令牌、后臺服務(wù)令牌驗證。認證體系包含以下關(guān)鍵點：

• 賬號體系：包括個人賬號和組賬號。
• 令牌類型：包括常規(guī)訪問令牌、代理訪問令牌和降級令牌。
• 降級令牌機制：確保在密鑰分發(fā)中心異常時，不影響當(dāng)前訪問。

5. 關(guān)鍵技術(shù) – 權(quán)限模型

權(quán)限模型用于控制用戶對資源的訪問權(quán)限。業(yè)界常見的權(quán)限模型包括：

• 訪問控制列表 (ACL)：直接建立用戶和資源之間的關(guān)系，每次訪問時檢查用戶是否有權(quán)限。
• 基于角色的訪問控制 (RBAC)：引入角色的概念，角色與資源綁定，用戶通過加入角色繼承權(quán)限。
• 基于策略的訪問控制 (PBAC)：引入策略概念，根據(jù)主體的屬性、環(huán)境或客體的屬性綜合判斷訪問權(quán)限。
• 基于屬性的訪問控制 (ABAC)：與 PBAC 類似，但更強調(diào)屬性在訪問控制中的作用。

快手由于資源復(fù)雜、賬號體系本地化等特點，結(jié)合 RBAC 和 PBAC 自研了基于策略的角色訪問控制 (PRBAC) 模型。PRBAC 模型以策略為核心，涵蓋以下四個方面：

• 主體：自定義用戶組、租戶賬號。
• 資源：統(tǒng)一標(biāo)識符 (UIN)，由公司域、資源域和唯一 ID 組成。
• 動作：讀、寫等常見動作。
• 條件：行級權(quán)限的關(guān)鍵所在，根據(jù) SQL 查詢中的 WHERE 條件判斷訪問權(quán)限。

6. 關(guān)鍵技術(shù) – 統(tǒng)一鑒權(quán)

鑒權(quán)體系可分為兩類：

• 應(yīng)用系統(tǒng)類：QPS 較低，延遲容忍度較高，與快手體系結(jié)合良好，可直接集成中間件框架和訪問遠程鑒權(quán)服務(wù)。
• 大數(shù)據(jù)引擎類：與大數(shù)據(jù)框架結(jié)合較少，基于開源引擎改造，提供鑒權(quán)插件，根據(jù)引擎特性選擇本地或遠程鑒權(quán)模式。

對于鑒權(quán)核心服務(wù)，包括：

• 自動化刷新器：增量或全量加載數(shù)據(jù)。
• 本地數(shù)據(jù)緩存：異常后快速恢復(fù)。
• 鑒權(quán)引擎：權(quán)限模型和策略規(guī)則計算，從而實現(xiàn)靈活的鑒權(quán)規(guī)則判斷。

7. 關(guān)鍵技術(shù) – 全鏈路審計日志

全鏈路審計旨在追蹤數(shù)據(jù)泄露的源頭，包括生產(chǎn)系統(tǒng)、應(yīng)用系統(tǒng)、Hive 引擎、HDFS Server 等環(huán)節(jié)。審計基于上游數(shù)據(jù)源，實時收集資產(chǎn)操作日志、訪問日志和下載日志。審計日志經(jīng)過轉(zhuǎn)換處理，例如展開 Hive 上下文，便于后續(xù)審計。審計日志用于清查和策略構(gòu)建，如審批日志策略。全鏈路審計的特點包括：

• 全鏈路覆蓋
• 融合血緣信息
• 審計格式統(tǒng)一
• 支持實時風(fēng)險告警

三、治理實踐

接下來將具體介紹快手?jǐn)?shù)據(jù)治理實踐中的重點問題和解決方案。

1. 數(shù)據(jù)分類分級

首先要介紹的是分類分級。分類分級旨在將數(shù)據(jù)按敏感性劃分為不同級別，優(yōu)先處理高敏感數(shù)據(jù)。

• 分類：原先融合在一起的數(shù)據(jù)現(xiàn)已區(qū)分開，隱私數(shù)據(jù)單獨列出。通用數(shù)據(jù)和隱私數(shù)據(jù)均按公開級別分級，通用數(shù)據(jù)分為 C1 至 C4 級（公開級、內(nèi)部級、機密級、原密級），隱私數(shù)據(jù)分為 P1 至 P4 級。
• 分級：分級后，不同敏感級別的數(shù)據(jù)將采取不同的保護措施。例如，C4 級和 P4 級數(shù)據(jù)將采用更嚴(yán)格的審批流程，涉及部門負責(zé)人和二級部門負責(zé)人審批。此外，這些數(shù)據(jù)在存儲時將采取加密或脫敏等保護措施。

數(shù)據(jù)分類分級遵循以下原則：

• 升級原則：如果表中存在敏感信息，則整表按最高標(biāo)準(zhǔn)處理。
• 降級原則：數(shù)據(jù)脫敏或匿名化后，可降低其敏感級別。

數(shù)據(jù)分類分級流程分為三個階段：

• 元數(shù)據(jù)采集：通過元數(shù)據(jù)中臺自動采集外部平臺的數(shù)據(jù)源、數(shù)據(jù)表變更信息，并存儲至元數(shù)據(jù)中心和圖庫中。
• 基于元數(shù)據(jù)，采用以下三種方式進行自動化識別，其中，血緣識別：分析表血緣、任務(wù)血緣等，識別敏感字段并進行打標(biāo)。算法檢測：使用算法檢測特定數(shù)據(jù)類型，如銀行卡號。規(guī)則模板匹配：匹配內(nèi)置的個人信息識別規(guī)則模板，如姓名、手機號、銀行卡號等。
• 數(shù)據(jù)大盤分析，識別后，將數(shù)據(jù)推送給用戶進行二次確認和打標(biāo)。同時，提供事后資產(chǎn)大盤，幫助用戶從個人、組織、部門等視角審查資產(chǎn)分布情況。

2. 數(shù)據(jù)引擎安全

數(shù)據(jù)引擎安全存在以下問題：

• 內(nèi)部規(guī)范方面：早期缺乏賬號體系和租戶賬號體系；資產(chǎn)歸屬不明確，安全責(zé)任不清。
• 安全能力方面：缺乏身份認證信息，缺少安全審計和溯源能力，權(quán)限管控缺失。
• 運營治理方面：無法定位真實訪問用戶，阻礙推動工作；多個團隊使用多個平臺，協(xié)作困難。

針對數(shù)據(jù)引擎安全問題，我們制定了以下解決方案：

• 規(guī)范方面：落實賬號體系和認證體系。明確管理角色職責(zé)，包括租戶管理員和安全接口人的審批權(quán)限。
• 工具方面：引入精細化權(quán)限管控，如行列級權(quán)限。優(yōu)化鑒權(quán)模式，根據(jù)引擎層級進行分層認證。
• 治理方面：成立專門工作組，針對每個引擎推進治理工作。采用二八原則，重點關(guān)注頭部平臺。采取靈活的封禁策略，逐步推進平臺改造。

3. 敏感數(shù)據(jù)保護

敏感數(shù)據(jù)保護治理面臨以下挑戰(zhàn)：

• 法律法規(guī)差異：不同國家對敏感數(shù)據(jù)的要求不盡相同，需要仔細研究相關(guān)法律法規(guī)。
• 集中管控：敏感數(shù)據(jù)應(yīng)與通用數(shù)據(jù)分開管理，以便于安全管理和風(fēng)險預(yù)警。
• 成本與效率：將敏感數(shù)據(jù)從通用數(shù)據(jù)中分離會涉及不同鏈路的改造，需要綜合考慮成本和效率。

各改造的成本和效率存在差異，需要綜合考量。改造涉及以下方面：

• 數(shù)據(jù)入倉：加強識別和自動脫敏。
• 數(shù)據(jù)加工：注重敏感數(shù)據(jù)審批。

在敏感數(shù)據(jù)保護解決方案中，為解決敏感數(shù)據(jù)保護挑戰(zhàn)，我們重點引入了安全隔離倉的概念：

• 安全隔離倉：虛擬概念，用于隔離包含敏感信息的外部數(shù)據(jù)源。
• 加密和隔離：識別包含敏感信息的外部數(shù)據(jù)源后，自動加密并將其放置在安全隔離倉中。

此外，我們還采取了以下措施：

• 規(guī)范建設(shè)：研究不同國家法律法規(guī)，定義敏感信息類型、脫敏方式和要求。
• 工具建設(shè)：開發(fā)數(shù)據(jù)識別、文件字段加密和脫敏工具。
• 數(shù)據(jù)保護措施：實施字段級權(quán)限管控、嚴(yán)格審批流程等數(shù)據(jù)保護措施。
• 增量處理：定期掃描識別新出現(xiàn)的敏感信息，推動用戶治理和落地。

通過上述措施，我們建立了全面的敏感數(shù)據(jù)保護體系，確保敏感數(shù)據(jù)得到有效保護。

四、成果和規(guī)劃

1. 成果總結(jié)

自建設(shè)以來，快手大數(shù)據(jù)安全體系已在 30 余個系統(tǒng)中落地實施，資源規(guī)模達到千萬級，日均申請量達到千級，覆蓋了 C2 至 C4 及 P4 等審批流。應(yīng)用范圍涵蓋多個層面，包括 Web 系統(tǒng)、認證鑒權(quán)等服務(wù)。整體運行穩(wěn)定，未出現(xiàn)重大故障。有效保障了數(shù)據(jù)安全，提升了數(shù)據(jù)治理水平。

2. 未來規(guī)劃

未來規(guī)劃主要包括以下幾個方面：

• 覆蓋度提升：推動底層引擎使用方 100% 接入認證和鑒權(quán)；完善 HDFS 上層使用方的認證和鑒權(quán)接入。
• 態(tài)勢感知增強：分析數(shù)據(jù)資產(chǎn)分布和敏感數(shù)據(jù)訪問行為；檢測數(shù)據(jù)異常行為。
• 新技術(shù)探索：探索增強型數(shù)據(jù)保護技術(shù)，如增強隱私數(shù)據(jù)保護、多方安全檢測等；研究 data fabric 等新思路，實現(xiàn)數(shù)據(jù)可用但不可見。
• 智能化提升：利用大模型和機器學(xué)習(xí)算法提升數(shù)據(jù)分類分級和敏感數(shù)據(jù)識別準(zhǔn)確性；探索智能化數(shù)據(jù)治理手段。

通過以上工作，保障敏感數(shù)據(jù)的保護，為企業(yè)數(shù)據(jù)安全保駕護航。

五、問答環(huán)節(jié)

Q1：關(guān)于令牌化數(shù)據(jù)入湖處理：如何處理已令牌化的實時數(shù)據(jù)庫數(shù)據(jù)入湖？

A1：入湖時，識別令牌化數(shù)據(jù)的敏感性。如果數(shù)據(jù)僅用于建模，則無需額外處理。否則，根據(jù)數(shù)據(jù)脫敏規(guī)范進行脫敏處理，確保數(shù)據(jù)安全。

Q2：關(guān)于跨部門數(shù)據(jù)權(quán)限申請：快手如何劃分?jǐn)?shù)據(jù)權(quán)責(zé)歸屬？

A2：權(quán)限申請分為不同級別：

• 普通數(shù)據(jù)：權(quán)限負責(zé)人審批。
• 重要數(shù)據(jù)（如 C4）：權(quán)限負責(zé)人、二級部門負責(zé)人審批。
• 非常重要數(shù)據(jù)：權(quán)限負責(zé)人、二級部門負責(zé)人、一級部門負責(zé)人審批。

申請方式包括個人名義和組名義，權(quán)限有效期過后可續(xù)簽或升級。

Q3：關(guān)于大數(shù)據(jù)平臺行級記錄刪除：快手如何支持隱私合規(guī)下的行級記錄刪除？

A3：全鏈路刪除數(shù)據(jù)，包括業(yè)務(wù)庫和下游數(shù)據(jù)。Hive 分區(qū)文件：不適合行級刪除，成本高。建議采用 Hudi 引擎：支持行級增刪改，性能較好。其刪除的具體流程如下：

• 用戶提出數(shù)據(jù)刪除請求。
• 系統(tǒng)驗證請求合法性。
• 啟動全鏈路數(shù)據(jù)刪除流程。
• 業(yè)務(wù)庫刪除對應(yīng)數(shù)據(jù)。
• Hudi 引擎刪除對應(yīng)行級數(shù)據(jù)。
• 其他下游系統(tǒng)同步刪除對應(yīng)數(shù)據(jù)。