【51CTO.com快譯】在過去幾十年，Web應用防火牆(WAF)變成了一種無處不在的安全設備。凡是有Web應用程序的組織(包括大多數大企業)都安裝了WAF，以保護其數據和資產不被人利用和攻擊。保護Web應用程序安全的最佳實踐已演變為僅僅在應用程序前面部署WAF。但是在當前市場，隨著現代應用生命週期助力DevOps以極快的頻率發佈更新，傳統的WAF能否跟得上步伐?
在現代敏捷開發環境下，WAF並不像人們說的那麼好，這已是公開的行業秘密。WAF跟不上頻繁的應用程序更新，維護WAF已變得非常費力又費事。
如果WAF死了，安全專家該如何是好?什麼會阻止您的Web應用程序成為進入貴組織安全環境的正門?知道DevOps會繼續推出新代碼，您如何確定WAF是否值得維護或者它是否已進入死衚衕?不妨看看您的WAF如何跟得上DevOps的速度。
圖1
上下文為王
網絡安全旨在監控靜態網絡(使用彼此相同的協議)，而WAF旨在保護彼此明顯不同的Web應用程序。每個應用程序都是唯一的，每個代碼段都不同，都有自身的一系列漏洞。甚至在引入雲存儲和速度飛快的DevOp之前，WAF都被認為只是很普通的安全解決方案。
使用位於應用程序前面而不是內嵌的解決方案意味著，不可能進行上下文分析。由於沒有上下文來了解正在交互的應用程序裡面的內容，WAF方面的發展就不可能自動跟上應用程序方面的發展。
教育、教育、教育
機器學習方面的改進只能在一定程度上解決這個難題。複雜的WAF“只”需要一個月靜靜安置下來、學習為應用程序創建基準，可任由應用程序在一個月內不受保護實在太久了。人們難免需要介入，幫助調校WAF，這時候維護變成了繁重任務。如果每當內容或代碼更改，WAF就需要時間來學習和創建基線，管理員面臨大量的繁重工作，以便減少警報，並創建例外。
不自動化就瓦解
說說下一個問題：您的WAF是否可以在沒有人幹預的情況下真正保護Web應用程序免受邏輯攻擊?答案在於，如果持續交付，這根本不可能。事實上，大多數WAF都不處於警報模式。允許它們阻止的話，太危險了，因為大量警報會造成警報疲勞。
也許管理員會做一些細微的調整，以便用阻止規則保護應用程序的敏感部分，但是應用程序的其餘部分將由警報模式下的WAF使用模式匹配及其他粗陋的技術加以保護。這就導致安全解決方案無法隨著應用程序的發展而自動部署，以免受新的邏輯攻擊。
不快速就回家
雲計算的主題是敏捷性。2015年要花兩週才能創建的軟件現在只需幾秒鐘。如果利用微服務，您可以在幾分鐘內顯著改變應用程序。在這種新環境下，考慮使用依賴學習或手動配置的標準老式應用程序安全解決方案很荒謬。
每當開發人員調整代碼並將其發送到外面，這都是單方面的舉動，沒有與安全人員協商。
如果您使用的WAF依賴這種假設：您環境中的一切都是非特有的，您的WAF已經失效，那是時候改變了。WAF已死，DevOps殺死了它。現在是時候進行分析了，以確定您的WAF是否還可用或者您是否使用的很累贅。
原文標題：The Web App Firewall Is Dead and We Know Who Killed It，作者：TJ Gonen
【51CTO譯稿，合作站點轉載請註明原文譯者和出處為51CTO.com】
轉載請超鏈接註明：頭條資訊 » Web應用防火牆已死，你知道是誰殺死了它嗎？
免責聲明
：非本網註明原創的信息，皆為程序自動獲取互聯網，目的在於傳遞更多信息，並不代表本網贊同其觀點和對其真實性負責；如此頁面有侵犯到您的權益，請給站長發送郵件，並提供相關證明(版權證明、身份證正反面、侵權鏈接)，站長將在收到郵件24小時內刪除。