數據安全工具建設與治理思路

1 評論 4380 瀏覽 48 收藏 21 分鐘

近年來,在信息技術支撐下,數據經濟驅動著全球各經濟體的經濟總量不斷增加,“數據安全”也已上升到我國國家安全戰略高度。政府部門和企業持續加大在數據治理、數據存儲、數據保護、數據加密等方面的重視程度和投資力度。作者將基于在業務場景中遇到的數據安全治理問題,幫助大家理解“數據安全”概念,并向大家分享在數據安全治理過程中所采用的工具手段和思維思路。

今天的介紹會圍繞下面四點展開:

  1. 安全概念
  2. 安全目標
  3. 工具框架
  4. 安全治理

一、安全概念

首先和大家介紹一下本文分享范圍內的安全概念,了解什么是數據安全、數據全生命周期,以及安全4A/5A理論。

1. 數據安全的定義

(1) 數據安全在公司安全中的位置

其實在一個公司里面,安全的概念非常的廣泛,例如公司內部會將整個公司的安全分為幾個領域:政治安全、聲譽安全、法規安全、公共安全、財務安全、金融安全、信息安全、業務安全、內容安全。我們看到數據安全屬于信息安全的一個子模塊。

(2) 數據安全的概念

針對數據安全,我們要解決的問題是,在整個數據生命周期中,從采集到銷毀過程中所面臨的全部數據安全挑戰。換句話說,數據安全就是保障數據從采集到銷毀的全生命周期中的一切操作符合國家和公司的安全法規。

2. 數據全生命周期的定義

數據全生命周期是指數據從采集到銷毀的全過程,通常包括以下幾個階段:

  1. 數據采集:數據從客戶端(APP/網頁)中以日志的形式進行收集的過程;
  2. 數據傳輸:數據通過高速通道(kafka)快速集成到服務器存儲介質中的過程;
  3. 數據存儲:包括各類硬件存儲介質和一系列數倉建模規范;
  4. 數據加工:數據提取/轉化/合并/去重等操作過程;
  5. 數據交換:數據從各類冷/熱存儲引擎中搬來搬去的過程;
  6. 數據治理:通過產品技術手段規范數據的完整性、準確性、時效性等特性的過程;
  7. 數據應用:數據應用到分析、展示、算法畫像等領域的過程;
  8. 數據銷毀:數據刪除銷毀的過程。

3. 安全4A/5A理論的定義

行業中比較認可的分類方法為身份認證、授權及訪問控制、行為審計、資產保護這4A。通過以上4A理論,可以將數據全生命周期中涉及到的安全問題拆分為這四個業務場景,如果將四個業務問題管控好,結合鋪展到位的數據安全建設工具和第三方監察審計部門對數據資產進行監察,整個過程會形成一個完整的數據安全保護閉環。

二、安全目標

1. 數據安全范疇和邊界

目前絕大多數做數據安全相關工作的人,主要集中在賬號管理-數據采集傳輸和安全審計-應用消費層面(例如數據人物畫像、分析工具、數據加工生產等),其中在授權管理模塊會花費70%~80%的精力。

2. 數據安全建設目標

上圖中的數據安全建設目標是參考亞馬遜的定義,即數據安全會經歷三個階段:不信任外網→不信任內網→0信任,其含義為:

  • 不信任外網:公司的資產和數據只對內部員工開放,外部員工沒有經過公司身份認證無法訪問公司的數據;
  • 不信任內網:對于公司內部的數據會進行分級分類,根據公司內部員工的職責、崗位和分類去細分權限;
  • 0信任:數據在不經過數據所有人或產權人授權的情況下,無人能夠拿到這個數據。

目前絕大部分公司能做好外網隔離,即不信任外網,已是非常不容易,也是性價比最高的建設目標。

三、工具框架

接下來將從身份認證、權限管控、資產保護以及綜合實踐來介紹數據安全的工具框架。

1. 身份認證

身份認證包含賬號和認證兩個部分。以下通過這兩部分的設計和實踐,分別闡述其搭建思維和方法。

(1)賬號設計

在做身份認證之前,最基礎的工作便是完成賬號設計,搭建賬號系統。我們可以將賬號進行分類,包括自然人賬號,組織賬號,角色賬號,部門賬號,應用賬號,還有一些比較小眾的其他賬號,以便實現安全管控的前提——準確無誤的識別出訪問主體。數據安全第一個條件就是要建立起清晰可信準確的賬號體系。

賬號通常分為三類:

  1. 自然人賬號:包含崗位、職級、合同類型以及其他屬性等基本信息的賬號,可以清晰地區分出公司內不同類型的員工。
  2. 組織賬號:通過組織身份或者業務線形態對系統進行訪問,組織內部通常是多種詳細分工角色的集合,需要在底層建設時就搭建好框架。
  3. 應用/服務賬號:通過APP/服務進行數據訪問,也通過該賬號來進行后續的消費和應用。

當我們設計好賬號,搭建好系統,便可以進入實踐步驟。在安全中心中,有賬號申請模塊,即賬號注冊工具,其功能為:在信息安全部以及IT支持部門,錄入信息,生成SSO,完成基礎服務支持。

(2)認證設計

身份認證的第二個部分是認證。認證方式有密碼認證、微信/支付號第三方認證、電話/郵件驗證碼認證等方式。這些認證方式的底層結構都和上圖流程圖類似,分三個系統:SSO、應用系統、權限系統:

  • 應用系統:用戶通過一個應用系統登錄,應用系統會分別與SSO和權限系統交互,獲取用戶信息和數據權限信息,并將有權限的數據內容返回給用戶。
  • SSO:單點登錄系統的加密存儲用戶信息數據庫,主要存儲用戶的賬號密碼等用戶信息。
  • 權限系統:用于查看申請數據內容的用戶是否有請求該數據內容的權限,會給應用系統返回鑒定結果。

在實踐中,可以通過合理設置SSO實現“0信任”的方式,來解決例如第三方BD需登錄商家后臺去幫助商家處理問題存在的潛在安全問題。

具體的可以設置多方SSO:內部員工SSO、第三方合作商BSSO、外部用戶CSSO。然后第三方BD通過BSSO認證系統登錄并申請外部用戶的短信認證,以此取代傳統使用商家的賬號密碼去登錄的方式,做到“0信任”,降低安全風險。

2. 權限管控

當我們要對一個業務系統進行訪問和操作時,要經過權限管控環節,在該環節聲明用戶與權限的關系。將介紹它的幾個迭代模型和實踐示例。

權限管控模型先后經歷了三個時期:ACL模型、RBAC模型、ABAC模型:

  • ACL模型:即Access Control List,直接維護列表中用戶與資源的關系從而達到權限管控的目的。缺點是隨著業務體量的增加,職級崗位復雜度提高,數據量增加,該模型的效率低下。
  • RBAC模型:即Role-Based Access Control,基于角色的訪問控制,將用戶添加到角色列表從而間接獲得對應的權限。將角色和權限建立權限關系,用戶和權限形成間接的關系,在ACL模型的基礎上,提高了效率。
  • ABAC模型:即Attribute-Based Access Control,基于屬性的授權,通過事先定義好的規則屬性來控制用戶的權限范圍。與RBAC模型相比,其定義空間更大,可以抽象出更具體和差異化的控制條件,建立屬性與權限的權限關系。

上圖是一個基于ABAC權限模型改良的TRFAC模型設計的權限產品DEMO,包含獲權方和資源列表。獲權方可以是用戶、用戶組、角色、部門、應用和其他,還可以增加一些附屬條件。該模型基于“對象-資源-條件-行為”的權限控制,描述了“xx對象(人/應用/組織/角色等)對xx資源(頁面/菜單/按鈕/數據等)在xx條件/因素(城市=北京等)下擁有xx行為類型(增刪改查等)的權限”。

上圖即為TRFAC模型權限系統健全的流程,需方和供方分別使用業務系統和權限中心以API為橋梁接口進行交互,互相傳輸請求和返回結果。

3. 資產保護

為防止有權限的用戶將數據不合規的泄露和傳播,需要建立資產保護體系,以下介紹資產保護模塊的設計思路和實踐示例。

在整個資產保護模塊中,主要分為事前預防-事中監控-事后審計三部分。

(1) 事前預防

工具主要包含:

  • 離職轉崗交接平臺:80%的數據安全case都發生在離職轉崗環節,設計專門的針對角色、權限、任務、各類型資產的交接回收平臺能極大降低風險發生的可能性。
  • 敏感數據識別:有利于我們及時發現諸如電話、身份證號等敏感數據,及時對識別出的數據做出標記和升級,就能堵住可能的泄露風險。其實現方法主要是底層算法邏輯結合前端界面,然后根據目標數據庫進行敏感數據識別。
  • 敏感數據脫敏展示/下載:針對特定用戶查看/下載數據時進行數據脫敏。

(2) 事中監控

在事中監控環節,是在事前預防的敏感數據識別和敏感數據脫敏展示/下載配置好的基礎上,進行監控。針對高風險人群(比如待離職人員、外包賬號、實習生等)和高風險行為(敏感數據下載和查詢)配置監控規則,設置閾值,感知風險并阻止風險。

(3)事后審計

事中監控一旦檢測到風險或者安全風險已經發生,通過設計審計日志查詢工具對風險進行追責以及及時堵住安全漏洞。

4. 綜合實踐

上面介紹了身份認證、權限管控和資產保護,在現實業務中往往是復雜的綜合性業務問題,因此以下將介紹從數據的采集、存儲、生產、加工、治理,到數據的應用、分析、服務,即加工層到應用層的框架模型。

在實際業務場景中,往往不是單一的賬號、認證、權限等管控需求,而是綜合了賬號、認證、權限、隔離等交叉需求的綜合場景,比如加工層的“賬號-工作空間-項目空間”的三級劃分結構。又比如應用層SaaS系統中超級餐飲連鎖企業使用的CRM系統。

加工層,也叫作工作空間-項目組體系:

  • 工作空間:面向不同崗位角色(分析師、產品、RD等),集成各類分場景工具,提供相應的分析、加工和應用服務能力的虛擬綜合工作場所,用戶可以按照自己的崗位屬性選擇相應場景的工具和數據開展工作;
  • 項目組:工作空間的組成單元,劃分了數據存儲、計算資源,整合了權限、數據資產,將相同發任務的人員集合一個組,共同進行數據生產、加工和治理;項目組內根據需求還可以進一步細分出角色和權限分配。

當遇到不同業務線,具有不同的組織架構劃分,有時候細化出不同的角色時,我們就需要采用應用層,是工作空間制下,由業務線組織決策分類管控的體系。

應用層的一個典型特點就是組織層級復雜,角色多樣,比如類似于麥當勞這種國際超級餐飲企業,從“全球總部-大區總部-區域總代-門店”劃分出多級組織體系,同時又有直營和加盟等不同組織性質,所以數據中臺為了滿足這類業務團隊關于組織賬號和權限的需求時,就需要考慮組織-角色的多級體系。同時,一個角色在不同組織所擁有的權限也是不一樣的。

四、安全治理

1. 核心理念

靈魂三問:你為什么要做數據安全建設?你為誰做數據安全建設?你做數據安全有什么價值?

回答:數據安全不僅是在保護數據不泄露,其終極目標是在保障數據流通的安全性,促進數據的共享和流通,讓數據為業務賦能!

2. 實施策略

安全治理的重要性不言而喻,其實施策略主要分為下列幾步:標準立法、工具支持、運營第三方數據安全治理。

(1)標準立法

安全治理的第一步為標準立法,需要借助國家的安全法規和企業建立的相應的安全規范,滿足數據全生命周期各個環節的標準和數據應用環節的標準。

(2)工具支持

其次安全中心會提供一整套包括權限服務、資產交接、流程服務、安全監察、數據流通等工具。整合分散產品,集合權限服務、流程服務、離職轉崗服務、安全審計服務、數據流通服務幾大方面能力的工具平臺,提供綜合化安全管控治理服務。

關于數據流通目前有兩種方案,各有利弊:

  • A方案:只提供工具和平臺,各個業務可以注冊使用不同部分,將其數據上傳對外,但是平臺不會管理其交易。
  • B方案:作為平臺方,將各個業務線的數據統一收口到平臺,由平臺方進行綜合規范和治理,業務方如有數據需求,再將數據授權。

(3) 運營第三方數據安全治理

最后一個模塊為運營第三方數據安全治理,主要分為四大塊:組織保障、落地路徑、運營策略和基礎保障。

我們可以將數據安全中心運營目標整體分為三個:

  1. 培養和建立用戶心智,完成組織保障;
  2. 推動各業務團隊將所屬數據納入數據市場,統一取數流程;
  3. 制定標準和定責追溯的SOP,提升安全治理能力。

作者:馬小陽;編輯整理:陳妃君

本文由 @明明 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 既然數據安全工程好,那我們應該怎么去把它做的更好呢?僅僅有治理思路應該還是不夠的,還需要去實踐和總結,才能得出更好的結論和方法,才能做的更好。

    來自湖南 回復