從B站的代碼泄露事件中，咱們能學到些什麼？

先聲明一下，本文不聊ISSUE中的七七八八，也不聊代碼是否寫的好，更不聊是否是跟蔡徐坤有關之類的吃瓜內容。僅站在技術人的角度，從此次的代碼泄露事件，聊聊在代碼的安全管理上，一般都須要作哪些事來預防此類事件的發生。同時，你們在閱讀本文的時候，也能夠深刻思考下，本身團隊是否也存在相似的問題，通過此次的事件，是否有必要針對性的作一些優化。

最小權限

「最小權限」原則是咱們在學習Linux用戶管理時候常常被提到，而且被反覆強調的內容。該原則是指每一個程序和系統用戶都應該具備完成任務所必需的最小權限集合。賦予每個合法動做最小的權限，就是爲了保護數據以及功能避免受到錯誤或者惡意行爲的破壞。

在代碼的安全管理上，「最小權限」原則一樣適用。可是，今後次的代碼泄露內容中能夠看到，這一點作的並很差，一塊兒來看看源自泄露代碼的README介紹：

從說明中，能夠知道這是一個後端項目的大倉庫，每一個業務線都經過文件夾的方式管理本身的業務模塊。那也就是說，每一個業務模塊的人都是能夠看到這個大倉庫的。繼續看README最後的負責人信息：

能夠看到這個大倉庫中包含了很是多的業務模塊與相關負責人信息。

因爲Git的權限管理都是對整個倉庫的，沒法精細化到具體的文件夾。換言之，對於這個大倉庫的訪問，實際上是有很是多的人員能夠拿到全量代碼的，而其中有大部分代碼可能並非本身業務線的內容。可見，這個倉庫的內容，對於代碼自身的保護上，並無作到最小權限控制。因此，當出現代碼泄漏的時候、對於泄露範圍就很難控制。可能一個小環節的過失，就會致使很是大的泄漏災難。

配置分離

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

爲何要強調這一點呢？一樣的，咱們看看從網絡上流出的一段代碼片斷：

若是這段代碼是真實存在的話，那麼配置管理和安全意識上確實就作得很是差了。

因此，對於配置中心的建設，大論大小團隊，從安全角度上來講，都是很是重要的。況且在目前有大量開源配置中心的大背景之下，作到配置分離，是一件性價比很是高的事。若是作到這一點，那麼即便代碼有流出，對於重要密鑰、數據庫帳戶密碼等等敏感信息也不會被泄露。

外部監控

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

在筆者知道這件事的時候，距離代碼上傳已經有6小時之久了。各種技術討論羣中幾乎也都是相關信息的八卦。幾乎每一次刷新頁面，都是幾百Star的增加。雖然處理的速度不能說快，可是沒過多久，與之相關的倉庫都開始沒法訪問。至於，是否是有作代碼泄露掃描的監控，咱們不得而知。由於，在掃描告警以後，對於代碼的擴散控制，做爲B站來講，自己是被動的，仍是須要Github等倉庫運營方來完成。因此，這中間到底哪一步慢了，咱們沒法考證。

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

對於不少中小團隊來講，可能自己就沒有什麼人力去作這件事，那麼是否是就沒辦法了呢？實際上，不少安全服務商，甚至一些大型互聯網公司都有提供這樣的產品服務。若是說，你連買這類產品的錢都不想出，那麼順手推薦一個開源項目能夠參考一下：Github leaked patrol

最近，歡迎留言交流，說說你們所在團隊對於代碼的安全性都是如何作的？用了什麼商業服務？或是用了什麼開源軟件？歡迎一塊兒分享學習與進步！