網際網路企業安全進階指南3.6 需要自己發明安全機制嗎

<b>3.6　需要自己發明安全機制嗎</b>

<b></b>

<b>1. 安全機制的含義</b>

首先解釋一下發明安全機制這句話的意思。安全機制包括：常見的對稱和非對稱加密算法，作業系統自帶的rbac基于角色的通路控制，自帶的防火牆netfilter，android的基于appid隔離的機制，kernel支援的dep（資料段執行保護），以及各種aslr（位址空間随機映射），各種安全函數、伺服器軟體的安全選項，這些都屬于已經存在的安全機制，注意我用的詞是“已經存在”，而這個話題是針對是不是要在已有的安全機制上再去發明新的安全機制，比如三星手機的knox，就是在android基礎上自己造了個輪子。

<b>2. 企業安全建設中的需求</b>

企業安全的日常工作是不是也會面臨自己去發明安全機制的需求？會，但是不常見。實際上，在日常中發生的絕大多數問題都屬于對現有安全機制的了解有誤、沒有啟用或沒有正确使用安全機制而導緻的漏洞，而不是缺少安全機制，是以絕大多數場景都不需要去發明安全機制。發明安全機制是需要成本的，且需要有足夠的自信，否則不健全的安全機制消耗了開發的人力又會引入新的安全問題，但此話不絕對。

<b>3. 取舍點</b>

那什麼情況下應該發明安全機制呢，這其實非常考驗判斷者的技術實力。之前也提過對于很多安全漏洞的修複是否要上升層次的問題，首先要判斷這是單個問題還是屬于一類問題，如果是前者，用救火的方式堵上這個洞就好，沒必要再去考慮更多。但假如這是一類問題，而你又沒提出通殺這一類問題的手段就會永遠處于救火之中，疲于奔命。如果是一類問題，分幾種情況。第一種歸入安全程式設計能力不足導緻的安全問題，這類問題不需要通過導入新機制解決，而是通過加強sdl的某些環節，加強教育訓練教育去解決。第二種情況則是屬于在相應的領域還沒有成熟的安全解決方案或者現有的安全機制對抗強度太弱，則可以考慮自己去造輪子。

比如有一個函數存在整形溢出，但隻有在極特殊的情況下才能觸發，平時開發過程中已經大量的使用了安全函數，啟用了編譯的安全選項，除了給這個函數加一個條件判斷修複這個bug外是不是還要考慮更進一層的防護呢？大多數情況下顯然是沒必要的，假如這是一個公共函數，那你可以選擇把修複後的代碼封裝成安全的api，避免其他程式員自己實作的時候發生同類問題。

換個問題，如果公司産品的某個私有協定總是被人頻繁地解密和利用，而這種解密對産品的影響又較大，假設就是遊戲用戶端跟服務端通信的指令都能被破解和仿冒，那這種情況下就需要考慮是否更改或建立安全機制，即有沒有必要通過實作更強的通信協定加密或提高用戶端反調試的對抗等級來緩解這一問題。

如果你說建立安全機制也是補洞的話，其實也沒錯，就像dep相對于使用者态的程式而言是一種機制，而對于作業系統和馮·諾依曼體系結構而言是一個洞。當你過于勤奮地在很微觀的細節上補洞卻總是補不完的時候，不妨停下來看看能否在更高更抽象的層次上打個更新檔。

安全工程師如果要晉升為leader很重要的一點就是對安全事件和安全漏洞的抽象能力，沒有抽象就談不上pdca，就意味着更高的管理者對安全kpi在你手上能否改進不一定有信心。在縱深防禦體系向中高階段發展時，實際上會比較多的遇到是否要創新安全機制的問題，但是這個場景大多數公司未必會遇到。