有沒有想過，公司裡的資料萬一洩露，會有什麼影響？今天來分享ㄧ個由我負責主導，卻失敗收場的專案。

「這份資料是怎麼流傳出去的？」某天，主管們和資安團隊集中在CTO辦公室，CTO出示ㄧ份影印文件，望著大家。

「上次HR人資部門誤傳薪資單給別人，這次是否…」
「那位員工已經離職了。」
「啊？這麼嚴重？」
「不管上次怎麼回事，這次上頭要我們找出誰洩露公司內部資料，如果找不出是誰…」

言至於此，大家心頭ㄧ緊，各自默默進行，開始進行偵探遊戲，從各個系統追尋，雖然最後找出洩漏資料的員工呈報HR人資部門，主管希望能研究一勞永逸解決這個問題的方法。當時我依據書本學到的知識，建議選擇一套Data Loss Prevention (DLP)資料外洩防護方案，接著準備好幾份簡報，在MIS部門會議多次介紹DLP，甚至向高層主管CTO、CFO等等建議「DLP是解決方案」，獲得主管同意後開始和不同廠商聯絡，請SE來DEMO或計劃測試。

首先我們測試一些現有環境下既有的DLP能力，例如Microsoft Office365的DLP功能。發現功能不足以滿足需求後便開始聯絡幾家知名DLP廠商。一般Data Loss Prevention (DLP)資料外洩防護方案粗分為幾種型態：閘道型、端點型、資料型，和綜合型。閘道型方案是在網路閘道Gateway或代理伺服器Proxy攔截檢視資料；端點型方案是直接在端點主機電腦安裝Agent程式，檢視資料，執行政策；資料型方案通常和資料庫、檔案伺服器、郵件伺服器等等整合，直接對檔案資料本身存取和內容偵測；綜合型則是結合以上幾種方案，提供全面性的防護。

半年過去，測試過好幾項方案並比較功能性，結果都不盡理想後，才發現這個專案進行時有致命的缺陷。首先我只是依據書本上的知識判定DLP是解決方案，很認真地去比對各方案優缺功能性，想選一套價格便宜功能又多的軟體方案，沒有花時間先了解需求，評估業務上的影響和作業流程，等我意識到個問題開始和業務單位開會了解時，才發現其實並非每個部門都明確掌握自己的資料，當時業務單位本身並沒有明確界定什麼資料是敏感或機密的，但是DLP主要是以安全政策(Policy)及資料分類規則(Data Classification)為判別基礎，透過比對文件內容來偵測資料風險程度，進而決定攔阻、紀錄、警告、或讓資料順利寄出。如果無法明確標明那些資料需要設定安全政策來監測，DLP軟體只能憑本身內建的安全政策處理一般的敏感資料，例如身分證字號、信用卡號碼等等，就算在安全政策中加入特定關鍵字詞Keyword，仍然有相當多誤判false positive，猶記得測試其中一家DLP方案時，每天都收到幾百封甚至近千封警告，嚴重影響本身工作。

「DLP is a process，not just getting a tool」。當時某廠商一位Sales Engineer在電話中指出這點，DLP並非買個產品就可以做到完善的防護，而是要從政策、觀念、流程上先著手。換言之，如果有確的IT政策，做好資料分類，從業務單位、各部門開始建立處理各級不同資料的流程，DLP產品可以極短時間內順利地在不影響業務下幫助保護資料。否則就需要準備一段很長的過渡期，讓各單位慢慢導入。

「我們也有輸的時候，這是很難得的經驗。」- - 堂本教練《灌籃高手》

你也有專案不成功的經驗嗎？你曾經在公司導入DLP方案嗎？歡迎分享導入DLP的經驗。