現狀

早在筆者剛入行的那個時期，安全崗位基本只有兩種，WEB安全工程師和Android安全工程師，回憶一下前幾年企業出現的風險事件、大多是安全工程師參圍繞應用安全漏洞，以及如何在漏洞攻與防之間進行技術博弈。普遍受限于當時年代對安全的認知，很少有人真正關注到用戶數據對一個企業真正的重要性。

現如今隨著GDPR、個人信息安全保護規范等一系列的實施，針對數據泄漏產生的負面影響越來越大，老板們為了能更好的(避)保(免)護(背)公(鍋)司數據，數據安全的崗位開始火熱了起來，那么數據安全有什么用?

[[313872]]

運營角度看數據安全

從安全運營角度來看數據安全建設的必要性，在我們呆過企業中可能會存在這樣的對話

part1焦躁的安全工程師問到”你你你xxxxURL有個sql注入，趕緊看下，還有哪個應用使用這個庫，表里都有哪些敏感字段，有多少受影響的數據量”。業務通常會一臉天真的回復“這個表沒什么敏感數據，不重要，我們現在就把漏洞修了，安全漏洞通告發給我就行了，別抄給我們領導”。

Part2焦躁的安全工程師收到來自暗網的監控告警，某某公司幾億訂單數據泄漏，來自靈魂的拷問“是有內鬼吧，這是哪個庫的數據，這么多敏感字段還是明文，之前某次應急 好像在哪里見到過這種字段，難道上次的SQL注入拖出去這么多數據，md業務還坑我是測試數據”。

[[313873]]

如果企業安全工程師的日常還經常出現上述類似對話，那么一定還沒開始做數據安全方面的建設。

感知&盲區

數據安全第一階段永遠離不開的問題，數據在哪里也就是我們常說的對敏感數據的感知能力?只有知道敏感數據在哪里才能將重要的精力資源投入到需要重點保護的數據資產上。從安全運營的角度思考一下。

[[313874]]

part1秋高氣爽的一天SRC接到一個SQL注入，一個RCE打到應用、打到庫上，安全工程師可以直接在安全中臺看到這條漏洞攻擊到了哪臺數據庫是什么級別，有什么表，有什么字段、有多少數據量，拖拽數據量是多少，風險級別直接量化。

這些更準確的信息可以用自動化發單方式通知到業務告警到安全部，即降低了安全工程師繁瑣的排查流程又撕壁和業務一輪輪的四壁扯皮的過程。

Part2如果某個秋高氣爽的一天，你正吃著火鍋唱著歌，突然發現暗網出現了疑似數據泄露，通過安全中臺快速將數據字段進行檢索，更快的定位到哪些庫存在隱患，這些庫對應哪些應用，進行快速的應急響應。

結合運營安全工程師的分析可以進一步確認受影響的范圍，原來毫無頭緒的問題突然有了逐漸清晰的解決的方向，不再像之前一樣空有一群南拳北斗的“武林高手”跳上擂臺卻發現找不到像樣的兵器、打不出力，一頓花球秀腿后匆匆下場落得臺下觀眾一片奚落。

數據安全

數據安全在數據生命周期內的六個階段內憑借公司的基建完善程度，安全團隊按自己團隊的配置，有選擇性的選取好下手的環節進行發力，以降低后續安全和業務相互溝通成本、普及數據安全重要性的成本。

從哪里下手

筆者認為數據安全的基礎的感知能力可以協同DB部門或者從業務側首先開展，而作為數據安全工程師應該先考慮用何種方式可以達成你的第一個小目標-“具備基礎數據在哪的感知能力”，筆者認為從DB部門切入可以更快的實現安全部門與db部門的協同工作閉環運營，主要因為db部有你需要的數據資源，安全部有數據分類分級使用上的需求分析能力，二者相結果，可以最短路徑實現數據安全運營落地閉環;

而先從業務線下手筆者認為成本會較大，因為企業內部業務部多則幾千少則幾百，對待安全的激情也是高低不均的，在前期開展數據安全所有的資源有限的情況下沒必要將寶貴的安全工程師投入到業務線(試點除外)，那無異議蚍蜉撼樹，下場無非是安全同學被業務一頓懟”每天有這么多數據庫、有什么變更都我要跟你說嗎”，”你們安全部天天就知道讓我們業務弄這個也弄弄那個也弄，我們自己業務還做不做了”。

主動發現數據

從上至下，從安全委員會推到業務線和db部門建立完善的線上數據庫制度流程，統一的分類分級標準，數據級別方面數據分級大致可以按用戶的數據屬性來劃分，比如用戶信息類、企業信息類、商戶信息類：

按類別分類：

對數據進行動態識別、識別的方式有很多，例如機靜態規則、機器學習、目標是不斷完善敏感數據的識別率，最簡單的可以直接去遍歷所有的庫表結構字段、遍歷集中日志存儲中心，對不同的應用，不同的數據庫表中存在哪些敏感數據進行自動化審計。

線下通過數據安全團隊對離線分析數據進行分類分級打標庫表級別畫像，可以完善出一套基礎的“數據資產”圖譜，有了圖譜權限管理、審計都可以逐步開展，當然感知能力，數據資產也不止這一個維度需要多維度共同作用構成。

安全團隊做到了實時的線上線下敏感數據采集感知，那么下一步就很清晰了，對數據進行分類分級重點關注L3，L4級個人敏感信息、公司級別敏感信息、對敏感數據進行落地加密存儲、權限審計、數據庫加解密等。

更多的是場景

更多的是場景問題，數據溯源，場景的數據溯源過程大致如下，數據樣本收集、數據樣本特征分析(定位泄漏時間、定位字段、定位數量)確認泄漏源、確認泄漏應用，我們需要從海量的數據中提取特征，比如本批次泄漏字段有哪些，該字段同時存在與哪些庫表，隸屬于哪幾個應用。依次定位調用時間、調用庫表、調用應用。

[[313876]]

圍繞數據泄漏的不同場景，安全工程師會有意的向加工數據增加一些“染色數據”，增加“染色數據”的好處在于方便數據審計、方便數據溯源采集特征。

對二次存儲分析使用的離線數據進行加密各種的數據脫敏(數據染色)，二次使用的數據進行染色大致原則可以這樣理解，將數據重新生成，但不影響原有業務開展數據統計分的析結果，例如業務提出的需求“我們需要最近24小時訂單分析每個地區的下單情況”，

安全工程師需要對此需求進行提煉，提煉后的業務真實想要的需求是“業務需要訂單轉化比率，關注的是總體的比例，是在統計一批數據的百分比，但不關注某一字段的準確性，”例如小明使用的是聯通手機號185123123123，我們在保持聯通的屬性185不變后續幾位可以轉換為“0”即185123000、住所地址保留市區街道不變具體樓單號進行染色、一批數據的性別比例染色，保持原有的男女比例不變，這樣這批數據在提供給業務側進行統計分析的時候不會產生影響，同時可以保障用戶數據的安全性。 這些都屬于數據染色區別在于不同應用場景。

這塊感興趣的同學可以參考美團的數據差分隱私、數據染色的技術相關文章，都非常值得一讀。

小結

總之筆者在開展數據安全工作上踩過很多坑，總結總結，無非是受限于老三樣，安全部規模，基建程度，老板關注度(是否出過事)，比如在數據分散且沒有統一的數據總線情況下最好不要異想天開的先去做什么權限管理，優先考慮那些能占用資源少且能閉環運營的工作，如做自動化分類分級打標打標、加解密等，不斷迭代安全部對數據安全方面的能力，豐富企業常見的數據安全場景的解決方案能力，再去啃標識化染色權限管理未嘗不是也是一種不錯的選擇。