隨著網絡攻擊的演進,，Web應用防火墻（WAF）的應用也在發(fā)生變化,。企業(yè)組織部署WAF不僅要對網站進行保護,，還要對逐漸普及的Kubernetes,、微服務、API和無服務器部署等新興應用進行保障和支撐,。因此,，部署和管理WAF已不再是安全團隊的責任，而是從應用設計,、敏捷開發(fā),、信息化應用到安全團隊所有人的任務。
在傳統(tǒng)模式中,，WAF通常作為物理的,、本地化的（on-premises）工具部署在Web服務器的前面，保護Web應用和API遠離內外攻擊,，尤其是防止注入攻擊和應用層拒絕服務攻擊（DoS）,，監(jiān)控對Web應用的訪問以及收集訪問日志用于合規(guī)審計和溯源分析。而近年來,，基于云的WAF服務也成為一種很流行的應用方案,，它通過訂閱方式SaaS化交付服務，安全策略由服務提供商預先定義好,，能夠共享威脅數據并得到標準化的運維支持,，從而更快捷地應用和管理。
然而,，并非所有企業(yè)都適用云WAF,。兩種服務模式各有利弊，企業(yè)需要從價格,、性能,、功能以及應用程序和數據的敏感程度進行綜合評估。
云WAF的價值
易于部署
云WAF通常更易于部署,，服務商會在交付前對其進行優(yōu)化,，并設計更規(guī)范的工作流程和功能。用戶無需安裝任何軟件或者部署任何硬件設備,，只需修改DNS即可實現云WAF服務的部署應用,。
較低的購買成本
云WAF一般會用標準化的規(guī)則或訪問控制列表（ACL）來實現防護功能，因此服務交付的難度低,，應用成本可控,。
與其他服務的集成
原生化的云WAF可以與云上其他服務（比如日志工具、DNS管理和應用交付功能）更好集成,。如果企業(yè)正在運行Kubernetes或其他容器編排工具,，這一點顯得尤為重要。對于企業(yè)組織來說,，IT團隊肩負許多工作職責,，輕松集成可以節(jié)省大量時間，降低運營復雜性,。
運維難度低
云WAF的防護規(guī)則都處于云端,，一旦發(fā)現新的安全威脅，可以由服務商統(tǒng)一在云端更新規(guī)則并維護,，用戶無需擔心因為疏忽而導致安全事件的發(fā)生,。
云WAF的不足
擴展性不足
云WAF往往是標準化的解決方案，無法讓企業(yè)對未來的擴展性進行精細化控制,，一些復雜的安全防護配置通常難以在云WAF上實現,。
可靠性較低
云WAF處理請求時，需要經過DNS解析,、請求調度,、流量過濾等多個環(huán)節(jié)，其中涉及協(xié)同關聯(lián)工作,，其中只要有一個環(huán)節(jié)出現問題,，就會導致網站無法正常訪問的情況,。必要時，還需要手動切換為原DNS來保證業(yè)務正常運行,。
不可預測的成本
云WAF常常根據多個參數來定價,，比如訪問控制列表（ACL）的數量、防火墻規(guī)則的數量,、防火墻組的數量,、處理的請求數量等。如果發(fā)生不可預見的事件（比如重大擴展事件或復雜的網絡攻擊）,，反而會導致更高的使用成本,。
不支持多云或混合云
由于大多數組織選擇多云或混合架構，這會給云WAF的應用帶來阻礙,。安全團隊必須通曉每個云上WAF服務所特有的身份驗證方案,、管理控制臺和語法規(guī)則。
服務商鎖定
如果企業(yè)在一個云中構建了復雜的WAF規(guī)則,，會難以擴展到另一個云平臺,，因為將這些規(guī)則導出會非常困難。當然,，企業(yè)可以手動完成這項任務,，但在微服務環(huán)境下，這可能意味著遷移大量WAF規(guī)則,，甚至可能出現規(guī)則丟失的情況,。
結語
分析利弊后，我們發(fā)現基于云的WAF更適合安全需求較低的企業(yè)應用,，但可能不適用在大型應用程序,、復雜用例和不斷變化的應用架構等場景中。尤其是可能有數千個微服務,，東西向流量與南北向流量一樣備受關注的Kubernetes,、微服務和無服務器環(huán)境，云WAF的管理可能變得棘手起來,。
此外,，當開發(fā)人員或DevOps團隊需要更全面地控制應用擴展模式和規(guī)則時，云WAF可能無法提供足夠的細粒度,。公共云中的管理控制臺可自動管理ACL和規(guī)則,，并簡化這種管理，但它們通常無法在多云或混合云環(huán)境使用,。
具體采用哪種WAF形式并不是“一方醫(yī)百病”的問題,，企業(yè)安全人員需要結合業(yè)務需求，弄清楚企業(yè)重心是什么，以及轉向云端的速度如何,，當明確了企業(yè)業(yè)務發(fā)展路線之后,，他們就可以決定自己想要的WAF部署模式究竟是本地化還是云交付的模式。
更多信息可以來這里獲取==>>電子技術應用-AET<<
