數據安全,數據銷毀怎么做

一、熟悉業務

其實這么多年信息安全、數據安全做下來，跟很多同行有過不同程度的交流，業內的分享也很多了，我覺得現在已經不能說“不知道怎么做數據安全”了，但是確實依然有很多同行在問“應該怎么做數據安全”。我對這個現象的研究和判斷是：因為數據安全和業務結合太緊密，技術人員很難把握實施數據安全措施的尺度，無法在安全和業務中取得良好的平衡。本質上是因為對業務不了解、不熟悉，或者是公司管理層、業務管理層人員沒有參與到數據安全決策中。所以做數據安全的同事，一定要對公司的業務有充足的了解，要了解公司各類業務的流程，以及在流程中的物流、人流、數據流、資金流。

這里就有必要提一下Gartner提倡的DSG方法，理念肯定是正確的。如果完全不懂業務或者對業務只是一知半解，就著手做數據安全，大概率沒有辦法真正、有效解決數據安全風險。從網上拷貝了一張圖，見下圖。

運用DSG方法的時候，要特別注意：涉及數據安全風險的業務有很多，短期內機制、流程卡點不完善的情況下，很難全面熟悉業務、評估風險，因此熟悉業務也要有針對性，這時候往往根據法律法規強制要求、公司當期經營重點、過往或同行多發的場景、近期主要執法案例等因素選擇重點業務先入手、做起來，也就是DSG的框架第一層描述所包含的那些維度。一定要保證當下選擇的業務及數據真的重要，也要讓關鍵干系人覺得重要。為什么？因為只有選擇了這些重點業務，短期內數據安全才能出成績，才能得到后續長期的支持。

運用DSG方法的過程中，要注意這不是一個靜態的方法論，而是一個類似PDCA循環的動態方法論。這個方法論告訴我們的是：一要意識到數據資產的動態性，數據資產的流動、使用隨著業務的變化而變化，很難能找到一個完全的卡口，因此要持續了解、感知、熟悉業務；二是單位里面往往都是業務在先、數據安全在后，業務都上線運行了，數據安全再去推廣落地、就會面臨壓力，所以需要很好的業務切面和技術切面的能力（業務切面我在7.2會講，技術切面我在11.1會講）；第三，因為數據和業務緊密綁定，業務在動態變化過程中，數據面臨的安全風險也會動態變化，因此要在業務動態變化的過程中實現數據安全的動態平衡，就要有機制、有技術手段感知、介入和控制風險。

二、定義數據安全

了解完業務之后，是不是馬上就要開始數據安全的工作了？根據我的經驗，不是。為什么？因每家公司對“數據安全”這個詞的定義是不一樣的，雖然《數據安全法》對“數據安全”的定義是：數據安全是指通過采取必要措施，確保數據處于有效保護和合法利用的狀態，以及具備保障持續安全狀態的能力，但這個定義仍然有待進一步拆分和解讀，什么叫“必要措施”、“有效保護”、“合法利用”、“持續安全”？因此必須要通過回答如下問題來明確數據安全工作的邊界，明確數據安全工作對什么結果負責。

1、“數據”是指哪些內容的數據。個人信息、商業秘密、國家秘密？商業秘密中的哪些？這里其實本質上說的不是該被保護的“內容”，而是基于不同組織利益而要求保護的信息。比如自身組織利益，就是商業秘密；客戶利益，就是和客戶協議定義的客戶信息；個人利益，是個人信息；國家利益、公眾利益，就有數安法定義的核心數據、重要數據；保密法定義的國家秘密；還有美國14117行政令定義的美國“政府相關數據”。這其中不同類別的數據也會有交集，有些國家關基單位的商業秘密可能同時就是國家的重要數據；有些互聯網或者物流企業，其掌握的個人信息本身也是該組織的商業秘密。

2、“數據”指哪些形態的數據，電子化數據、紙質數據？指服務器、應用系統中的電子數據，還是也包括終端、合作方系統中存儲流動的電子數據？是包括結構化數據，也包括非結構化數據（通常指各種文檔、研發設計圖紙）？是僅在公司業務系統、公司終端中存儲流動的數據，還是也包括提供給客戶、合作方的客戶端、App中存儲流動的數據？如果包括紙質數據，往往會超出IT部門的能力范疇，需要慎重考慮。

3、數據安全的管控邊界在哪里、是什么？這里的管控邊界通常是指安全策略、措施能夠管理的范圍，包括網絡范圍、物理邊界、存儲介質形態。比如電子數據、紙質數據管到哪些，在線數據、離線數據管哪些？比如研發設計圖紙要交給合作伙伴，對合作伙伴管到什么地步？比如服務器外出維修或報廢、移動存儲介質外出維修，這些邊界要不要管到？有沒有一些數據只流經公司、但沒有落地存儲，那這些數據要不要管，管到什么地步？比如有跟第三方公司開展隱私計算業務，那數據安全在隱私計算過程中要管到哪個環節？

4、“安全”指的到底是什么特性，機密性、完整性、可用性、抗抵賴性、可追溯性、合規性、可見性中的哪些？不同的行業，不同的安全分工，不同的團隊職能對這個問題的回答可能都是不一樣的，所以要回答清楚。這里要特別搞清楚“公司領導想要的數據安全里的安全到底是什么”？舉個例子，安全團隊可能只對機密性、可見性負責，研發團隊對完整性、抗抵賴性、可追溯性負責，運維團隊對可用性負責，領導的意圖是“都想要”，那數據安全工作交給安全團隊總體負責，安全團隊在實際工作中，不但要承擔機密性、可見性的工作，還要對研發和運維團隊的工作進行監督、督促。

在實踐中，我們發現“安全”有時候還包含“自證清白”的內涵，也就是當接到投訴、舉報或外部監管檢查的時候，數據安全團隊必須要能夠舉證自己的管控措施是有效的、合規的、充分的，從而幫助公司盡可能免責、保護公司利益，這點內涵也要充分識別與考慮，尤其是金融、互聯網平臺等類似的單位。

5、“數據安全保護的效果”是什么，得描述清楚，至少要用明確的、盡可能量化的描述方式跟老板對齊目標和效果。“不發生被監管通報處罰的數據安全事件”，“數據被竊取、勒索造成的損失每年小于公司營收的0.3‰”，“晚于監管機構發現的互聯網、暗網數據泄露事件每年為0”，“敏感數據的訪問和操作可對應到人、數據可追溯1年”，“對敏感數據的常見異常訪問、操作可在發生后48小時內發現”等類似的描述方式都是可以借用的。這里給出這些例子，核心目的是像定義KPI一樣跟老板對齊數據安全工作的目標和效果，否則只是一個含糊的“不出事”“別丟數據”，是沒有辦法干活，出了事也是沒有辦法界定責任的。這個指標最好還是能不斷提升的，這樣才能持續驅動改進。

6、在完成上面這個步驟之后，還要再考慮一個問題。在現階段，“數據合規”這個詞的含義基本等同于“個人信息保護、隱私保護、跨境數據合規、個人信息合法合規采集使用”，數據安全團隊必須要明確“數據安全”和“數據合規”工作之間的關系，是包含還是交叉，對于交叉部分、由哪些團隊分別對什么負責。如果數據合規和數據安全是兩個團隊的話，一般建議的操作方式是：數據合規團隊（可能是法務團隊，也可能是其他技術團隊）負責解讀、提出合規和業務需求，數據安全團隊（一般在IT部門內）對技術實現負責，非技術部分的實現由數據合規團隊負責。同時也要敏銳地注意到，“數據合規”現階段仍主要圍繞“個人信息”、“隱私信息”的保護，而“數據安全”往往不只是保護個人信息，因此兩者按照上述分工是一種比較合理的協作方式。

關于不同團隊分工的話題，本文的幾位作者提出了一些不同意見，也是很有趣：其實也可以考慮用一個團隊來統籌管數據治理、數據合規和數據安全，就是成立一個獨立的數據管理團隊。因為數據安全本身就是數據管理的一個屬性，很多數據的梳理，數據流轉的梳理，可以和數據團隊的業務一并來做，或者用較為相同的流程方法來做。

有幾位作者也認為：在不同的公司里面，也要切實考量下數據合規團隊和數據安全團隊劃分邊界之后的可操作性。把非技術的交給合規，技術的交給數據安全團隊，恐怕這樣的邊界比較難以厘清。因為技術是實現業務目標的一個手段，有時候非常難以切割。就以數據分類分級這個業務目標來說，因為最末端流程一定是要涉及到業務一線的，只有業務一線能知道自己的業務流程是否會接收或產生商業秘密、重要數據、個人信息、國家秘密等，那這個工作發起者，推動者到底是合規團隊，還是數據安全團隊？是否數據安全團隊只負責提供工具，其實是由合規團隊向下推進呢？但實際情況，可能早在合規之前，數據安全團隊已經存在了，幫助業務單位識別了商業秘密等，來了合規團隊，又是另一個方法去識別合規相關的數據？

看起來，關于分工問題沒有定論，每個組織選擇一個自己合適的方式就好，但是一定要講清楚。很多單位數據安全做不好，一個很重要的原因就是天天在扯皮。

7、在某些央國企、事業單位，大概率還有保密辦這么一個組織，主要落實對國家秘密、商業秘密的保護要求。單位里面類似的組織多了，就很容易扯皮，那么數據安全和保密辦之間是個什么關系？我一直以來的建議就是：盡可能簡單點來，只要老板給我資源和支持，我不怕多扛職責。有更多機會鍛煉提升自己，是好事哇！因此一般來說，我建議把保密辦當做一個業務部門看待，也就是上面說的：保密辦提需求，技術部分由數據安全團隊負責實現，非技術部分由保密辦負責實現。

上面提出了很多需要思考和注意的問題維度。最后總結一下，定義“數據安全”是為了劃邊界，劃一個做什么、不做什么的邊界（其實任何工作職責都得有這么個邊界，我以前講過“怎么做規劃”的課程，也有這么個環節，其實都是一個意圖）：

1、明確定義數據安全工作中需要保護的對象是什么；

2、針對這些保護對象，數據安全工作中到底要解決哪些風險？

3、針對這些風險的控制活動由誰定規則、由誰執行、誰對最終結果負責，本質上這是一個組織分工問題。

三、開展數據安全規劃

業務也了解清楚了，“數據安全”的定義也定義好了，該開始下手買工具、建系統了吧？不、不、不，還早著呢。下一步工作是做規劃。

很多人不理解為什么要做規劃，我拉著團隊內部討論一下、統一一下意見，不就搞定了？一定要做個數據安全規劃出來嗎？答案是“一定要做”。因為規劃的目的和意義在于“統一思想”，數據安全規劃的目的和意義在于“統一和管理層、協作團隊、業務部門的思想”，統一對于“數據安全”定義的認知，統一對于數據安全工作開展過程中的各方職責、定位和協作關系的認知，統一先解決哪些數據安全問題、后解決哪些數據安全問題的認知，統一重大數據安全策略、尺度的認知。

傳統意義上，網絡安全、基礎安全更多屬于技術層面的工作，可能1、2個技術團隊拉在一起就討論、確定了。數據安全本身和公司業務關系緊密，必須要通過“制訂規劃、匯報規劃、確定規劃”的套路把以上這些問題解決掉才能往后推進，否則一定會在執行過程中遇到多方阻力，因為你上安全手段就會對業務便捷、數據流動、系統穩定造成負面影響。所以，一定要通過數據安全規劃這個動作要解決這些推進過程中出現的風險。至于怎么做規劃，我以前的文章都寫過，就不細說了，特別提醒的一點是：規劃中要基本明確針對各類數據安全風險的控制措施，盡可能細化、明確，如果確實精力、能力不夠，可以先把確定要干的明確了，剩下的寫個大概，然后在不斷的技術交流、評估測試、技術選型、同行交流過程中磨合、確定。

有人會問，做個3年規劃耗時耗力，有沒有簡便的辦法？也可以，那就是每年滾動規劃。每年底做預算之前，花一定的時間，完成下一年度的數據安全規劃，在年度規劃中把以上這些問題逐步解決掉。但具體如何切分，就看自己把握了。

數據安全規劃中要特別注意的一點是，數據資產的流動和使用與業務緊密相關，業務過程靈活調整、數據資產彈性變化、訪問使用多元多面都可能導致數據安全規劃會失效，所以數據安全團隊一定要有機制流程和技術手段感知、適應以及應對這些變化，怎么做？再就是企業內部一般都是業務系統已經建好了，業務流程已經基本建好了、運行了一段時間了，這時想再推廣、落地數據安全控制措施，就會面臨很大的阻力，那么應該怎么辦？這些問題在6章數據流動，7.2業務運營 和11章 切面技術思想 中有描述。

四、分類分級

做完規劃，就進入執行階段。執行階段的第一步是什么，一定是分類分級。

分類分級怎么做，其實很多人都說過了，概括來說無非就是人工分，或者結合系統和流程用機器分。這個環節很多人都寫過文章，我就不細說了。但是我發現很多人其實對分類分級的本質并沒有正確的認識。到底什么是分類分級？為什么要做分類分級？

分類分級其實不是一個新概念，但凡資源有限的領域，想更好地開展工作，一定是要把手頭的任務區分重點和次要，并做優先級排序。數據安全的分類分級本質上也是識別需要重點保護的數據和優先級。

分類其實很簡單，公司有哪些業務活動、經營管理活動，就有哪些類別的數據；分級就是區分在這些業務活動、經營管理活動中有哪些數據在流動，這些數據從安全保護的重要性來說屬于1、2、3、4什么級別。傳統的分類分級會根據這個結果輸出一張巨寬、巨長的Excel，到這里就結束了，也可能把這個Excel存到數據庫里面，以便后續共調用。

但實際上，我認為這樣的分類分級是有嚴重缺陷的。正確的分類分級應該是

（1）識別公司有哪些業務活動、經營管理活動對公司是最重要的、當前和未來一個階段最有價值的；

（2）對這些重要的業務活動、經營管理活動進行理解和拆分，將這些活動拆解為人流、物流、資金流和數據流，最后形成一個數據流圖，并附加說明數據在流動中有哪些人、崗位角色可以訪問、操作這些數據；

（3）對數據流圖中的數據進行分級、定級；

（4）將分類分級的結果，以某種結構化、容易被自動化識別的方式保存下來，便于后續在自動化的識別過程中調用；

這樣的分類分級方法，其實應該是在第一章“熟悉業務”中完成的，這才是真正有靈魂的分類分級，是站在業務視角、保護業務利益的分類分級。不講業務過程的分類分級，不止效率最低，對后續的數據安全保護動作也很難形成有價值的輸入。

以上的分類分級完成后，基本還只是一個靜態的數據分類分級成果，也就是“知道”了哪些數據是需要被保護的，但在實際應用中，還有一個動態識別的過程。比如從系統A通過API讀取了系統B的數據，那么這些API里面包含了哪些類別的數據，這些數據分別定級是多少，有沒有未定級的數據？也都需要被識別出來。識別出來之后，就可以按照后續的數據安全策略予以保護；如果發現有未分類分級的數據，也要按照既定的策略對數據訪問操作予以控制。那么具體怎么做，在第六章里面闡述。

分類分級的流程和方法也可能跟以上的做法不一樣，不過我們認為最本質的一點是相通的，要基于業務活動來識別、分類、分級。

五、確定數據保護措施

5.1 基本認識

做完分類分級、識別了需要保護的數據之后，緊接著就是要確定數據保護措施了。趕緊的，上工具、上手段！這是不是很多人的第一反應？

慢點，慢點，你是不是快了點，這里面是不是缺了點啥？

從邏輯上分析，應該先做數據安全威脅建模，然后才是確定數據保護措施。威脅建模這個步驟一定不能省！不一定要寫下來，即便你在腦子里面過了一下，這個建模的動作也必須要有，否則怎么可能知道在上一個步驟中輸出的數據流圖中的數據有哪些安全風險？安全風險不清晰、準確的話，怎么保證數據保護措施是恰當、合理的？當然，如果數據安全工作涉及人員較多或者跨團隊的話，這個威脅建模的結果最好寫下來、有評審，避免遺漏。關于如何做數據安全威脅建模，參見

https://mp.weixin.qq.com/s/jLsf_LQZZycLAdNKQrOJ2g。注意個細節，這個威脅建模不只是分析了威脅，其實還同步評估了風險。

完成數據安全威脅建模之后，就要確定數據保護措施。大多數人對數據保護措施的反應就是“上安全工具”！這也是一個要不得的誤區。我們之所以說數據安全難做，就是因為數據是在業務過程中流動的，數據的流動、使用就代表著業務活動，上工具就很容易對業務活動造成阻礙；而實際過程中很多數據安全風險就來自于業務活動中對數據的不當使用、流動和授權。所以考慮數據保護措施的時候，首先應該考慮對業務活動的流程、工具、方法是否可以做改造、優化，降低數據風險暴露面、減少不必要的授權，這往往是最有效的數據安全保護措施。只有無法、不愿改變業務活動的情況下，才需要動用外掛式的安全工具來達到保護數據安全的目的。

當然，確定數據安全保護措施的過程中，有一個風險容忍度的平衡。不同的人對于風險接受度是不一樣的，因此在這個過程，是需要和管理層做充分溝通的，這個一定是需要管理層參與和決策的。數據安全保護措施和其他安全措施的類型是一樣的，要綜合采用規避風險（包括業務最小化滿足、技術方案的設計安全等前置工作），降低風險（例如采取功能優化，使得影響程度小、影響面小、影響對象重要性低），接受風險等組合型措施。

如果翻閱一下市面上各類數據安全管理技術規范、標準，都會提到“數據全生命周期保護”。這個提法的初衷是沒錯的，因為確實存在數據采集、傳輸、存儲、使用、分享、銷毀這么一個鏈條，如果忽略了其中任何一個環節，就容易造成數據安全保護措施的缺失。因此，在對數據安全威脅建模的過程中，不但要考慮業務活動中的數據安全風險（這里大多涉及的是采集、使用、分享），還要考慮IT基礎設施管理與服務中的數據安全風險（這里大多涉及的是傳輸、存儲、銷毀）；要根據企業數據安全工作的目標，不但保護機密性，也根據數據安全規劃定義的目標，適當地保護可用性、完整性、可追溯性、抗抵賴性、可見性。

上一章講分類分級的時候，特別提到“將分類分級的結果，以某種結構化、容易被自動化識別的方式保存下來，便于后續在自動化的識別過程中調用”，在確定、實施數據保護措施的時候就能用到。比如在數據流動的監測中，對某個API訪問的數據進行監測并和庫中的分類分級樣本進行比對，發現有敏感數據則根據保護策略自動啟動相應的告警、加密等保護措施，過程完全自動化實現，效率和質量都有很大的提升。

5.2 場景抽象

傳輸、存儲、銷毀的環節以及保護措施相對明確，本文就不做贅述了。基于過往對數據安全的認知和經驗，我把企業內部數據采集、使用、分享的場景做了一個抽象，將各類業務活動、經營管理活動中的數據采集、使用、分享環節抽象成如下圖所示的一個田字格。

網絡架構簡述：企業內部網絡分成辦公網、生產網兩張大網，中間有效、邏輯隔離，每張大網的安全管控要求有差別，可以理解為生產網是高密區、辦公網是低密區；每個大網細分終端側、應用側，中間有效、邏輯隔離；紅色圓角方框代表企業網絡邊界、辦公場地邊界；藍色帶箭頭粗線代表數據流向；辦公網、生產網的終端統稱“員工辦公終端”。

場景A1：員工辦公終端訪問互聯網；

場景A2：員工辦公終端的數據離線存儲（拷貝到U盤，打印復印掃描紙件）；

場景B：員工辦公終端帶離公司管控邊界以外；員工通過個人手機、個人電腦以遠程方式訪問公司內網資源；第三方人員以遠程方式訪問公司內網資源；

場景C：員工辦公終端訪問公司應用系統、公司數據；IT特權運維人員訪問操作數據；

場景D1：在同一個大網內應用系統之間的數據流動；

場景D2：跨大網的應用系統之間的數據流動；數據從不同應用系統進入數據倉庫（數據湖）；運用公司數據訓練AI模型；

場景E：應用系統被互聯網用戶訪問；

場景F：應用系統被第三方合作機構訪問，或訪問第三方合作機構；

以上對數據安全場景抽象、解耦的邏輯、思路、方法，可能每個單位不太一樣，本質上還是基于不同類型數據、不同威脅和業務場景來做管控。

5.3推薦策略和順序

將這些場景抽象以后，我推薦的策略實施重點和優先順序是

1、先控制A、B、E、F的風險，因為數據出了管控邊界；AB的保護措施實施起來相對容易，可以先做；E、F會復雜一些，可以放在第二步。在完成這些保護措施的同時，調研熟悉C、D的場景，做威脅建模、評估保護措施。實施ABEF的保護措施，可以為CD保護措施贏得時間和空間。當然，第一步并不只是針對這個場景，還是要看業務需求、公司領導的需求綜合判定，但選擇第一步的原則就是“先救命、再養生”。

2、再控制C、D的風險。這2類場景最復雜，技術實施難度也很大。

3、A、B類主要管員工、服務商，可控性強，策略可以選擇脫敏、加密、隔離、阻斷、嚴格審批為主，強勢一些；E、F類主要管用戶、合作機構，可控性弱，策略以監測、阻斷、審計可追溯、簡單審批為主，略微弱勢一些；C、D場景復雜、數據類型復雜，策略以監測檢測、數據流動可視化、收斂暴露面、備案告知為主，配合獎懲、績效考核等管理措施驅動治理和改進，減少對業務、系統的打擾，又能達成數據安全目標。

以上保護措施舉例的更多是技術類的保護措施，很容易造成大家的誤解，因此需要特別強調一下，保護措施也包括流程類、管理類的保護措施，比如數據訪問的權限控制既要有工具控制、也要有授權審批，比如對數據接口類的API要在變更流程后配套一個滲透測試的檢查環節，比如要在立項環節對系統架構和方案進行評審、控制數據安全風險，比如在員工申請從生產環境提取數據后要自動追加一個“30天確認刪除”的動作。這些流程類、管理類的保護措施，有的是通用類的（比如立項評審、授權審批），有的是業務專用類的（比如API變更后的滲透測試），但都是建立在數據安全威脅建模的基礎上確定的保護措施。數據安全保護措施也應該參照安全左移的思想，盡可能在在項目初期完成數據的識別與威脅建模、隱私保護設計（Privacy by Design），并配套相應的數據安全工具；參照安全右移的思想，確保技術保護、流程改進、業務提升類措施是閉環的、持續改進的。

5.4多云數據安全

云上數據安全和傳統最大的差異在于基建的變化，在治理思路上打破了傳統安全的人為分類，尤其是在基礎設施安全和數據安全之間的分類，更考驗的是技術的管理執行。多云的數據安全其實是互通的，前提是需要先了解和熟悉單云的數據安全風險及差異。

深入理解云上的數據安全風險，一個關鍵的認知很重要，云上的產品從誕生之初就肩負著“獨立生存的使命”，要在這種使命下看他們的風險，云上產品既可能單獨存在風險，也可能因為組合使用后構成新的風險。

在云環境下，傳統的終端數據安全場景風險即5.2中的ABC依然是存在的。不過，在終端數據安全場景下時，需要將云平臺視為一個應用來進行管理，C模式下的風險更甚。因為，從云廠商的視角看，云管控臺可以通過任何地方、任何終端訪問，所以通過終端上的泄露場景是首先需要解決的風險，要保證可控數據落在可控端。

在云環境下，還會面臨傳統IDC場景下永遠不會面臨的問題，正如下圖所揭示的“企業云化數據安全管控”中總結的5大挑戰，云上傳統的網絡邊界會被打破，有很多種的方式：

●AK是打破大門的第一環，未經任何限制的AK可以在任何地方、任何設備自由的出入云上環境，當然更會有各種隱藏模式，防不勝防；

●除了AK之外，還有存儲桶Bucket，云上數據泄露80%來自于此。

這些都是需要單獨拿出來去關注和管理的云上數據安全場景。管控方案也很簡單，正如“新視角下企業云化安全管控框架OCBC”（https://mp.weixin.qq.com/s/QcMkBOH6KzMMwSJUjqp9Ug）中提及的，要做好這塊的工作，首先需要關注“3控”（控邊+控權+控桶），同時處理好“雙非”風險。

在云環境下，最后一個需要關注的就是云產品，所有云產品拿來即用的思路也是不可取的，很有可能因為一個新的云產品的引入打破原有的已經固防的安全邊界，造成新的攻擊面和數據泄漏點。所有，尤其需要關注云產品的“選、用、留”，做好云產品的數據安全基線就非常關鍵了。

每家云平臺都可能存在安全漏洞，只是存在多與少、發現早與晚的問題。但是，更多的時候，其實是作為甲方企業沒有安全、合規的使用云而造成的安全漏洞或數據泄露，云平臺間接成了”背鍋俠“。所以，堅持做好用云數據安全第一責任人的角色定位是重要的。

六、關于數據安全可觀測

講一個近年來經同行啟發后的思考成果：數據安全可觀測其實也是一種有效的數據安全保護策略。

比如上面這張圖，是N年前我們經過訪談梳理出來的用戶信息流轉圖。只是這么一張粗略的流轉圖，完全足以指導我們后續的數據安全規劃和保護策略的實施，重要性不言而喻。當時畫這張圖，是為了便于數據安全同事理解、便于向老板匯報，但是用下來效果特別好。對這個現象，我們也進行了持續的思考。

傳統的數據分類分級方法主要聚焦于對數據本身的理解，依據數據的敏感程度、重要性等屬性進行簡單分類，其核心目的是便于企業初步識別和管理數據。然而，這種方式存在明顯的局限性，它未能充分考慮數據的載體以及數據在企業內部和外部的流轉情況。在復雜的業務環境中，數據的載體多種多樣，數據的流轉路徑錯綜復雜，缺乏對這些關鍵信息的了解，企業難以構建全面有效的數據安全防護體系。因此，有必要建立“數據安全可觀測能力”。

與之形成鮮明對比的是，現代數據安全觀測能力涵蓋了“我有什么數據（數據標簽分類分級）”“在哪里（數據資產清單）”“如何流動（數據流轉地圖）” 這幾個核心能力，實現了對數據全生命周期的可視化管理。

（1）數據標簽分類分級是數據安全觀測的基礎。通過更細致、精準的分類分級體系，企業不僅能像傳統方式那樣識別數據的敏感程度，還能基于業務場景和風險特征為數據添加豐富的標簽。例如，對于金融企業，除了將客戶的身份證號、銀行卡號標記為高敏感數據外，還可以根據數據的使用場景，如線上交易、線下業務辦理等，進一步細分數據標簽。這樣，企業能夠更全面地理解數據的價值和風險，為后續的安全防護提供更精準的依據。

（2）數據資產清單則明確了數據的具體存儲位置和所屬系統。它就像是一份詳細的數據“地圖”，記錄了企業內各個數據資產的詳細信息，包括數據的存儲介質、所在服務器、關聯的業務系統等。有了數據資產清單，企業可以快速定位重要數據，了解數據的存儲環境和訪問路徑，及時發現潛在的安全隱患。比如，當發現某個服務器存在安全漏洞時，通過數據資產清單可以迅速確定受影響的數據范圍，采取相應的防護措施，避免數據泄露的風險擴大。

（3）數據流轉地圖是數據安全觀測的關鍵能力之一。它通過實時監測和分析數據在不同系統、部門、地域之間的流動軌跡，幫助企業掌握數據的去向和使用情況。以電商企業為例，數據流轉地圖可以清晰地展示用戶從注冊、瀏覽商品、下單、支付到售后整個過程中數據的流轉路徑，包括數據在各個業務系統之間的傳遞、存儲和處理。通過對數據流轉地圖的觀測，企業可以及時發現異常的數據流動，如數據流向未經授權的第三方，從而及時采取措施阻斷數據傳輸，防止數據泄露。

總結來看，數據安全觀測能力不僅僅是對數據的了解，更是實現數據安全防護和運營的基礎。在理解業務的前提下，通過數據安全觀測，企業可以制定更有針對性的防護策略。例如，對于頻繁流轉且涉及敏感信息的數據，可以加強加密和訪問控制措施；對于存儲在高風險環境中的數據，增加備份頻率和安全防護級別。同時，數據安全觀測也為數據安全運營提供了有力支持。通過對數據標簽分類分級、數據資產清單和數據流轉地圖的持續監測和分析，企業可以及時調整安全策略，優化安全流程，提升數據安全的整體運營水平。因此，企業建立數據安全可觀測能力，將數據的分布、流轉以直觀、量化的形式展現出來，本身就是一項重要的基礎工作。有了數據安全觀測能力，依靠對業務的理解就能發現數據安全風險、建立業務切面和技術切面的感知能力，并指導安全人員采取下一步的保護措施；同時數據安全可觀測的成果（比如數據資產清單、數據流轉地圖）可以做到很直觀的效果，很容易打動業務部門、公司領導，很容易驅動數據安全決策。因此我們認為數據安全可觀測也是一種有效的數據安全保護策略。過往我們很容易忽視這一點，現在該加強重視這個能力的建設了。

因此，數據安全觀測是企業數據安全管理的核心環節。它彌補了傳統數據分類分級的不足，通過實現對數據的全面了解和可視化管理，為企業構建了一道堅實的數據安全防線。隨著數據安全威脅的日益復雜，企業應不斷強化數據安全觀測能力，將其融入到數據安全防護與運營的全過程，以保障數據資產的安全，推動企業的數字化轉型和可持續發展。

七、數據安全運營

7.1 技術運營

攻防對抗場景下部署了這些安全工具都要運營，數據安全也同理，更需要運營。無論是DLP、數據庫審計、數據脫敏還是審計可追溯，這些數據安全工具的有效性咋樣？漏報誤報咋樣？告警處置了沒？復盤分析改進了沒？都得按照安全運營的邏輯展開運營。同理，不但要有運營閉環，也要有數據化的度量。度量指標哪里來？請參見第二章“定義數據安全的目標和效果”一節的描述。

這里特別要強調的一點是，安全運營不能只管安全工具，凡是可能造成數據安全工具效果變化的工具、系統也應該納入數據安全運營的范疇。比如要控制U盤拷貝，你是在桌管軟件上實施策略的，但這個系統在桌面團隊運行管理，那他們執行的怎樣，要運營、要監督；比如在應用系統中部署了水印插件，對敏感信息展示的頁面要附加水印，那這個插件作為系統的一部分、屬于系統運維范疇啊，那這個插件是否正常運行要有檢查和運營；比如你部署了一個基于DNS引流的數據安全網關，那DNS服務及其配置的變更就可能影響數據安全網關的運行有效性，則DNS服務及其配置變更后就要有有效性驗證。

容易被忽略的是，數據安全運營活動本身蘊含數據安全風險，常見的場景是數據安全運營人員由于風險告警的響應、調查需要接觸敏感數據。誰來授權、監督數據安全運營人員接觸數據安全工具中記錄的敏感數據，以免引起公司其他領導和同事過度的隱私擔憂與爭議，這本身也是一種數據安全風險，也需要通過合適的規范、機制、工具來予以控制，例如人力資源部門擔心薪酬數據被數據安全工具監控；數據安全運營人員應該在何種受管控的流程、環境下接觸敏感數據，是否僅能在必要的情況下，取得授權并在安全的環境中最小化的訪問使用敏感數據。

7.2 業務運營

除了安全工具、系統的持續運營外，還有一個要特別提醒的運營活動，就是要建立機制、主動感知公司有哪些業務活動、經營管理活動、技術活動存在數據安全風險。怎么建立？一般幾個渠道（1）參與立項評審，設立數據安全風險評估卡點；（2）安排個意識敏感的人，參與公司的研發、運維、AI、外部合作等領域的例會，聽聽其他團隊、部門都在做什么，既熟悉了業務，也及時察覺這些領域存在的數據安全風險，避免被動。（3）在上一章的“數據安全可觀測”部分提到的，建立數據安全可觀測能力，能看到數據分布流動，基本也就七七八八知道哪里可能有風險了。對于這種能力，我稱之為“業務切面”，本意是想說在公司的業務活動中，我們要建立對各類業務活動中數據安全風險的觀測能力，進而幫助提升數據安全保護措施的覆蓋面和有效性。

數據安全運營活動與公司風險、合規等后臺執法部門建立良好的協作機制至關重要，一方面需要從這些部門獲取支持以表明實施監控的合規、合理性，另一方面也需要借助這些部門的執法權力與流程威懾、處罰違法違規人員。

八、數據安全制度和組織運作

數據安全的工作要想做得好，制度和組織運作也是必不可少的。這也是為什么“數據安全工作”經常也會被稱為“數據安全治理工作”的原因。

1、數據安全在絕大部分場景上，基本上等同于業務安全。那么在業務活動、經營管理活動中，誰對數據安全的最終結果負責，需要在組織中通過制度、組織運作確定下來。比如：業務部門說我就要通過這種方式把數據給到合作單位，就要追求快、敏捷靈活，安全團隊說你這樣不行，我們現有的安全手段保護不了你，你得改業務流程、改系統接口。在這種情況下，是安全團隊有一票否決的權利，還是業務部門簽字畫押、承擔風險，還是升級到最高領導決策拍板，組織內部必須明確這樣的責任，明確仲裁和決策的流程。

2、數據安全團隊與數據治理團隊、數據合規團隊的協作關系，也要參照上一條，通過制度或組織運作的形式界定清楚。畢竟，數據治理、為單位內部提供數據服務的過程，本身也是一項經營管理活動，那么在這項活動中的數據安全誰負責、對什么負責，是需要界定清楚的。

3、按照“責權利對等”的原則，明確了數據安全責任之后，誰承擔最終責任，就要給責任部門提供相應的工具、手段，讓他們管好業務活動、經營管理活動中的數據安全風險，技術團隊至少要讓他能看到數據安全風險。因此這時第6章提到的“數據安全可觀測能力”就很重要了，當然，還可以整合數據安全工具的數據，將“數據風險可視化”。

4、數據安全團隊要通過月報、例會、安全委員會等不同層級的渠道，展現數據安全工作的進展、運營狀態和風險問題。所有的匯報都是為了展現業績、暴露問題、驅動問題的解決，數據安全也不例外。

5、持續的、為員工喜聞樂見形式的安全意識教育是必不可少的。

九、技術措施的逐步演進

在這幾年開展數據安全工作的過程中，從安全運營的方法論中也吸取了一點想法，最終有這么一個認識：從整體視野看，數據安全防護能力的建設一定是先解決痛點場景、痛點問題，采購部署工具，就形成了多個場景的單點能力；然后隨著場景的深入解構和實施，我們發現有必要將這些單點能力串聯、編排，形成多場景下的平臺化能力，所以如果要看數據安全的技術架構的話，最終很可能是“基礎工具”-“能力”-“場景”這么一個層次架構。

想列出這個層次架構的目的是想說

1、數據安全技術體系的建設，不太可能一下子想清楚、看明白，大多數人都是一步一步走過來之后，才看到一個完整的數據安全技術體系是咋樣的。

2、如果這篇文章看到這里的話，希望上面這個層次架構能對你有一點幫助，至少在技術選型的時候，可以多考慮一些工具和能力的互聯互通、可整合性，比如API的開放，比如多節點部署，比如策略設置的格式、字段一致性。

3、數據安全保護措施基本都是針對一個個場景，這些場景本質上就是一類業務活動、業務流程，因此數據安全保護措施要做的要么是規范、調整業務活動、業務流程，要么就是適應場景、部署針對性的保護措施。

十、集團型企業數據安全應該怎么做

關于集團型企業數據安全應該怎么做，有以下幾點想法：

1、集團層的數據治理制度、數據安全制度要區分集團和一級子公司、二級子公司之間的關系，主要強調數據安全組織、職責和決策機制、通用的保護&教育&應急要求、運作匯報機制等，不要對具體的數據保護要求做出過多約束，盡可能把這部分職責交給子公司自己決策、落實。因為子公司的業務特性、風險接受程度是不同的，集團層要避免把這些要求做出太硬性的要求。

2、加強與管理層/業務部門溝通，明確需要保護的數據和目標。如果管理層和業務部門不清楚哪些數據需要保護，可以考慮推動數據湖或者數據中臺的建設，再從數據湖或數據中臺梳理出現有的數據，提供給管理層/業務部門參考；

3、明確需要保護的數據后，進行風險評估，開始查漏補缺。這些數據的當前保護措施是否依然有效，或者是否符合管理層/業務部門的期望，列出當前無效的措施或者沒受到保護的數據；

4、根據風險評估結果以及數據的重要性，制定管理和技術控制措施，管理措施一般都是制度與流程，技術措施例如以下：

(1)網絡層：根據數據的重要性，將業務系統進行分類，在網絡層面進行分區分域，做好網絡層訪問控制以及相關的審計措施，攻擊防護和流量分析等；

(2)服務器主機層：防勒索，主機安全，特權管理等；

(3)應用層：應用系統訪問控制，權限管理，攻擊防護，代碼/組件安全（SDL/DevSecOps)

(4)數據層：高敏感數據加解密、脫敏，二次認證，數據防泄漏等；

(5)客戶端側：終端安全管理，高敏感文件加密，防釣魚/勒索；

(6)數據安全運營：數據地圖、流轉監測、數據溯源、事件管理等

十一、對數據安全工具的期待和思考

11.1 切面技術思想

螞蟻集團這幾年力推的“切面技術思想”，是我現階段看到的數據安全領域最好的技術思想，強烈推薦。當然，其他數據安全技術工具還是有不錯的，但在技術思想上沒有新的突破；切面技術思想之前在國外也有應用和普及，但是我覺得螞蟻的同事們在理論和實踐上都有很好的突破。具體可參見https://mp.weixin.qq.com/s/bCZ6gHwXXObE3XCfA2Y8XA和相應公眾號。同時也期待螞蟻的平行切面技術聯盟能夠聯合國內廠家，推動基于切面技術思想的數據安全工具整合、優化。

之所以很喜歡這個技術思想，從第9章的內容描述來看，就能看到。數據安全工具的精細化場景應對，決定了數據安全工具、能力未來會朝著“多個基礎能力控制點+一個控制平臺”的方向演進，切面技術思想正好應運而生。這樣可以做到既不打擾業務、不改造系統，數據安全保護措施也可以動態演進、有效實施。螞蟻把切面技術思想比喻成平行的高速公路，我覺得比喻成“輸液埋管”更合適：通過這根管子既可以監測血液流動和監測指標，還可以輸液、施加控制措施。

11.2 融合框架性技術

在文章的編寫過程中，有作者貢獻了一個非常有價值的觀點：數據安全技術、工具應該融合IT技術領域的框架性技術。

前面多次提到，數據安全工作面臨的主要挑戰之一就是“業務在先、安全在后”，因此對于數據安全控制措施而言，是具有較大的滯后性、有時候可能跟不上業務和應用系統的變化。那為了讓數據安全技術、工具能夠適應變化，就必須要和主流的技術框架做融合，就必須要融合、迎合技術生態，這樣才能具有普適性。國內有的數據安全廠家在JDBC、ODBC層面提供數據安全的能力，這就是一種融合技術框架、具有普適性的數據安全技術；切面技術思想本身也是符合這個技術理念的，在操作系統、Java解釋層做切點切入。

大家看WAF為什么能賣得好？因為HTTP和HTTPS協議是標準化的，可以基于此做解析和風險控制。那為啥數據庫防火墻買不好？因為每個廠家有自己的私有協議，你得一個一個適配，他不是通用性的框架和技術。

當然，在融合的過程中如果又能夠運用切面技術思想，善莫大焉。

11.3數據安全系統的開放性

從上面多個章節的闡述中，我們已經看到非常明顯的趨勢：（1）數據安全工具之間存在數據打通、訪問調用的需求，比如敏感數據識別檢查策略的一致性，比如多個工具脫敏策略設置的一致性，比如告警數據的統一身份關聯、告警數據格式化和標準化；（2）為了被集成、嵌入業務活動中，數據安全工具也需要被其他業務系統、IT工具所調用，一些通用的數據安全能力很可能需要作為服務對內開放，比如加密、動態脫敏、水印展示、數據敏感度檢查等。

從甲方角度來看，顯然是有如上的訴求，也期待各個數據安全廠商能夠意識到這一點，在產品設計、架構上做出改進。從廠商角度而言，做大而全的數據安全產品也不太可能，更多的可能是針對某個、某幾個場景推出有效果的數據安全產品，因此短期內來看，甲方環境下部署多個數據安全產品的局面不會改變，那如果數據安全產品的開放性、可集成性比較強的話，會更容易受到甲方的青睞。