從B站的程式碼洩露事件中，我們能學到些什麼？

先宣告一下，本文不聊ISSUE中的七七八八，也不聊程式碼是否寫的好，更不聊是不是跟蔡徐坤有關之類的吃瓜內容。僅站在技術人的角度，從這次的程式碼洩露事件，聊聊在程式碼的安全管理上，通常都需要做哪些事來預防此類事件的發生。同時，大家在閱讀本文的時候，也可以深入思考下，自己團隊是否也存在類似的問題，經過這次的事件，是否有必要針對性的做一些最佳化。

最小許可權

“最小許可權”原則是我們在學習Linux使用者管理時候經常被提到，並且被反覆強調的內容。該原則是指每個程式和系統使用者都應該具有完成任務所必需的最小許可權集合。賦予每一個合法動作最小的許可權，就是為了保護資料以及功能避免受到錯誤或者惡意行為的破壞。

在程式碼的安全管理上，“最小許可權”原則同樣適用。但是，從此次的程式碼洩露內容中可以看到，這一點做的並不好，一起來看看源自洩露程式碼的README介紹：

從說明中，可以知道這是一個後端專案的大倉庫，每個業務線都透過檔案夾的方式管理自己的業務模組。那也就是說，每個業務模組的人都是可以看到這個大倉庫的。繼續看README最後的負責人資訊：

可以看到這個大倉庫中包含了非常多的業務模組與相關負責人資訊。

由於Git的許可權管理都是對整個倉庫的，無法精細化到具體的檔案夾。換言之，對於這個大倉庫的訪問，其實是有非常多的人員可以拿到全量程式碼的，而其中有大部分程式碼可能並不是自己業務線的內容。可見，這個倉庫的內容，對於程式碼自身的保護上，並沒有做到最小許可權控制。所以，當出現程式碼洩漏的時候、對於洩露範圍就很難控制。可能一個小環節的過失，就會導致非常大的洩漏災難。

配置分離

配置與程式碼的分離，自雲原生應用的流行開始，就一直被反覆的強調。將配置內容隔離開之後，賦予程式碼的將僅僅是邏輯，對於各種與環境相關的敏感資訊都應該被剝離出去，這就使得程式碼中將不再含有各種環境資訊和敏感資訊。同時，這麼做也可以輕鬆的實現多環境的不同配置，這種實現方式與我們傳統透過構建工具來實現的多環境是完全不同的。只有在嚴格分離了配置之後，才真正的可以實現：一次構建，多處執行的標的。基於構建工具實現的多環境部署，實質上多次構建，多處執行的結果，每個環境執行的介質只是上都不是同一個程式。

為什麼要強調這一點呢？同樣的，我們看看從網路上流出的一段程式碼片段：

如果這段程式碼是真實存在的話，那麼配置管理和安全意識上確實就做得非常差了。

所以，對於配置中心的建設，大論大小團隊，從安全形度上來說，都是非常重要的。何況在目前有大量開源配置中心的大背景之下，做到配置分離，是一件價效比非常高的事。如果做到這一點，那麼即使程式碼有流出，對於重要金鑰、資料庫賬戶密碼等等敏感資訊也不會被洩露。

外部監控

任何與安全相關的內容，都少不了監控。事前的所有策略，最終都有可能被一一擊破，留給我們最後的一道防線就是在事件發生之後馬上得將其堵住，以防止問題的擴大，而造成更大的損失。

在筆者知道這件事的時候，距離程式碼上傳已經有6小時之久了。各類技術討論群中幾乎也都是相關資訊的八卦。幾乎每一次掃清頁面，都是幾百Star的增長。雖然處理的速度不能說快，但是沒過多久，與之相關的倉庫都開始無法訪問。至於，是不是有做程式碼洩露掃描的監控，我們不得而知。因為，在掃描告警之後，對於程式碼的擴散控制，作為B站來說，本身是被動的，還是需要Github等倉庫運營方來完成。所以，這中間到底哪一步慢了，我們無法考證。

不過這些都不重要，這裡主要強調一點，除了管理上的防護之外，必須留一手外部監控，以快速的發現洩漏並採取措施。這塊可能大部分開發人員不太瞭解，這邊我就稍微提一下。做一下這個是不是很費勁？

對於很多中小團隊來說，可能本身就沒有什麼人力去做這件事，那麼是不是就沒辦法了呢？實際上，很多安全服務商，甚至一些大型網際網路公司都有提供這樣的產品服務。如果說，你連買這類產品的錢都不想出，那麼順手推薦一個開源專案可以參考一下：Github leaked patrol

最近，歡迎留言交流，說說大家所在團隊對於程式碼的安全性都是如何做的？用了什麼商業服務？或是用了什麼開源軟體？歡迎一起分享學習與進步！