[原創]如何利用雲安全運營中心監測資料洩露

前言：

2019年上半年資料洩露事件頻出。

4月，國內一大型二次元網站後臺工程原始碼被上傳至Github；

5月，三星手機廠商多個內部專案程式碼洩露，包括SmartThings敏感的原始碼、證書和金鑰。

近日，Verizon釋出的《Verizon 2019年資料洩露調查報告》對41686起安全事件進行分析，其中包括2013起已證實的資料洩露事件。

洩露事件層出不窮，作為一名安全攻城獅，除了當個吃瓜群眾看熱鬧之外，我們能做些什麼來強化自身能力呢？這裡不準備大談特談資料安全治理、資料加密、脫敏之類的重性措施，僅僅從可實操、可運營的角度分享一些個人在雲上做資料洩露監測的一些技巧和經驗，希望能幫助到一些雲上的使用者。

0×00 適用物件

l 業務上雲的開發者、運維工程師、安全小白；

l 業務跑在雲上且對資料洩露較關注的企業；

0×01 資料洩露的“冷靜三問”

l 典型的資料洩露事件有哪些？

l 資料洩露產生的主要原因是什麼？

l 為避免資料洩露事件，我們能做什麼？

0×02 關於資料洩露那些事兒

1. 資料洩露定義及常見分類

資料洩露的嚴格定義一般指“受保護或機密資料可能被未經授權的人檢視、偷竊或使用”。而由於企業業務性質、開發制度等原因，網際網路公司一般會涉及較多的版本變更，且大部分網際網路企業內部崇尚開源文化，開放的同時，也為資料洩露事件的埋下隱患。

以近幾年資料洩露的影響較大的幾個事件案例來分，從洩露渠道上可以分類為：

Github程式碼類資料洩露事件：

即由於人為有意或無意的上傳了包含企業內部敏感資訊的程式碼到Github網站，從而導致被外部攻擊者獲取到進行入侵利用。

案例：某大型二次元網站後臺工程原始碼被上傳至Github。

網站入侵類資料洩露事件：

往往由於網站或服務平臺、App等存在漏洞遭受攻擊而導致資料丟失洩露。

案例：某大型技術社群網站六百萬使用者資訊洩露。

網路黑市交易類洩露事件：

二手洩露渠道，指在地下交易市場上售賣和交易的資料洩露事件，其中資料來源渠道可能會有很多種，比如通過僱傭黑客社工獲取到了資料伺服器的許可權，或通過內部暗箱操作獲取到了內部資料等，這裡的資料洩露事件往往以盈利為目的被在網路黑市渠道進行釋出和售賣。

案例：國內某知名酒店住房資料洩露事件。

合作商介面類資料洩露事件：

由於合作商介面呼叫內部資料沒有做好安全防護措施或監測，導致敏感資料通過合作商渠道洩露到了外部，這其中包含合作商惡意的和非惡意的，可能由於本身技術問題，也有可能非法利用這部分資料進行他用。

案例：劍橋分析公司不正當方式獲取5000萬Facebook使用者個人資訊

案例方面還有其他種種，這裡不再一一舉例。

2. 資料洩露產生的根本原因是什麼？

“策略”不規範，“企業”兩行淚。

資料洩露的根本原因可能多種多樣，總結起來，幾乎都可以歸類為兩種，一種為企業對於資料的技術管控策略不足到導致的資料洩露，另外一種則是資料安全管理策略或制度上缺失導致敏感資料被未授權的訪問。

技術方面，網站/平臺/應用/系統因為存在安全問題，如系統漏洞或配置失誤、資料脫敏手段和資料加密措施缺失、異常操作審計手段缺失、敏感資訊洩露發現機制缺失等，都可能導致攻擊者利用獲取到敏感資料；

管理方面，由於開發人員或實習員工安全意識薄弱、或對合作商缺乏資料使用約束條款或限制措施等，導致資料未授權公開或被非法濫用，也是導致資料外洩另外一大主要原因。

3. 出現資料洩露事件，我們能做什麼？

資料可說是企業的核心生命線了，資料洩露事件的危害不言而喻，當企業出現洩露事件，雖不至於致命，但往往也讓企業元氣大傷。

大多數場景下，一般企業洩露的內容往往是部分較敏感資料，攻擊者利用這部分資料可通過滲透或進一步挖掘獲取到更為深層的敏感資料資訊，據此，如果企業建立了敏感資訊洩露監測體系，在出現洩露事件後能通過技術手段快速應對並積極開展自查修復，仍然能夠起到“亡羊補牢”的作用，在黑客利用之前提前進行整改和加固防禦，規避各類不必要的隱性風險，將損失降到最低。

上述提到了四種主流的資料洩露事件風險，因網站/應用/APP漏洞引起的資料洩露，由於涵蓋面涉及較多，這裡不一一列舉，且一般稍大型的企業內部安全體系也會將分網分域、入侵檢測、加解密、資料庫審計等基本措施覆蓋得相對比較齊全，攻擊者獲取敏感資料難度也相對較大，合作商導致的資料洩露更多是在合同的條款缺失、資料共享脫敏上、介面許可權上做一些控制，管理和技術上各佔一部分，這裡不再展開。

這裡我們重點針對比較典型的、且危害較大的Github程式碼洩露、黑市資料交易這兩種行為，探討我們能夠能在技術上落地的手段和管理上的控制思路。

l 技術管控策略

1） 嚴禁員工私自搭建程式碼管理工具，需使用公司統一授權的程式碼管理工具(git,svn)進行程式碼管理；

2） 嚴格管控專案程式碼許可權，人員變動（轉崗、離職）需及時回收程式碼許可權；

3） 大型專案使用 submodule（子模組）進行劃分，對專案進行實行許可權最小化原則；

4）  不把程式碼存放在外部網站，如：Github、Onedrive等網站

5） 對Github、地下交易市場等網站進行敏感資訊洩露監測，當出現敏感資訊時，關注進行自查確認，避免問題擴散。

l 合規管理策略

1） 制定《原始碼開源安全管理》，開源需經過開源流程評估；

2） 對合作商的介面的使用範圍約束條款、限制或監督審計等

3） 對內部員工的合同法律約束，高壓線措施

合規管理策略一般涉及到企業的採購、法務等流程，這裡暫不細說，技術管控策略前面4項偏向於事前，作為一個安全技術人員，比較好落地且運營效果比較好的是Github和網路黑市的洩露監測：即當發現有企業自身關注的敏感資訊上傳到公網時，安全人員能夠快速瞭解，並展開處理。

“工欲善其事，必先利其器”，重複造輪子、從0到1去開發Github監測系統的人，這裡太耗費工作量，個人不太推薦；將開源的系統拿過來自己用，雖然高效，但存在一定的部署維護成本，且部分系統的穩定性、安全性及API限頻等問題也是後期解決起來比較麻煩的，很多企業往往考慮到系統自身安全性，會將系統部署在企業外部伺服器，但是在真實運營過程中，會不利於企業進行統一運營管理。使用雲平臺SaaS化的服務形式，雖然可控性差了點，但短平快、輕量級的特點還是比較友好，也不需要太多的維護工作量。

這裡以一個普通的雲使用者或企業為例，介紹下雲上資料洩露監測的一些思路或方法。

0×03關於洩露監測的安全運營平臺

傳統的洩露監測系統往往會固定死某幾個監測特徵(如雲金鑰、MySQL密碼洩露監測），騰訊雲的安全運營中心對外免費開放了洩露監測功能，提供了相對比較靈活的規則配置，可以監測不同平臺，不同資料庫系統以及自定義特徵的資料洩露。除洩露監測外，騰訊雲安全運營中心還免費提供了另外一個比較實用的功能——安全情報，一個偏事前，一個偏事後。

（圖：The Verizon 2019 Data Breach Investigations Report）

由《Verizon 2019年資料洩露調查報告》中資料洩露威脅源頭趨勢圖可見，內鬼及無意識管理員在最大的上升趨勢，騰訊雲安全運營中心資料洩露監測功能正是針對這一類。

這裡分享下雲鼎實驗室工程師在程式碼洩露監測規則配置上的一些技巧。

1. 使用方式

SaaS化服務的優勢是無需伺服器、也無需程式碼部署、Github Token申請除錯等，使用起來快速便捷。整體大致分三部走：

l Step1：一鍵點選開通

l Step2：配置需要監測的規則關鍵字

l Step3：檢視洩露監測結果

詳細操作步驟如下：

Step1：點選開通騰訊雲-安全運營中心（免費，賬戶有無費用、機器都行）；

Step2：進入控制檯，點選安全運營中心 > 產品設定 > 洩露監測> 新增，接下來進行Github和網路黑市監測的規則新增，新增過程會有示例模板，可作為參考；

Step3：新增完成後，任務應該在後臺自動跑起來了，稍等一會後，可以點選左側的洩露監測檢視監測詳細結果。

洩露監測事件控制檯列表

洩露監測事件詳情

2. 如何更好的配置監測規則？

騰訊雲提供了比較靈活關鍵字配置，猶如一把鋒利的武器，當關鍵字規則配置的好的時候，猶如高手使用，往往能夠發揮巨大威力，如果規則關鍵字配置不當，可能起到的效果就很一般。

這裡分享下雲上Github洩露監測規則運營所積累的一些經驗，供參考：

規則1：基於雲業務場景的規則——雲API金鑰規則

相信對於雲使用者而言，雲API金鑰的重要性不言而喻，如果洩露，危害巨大，但因業務需要，往往很多雲使用者在進行API呼叫時都會用到，因為開發的有意或無意中的一些操作，可能導致程式碼被上傳到Github，最終導致企業內部敏感程式碼洩露，這樣的案例比比皆是，因此針對雲API的金鑰洩露監測規則十分必要。

以騰訊云為例，這裡簡單列舉監測規則配置思路及步驟：

1、獲取SecretID：

獲取SecretID

2、將SecretID作為監測關鍵字進行配置

參考配置：     

AKIDmQtAxYTAB2iBS8s2DCzazxxxxxxxxxxxxx

監測效果：

洩露監測結果（規則1）

優點：檢查結果精準，干擾誤報少。

缺點：暫無。

規則2：基於帳號維度的規則——帳號ID+帳號關鍵詞

帳號型別極多，如資料庫（MySQL、MongoDB）、網站後臺登入模組帳號、中介軟體帳號等，具體可根據企業內部業務自身情況進行配置。

參考配置如下：     

雲帳號appid/uin secretkey/qcloudAppId  （雲帳號ID+關鍵字標識）

10332xxx password/mysql/passwd  （資料庫/網站帳號ID+關鍵字標識）

10332xxx login password/passwd  （資料庫/網站/帳號ID+登入識別符號+關鍵字）

監測效果：

洩露監測結果（規則2）

優點：識別結果較為精確，干擾資訊較少，誤報少，方便快速定位分析。

缺點：有點繁瑣，需要收集下內部部分資料庫管理員或開發釋出人員帳號ID資訊，才能做到更精準識別。

規則3：基於域名場景的規則——域名/IP+業務關鍵字/帳號組合

基於域名或IP場景應該是很多公司目前現有的做法，比如公司某個產品名稱或內部域名、介面API域名，這種方式屬於比較常見的、相對比較有效規則，在知道自己內部標準域名的情況下，配合帳號ID或部分關鍵字，可以相對比較全面的定位到受影響的程式碼。

參考配置如下：     

console.xxx.com 雲帳號AppId/access_key  （後臺域名+帳號/關鍵字）

api.qcloud.com  雲帳號AppId/access_key  （API域名+帳號/關鍵字）

xxxx-inc.com 帳號ID/password/access_key （域名+帳號/關鍵字）

10.23.xx.xx AppId/password/access_key/secretKey

Qunar/bilibili/qq/alipay  appid/password/access_key/secretKey（產品名+帳號ID/關鍵字）

監測效果：

洩露監測結果（規則3）

點選規則3監測結果連結進行Github連結深入驗證

優點：優點是監測範圍覆蓋較全，漏報相對較少。

缺點：誤報相對較多，關鍵字的組合需進行一定調整、優化和運營。

規則4：其他場景的規則——開發人員英文名/全拼+開發關鍵字+…

除了以上場景外，還有一些其他場景，如根據內部開發人員帳號+開發介面變數名的組合，或者加上資料庫特徵、使用者名稱密碼特徵欄位、Memcached、Redis、MongoDB後臺配置檔案欄位名等，這裡可以自由組合搭配，靈活配置。

參考配置如下：     

wangwu secret_key （開發人員姓名+密碼特徵欄位）

jackwang jdbc password  （開發人員姓名+資料庫特徵+密碼特徵欄位）

account_name/id cursorclass password/passwd（資料庫連線特徵關鍵字+密碼特徵欄位）

account_name/id ConnectionPool password/passwd（資料庫連線特徵關鍵字+密碼特徵欄位）

account_name/id  MongoClient password/passwd（資料庫連線特徵關鍵字+密碼特徵欄位）

監測效果：

洩露監測結果（規則4）

點選規則4監測結果連結進行深入驗證

優點：能發現一些較為隱蔽的洩露，誤報少。

缺點：需要基於企業情況，對涉及介面開發的人員、資料庫開發人員帳戶或Memcached、Redis、MongoDB登入欄位資訊進行簡單梳理，並對組合規則進行運營，逐漸進行優化，消除誤報。

3. 注意事項

關於規則運營的建議

a) 在配置規則過程中，騰訊雲提供了規則命中數的欄位，可以依據不同的規則命中數量檢視洩露監測結果，並參考結果數量開展優化，這點對安全運營有比較大的參考意義；

洩露監測規則配置圖

b) 建議多收集一些的資料介面特徵作為關鍵字進行監測，如cursorclass、MongoClient，ConnectionPool等，配合內部域名、帳號密碼關鍵字組合可以比較準確的監測到某類應用的敏感資料洩露，效果較好；

c) 如果真的出現洩露事件該如何處理？

1、發現有敏感資訊洩露事件時，第一時間是通知開發確認，若屬實則聯絡開發或作者在Github上進行刪除或脫敏處理，當被fork到大量人員時或事件影響較大時，則可以考慮聯絡GitHub DMCA（數字千年版權法案處理規則）向GitHub傳送郵件進行處理，要求進行刪除，並同時針對內部受影響系統開展自查，修改帳號密碼等；

2、建立一套洩露監測處理規範，比如出現洩露後的敏感資訊刪除或修改，涉及敏感資訊的系統或伺服器的內部安全自查、內部的安全意識宣告，程式碼管理平臺或工具建設等

d) 除Github監測外，目前在騰訊雲洩露監測關鍵字配置介面還可選擇絡黑市監測這一項，網路黑市監測的規則相對於企業而言相對會簡單，可以根據企業名、域名、產品的思路開展絡黑市的監測，這裡不再展開贅述，感興趣的朋友可以自己去嘗試下。

0×04 思考及感悟

洩露監測是一個偏事後的安全策略，對於企業而言，雖不如滲透測試、漏洞掃描、WAF等其他事前事中手段來的直接乾脆，但根據安全的“木桶原理”，很多入侵往往不是因為大家所關注的各類高深的漏洞，而很可能是因為內部人員不小心的一次失誤或誤操作將具備高價值的內部資訊或金鑰外洩，導致入侵者輕鬆獲取到這部分資訊並順藤摸瓜，最後獲取到了比較重要的核心資料。

因此，敏感資訊的洩露監測也是企業安全運營中的重要一環，在設定各類複雜的安全入侵防護策略和漏洞掃描規則的同時，企業也應投入一定精力去開展敏感資訊洩露的監測和處置，通過把一類問題“全盤考慮，迭代運營”，在某種程度上才能說真正防範此類危機或風險，而不僅僅是搭建了一套系統。

0×04 寫在最後

沒有絕對的安全，如同沒有絕對完美的安全系統，也因此，就有了安全運營的概念，即通過持續的運營對抗，來彌補企業安全體系木桶的“短板”（漏洞、弱口令）。

基於SaaS安全運營平臺對於企業安全運營的收益，可以簡單理解為以下幾點：

1、Saas化的服務省去了自身洩露監測系統的程式碼維護成本和伺服器成本，能是企業開發者、運維者或安全管理員將更多精力集中在規則運營上；

2、與雲平臺能夠更好的整合，開發，運維，事件處理集中在一處，提高處理效率；

3、在誤報規則的運營處理上，SaaS化的平臺比開源系統運營更持久，基於雲上使用者的集中體驗優化，及背後目前由雲鼎實驗室團隊進行後臺策略維護支援，誤報問題應該會相對少一些，告警的質量相對較高。

由於企業安全建設過程中人員安全意識帶來的安全問題是很常見的一塊“短板”（Github洩露），常常被企業忽視，因此，筆者這裡花了較多筆墨分享雲上安全資料洩露監測的運營淺見和思路，希望對業務上雲的開發者、業務跑在雲上且對資料洩露較關注企業使用者有幫助，相互學習，共同進步。