現如今隨著GDPR、個人信息安全保護規范等一系列的實施，針對數據泄漏產生的負面影響越來越大，老板們為了能更好的保護公司數據，數據安全的崗位和產品開始火熱了起來，那么數據安全有什么用？運營角度看數據安全從安全運營角度來看數據安全建設的必要性，在我們呆過企業中可能會存在這樣的對話part1焦躁的安全工程師問到”你你你xxxxURL有個sql注入，趕緊看下，還有哪個應用使用這個庫，表里都有哪些敏感字段，有多少受影響的數據量”。

業務通常會一臉天真的回復“這個表沒什么敏感數據，不重要，我們現在就把漏洞修了，安全漏洞通告發給我就行了，別抄給我們領導”。

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

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

如何解決筆者認為數據安全的基礎的感知能力可以協同DB部門或者從業務側首先開展，而作為數據安全工程師應該先考慮用何種方式可以達成你的第一個小目標-“具備基礎數據在哪的感知能力”，筆者認為從DB部門切入可以更快的實現安全部門與db部門的協同工作閉環運營，主要因為db部有你需要的數據資源，安全部有數據分類分級使用上的需求分析能力，二者相結果，可以最短路徑實現數據安全運營落地閉環；而先從業務線下手筆者認為成本會較大，因為企業內部業務部多則幾千少則幾百，對待安全的激情也是高低不均的，在前期開展數據安全所有的資源有限的情況下沒必要將寶貴的安全工程師投入到業務線（試點除外），那無異議蚍蜉撼樹，下場無非是安全同學被業務一頓懟”每天有這么多數據庫、有什么變更都我要跟你說嗎”，”你們安全部天天就知道讓我們業務弄這個也弄弄那個也弄，我們自己業務還做不做了”。

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

依次定位調用時間、調用庫表、調用應用。

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

對二次存儲分析使用的離線數據進行加密各種的數據脫敏（數據染色），二次使用的數據進行染色大致原則可以這樣理解，將數據重新生成，但不影響原有業務開展數據統計分的析結果，例如業務提出的需求“我們需要最近24小時訂單分析每個地區的下單情況”，安全工程師需要對此需求進行提煉，提煉后的業務真實想要的需求是“業務需要訂單轉化比率，關注的是總體的比例，是在統計一批數據的百分比，但不關注某一字段的準確性，”例如小明使用的是聯通手機號185123123123，我們在保持聯通的屬性185不變后續幾位可以轉換為“0”即185123000、住所地址保留市區街道不變具體樓單號進行染色、一批數據的性別比例染色，保持原有的男女比例不變，這樣這批數據在提供給業務側進行統計分析的時候不會產生影響，同時可以保障用戶數據的安全性。

這些都屬于數據染色區別在于不同應用場景。

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

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