0×01 概要
代碼資源是組織的核心資源，對於敏感的代碼是不希望流傳到外部的，但由於各種原因還是有資源洩露出去， 對於洩露的原因先不論，因為相對比較難避免，但我們可以通過一定的技術手段對關鍵的數據進行審計監控，把資源洩露縮小到一定的範圍內，現在普遍流行的方式是對Github進行監控，在Github查找敏感詞，比較常見。本文在此之外提出了一種對內監控的方案，以SVN監控為例。從相關人員從內部系統下載時就行一定成度的監控審計，對下載者的下載量和行為進行分析，這個出發點建立一個監控系統。
0×02 關鍵資源與角色
整個數據洩露的過程是一個把關鍵資源從內部倉庫下載到本地，再上傳到Github的過程。對開發者本地的監聽是比較不合適的，但我們可以對外部Github倉庫監聽，Github本身也提供相對方便的監聽接口。我們這次重點不講gihub的監控， 講內部倉庫監控分析， 自動化的產生下載量分析報告和特定行為提示的系統構建思路。
三種資源倉庫：
1.內部倉庫：組織內部的代碼管理系統，外部人員不可見，比如SVN。
2.開發者倉庫：開發者本地倉庫。
3.Github外部倉庫：Github對外公有倉庫。
0×03 敏感資源角色關係模式
從代碼資源生產到消費一般會有三種角色：
1.代碼提交者： 代碼工程相關上傳人員，代碼生產者。
2.開發下載者：開發者本身：
3.代碼讀者（消費者）：本地倉庫的消費者就是相關開發人員，外部Gihub倉庫的消費讀者就是Github用戶。
我們的系統是，增加一個第4種人:安全管理監控人員。通過接入二種監控系統來分析當前資源是否洩露：1.內部倉庫下載行為分析系統。2. Github敏感詞監控系統。
0×04 重要監控著眼點
內部倉庫監控和外部倉庫監聽的核心關注重點是什麼。
1.內部倉庫監控重點：關鍵代碼資源被下載時要關注，異常下載量過大要關注，特別用戶的下載要關注。內部監控系統的成果物：下載量統計更表，重點資源被下載報警提示。
2.外部倉庫監控重點：外部倉庫因為我們沒有明確的用戶列表，現階段是通過對關鍵資源有關聯的關鍵字進行監控， 這種系統很多公司都在用，文章最後我們給出代碼方案。
0×05 構建內部倉庫審計分析系統的生產實踐
對於內部了倉庫系統進行審計的一個關鍵是，如何收集相關的數據，其次是如何分析數據，分析行為。一般企業代碼管理倉庫可能有自己的特定要求，對於主流的代碼管理工具來說，最常的工具就是SVN和Git。我們以SVN為例，我們選擇對SVN的日誌進行集中並進行分析，來實現對資源和用戶的審計。
構建內部監控系統分兩步走：
1.系統日誌收集: 收集SVN系統日誌，傳統的SVN日誌都在服務器本地，需要把文本日誌集中。一般重要生產服務器是不希望部署太多的不相關服務，系統本身的工具如Rsyslog、Rsync不會對系統的穩定性有損害。如果不在乎數據同步的週期時間快慢，可以使用Rsync進行日誌數據同步。
2.日誌數據接口化：對自動監控程序來說，好的交互方式不是去直接讀文本，如果可以通過調用REST API, 監控業務可以集中做監控策略而不是，把大量的時間去做數據處理。所以像ELK、SPLUNK、Graylog這種數據服務的存在就可以減監控開發本身的工作量。
對於一般的公司來說，可以選擇適合自己的方式，選擇對應的方案進行處理。這裡我們抽象出了一個相對通用的處理流程給大家，但不一定能普通適用所有場景。
我們將日誌數據接口化構建分成5個步驟：
1.SVN文本日誌-> 2.rsync到一臺大容量文本服務器->3.文本服務器部署nxlog發送到syslog服務器->4.syslog服務器進行數據接收並通過本地服務將文本數據存入ES–>5.建立一個數據網關對外提供REST API服務提供數據查詢。
3 監聽策略實施：當我們有了日誌查詢的REST API,再對數據進行監控就是相關容易了， 我們通過ES本身的功能，進行數據的檢索和統計。使用Python和GO或是其它語言工具都可以，每個公司的業務不一樣，自己定製比較好。
0×06 監聽任務分發處理
為什麼用RPC做監聽分析處理：
日誌是用戶行為分析的最好的素材，上面系統的構建後，我們可以通過REST API相對容易的得到日誌數據，下面我們就可以集中精力，實現我們的監控策略。我們通過按一定的時間週期自動拉取分析的日誌數據。crontab與監聽的調度問題，Cron在這裡只是我們按時間切分執行任務的一個觸發者，我們在真正的分析處理和Cron之間加了一層任務調度層Wrapper應用，Cron只是執行到Wrapper層，具體調度任務的內容可隨時調整 ，與時間週期無關的更新都不用修改Cron，然後再次解耦，用RPC把監聽與Cron機分開，通過Wrapper層進行通信， 這樣具體監聽分析處理和Cron調度放到不同機器上。如果監聽審計的需求變更，只需要改Wrapper調層配置好新執行層就可以免於整體工程的集中變更。
分析成果物：
我們設計的這個系統的成果物是： 單位週期X內用戶SVN下載量的統計，特定資源下載提示報警，高權限用戶下載行為提示。可以通過郵件、釘釘、企業微信等形式通知管理員。隨著安全策略的增加，報告成果物也會越來越多。
0×07 總結
自動化的審計手段只能在一定程度上監控審計洩露問題，但不能從根本杜絕問題的發生。本文只是對我們生產實踐系統的一次思路分享，有不足的地方希望大家給出您寶貴的意見，幫助我們改進。
本文提供了內部監控和外部監控二種方案：
1.Github外部監控：給大家推薦一個方案: https://github.com/freebuf-friends/x-patrol
2. 內部監控：要搭建自己的日誌系統，就推薦文章，以大家的工程能力搭建系統和實現監控都不難。ELK、SPLUNK、Graylog根據場景選擇，這種系統是平臺系統，構建完成了可多次重用，不只可能分析SVN行為審計，可以分析各種數據行為。
閱讀更多 JAVA柯尼塞克丶 的文章
