Azure Web 應用程式防火牆（WAF）保護您的網頁應用程式免受常見的 HTTP 層攻擊，如 SQL 注入、跨站腳本（XSS）及路徑遍歷。 與 Azure 防火牆 不同，後者會在第 3 至 7 層檢查網路層級威脅，WAF 僅在第 7 層運作，並理解 HTTP 語意，包括請求標頭、查詢字串、請求主體及 Cookie。 將 WAF 部署為附加政策，綁定在 Azure 應用程式閘道（區域性）或 Azure Front Door（全球邊緣），以匹配保護範圍與你的應用程式架構。 Web 應用程式防火牆 是三大核心 Azure 網路安全服務之一，另外兩項是 Azure 防火牆 和 Azure DDoS 防護。
本文涵蓋的內容
本文介紹使用 Azure Web 應用程式防火牆 進行 HTTP 層保護。 您瞭解：
- Application Gateway v2 上的 WAF 與 Azure Front Door 上的 WAF 之間的平台比較。
- 基於 OWASP 的規則集，包括預設規則集（DRS）與核心規則集（CRS）。
- 偵測模式與預防模式，以及何時使用。
- WAF 原則範圍選項：全域、每個網站及每個接聽程式關聯。
- 自訂規則用於速率限制、地理過濾及應用特定邏輯。
- WAF（第 7 層 HTTP）與 Azure 防火牆（第 3–7 層網路）之間的區別。
誰需要這篇文章
當您的工作負載符合以下一項或多項標準時，部署 WAF：
- 面向公眾的網頁應用程式： 您的應用程式接受來自網際網路的 HTTP/HTTPS 入站流量，導致它們暴露於 OWASP 十大漏洞，包括注入攻擊、驗證失效濫用及敏感資料外洩嘗試。
- 合規要求： 像 PCI DSS（支付卡產業資料安全標準）這類法規要求在任何處理支付卡資料的應用程式前方設置網路應用程式防火牆。
- API 保護： 你的 API 是公開存取的，需要防範請求走私、超大型載荷以及網路防火牆不會檢查的協定層級攻擊。
- 機器人防護： 你需要分類並控管自動化流量，阻擋惡意機器人，同時允許合法的網路爬蟲和監控服務。
若組織僅需網路層級流量過濾（IP、埠口與協定），且不需 HTTP 請求檢查，則應改用 Azure 防火牆 或 NSG。
隨即轉移重點：許多重新裝載的內部應用程式沒有網際網路輸入，因此不需要 WAF。 只有在遷移過程中或之後，將網頁應用程式暴露給網路時才加入 WAF。
現代化重點：面向客戶的前端 Web 應用程式，全域應用程式使用 Azure Front Door 上的 WAF，單地區應用程式使用應用程式閘道上的 WAF，與您選擇的 Front Door 或流量管理員交付方式保持一致。
跨雲重點：針對已移轉的公用 Web 應用程式，在輪輻中的 Application Gateway 上部署第 7 層 WAF，並將其他雲端的 Web 防護機制（例如 Google Cloud Armor）對應至 Azure WAF。
Azure WAF 平台比較
Azure WAF 支援兩個平台。 每個平台將WAF檢測整合到交通流的不同點。
| 能力 | 應用閘道 v2 上的 WAF | Azure Front Door 上的 WAF |
|---|---|---|
| 部署範圍 | 區域性（單一 Azure 區域） | 全域 (192+ 個遍布全域的邊緣 PoP) |
| 檢查點 | 當交通抵達你的區域後 | 在邊緣 PoP，流量到達來源之前 |
| 支援的規則集 | DRS 2.2、DRS 2.1、CRS 3.2 | DRS 2.2、DRS 2.1、DRS 2.0 |
| 自訂規則 | ✔ | ✔ |
| 機器人防護 | ✔ | ✔ （僅限高級等級） |
| 速率限制 | ✔ | ✔ |
| Geo-filtering | ✔ | ✔ |
| 每個網站原則 | ✔ (每個接聽程式、每條路徑) | ✔ (每個端點) |
| 受管理的規則集 | ✔ | ✔ （僅限高級等級;標準版僅支援自訂規則） |
| 要求本文檢查 | 最高可達 128 KB（可設定） | 最高可達 128 KB（可設定） |
| Private Link 來源支援 | 不適用（與 App Gateway 內嵌） | ✔（私有來源端連線） |
| 最適合用於 | 單區域應用程式、L7 負載平衡 + WAF | 多區域應用程式、全球加速 + WAF |
Note
Azure Front Door 有兩個等級：標準與高級。 受管理規則集（包括 DRS 和機器人防護）僅在 Front Door Premium 上提供。 Front Door Standard 僅支援自訂規則。 Front Door（經典版）僅支援 DRS 1.1 或更早版本。
如何選擇你的WAF平台
請依照以下決策標準：
- 當您的應用程式部署於單一區域，且已使用第 7 層負載平衡、TLS 終止或基於路徑路由的應用閘道時，請選擇 WAF。 WAF 可在不引入額外服務轉送的情況下，新增內嵌式 HTTP 檢查。
- 當您的應用程式跨越多個區域、需要全球負載平衡，或享受內容傳遞網路（CDN）加速時，請選擇 Azure Front Door 上的 WAF。 Front Door WAF 會在最近的邊緣存在點 (PoP) 檢查流量。 該服務會在惡意請求經過 Azure 骨幹網到達你的來源前阻擋它們。 此方法可降低暴露的攻擊面，並在邊緣端吸收大流量的第 7 層攻擊。
- 當 Front Door 服務的多區域應用程式也需要區域 WAF 政策，且後端各有差異時，請同時選擇兩者（分層）。 Front Door 提供第一線的全球防護，而 Application Gateway WAF 則在更靠近工作負載的位置套用區域特定的自訂規則。
設計考量
隨即轉移 WAF 設計重點
- 對於僅供內部使用，且沒有來自網際網路之傳入路徑的重新託管工作負載，可略過 WAF；當您將應用程式發佈到網際網路時，再重新評估。
- 當您暴露一個 Web 應用程式時，先以偵測模式啟動 WAF 來偵測基準流量，然後在排除誤判後切換到預防模式。
- 對於已在前端使用應用程式閘道進行第 7 層路由的單一地區重新裝載 Web 應用程式，請使用應用程式閘道 WAF。
- 以您內部部署的 Web 防護規則意圖（例如 OWASP 涵蓋範圍）作為起始原則。
WAF 設計重點現代化
- 從一開始就以預防模式執行 WAF，針對面向客戶的應用程式，並採用最新的管理規則集，讓覆蓋率自動追蹤新的 OWASP 威脅。
- 啟用機器人管理功能，區分合法爬蟲與惡意自動化程式，保護你的公開應用程式。
- 以程式碼形式管理 WAF 原則，讓主動-主動地區後端透過部署管線保持同步。
- 將邊緣 WAF 與集線防火牆結合以進行深度防禦，並在 VNet 上開啟 DDoS 網路保護，啟用應用閘道 WAF 計費折扣。
跨雲 WAF 設計重點
- 在 Spoke VNet 的應用閘道上架設第 7 層 WAF，這樣就能檢查公開網路流量，而不會直接將公開 IP 附加到虛擬機上。
- 將其他雲端（例如 AWS WAF 或 Google Cloud Armor）現有的網路保護對應到 Azure WAF 管理的規則集，讓覆蓋範圍得以延續。
- 透過 WAF 檢查面向公眾的通訊，並在虛擬 WAN 中樞防火牆上保持東西向和跨雲端傳輸檢查。
- 切換期間，請先以偵測 (學習) 模式執行 WAF，待確認合法流量模式後，再執行流量模式。
先決條件
在部署 Azure Web 應用程式防火牆 之前，請確保你具備：
- 應用程式閘道版本 2 或 Azure Front Door 資源：WAF 做為附加到這些平台之一的原則進行部署。 你必須先設定一個現有的 Application Gateway v2 實例或 Azure Front Door 設定檔，才能建立並關聯 WAF 政策。
- 面向公開的 HTTP/HTTPS 工作負載： 你的應用程式必須接收入站的 HTTP/HTTPS 流量。 WAF 檢查請求層級語意，對非 HTTP 工作負載或純內部服務無益處。
- 理解 HTTP 流量模式： 熟悉應用程式的正常請求模式（標頭、查詢參數與內容）有助於你配置排除與調整規則，以減少偵測到防範模式轉換期間的誤報。
規則集與規則處理
WAF 使用規則集來偵測 HTTP 請求中的惡意模式。 了解規則階層和處理順序，有助於你針對特定應用調整 WAF。
受管理的規則集
Microsoft 維護基於 OWASP 核心規則集（CRS）模式的受管理規則集。 新部署的建議規則集是 DRS 2.2 （預設規則集）。 DRS 2.2 建立在 OWASP CRS 3.3.4 基礎上，並新增了 Microsoft 威脅情報特徵碼。
| 規則集 | 根據 | 平台支援 | Recommendation |
|---|---|---|---|
| DRS 2.2 | OWASP CRS 3.3.4 + Microsoft Threat Intel | App Gateway v2， Front Door Premium | 建議使用於新部署 |
| DRS 2.1 | OWASP CRS 3.3 | App Gateway v2， Front Door Premium | 前一代;兩個平台都支援 |
| DRS 2.0 | OWASP CRS 3.2 | 僅限 Front Door 進階版 | 支持;前門 N-2 版本 |
| CRS 3.2 | OWASP CRS 3.2 | 僅限 App Gateway v2 版本 | 支持;新部署請使用 DRS 2.2 |
DRS 和 CRS 規則集使用 異常評分。 每條匹配規則都會貢獻分數，而非立即封鎖請求。 當累積異常分數超過可設定的閾值時，WAF 會採取行動（封鎖或日誌）。 此方法與個別規則封鎖相比，可減少更多誤判，因為單一信心值低的對比結果不會觸發執行。
自訂規則
自訂規則會在受管理規則 之前 執行，並使用優先順序來控制評估順序（較低的數字=較高的優先權）。 使用自訂規則：
- 速率限制： 在限定時間內限制每個用戶端 IP 的請求，以減少憑證填充和暴力破解攻擊。
- 地理過濾： 根據客戶的國家或來源地區來允許或拒絕流量。
- IP 允許清單與拒絕清單： 在受管理規則評估前，允許已知合作夥伴 IP 或封鎖已知惡意行為者。
- 請求標頭檢查： 強制執行應用程式特定的要求，例如強制的 API 金鑰或預期的內容類型。
Bot 保護規則集
兩個平台都提供一套機器人防護規則，將自動化流量分類為良好機器人（經過驗證的搜尋引擎）、壞機器人（已知惡意掃描者）及未知機器人。 為每個類別設定動作：允許好機器人、封鎖壞機器人，並以速率限制或 CAPTCHA 挑戰未知機器人。
偵測模式與預防模式
WAF 政策以兩種模式運作，決定系統如何處理匹配請求：
| Mode | 行為 | 應用案例 |
|---|---|---|
| 偵測 | 日誌會匹配請求，但不會封鎖它們。 請求會繼續傳送到後端。 | 初始部署與規則調整。 監控哪些規則被觸發，而不影響生產流量。 |
| 預護 | 封鎖符合條件的請求，並傳回 403 回應。 記錄被封鎖的請求。 | 規則調整完成後的生產工作負載。 主動防護攻擊。 |
推薦的調校工作流程
- 以偵測模式部署：在偵測模式下，使用您選擇的規則集啟用 WAF。 將生產環境流量路由至 WAF。
- 分析日誌： 檢視 WAF 日誌以識別誤報。 確定合法應用程式流量觸發的規則。
- 建立排除項目： 針對會產生誤判的規則，請定義排除項目，以指定要針對特定規則略過的請求欄位（標頭、Cookie 和查詢參數）。
- 切換到預防模式： 在偵測日誌乾淨且誤報率達可接受 1 至 2 週後，切換至預防模式進行主動阻斷。
- 持續監測： 切換到預防模式後，請繼續監控日誌。 新的應用程式功能或 API 變更可能會產生新的誤報模式。
Important
一律在預防模式下執行生產工作負載。 偵測模式無法提供任何保護。 它只會記錄潛在攻擊。 偵測模式僅在初期調校階段或排除特定誤報問題時使用。
WAF 政策範圍與關聯
WAF 政策是一個獨立的 Azure 資源，包含你的模式選擇、規則集設定、自訂規則和排除事項。 將保單與一個或多個目標綁定以控制保護範圍。
應用閘道 WAF 政策範圍
在 Application Gateway 上，將 WAF 政策關聯到三個細緻層級：
- 全球（全門戶）： 此政策適用於應用閘道上的所有監聽者及路徑規則。 當閘道器背後的所有應用程式共享相同的保護需求時，使用全域範圍。
- 聽眾層級： 不同的 WAF 政策適用於特定的監聽器（主機名稱與埠口組合）。 當多個應用程式共用閘道但需要不同的規則微調或排除時，使用接聽程式層級的範圍。
- 路徑規則層級： WAF 政策適用於監聽器內的特定 URL 路徑規則。 使用路徑規則範圍來對具有多元後端敏感度的應用進行細緻控制。
當多個範圍同時適用於單一請求時，最具體的原則會優先套用：路徑規則優先於接聽程式層級，接聽程式層級又優先於全域層級。
Front Door WAF 原則範圍
在 Front Door 中，WAF 原則可在端點或路由層級建立關聯。 每個 Front Door 端點都可以有自己的 WAF 政策。 此方法使得在單一前門實例中實現應用專屬的保護設定檔。
跨資源共享政策
在多個應用閘道實例或前門端點間共享單一 WAF 政策。 Azure 防火牆管理員 提供涵蓋所有 WAF 政策的集中式可見性與管理，無論平台為何。 當多個資源需要相同保護時，使用共享政策以簡化管理並維持穩定的安全態勢。
與 Azure 防火牆 的差異
WAF 與 Azure 防火牆 保護網路堆疊的不同層級，並擔當互補的角色。 兩者都應部署，以實現縱深防禦。
| Attribute | Web 應用程式防火牆 | Azure 防火牆 |
|---|---|---|
| OSI 層 | 第七層（僅限 HTTP/HTTPS） | 第3–7層（網路與應用層） |
| 交通類型 | 傳送至 Web 應用程式的 HTTP/HTTPS 傳入要求 | 所有交通方向（南北向、東西向） |
| 檢查重點 | HTTP 語意：標頭、正文、Cookie、URI | IP 位址、埠口、協定、FQDN、URL |
| 規則引擎 | 基於 OWASP 的模式匹配 + 異常評分 | 網路規則、應用規則、NAT 規則 |
| 部署模型 | 可與 App Gateway 或 Front Door 整合 | 在中樞子網路中獨立部署，使用 UDR 路由 |
| 典型攻擊被阻擋 | SQL 注入、XSS、CSRF、路徑遍歷 | 埠掃描、C2回撥、DNS外洩 |
使用 WAF 來保護 HTTP 應用程式，使用 Azure 防火牆 進行集中式網路流量檢查。 在樞紐輻射架構中，從網際網路到網頁應用程式的流量通常會經過 Azure 防火牆（用於 DNAT 和網路層級檢查），然後再經過帶有 WAF 的應用閘道（用於 HTTP 層檢查）。 請參見 Azure 防火牆 與流量檢查以了解網路層級元件。
安全性考慮
以下安全措施能幫助您獲得最大程度的 WAF 防護：
- 生產預防模式： 切勿將生產工作負載留在偵測模式。 偵測模式提供可見性但不強制執行，導致應用程式暴露於攻擊之下。
- 規則調整仍在進行中：應用程式不斷演進。 新的 API 端點、參數和內容類型可能會在既有規則集中產生誤判。 部署後定期檢視WAF日誌。
- Log Analytics 整合：將 WAF 診斷日誌傳送至 Log Analytics 工作區。 使用 WAF 工作簿來視覺化被封鎖的請求、觸發的規則及異常分數分布。
- DDoS 與 WAF 一起： WAF 能防範第 7 層應用程式攻擊，但無法減輕體積網路層 DDoS 攻擊。 將 WAF 與 Azure DDoS Protection 搭配，實現全端覆蓋。
- 起源封鎖： 使用前門 WAF 時，請設定你的來源節點只接受來自前門服務標籤的流量。 若無來源鎖定，攻擊者可以繞過 Front Door，直接向你的原始 IP 地址發送請求。
- 敏感資料保護： WAF 日誌可能包含請求資料。 設定日誌清理規則，以掩蓋 WAF 診斷日誌中的敏感欄位（授權標頭、Cookie 或正文內容）。
相關文章
以下文章涵蓋相關的網路安全主題：
- 網際網路入口與流量路由：面向公開應用程式的入口模式。
- 應用程式交付服務：應用閘道與前門作為交付平台。
- Azure 防火牆 與流量檢查：網路層級檢查，補充 WAF 第七層防護。
- DDoS 防護：針對公共 IP 位址的量級攻擊防護。
- 什麼是 Azure 網路安全？：概述中心，比較 Azure 防火牆、DDoS 防護與 Web 應用程式防火牆。
瞭解更多資訊
- Azure Web 應用程式防火牆 概覽
- 應用閘道上的 WAF
- WAF on Azure Front Door
- WAF 原則概觀
- 網頁應用防火牆 CRS 規則群組與規則
- 調整 Azure Front Door 的 Web 應用程式防火牆
下一步
Tip
自己探索？ 回到 總覽導航 器，依能力尋找你的下一篇文章。
您的隨即轉移之旅的下一步：
設定遷移網路監控：在設定網路應用防火牆後，驗證連線與效能。
接下來的現代化旅程：
啟用公共端點的DDoS防護：保護您的公共IP資源免受分散式阻斷服務攻擊。
接下來的跨雲端旅程：
交付您已移轉的應用程式：針對您的跨雲工作負載，將 AWS 和 Google Cloud 的負載平衡器對應至 Azure 的相應服務。