一、數據安全治理與法律法規

下面和大家分享下數據安全治理與相關的法律法規。

1、逐步完善的法律法規

近年來，數據安全相關的法律法規正在逐步完善。

相關立法之前普遍是以國家或者行業的推薦性標準的形式存在，我們所熟知的數據安全能力成熟度模型（DSMM）中也提到過，但是現今已經明確立法，如果不遵守相關法律法規，未履行數據安全保護義務，可能會被立案處罰。

我們也可以看到，當今的企業開展相關業務時，只要存在數據收集行為，就需要重點關注以及遵守上圖所示的法律法規（網絡安全法、數據安全法、個性信息保護法、民法典，還有一個強制性的國家標準即等保2.0），企業開展數據安全治理可以參照相關行動指南（例如DSMM、特定行業相關標準等），從而使得企業的經營合法合規。

2、法律條文中的數據安全治理

數據安全法中，第四條、第十一條都分別提到了數據安全治理，可見在政企單位數據安全建設中，建立數據安全治理體系的重要性。

• 例如下圖中所示，數據安全法第21條，應該對數據實行分類分級保護，之前也是存在于國家或者行業的一些推薦性標準，目前已明確寫入到了數據安全法中。
• 同樣下圖所示，數據安全法第24條，提到了數據安全審查，落地到數據安全治理中，就是操作審計，第29條提到了發現數據安全缺陷、漏洞等風險時應當立即采取的補救措施，發生數據安全事件時應當立即采取的處置措施，對應到數據安全治理中就是對風險的響應，主要包括告警、阻斷、審批等方面。

接下來我們一起討論一下數據安全治理的本質和方向。

二、數據安全治理的本質與方向

提到數據安全治理，首先會想到保護企業自己的資產，數據資產最主要的就是數據表，但是數據安全治理保護的重點不是數據表本身，而是其中對應的信息，保護信息的手段是通過控制數據的訪問（信息存儲在數據中，數據存儲在IAAS層）來實現的，如下圖所示：

所以說，數據安全治理的本質是處理好身份、行為、資產之間的關系。

說到數據安全治理，它實際上是一系列運營體系，管理體系，技術體系融合起來的一系列活動，以前企業做數據安全治理的目的更多是從風險的角度出發，保證企業數據資產不被泄漏，不被濫用，隨著現在監管越來越嚴格，更多是為了合規性考慮，但是僅僅是為了合規性，就有些舍本逐末了，做數據安全治理更多的是一種社會責任的體現，同時也是企業命脈的保護。

針對數據安全治理思路，從過去到現在是有一個本質的變化，以前更多的是南北向安全，也即企業南北向的數據訪問和傳輸安全，防止外部入侵。現在更多的是東西向安全，涉及到了過程安全技術，實際上是對人員行為的管控，是一種零信任的理念，始終不信任，一直在驗證，通過一些基線規則、檢查規則，或者是機器學習的風險行為識別模型等進行攔截管控。

因為是對人員行為的管控，所以做數據安全治理就需要組織的建設，制度的建設和技術工具的建設，我們討論的更多是技術工具的建設，以及基于技術工具的最佳實踐的經驗分享。

在開展數據安全治理之前，管理者都應該清楚下圖所示的6個問題：

如果想要較好地回答上面的6個問題，就需要從身份鑒別，用戶管理，訪問控制，操作審計，資產管理，風險管理這幾個方面做安全能力的建設。

三、阿里云DataWorks數據治理實踐

接下來分享Dataworks如何幫助管理者去解決上述6個問題。

首先介紹一下什么是Dataworks，如下圖所示：

DataWorks基于MaxCompute、Hologres、EMR、AnalyticDB、CDP等大數據引擎，為數據倉庫、數據湖、湖倉一體等解決方案提供統一的全鏈路大數據可視化開發治理平臺。從2009年起，DataWorks不斷沉淀阿里巴巴大數據建設方法論，支撐數據中臺建設，DataWorks十多年沉淀了數百項核心能力，通過智能數據建模、全域數據集成、高效數據生產、主動數據治理、全面數據安全、數據分析服務六大全鏈路數據治理的能力，幫助企業治理內部不斷上漲的“數據懸河”，釋放企業的數據生產力。這次主要分享的是Dataworks中數據安全相關的功能。
接下來我們具體看下上面提到的6個問題：

1、問題1 – 誰？通過什么方式來使用大數據系統

這個問題比較好理解，就是本公司內部的開發、運維、分析師，資產管理員，CIO或者開發者寫的程序來訪問大數據系統，Dataworks支持自主可用的登錄認證體系，例如：部分企業傾向于統一管理一套本地賬號（通過AD，LDAP等），而不愿去管理另一套云賬上的子賬號。DataWorks滿足這樣的訴求，即：允許用戶通過本地賬號扮演一個RAM Role，以角色扮演的方式登錄至阿里云管控臺上使用DataWorks；RAM Role可被加入至DataWorks空間作為空間成員，一個RAM Role可以被多人扮演，也可以被一個人扮演。通過這樣的方式企業實現統一認證管理，做到自主可控。當然Dataworks也支持普通的云賬號登錄方式，RAM同時也支持U2F實體密鑰，多因素鑒別等。登錄完成之后，Dataworks開發平臺與后端的大數據引擎（自研Maxcompute, 開源EMR，CDH等）對接時，身份都可以做到一一映射，保證用戶的身份是可靠的。

2、問題2 – 用戶在哪、通過哪個入口訪問大數據系統

跟大多數產品一樣，用戶會在自己的辦公地點、住宅、或者公網，通過VPN或者公網訪問，Dataworks的入口有管控臺，命令行OpenAPI，Web端，大部分用戶是通過Web端去訪問的，對于不同類型的用戶，可以限制訪問某一個云上的入口。

3、問題3 – 用戶在什么時候會訪問大數據系統

如果按照自然人維度來看，分為工作時間和非工作時間訪問，根據業界相關統計，在非工作時間產生的數據風險，尤其是非工作目的的數據訪問行為會占較大比例，在做一些數據審計時，要求著重去分析非工作時間的訪問行為，例如：0點至凌晨5點的訪問行為會不會存在風險。
如果從資產維度來看，對數據表申請訪問時，一般會填寫數據表使用時長，另外數據表本身也有生命周期，在這兩個時間段內，都是可以正常去訪問數據表資產。

4、問題4 – 哪些資產對象會被操作

資產操作一般是對數據表的操作，除了數據表之外，還有對很多其他實體的訪問也會間接地產生數據風險，例如UDF，有些UDF會有讀表的邏輯，如果UDF授權不當的話，就會有越權訪問的風險，另外Dataworks上也可以配置數據源，如果數據源不做訪問控制，也是很危險的，還有數據服務，Dataworks有發布數據服務API的能力，可以把某張數據表快速生成HTTP Restful的API，發布出去的API也需要做訪問管控。除了以上這些比較典型的資產對象，還有很多其他類型的，比如數據計算任務，如果提交到生產的SQL除了寫入之外，還有讀操作，這樣也可以在運維界面直接讀出數據。還有審批策略，如果策略配置不當，會產生越權審批，另外還有數據質量規則，如果配置不當，會導致產生臟數據或者資損等，所以上圖中列出資產對象都是需要得到保護和訪問管控的。

5、問題5 – 用戶在何時何地可能產生哪些行為

這些行為總結下來，讀寫主要是對數據表的讀寫，執行主要是對軟件功能的執行，例如查出的結果下載到本地，或者發起一個數據跨境導出、流動任務，新增主要是新增導出任務，新增發布API等，刪除更是比較敏感，如果沒有備份，刪除操作后一般都無法恢復，這些行為如果不當組合的話，會導致數據風險，數據安全治理的目的也就是逐步收斂這些風險。

6、問題6 – 如何治理

所以企業的CIO或者安全合規部門應該都非常明確，誰應該在什么地方，應該在什么時候，應對哪些對象，應該做些什么，后面會著重來講述，如何支持這個“應該”的“應”，來實現和落地。

如下圖所示，首先數據安全治理的第一步都是去梳理資產，哪些對象應該被保護，應該被訪問，相應的在Dataworks平臺上做開發和治理，第一步就是劃分工作空間和項目空間，因為所有的代碼和數據都會存儲在項目空間中，目前有三種劃分方式，方式一是按照業務場景劃分，方式二是按照數倉層次劃分，方式三是按照業務部門劃分，目前采用最多的是方式二，其中ODS層，一般來說只需要業務系統開發的人員，用來配置相關數據集成（業務庫數據源配置和同步），數倉開發人員不需要加入，其他層例如CDM，ADS層主要是數倉開發人員做數據開發，這個也可以按照各企業實際情況進行劃分。只要把不同的人員加入不同的空間，就可以做到隔離。

數據安全治理的第二步是需要梳理另外一個很重要的資產就是數據，數據梳理就是對數據做分級分類，目前Dataworks中OEM了螞蟻集團的數據保護傘敏感數據保護的能力，用戶可以通過配置關鍵字，正則表達式，或者內置專家模版，語義特征模版，內容識別模版等，快速幫助用戶識別敏感信息，如下圖所示：

管理者只需要6步簡單的配置，就可以完成敏感數據規則識別的配置，如果是金融企業的用戶，還可以根據內置金融行業模版一鍵完成設置，如下圖所示：

接下來，我們來看下“誰應該對哪些對象應該做什么”這個問題的答案。

DataWorks在產品管控、功能使用等方面提供了完善的權限管控體系，其中產品管控通過阿里云RAM Policy實現，管控對象是控制臺操作，如創建工作空間等；功能使用權限通過RBAC實現，通過定義成員角色并授權來管控功能使用，并根據產品功能范圍分為全局級和空間級。
對于企業的IT運維團隊，可以對工作空間或者獨享資源組，進行細粒度的授權，例如，工作空間列表頁面中創建空間、禁用空間、刪除空間等操作；資源組列表頁面中的創建獨享資源組、配置獨享資源組網絡等操作；報警配置頁面的配置聯系人等操作，如下圖所示：

對于數據團隊，做數據開發的時候，可以根據DataWorks預設的部分全局角色和空間級角色，可以直接使用這些角色給用戶授權，也可以根據需要，自定義全局角色或空間級角色。用戶、角色、權限之間的對應關系，如下圖所示：

推薦最佳實踐是按照下圖所示的去做，如圖是標準模式的開發流程，首先一個DW空間對應了兩個引擎環境，一個用于開發，另一個用于生產。

在數據建模鏈路，先由數據團隊主管定義好建模過程中可能使用到的數據標準，隨后由數據建模人員設計模型，并對模型進行提交，最后經由數據團隊主管、運維或部署人員審核無誤后即可發布到生產環境。

在數據開發與生產鏈路，開發人員在開發環境先執行代碼開發、依賴配置與調試，冒煙測試無誤后可執行提交發布申請，此時應由一個運維/部署/管理員角色來進行代碼Review，確認無誤后即可執行發布到生產環境，讓規范、安全的代碼在生產環境定期運行產出數據。

這里面需要注意的一點是針對不同角色的人員，只分配對應的角色給相應的角色，例如不可以給數據開發人員空間管理員的角色，或者既分配開發角色又分配運維角色，而是只分配開發角色。

對于數據分析師，經常會用到數據開發人員開發好的新的數據表，默認都是沒有權限的，這時可以在Dataworks安全中心里面，進行表或者字段權限申請，如果企業已經做了數據分級分類，還可以自定義數據審批流程，例如對于級別較低的表，表Owner審批就可以了，對于級別較高的表，需要部門安全負責人審批，級別最高的表，需要CIO的審批，這樣就不容易出現越權審批的情況。

接下來是回答“誰應該在什么地方來訪問”這樣一個問題，這個問題也是很多高安全要求的企業的強訴求，目前Dataworks中支持了IP白名單訪問，以及訪問具體哪個入口（Web端和API端），如下圖所示：

前面講述的都是事前安全，這樣就足夠了嗎？很明顯，是不夠的。當今主流趨勢是過程安全，也就是之前提到的零信任。

在Dataworks中，也基于機器學習模型，統計模型，還有一些基線分析方法，構建了用戶行為識別機制，幫助管理者找出風險點，以及設置對這些風險點進行響應，如下圖所示：

其中響應的方式有審批、去標識化（即脫敏）、告警和阻斷。

下面主要來看下對于數據直接風險行為的響應，也即大家所熟知的脫敏，在很多法律法規中稱為去標識化，目前支持了加密、掩蓋、哈希的脫敏，場景一般分為數據分析場景和開發測試場景，如下圖所示：

在數據分析場景下，數據分析師一般來說是不需要查詢明細數據的，如果需要查詢明細數據，例如查詢手機號，可以把手機號中間的字符，替換成類似“*”這樣的字符，用來掩蓋。對于開發測試場景，開發人員在生產環境中導出數據進行開發或者測試的時候，導出的操作可以通過靜態脫敏來支持，導出的數據以脫敏的形式寫入到開發環境的存儲中。

下圖是一個實際的效果：

另外一個對數據直接風險行為的響應是告警和阻斷。這個也是近期一直在探索的，對于告警的行為，可以在Dataworks數據保護傘中做自定義的配置，也可以通過默認的規則模版，例如非工作時間去訪問數據，可以把非工作時間段設置為0點-6點，如果有這樣的訪問，就可以把它通過告警報出來，而針對阻斷來說，對于大規模查詢結果展示、下載、復制的阻斷，用戶可以對不同的角色設定不同的閾值，如果超過閾值，可以阻止這些行為，如下圖所示：

下面所展現的是針對數據通過非直接的訪問行為導致的風險的響應，目前是通過審批策略來支持，例如數據導出，開發者可以創建數據同步任務，目前支持管理者把任意的數據源配為源端和目的端來實施管控，也可以配置不同的人來進行審批，也包括數據API的發布（不同的數據源構建的API可以通過不同的人進行管控和審批）和數據跨境傳輸（由企業合規管理員去審批，后面也會幫助用戶自動識別哪些同步鏈路是跨境的）。

下圖是Dataworks安全能力概覽圖，其中標黃的部分是之前沒有提到的，例如成員離職轉交，風險處置等。

下面介紹四個不同類型的重點客戶數據安全治理的案例。

四、阿里云數據安全治理場景與案例

具體案例以及詳細內容如下面4張圖所示：

總之，數據安全治理體系是從制度，產品和運營三個方面來進行的，需要三個部分的共同協作，缺一不可。制度上確定了哪些是可以做的，哪些是不能做的，隨后用產品去具象化這些制度，最后運營根據這些制度去獎懲、優化。這樣就可以形成一個制度、產品、運營協同的數據安全治理體系的閉環。

阿里云DataWorks結合各引擎為企業提供一站式開箱即用的安全能力，這些能力可以覆蓋DSMM中所述的幾個重要的數據安全過程：傳輸、存儲、處理、交換、通用等。從另一個維度來看，Dataworks產品安全能力也覆蓋了事前、事中、事后結合的工作周期，從事前與事中的規范化開發生產、數據可用不可見，到數據風險行為管控，再到事后的敏感數據管控，為企業提供了周全的數據風險控制能力。

五、Q&A

Q1：開發和生產環境兩套環境中，開發環境數據是怎么來的？

A：開發環境的數據可以自行造一些數據，或者使用Dataworks數據集成工具，從業務生產庫中同步數據，同時開啟靜態脫敏。也可以通過命令行或者頁面自行上傳數據。

Q2：數據分類的方法，一般是線分類還是面分類，有些場景線分類不一定能Cover？

A：需要根據不同行業的規章制度來看。

Q3：不同行業有無分級分類的指南，例如廣告行業？

A：金融行業比較多，保險、醫療、健康、汽車行業都有，廣告行業不是很清楚，需要進一步了解。