3.6　需要自己發明安全機制嗎

1. 安全機制的含義

首先解釋一下發明安全機制這句話的意思。安全機制包括：常見的對稱和非對稱加密算法，操作系統自帶的RBAC基于角色的訪問控制，自帶的防火墻Netfilter，Android的基于appid隔離的機制，kernel支持的DEP（數據段執行保護），以及各種ASLR（地址空間隨機映射），各種安全函數、服務器軟件的安全選項，這些都屬于已經存在的安全機制，注意我用的詞是“已經存在”，而這個話題是針對是不是要在已有的安全機制上再去發明新的安全機制，比如三星手機的KNOX，就是在Android基礎上自己造了個輪子。

2. 企業安全建設中的需求

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

3. 取舍點

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

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

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

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

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