早在行業剛開始的那個時期，安全崗位基本只有兩種，WEB安全工程師和網絡安全工程師，回憶一下近幾年企業出現的風險事件、大多是安全工程師圍繞應用安全漏洞，以及如何在漏洞攻與防之間進行技術博弈。普遍受限于當時年代對安全的認知，很少有人真正關注到敏感數據對一個企業真正的重要性。
現如今隨著GDPR、個人信息安全保護規范等一系列的實施，針對數據泄漏產生的負面影響越來越大，老板們為了能更好的（避）保（免）護（背）公（鍋）司數據，數據安全的崗位開始火熱了起來，那么數據安全有什么用？
運維角度看數據安全
從安全運營角度來看數據安全建設的必要性，在我們的企業中可能會存在這樣的對話
part1
焦躁的安全工程師問到“你你你xxxxURL有個sql注入，趕緊看下，還有哪個應用使用這個庫，表里都有哪些敏感字段，有多少受影響的數據量”。業務通常會一臉天真的回復“這個表沒什么敏感數據，不重要，我們現在就把泄露處理，敏感數據泄漏通告發給我就行了，別抄給我們領導”。
Part2
焦躁的安全工程師收到來自暗網的監控告警，某某公司幾億訂單數據泄漏，來自靈魂的拷問“是有內鬼吧，這是哪個庫的數據，這么多敏感字段還是明文，之前某次應急 好像在哪里見到過這種字段，難道上次的SQL注入拖出去這么多數據，md業務還坑我不是敏感數據”。
如果企業安全工程師的日常還經常出現上述類似對話，那么一定還沒開始做數據安全方面的建設。
發現&盲區
數據安全第一階段永遠離不開的問題，數據在哪里也就是我們常說的對敏感數據的發現能力？只有知道敏感數據在哪里才能將重要的精力資源投入到需要重點保護的數據資產上。從安全運營的角度思考一下。
part1
秋高氣爽的一天Oracle接到一個plsql導出，安全工程師可以直接在數據庫審計看到這個plsql導出哪臺數據庫是什么級別，有什么表，有什么字段、有多少數據量，風險級別直接量化。
這些更準確的信息可以用自動化發單方式（通過郵件、企業微信等方式自動化轉發告警通知或者通過SYSLOG\KAFKA方式轉發原始日志的形式對接到安全部門）通知到業務告警到安全部，即降低了安全工程師繁瑣的排查流程又撕壁和業務一輪輪的四壁扯皮的過程。
Part2
如果某個秋高氣爽的一天，你正吃著火鍋唱著歌，突然發現暗網出現了疑似數據泄露，通過數據安全平臺快速將數據字段進行檢索，更快的定位到哪些庫存在隱患，這些庫對應哪些應用，進行快速的應急響應。
結合安全工程師的分析可以進一步確認受影響的范圍，原來毫無頭緒的問題突然有了逐漸清晰的解決的方向，不再像之前一樣空有一群南拳北斗的“武林高手”跳上擂臺卻發現找不到像樣的兵器、打不出力，一頓花球秀腿后匆匆下場落得臺下觀眾一片奚落。
數據安全
數據安全在數據生命周期內的六個階段內憑借公司的基建完善程度，安全團隊按自己團隊的配置，有選擇性的選取好下手的環節進行發力，以降低后續安全和業務相互溝通成本、普及數據安全重要性的成本。
從哪里下手
數據安全的基礎的發現能力可以協同DB部門或者從業務側首先開展，而作為數據安全工程師應該先考慮用何種方式可以達成你的第一個小目標-“具備基礎數據在哪的發現能力”，從DB部門切入可以更快的實現安全部門與db部門的協同工作閉環運營，主要因為db部有你需要的數據資源，安全部有數據分類分級使用上的需求分析能力，二者相結果，可以最短路徑實現數據安全運營落地閉環。
主動發現數據
從上至下，從安全委員會推到業務線和數據組建立完善的線上數據庫制度流程，統一的分類分級標準，數據級別方面數據分級大致可以按用戶的數據屬性來劃分，比如用戶信息類、企業信息類、商戶信息類
按類別分類
對數據進行動態識別、識別的方式有很多，例如靜態規則、機器學習，目標是不斷完善敏感數據的識別率，最簡單的可以直接去遍歷所有的庫表結構字段、遍歷集中日志存儲中心，對不同的應用，不同的數據庫表中存在哪些敏感數據進行自動化審計。
線下通過數據安全團隊對離線分析數據進行分類分級生成庫表級別畫像，可以完善出一套基礎的“數據資產”圖譜，有了圖譜權限管理、審計都可以逐步開展，當然發現能力，數據資產也不止這一個維度，需要多維度共同作用構成。
安全團隊做到了實時的線上線下敏感數據采集發現，那么下一步就很清晰了，對數據進行分類分級重點關注L3，L4級個人敏感信息、公司級別敏感信息、對敏感數據進行落地脫敏存儲、權限審計、數據庫加解密等。
更多的是場景
更多的是場景問題，數據溯源，場景的數據溯源過程大致如下，數據樣本收集、數據樣本特征分析（定位泄漏時間、定位字段、定位數量）確認泄漏源、確認泄漏應用，我們需要從海量的數據中提取特征，比如本批次泄漏字段有哪些，該字段同時存在與哪些庫表，隸屬于哪幾個應用。依次定位調用時間、調用庫表、調用應用。
圍繞數據泄漏的不同場景，安全工程師會有意的向加工數據增加一些“染色數據”，增加“染色數據”的好處在于方便數據審計、方便數據溯源采集特征。
對二次存儲分析使用的離線數據進行加密各種的數據脫敏（數據染色），二次使用的數據進行染色大致原則可以這樣理解，將數據重新生成，但不影響原有業務開展數據統計分析結果，例如業務提出的需求“我們需要最近24小時訂單分析每個地區的下單情況”，
安全工程師需要對此需求進行提煉，提煉后的業務真實想要的需求是“業務需要訂單轉化比率，關注的是總體的比例，是在統計一批數據的百分比，但不關注某一字段的準確性，”例如小明使用的是聯通手機號185123123123，我們在保持聯通的屬性185不變后續幾位可以轉換為“0”即185123000、住所地址保留市區街道不變具體樓單號進行染色、一批數據的性別比例染色，保持原有的男女比例不變，這樣這批數據在提供給業務側進行統計分析的時候不會產生影響，同時可以保障用戶數據的安全性。這些都屬于數據染色區別在于不同應用場景。
開展數據安全工作上踩過很多坑，總結總結，無非是受限于老三樣，安全部規模，基建程度，老板關注度（是否出過事），比如在數據分散且沒有統一的數據總線情況下，最好不要異想天開的先去做什么權限管理，優先考慮那些能占用資源少且能閉環運營的工作，如做自動化分類分級打標、加脫敏等，不斷迭代安全部對數據安全方面的能力，無時無刻對我們進行著考驗。
注：原題目為《論敏感數據發現能力對企業的重要性》