隨著網絡攻擊的演進，Web應用防火墻（WAF）的應用也在發生變化。企業組織部署WAF不僅要對網站進行保護，還要對逐漸普及的Kubernetes、微服務、API和無服務器部署等新興應用進行保障和支撐。因此，部署和管理WAF已不再是安全團隊的責任，而是從應用設計、敏捷開發、信息化應用到安全團隊所有人的任務。

在傳統模式中，WAF通常作為物理的、本地化的（on-premises）工具部署在Web服務器的前面，保護Web應用和API遠離內外攻擊，尤其是防止注入攻擊和應用層拒絕服務攻擊（DoS），監控對Web應用的訪問以及收集訪問日志用于合規審計和溯源分析。而近年來，基于云的WAF服務也成為一種很流行的應用方案，它通過訂閱方式SaaS化交付服務，安全策略由服務提供商預先定義好，能夠共享威脅數據并得到標準化的運維支持，從而更快捷地應用和管理。

然而，并非所有企業都適用云WAF。兩種服務模式各有利弊，企業需要從價格、性能、功能以及應用程序和數據的敏感程度進行綜合評估。

云WAF的價值

易于部署

云WAF通常更易于部署，服務商會在交付前對其進行優化，并設計更規范的工作流程和功能。用戶無需安裝任何軟件或者部署任何硬件設備，只需修改DNS即可實現云WAF服務的部署應用。

較低的購買成本

云WAF一般會用標準化的規則或訪問控制列表（ACL）來實現防護功能，因此服務交付的難度低，應用成本可控。

與其他服務的集成

原生化的云WAF可以與云上其他服務（比如日志工具、DNS管理和應用交付功能）更好集成。如果企業正在運行Kubernetes或其他容器編排工具，這一點顯得尤為重要。對于企業組織來說，IT團隊肩負許多工作職責，輕松集成可以節省大量時間，降低運營復雜性。

運維難度低

云WAF的防護規則都處于云端，一旦發現新的安全威脅，可以由服務商統一在云端更新規則并維護，用戶無需擔心因為疏忽而導致安全事件的發生。

云WAF的不足

擴展性不足

云WAF往往是標準化的解決方案，無法讓企業對未來的擴展性進行精細化控制，一些復雜的安全防護配置通常難以在云WAF上實現。

可靠性較低

云WAF處理請求時，需要經過DNS解析、請求調度、流量過濾等多個環節，其中涉及協同關聯工作，其中只要有一個環節出現問題，就會導致網站無法正常訪問的情況。必要時，還需要手動切換為原DNS來保證業務正常運行。

不可預測的成本

云WAF常常根據多個參數來定價，比如訪問控制列表（ACL）的數量、防火墻規則的數量、防火墻組的數量、處理的請求數量等。如果發生不可預見的事件（比如重大擴展事件或復雜的網絡攻擊），反而會導致更高的使用成本。

不支持多云或混合云

由于大多數組織選擇多云或混合架構，這會給云WAF的應用帶來阻礙。安全團隊必須通曉每個云上WAF服務所特有的身份驗證方案、管理控制臺和語法規則。

服務商鎖定

如果企業在一個云中構建了復雜的WAF規則，會難以擴展到另一個云平臺，因為將這些規則導出會非常困難。當然，企業可以手動完成這項任務，但在微服務環境下，這可能意味著遷移大量WAF規則，甚至可能出現規則丟失的情況。

結語

分析利弊后，我們發現基于云的WAF更適合安全需求較低的企業應用，但可能不適用在大型應用程序、復雜用例和不斷變化的應用架構等場景中。尤其是可能有數千個微服務，東西向流量與南北向流量一樣備受關注的Kubernetes、微服務和無服務器環境，云WAF的管理可能變得棘手起來。

此外，當開發人員或DevOps團隊需要更全面地控制應用擴展模式和規則時，云WAF可能無法提供足夠的細粒度。公共云中的管理控制臺可自動管理ACL和規則，并簡化這種管理，但它們通常無法在多云或混合云環境使用。

具體采用哪種WAF形式并不是“一方醫百病”的問題，企業安全人員需要結合業務需求，弄清楚企業重心是什么，以及轉向云端的速度如何，當明確了企業業務發展路線之后，他們就可以決定自己想要的WAF部署模式究竟是本地化還是云交付的模式。

參考鏈接：https://thenewstack.io/pros-and-cons-of-public-cloud-wafs/?