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

一、 確定業務接口因為業務的特殊性，業務接口可能不止是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設備做的流量清洗或者黑洞閥值不會設置的很低，那么這塊要如何做？后期我會分享出來我的解決辦法。

三、 業務架構圖設計根據邏輯架構圖來制定業務的整體現實架構（可用性部分）通過負載均衡實現代理服務器的雙活，大程度保證訪問不會中斷，同時應用服務器使用主備雙服務器，數據庫也是主備雙活，很大程度上保證了業務的可用性，防御服務器集群用來分析入侵行為，日志服務器用來匯總業務相關的所有日志。

當然防御服務器集群是至少3臺以上，并且每臺都會向下兼容應用服務器，這么做的目的在于，行為分析是十分耗資源的一件事，搭建集群會降低單一服務器的運算壓力，并且不用擔心出現單點故障。

同時保證每個業務接口的入口均為獨立入口，這樣可以將業務分離出來，也方便防御服務器做單一業務的規則，保證規則的準確性。