資料安全對企業重要性

導讀	現如今隨著GDPR、個人資訊保安保護規範等一系列的實施，針對資料洩漏產生的負面影響越來越大，老闆們為了能更好的（避）保（免）護（背）公（鍋）司資料，資料安全的崗位開始火熱了起來，那麼資料安全有什麼用？

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

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

焦躁的安全工程師問到”你你你xxxxURL有個sql注入，趕緊看下，還有哪個應用使用這個庫，表裡都有哪些敏感欄位，有多少受影響的資料量”。業務通常會一臉天真的回覆“這個表沒什麼敏感資料，不重要，我們現在就把洩露處理，敏感資料洩漏通告發給我就行了，別抄給我們領導”。

焦躁的安全工程師收到來自暗網的監控告警，某某公司幾億訂單資料洩漏，來自靈魂的拷問“是有內鬼吧，這是哪個庫的資料，這麼多敏感欄位還是明文，之前某次應急 好像在哪裡見到過這種欄位，難道上次的SQL隱碼攻擊拖出去這麼多資料，md業務還坑我不是敏感資料”。

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

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

秋高氣爽的一天Oracle接到一個plsql匯出，安全工程師可以直接在資料庫審計看到這個plsql匯出哪臺資料庫是什麼級別，有什麼表，有什麼欄位、有多少資料量，風險級別直接量化。

這些更準確的資訊可以用自動化發單方式(透過郵件、企業微信等方式自動化轉發告警通知或者透過SYSLOG\KAFKA方式轉發原始日誌的形式對接到安全部門)通知到業務告警到安全部，即降低了安全工程師繁瑣的排查流程又撕壁和業務一輪輪的四壁扯皮的過程。

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

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

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

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

從上至下，從安全委員會推到業務線和資料組建立完善的線上資料庫制度流程，統一的分類分級標準，資料級別方面資料分級大致可以按使用者的資料屬性來劃分，比如使用者資訊類、企業資訊類、商戶資訊類

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

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

安全團隊做到了實時的線上線下敏感資料採集發現，那麼下一步就很清晰了，對資料進行分類分級重點關注L3，L4級個人敏感資訊、公司級別敏感資訊、對敏感資料進行落地脫敏儲存、許可權審計、資料庫加解密等。

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

圍繞資料洩漏的不同場景，安全工程師會有意的向加工資料增加一些“染色資料”，增加“染色資料”的好處在於方便資料審計、方便資料溯源採集特徵。

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

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

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

原文來自：