Web應用程式經常受到SQL注入攻擊、XSS攻擊、cc攻擊、惡意IP攻擊、網頁篡改、機器掃描攻擊等，這些攻擊會影響應用程式的可用性，損害應用程式的安全性，消耗過多的資源，是以需要面向Web應用層的防護方案。
1. WAF部署及Access模式
WAF是Web應用防火牆的簡稱，支援主流Web漏洞檢測和攔截、最新高危漏洞防護、虛拟更新檔、防SQL注入、防cc攻擊等，支援靈活的自定義防護政策。下圖介紹了雲平台中的WAF部署方式，使用時無須建立雲主機與部署，直接通過CNAME域名解析的方式接入WAF服務，是以配置和使用起來更加簡便，對後端源站所處的雲平台和環境也沒有限制。
在開始配置域名并接入應用前需要先在雲平台中購買WAF服務，然後在域名管理中添加域名，需要配置Web應用的域名（如www.mumulab.com）及源站IP，配置完成後會生成一個CNAME域名，如abcd1234.waf.example.com。此時需要在域名DNS解析配置中将該域名（www.mumulab.com）按照CNAME類型解析到WAF配置設定的域名（abcd1234.waf.example.com）中，即可完成應用的接入。
圖 通過CNAME域名将應用接入WAF
可以看到，将流量轉發到伺服器是通過指定IP來實作的，并沒有限定伺服器的位置，是以可以是任何一個雲平台的伺服器上的IP、IDC或本地伺服器上的IP，隻要是公網可以連通通路的IP即可。結合之前的“通過混合架構擴充本地能力”設計模式，可以将混合架構中的應用流量全部接入雲平台WAF中，WAF會對請求進行攔截（Deny）或對記錄（Log）進行過濾，再将流量轉發至混合架構的後端服務節點，增強本地環境對Web應用層攻擊的防護能力。
此種防護方式同樣适用于在A雲中接入WAF服務，将防護的IP指向B雲中的伺服器，通過多雲部署安全政策和服務來增強對業務系統的安全防護能力。
WAF能夠有效地應對應用層攻擊，不過黑客在對業務進行DDoS攻擊時，WAF無法對衆多DDoS攻擊進行攔截，會造成WAF防護失效，此時可在WAF之前部署DDoS防護，先攔截DDoS網絡層攻擊，再将網絡層無法檢測的攻擊流量和過濾後的正常流量轉發到WAF中進行檢測，如下圖所示。
圖 WAF部署在DDoS防護之後
2. WAF中的攻擊日志處理及誤報處理
WAF對于各類應用層攻擊有兩種防護模式，攔截模式會對檢測出有攻擊的請求進行直接攔截，這種方式可能會出現一些誤判，特别是在業務系統剛增加WAF防護時；告警模式在檢測出有攻擊的請求時不會進行攔截，隻進行告警記錄，需要增加人工判斷。
圖 WAF防護統計
在業務系統剛增加WAF時，為了減少誤判，可先開啟告警模式，無論是攻擊流量還是正常流量，WAF都不會對其進行攔截，通過告警記錄由人工判斷哪些是嚴重的攻擊問題，哪些是誤判告警。對于誤判告警可手動添加恢複，并設定後續不再将其作為風險項進行攔截。待系統運作穩定、WAF誤判減少之後再開啟攔截模式，此時再手動檢測是否有誤報情況并手動排除。
3. WAF報表及告警
WAF提供幾乎實時的防護日志及統計報表，掌握目前應用請求數、攻擊數、攻擊IP、攻擊類型等資訊。圖8-20展示了需要重點關注的攻擊資料統計資訊，提供按時間次元的攻擊數量統計，可以通過對比得到目前遭受攻擊的趨勢；還包括遭受攻擊的類型及嚴重程度的分類資料，高風險的攻擊相比中低風險的攻擊更應該受到重視；按照攻擊類型分類可以自行判斷其緊急程度，有的應用更關注資訊洩露，有的應用更關注越權通路，根據這些統計資訊可以下鑽檢視該類别的所有攻擊記錄的詳細資訊。
圖 WAF安全報表
WAF安全報表統計使用者全部域名，将在固定時間周期内的安全攻擊報告發送到使用者的郵箱。攻擊告警統計使用者全部域名，将在固定時間觸發一定的攻擊次數後向使用者發送告警。源站狀态監控（如果源站對WAF的探測IP進行處理，可能會造成誤判告警）統計使用者全部域名，按分鐘級檢測使用者源站的連通性。下圖所示為WAF全局告警設定。
- 安全報告：統計使用者全部域名，将在固定時間周期内的安全攻擊報告發送到使用者的郵箱。
- 攻擊告警通告：統計使用者全部域名，将在固定時間觸發一定的攻擊次數後向使用者發送告警。
- 源站狀态監控：（如果源站對WAF的探測IP進行處理，可能會造成誤告警）統計使用者全部域名，按分鐘級檢測使用者源站的連通性。
- 安全報告：統計使用者全部域名，将在固定時間周期内的安全攻擊報告發送到使用者的郵箱。
- 攻擊告警通告：統計使用者全部域名，将在固定時間觸發一定的攻擊次數後向使用者發送告警。
- 源站狀态監控：（如果源站對WAF的探測IP進行處理，可能會造成誤告警）統計使用者全部域名，按分鐘級檢測使用者源站的連通性。
圖 WAF全局告警設定
4. 通過混合架構擴充安全防護能力
通過混合架構将所有流量切分到雲端，通過雲端安全服務進行過濾，再将正常業務流量切分到本地環境和雲端環境後端進行處理，擴充本地環境的安全防護能力。雲平台面向多租戶提供計算、存儲、安全防護等服務，相對而言遇到的各類挑戰和攻擊更多、更複雜，雲服務商為保障平台中的使用者業務安全、可靠，勢必時刻投入精力來應對挑戰和攻擊，是以更能提供完善的安全解決方案及應對攻擊和安全風險的項目經驗。
私有化部署的本地環境在安全防護方面有以下痛點。
- 本地環境中無論是租用IDC還是自建伺服器叢集，都難以實作足夠的安全防護能力。
- 本地環境安全防護裝置更新換代慢，也難以應對層出不窮、更新換代的各類攻擊。
- 本地資料中心除了計算資源擴充不便，安全防護能力也有限，本地環境采用硬體WAF、接入裝置進行攻擊檢測與攔截，遇到大規模網絡攻擊時通過部署硬體安全服務難以及時響應。
混合架構業務還是運作在本地環境中，将所有流量切分到雲端，通過雲端安全服務進行過濾，再将正常業務流量切分到本地環境和雲端環境後端進行處理。當遇到應用層攻擊時，攻擊流量也會分發到雲平台，進行流量過濾後，攻擊流量會被過濾阻斷。在安全防護的角度上講，雲平台相當于本地環境的能力延展，即利用雲平台種類豐富的安全産品、更強的防護能力和安全服務來對本地環境中的業務、資源、資料提供安全攻擊攔截、安全風險識别服務，保護本地業務的安全。
5. 擴充：安全防護體系
業務暴露在網際網路中，會受到很多的DDoS攻擊、cc攻擊、XSS攻擊、SQL注入等，也經常看到有企業發生“删庫跑路”事件，是以除了應對外部的安全攻擊，還要防護内部的運維風險，加強從業人員的安全意識教育訓練等。安全風險包括實體、終端、網絡、應用、資料等各方面，不同行業、地區對業務的合規要求也非常多，總之一句話，有哪些安全風險就提供哪些安全防護方案。安全合規體系圖如下圖所示。
圖 安全合規體系圖
6. 擴充：安全責任共擔模型
雲廠商會盡力提供各種服務來保障使用者業務、資料安全，并并非所有安全責任都由雲廠商來承擔，而是由使用者和雲廠商共同來承擔，這就是安全責任共擔模型。
雲廠商有責任要保障底層雲平台、提供的雲資源的安全防護，而雲平台中運作的業務屬于使用者，雲平台也沒有權力來通路使用者運作的資料，是以這部分的安全責任由使用者來承擔。舉個例子，雲廠商好比售賣門鎖的公司，提供了安全可靠、牢不可破的門鎖，而使用者把門鑰匙随意丢棄、不注意保管，這樣也不能保障大門的安全，是以大門的安全需要門鎖廠商和使用者共同來承擔。在雲平台中即便有非常可靠的安全保護措施，而使用者将雲主機、雲資料庫的密碼設定的比較簡單或暴露給其他人員，則會給整體的安全來帶非常大的隐患。
雲廠商提出安全責任共擔模型并不是雲廠商來推卸責任，而是雲廠商和使用者之間的責任界限是非常明确的，責任劃厘清晰。這樣也有一定的好處，就是使用者知道哪些安全責任需要自己來考慮，哪些安全責任是雲廠商來承擔的。
圖 安全責任共擔模型
7. 延伸思考
- 在混合架構中能通過雲端WAF來防護本地環境，那能否采用朵雲部署的方式來通過WAF互相進行安全防護？
8. 動手實驗
- 選擇一個雲平台，建立WAF配置，并解析到一個Web網站中，将配置進行截圖；
- 通過域名通路WAF配置中的域名，并模拟觸發SQL注入，在浏覽器中對攔截SQL注入的界面進行截圖；
- 在WAF報表中檢視觸發的安全攻擊資訊，進行截圖；
- 将操作的電腦IP位址加入到WAF黑名單中，再次通路該域名，在浏覽器中檢視效果并截圖。