最小權限

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

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

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

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

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

配置分離

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

為什麽要強調這一點呢？同樣的，我們看看從網絡上流出的一段代碼片段：

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

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

外部監控

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

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

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

對於很多中小團隊來說，可能本身就沒有什麽人力去做這件事，那麽是不是就沒辦法了呢？實際上，很多安全服務商，甚至一些大型互聯網公司都有提供這樣的產品服務，比如攜程的Github Scan：

如果說，你連買這類產品的錢都不想出，那麽順手推薦一個開源項目可以參考一下：Github leaked patrol

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

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