3.5　選擇在不同的維度做防御

攻擊的方法千千萬萬，封堵同一個安全風險的防御方法往往不止一種，如何選擇性價比最高的手段是甲方安全從業者需要權衡的。

1. 技術實現維度場景

在縱深防御的概念中（參考后面的“技術篇”）企業安全架構是層層設防，層層過濾的，常見漏洞如果要利用成功需要突破幾層限制，所以退一步對防御者而言有選擇在某一層或某幾層去設防和封堵的便利，比如SQL注入，治本的方法當然是代碼寫對，治標的方法WAF過濾，中間的方法SQL層過濾，從效果上說治本的方法固然最好，但在現實中總歸會遇到各種各樣的問題而無法全部選擇最安全的解，最后是退而求其次，還是選擇某一層或者某幾層去防御，需要整體考慮。比如SQL注入如果在HTTP層面去解決無論是靜態規則還是機器學習都需要對抗HTTP編碼的問題，不是解決這個問題ROI最佳的點，但是在SQL層面，一切SQL語句都是真實的?，F實生活中唯一的問題只是你能不能在最佳的點上推動解決方案。

2. “一題多解”的場景

假如同一個問題有>1種解決方案，可能會因場景不同而面臨選擇。比如對于SSH蠕蟲的暴力破解，你可以選擇：1）使用證書；2）選擇外部防火墻上關閉22端口，只通過堡壘機登錄；3）修改SSHD監聽非標準端口；4）修改sshd源代碼對源限制，只接受可信的客戶端地址；5）使用類似fail2ban這樣的工具或自己寫shell腳本，或者所謂的HIPS的功能。乍一看有的做法比較小眾，有的則屬于偏執狂式的。1），2），5）屬于大多數人都認同的普遍的做法，4）和5）看上去都比較小眾，有的人認為可能不適合用作生產網絡，其實要看場景。對于大型互聯網公司內部自用而言：4）和5）其實都成立，盡管偏離了業界標準，但只要在公司內部的自治生態里做到“一刀切”就可以，業界普遍是SSHD跑在22端口，你可以讓公司內部的都跑在50022端口，只要公司內部的服務器全都維持這個統一策略，但是這個方案價值不大的地方在于這種信息不對稱很容易被打破，你花了那么大力氣讓運維們都去連50022端口了，但攻擊方很快就能知道，然后努力就白費了。而對于開源軟件的修改，如果基礎架構研發比較強大，Linux、Nginx、SSHD、MySQL這些全都可以是改過的私房菜，加點有意義的安全功能也未嘗不可。不過中小型公司不需要考慮這一點，自研畢竟是有門檻和成本的。假如場景切換到公有云給租戶用的環境，這樣干就不合適了，你還是應該提供跟業界兼容的標準運維環境，在標準運維環境之上提供額外的保護。

3. 跨時間軸的場景

對于涉及跨時間維度的防護，典型的場景包括shellshock這樣的漏洞公布時，各廠商在第一時間分析漏洞評估影響，這種影響是多層面的，不只是說可能拿到什么權限，還包括影響線上系統的哪些組件，這些組件的實時在線要求，修復漏洞會不會導致關聯服務不可用。每一個漏洞修復的過程都是攻防雙方和時間賽跑，攻擊者盡量在廠商沒有修復之前尋找利用點并發動滲透，而廠商盡可能在沒出POC時趕緊把洞補了。在這個時間窗口中，甲方安全團隊需要考慮的就是跨時間維度上的布防。出補丁之前是不是就干等不作為呢，顯然不是的，細心的人會發現老牌安全公司的漏洞通告的解決方案里通常都會有一條，叫作“臨時規避措施”，經驗不足的團隊是不會寫上這條的。修不了漏洞時可以采用一些治標的補救性措施，比如對有漏洞的頁面做訪問控制，只允許有限的src.ip訪問，比如在前端的WAF/IPS設備上加規則過濾對應的惡意請求，或者臨時性的去掉一些權限，或者干脆關掉某些功能，但凡你想得到的通?？偰苷业脚R時規避方案，即便是有了補丁升級也不是立即完成的，在大型互聯網生產網絡里，全網打完一個補丁是需要不少時間的，有可能一個禮拜都弄不完，而且修復過程中要考慮服務可用性需要使用灰度和滾動升級的方法，比如修復前先把負載均衡上的流量切換到備用節點，然后對坐節點的服務器打補丁，打完再把流量切回去，然后對備用節點的服務器打補丁……打完補丁后把臨時防御措施再“回滾”掉（有價值的保留，核心設備上不建議留太多臃腫的規則），然后把特征加入全流量和主機IDS。回顧整個時間軸的防護措施依次是：臨時性規避措施—push補丁/根治措施—取消臨時性措施—添加常態性的特征檢測措施—檢測到漏網之魚—繼續上述過程，這個過程離最佳實踐實際上還差了一個環節，不過這里只是用來說明開頭提到的那個問題故而不展開了，后面會介紹對于一個漏洞修復是否需要上升層次的問題。

4. 風險和影響的平衡

假如你遇到一個安全問題是這樣的：vlan數目不夠，vxlan又不可用，提交問題后研發的反饋的方案A是如果要徹底修復則需要新增一個dhcpd的安全功能大約包含10000（loc）即1萬行代碼，此時產品線又處于整體加班加點趕工大版本的狀態，有人提出了方案B做IP/MAC雙向綁定的緩解性措施，但這樣的結果很可能是客戶覺得太麻煩，而且配置一多容易出錯，此時你想到了一個折中的辦法 方案C：給大客戶單獨vlan，若干小客戶共享一個vlan，這樣的好處是不需要太多成本，風險降低到可控，客戶可以接受。如果選擇方案A是不是更好？這個要看，假如這1萬行代碼只是用來臨時的解決這個問題，顯然ROI比較低，但是如果后續的版本本來就要加入這個功能，不妨考慮一下。又如果后續版本不需要這個小眾的功能，研發心里其實本不打算去開發的，說不定下次告訴你說要2萬行代碼，然后你到CTO那里也說不清風險到底多么嚴重，就會陷入僵局。風險緩解的原則是在以下三者之間做最大平衡：1）風險暴露程度；2）研發運維變更成本；3）用戶體驗的負面影響。

5. 修復成本的折中

一個安全漏洞的修復如果研發說要開發一周，另外一個方案是運維改一個服務器配置，而你其實心里知道在WAF上加條規則就能過濾，只不過你怕被繞過心里對這個措施不是特別有底氣。對于這個場景我也不打算直接給出答案，但通常情況下改產品的成本是最高的，成本最高的往往不容易推動，推不動就無法落地，最后就是一堆安全問題。

Amazon有一個研發理論，用一種T-Shirt Size 估計的方式來做項目。產品經理會對每一條需求評估上業務影響力的尺寸，如：XXXL 影響一千萬人以上或是可以占到上億美金的市場，XXL影響百萬用戶或是占了千萬金級別以上的市場，后面還有XL、L、M、S，這樣逐級減小。開發團隊也一樣，要評估投入的人員時間成本，XXXL表示要干1年，XXL干半年，XL干3個月，L干兩個月，M干一個月，S干兩周以下。等等。

于是，可以這樣推理：

當業務影響力是XL，時間人員成本是S，這是最高優先級。

當業務影響力是M，時間人員成本是M，這是低優先級。

當業務影響力是S，時間人員成本是XL，直接砍掉這個需求。因為是虧的。

當業務影響力是XXL，時間人員成本是XXL，需要簡化需求，把需求簡化成XL，時間人員成本變成M以下。

安全其實也類似，風險和修復成本去比較，在堅守底線的基礎上選擇最優解。

綜上所述，大家可以發現最優解往往不一定是最安全的解，市場上乙方公司滲透測試報告中提的修復方案有些也是無法實施的，很多批判企業安全做得不好的帽子們，有機會真應該到企業里體驗一下，企業安全豈是找洞補洞這么簡單的事。

參考資料

陳皓的“加班與效率”（http://coolshell.cn/articles/10217.html#more-10217）。

總結

以上是生活随笔為你收集整理的互联网企业安全高级指南3.5　选择在不同的维度做防御的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。