企業安全體系架構分析：開發安全架構之可用性架構

上一期大概講述了安全體系架構的概述以及管理層面的安全體系架構，這一期來講講業務在設計時制定安全架構的落地實施。

一、確定業務接口

因爲業務的特殊性，業務接口可能不止是web層面的，有些業務爲了保證傳輸速率甚至有可能是udp協議傳輸，也有些業務走的是socket協議，首先就是要確定你的業務接口走的是什麼協議，以下以TCP-HTTP協議爲主，其他協議的架構安全會在後期敘述。

二、業務邏輯設計

通過上面步驟確定好了業務接口後，需要按照業務的邏輯去設計架構（以下均爲http接口設計架構），舉例，某業務分爲以下幾點，API接口與客戶對接，靜態資源展示企業信息，管理接口對應企業內部人員審覈等工作，客戶接口對應客戶的管理工作。在資金並不充足的情況下（不投入廠商安全設備），那麼對應的架構應該如何設計呢？

邏輯架構圖（可用性部分）：

首先要有代理服務器，保證應用服務器不會直接暴露在公網上。其次要有日誌服務器，彙總應用日誌與攻擊日誌，防禦服務器可以自己組建，各種腳本的匹配來確定請求是否合法。

由互聯網訪問的請求首先經過代理服務器，這麼做的好處在於會保護應用服務器的真實IP與端口，舉個例子，應用服務器對外接口是443，那麼在代理服務器僅需要代理443端口對應應用服務器的443端口，其他端口全部封閉，那麼應用服務器上多餘的端口是在互聯網無法掃描到的，另外代理服務器上僅做轉發，性能上消耗會很小，一臺應用服務器上跑一個應用，然後通過代理服務器彙總，會很大程度上方便人員進行統一管理，不會造成應用堆砌的現象。

通過代理服務器轉發進來的請求，首先進行行爲異常分析，此處可以是使用廠商設備，也可以自研腳本，根據經費情況自行選擇合適的方案。

關於防禦服務器，有幾點想跟大家分享，第一是WAF，第二是防CC攻擊。

首先WAF我們都知道是通過正則表達式做內容匹配，如果內容匹配上則判定爲攻擊，那麼就會產生三個問題：

第一是正則的繞過

第二是正則的業務阻斷

第三是正則書寫本身的bug

第一點舉個例子好了，目前開源的WAF中規則寫的不錯的就是modsecurity了，以它舉例，規則基本上每週都會有更新，但是繞過方法還是屢見不鮮，沒有哪種防禦是能完全阻斷攻擊的，總會有各種各樣沒有被發現或已經被發現的漏洞，時常關注信息，及時查漏補缺方能在一定程度上體現安全性。

第二點是所有WAF的一個硬傷，因爲業務是不固定的，隨時可能有業務信息觸發了WAF的規則而導致業務阻斷，這也是爲什麼知名廠商WAF要先觀察一段時間調優後才能開啓阻斷的原因。

第三點還是以modsecurity舉例，畢竟是開源代碼都能看到，正則表達式本身因爲書寫的問題，會有很多模糊匹配或者聯合匹配，當這些匹配內容過大的時候就會因爲變相DoS攻擊，這在modsecurity3中也是被證實的，同樣的問題在日誌寫入的時候也會發生，導致i/o讀寫通道堵塞引起的DoS攻擊同樣在modsecurity2中被證實。

安全無止境，並不是設備的堆砌，腳本的堆砌就能保證業務的安全可用，這點是我通過以上3個問題重點想要說的。

關於防CC攻擊，一般的防CC設置是判定爲是CC攻擊，阻斷，而非丟棄，這塊我有不同的看法，假如說一個正常訪問請求我響應需要100k的相應包，一個阻斷包（返回403或自定義頁面）假設需要5k，但是流量還是通過入口進來了，尤其是雲服務器有的可能是按量付費，那我們是不是應該思考一下如何讓非法流量不能通過入口進來？傳統的抗DDoS設備做的流量清洗或者黑洞閥值不會設置的很低，那麼這塊要如何做？後期我會分享出來我的解決辦法。