3.6　需要自己發(fā)明安全機制嗎

1. 安全機制的含義

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

2. 企業(yè)安全建設(shè)中的需求

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

3. 取舍點

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

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的互联网企业安全高级指南3.6　需要自己发明安全机制吗的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。