若要協助保護 Azure 應用程式工作負載，請使用防護措施，例如應用程式本身的驗證和加密。 您可以將安全性層級新增至裝載應用程式的虛擬網路。 這些安全性層級可協助保護應用程式的輸入流程不受非預期的使用。 它們也會將輸出流量限制為只有您的應用程式所需的端點。 本文說明 Azure 虛擬網路 Azure DDoS 保護、Azure 防火牆和 Azure 應用程式閘道等安全性服務。 它也會描述何時使用結合它們的每個服務和網路設計選項。
DDoS 保護結合應用程式設計最佳做法，提供增強的 DDoS 風險降低功能，可改善對 DDoS 攻擊的防禦。 您應該在每個周邊虛擬網路上啟用 DDoS 保護。
Azure 防火牆 是受控的下一代防火牆，可提供 網路位址轉換（NAT） 功能。 Azure 防火牆會根據IP位址和傳輸控制通訊協定 （TCP） 或使用者數據報通訊協定 （UDP） 埠來篩選封包。 它可以使用以應用程式為基礎的屬性來篩選流量，例如 HTTP（S） 和 SQL。 Azure 防火牆也會套用Microsoft威脅情報，以協助識別惡意IP位址。 如需詳細資訊，請參閱 Azure 防火牆檔。
Azure 防火牆進階 除了傳輸層安全性 （TLS） 檢查和入侵檢測和預防系統 （IDPS） 等功能之外，也包含 Azure 防火牆標準的所有功能。
應用程式閘道 是受控 Web 流量負載平衡器和 HTTP（S） 完整反向 Proxy，可執行安全套接字層 （SSL） 加密和解密。 應用程式閘道會在
X-Forwarded-ForHTTP 標頭中保留原始用戶端 IP 位址。 應用程式閘道也會使用 Azure Web 應用程式防火牆來檢查 Web 流量，並偵測 HTTP 層的攻擊。 如需詳細資訊，請參閱 應用程式閘道檔案。Web 應用程式防火牆 是應用程式閘道的選擇性新增專案。 它會檢查 HTTP 要求，並防止 Web 層攻擊，例如 SQL 插入式和跨網站腳本。 如需詳細資訊，請參閱 Web 應用程式防火牆檔。
這些 Azure 服務彼此互補。 根據您的需求，使用一個服務可能會更適合您的工作負載。 不過，您可以將這些服務一起使用，協助在網路和應用層提供最佳保護。 使用下列判定樹和本文中的範例，為應用程式的虛擬網路選擇最佳安全性選項。
Azure 防火牆和應用程式閘道會使用不同的技術來協助保護不同類型的數據流。
| 申請流程 | 可由 Azure 防火牆篩選 | 可依應用程式閘道上的 Web 應用程式防火牆進行篩選 |
|---|---|---|
| 從內部部署或因特網到 Azure 的 HTTP（S） 流量（輸入） | 是的 | 是的 |
| 從 Azure 到內部部署或因特網的 HTTP（S） 流量（輸出） | 是的 | 不 |
| 非 HTTP（S） 流量（輸入或輸出） | 是的 | 不 |
設計可能會根據每個應用程式所需的網路流程而有所不同。 下圖提供簡化的判定樹，可協助您為應用程式選擇建議的方法。 這個選擇取決於應用程式是透過 HTTP（S） 或其他通訊協議發行。
本文說明流程圖中顯示的廣泛建議設計，以及適用於較不常見案例的設計：
Azure 防火牆： 虛擬網路中沒有任何 Web 應用程式時使用此設計。 它會控制應用程式和輸出流量的輸入流量。
應用程式閘道僅： 只有 Web 應用程式位於虛擬網路中，且 網路安全組 （NSG） 提供足夠的輸出篩選時，才使用此設計。 Azure 防火牆提供的功能可協助防止數個攻擊案例，例如數據外洩和 IDPS。 因此，通常不建議使用僅限應用程式網關的設計，因此不會包含在上一個流程圖中。
Azure 防火牆和應用程式閘道平行： 當您想要應用程式閘道保護 HTTP（S） 應用程式免受 Web 攻擊和 Azure 防火牆保護所有其他工作負載並篩選輸出流量時，請使用此設計。 Azure 防火牆和應用程式閘道是常見的設計。
Azure 防火牆前的應用程式閘道： 當您想要 Azure 防火牆檢查所有流量、Web 應用程式防火牆以保護 Web 流量，以及應用程式識別用戶端的來源 IP 位址時，請使用此設計。 透過 Azure 防火牆進階和 TLS 檢查，此設計也支援端對端 SSL 案例。
應用程式閘道前方的 Azure 防火牆： 當您想要 Azure 防火牆在到達應用程式閘道之前檢查和篩選流量時，請使用此設計。 由於 Azure 防火牆不會解密 HTTPS 流量，因此其新增至應用程式閘道的功能會受到限制。 此案例並未記載於上一個流程圖中。
本文稍後會說明這些基本設計的變化，包括：
您可以新增其他反向 Proxy 服務，例如 Azure API 管理 閘道，或 Azure Front Door。 或者，您可以將 Azure 資源取代為非Microsoft 網路虛擬設備 （NVA）。
注意
在下列案例中，Azure 虛擬機 （VM） 會作為 Web 應用程式工作負載的範例使用。 這些案例也適用於其他工作負載類型，例如容器或 Azure Web Apps。 針對包含私人端點的設定，請考慮 Azure 防火牆案例中的建議，以檢查目的地為私人端點的流量。
僅限 Azure 防火牆的設計
如果虛擬網路中沒有可從 Web 應用程式防火牆獲益的 Web 型工作負載，您可以使用僅限 Azure 防火牆的設計。 此範例中的設計很簡單，但您可以檢閱封包流程，以進一步瞭解更複雜的設計。 在此設計中，所有輸入流量都會透過使用者定義的路由傳送至 Azure 防火牆，以取得來自內部部署或其他 Azure 虛擬網路的連線。 其會尋址至來自公用因特網之連線的 Azure 防火牆公用 IP 位址，如下圖所示。 UDR 會將輸出流量從 Azure 虛擬網路導向至 Azure 防火牆，如下列對話框所示。
下表摘要說明此案例的流量流程。
| 流 | 通過應用程式閘道/Web 應用程式防火牆 | 通過 Azure 防火牆 |
|---|---|---|
| 從因特網或內部部署到 Azure 的 HTTP（S） 流量 | N/A | 是的 |
| 從 Azure 到因特網或內部部署的 HTTP（S） 流量 | N/A | 是的 |
| 從因特網或內部部署到 Azure 的非 HTTP（S） 流量 | N/A | 是的 |
| 從 Azure 到因特網或內部部署的非 HTTP（S） 流量 | N/A | 是的 |
Azure 防火牆不會檢查輸入 HTTP（S） 流量。 但它可以套用第 3 層和第 4 層規則和完整功能變數名稱 （FQDN） 型應用程式規則。 Azure 防火牆會根據 Azure 防火牆層級以及您是否設定 TLS 檢查，檢查輸出 HTTP（S） 流量：
Azure 防火牆標準只會檢查網路規則中封包的第 3 層和第 4 層屬性，以及應用程式規則中的主機 HTTP 標頭。
Azure 防火牆進階新增功能，例如檢查其他 HTTP 標頭（例如使用者代理程式），以及啟用 TLS 檢查以進行更深入的封包分析。 不過，Azure 防火牆與 Web 應用程式防火牆不同。 如果您的虛擬網路中有 Web 工作負載，建議您使用 Web 應用程式防火牆。
下列封包逐步解說範例示範用戶端如何從公用因特網存取 VM 裝載的應用程式。 為了簡單起見，此圖表只包含一個 VM。 為了提高可用性和延展性，負載平衡器後面有多個應用程式實例。 在此設計中，Azure 防火牆會使用 UDR 檢查來自公用因特網的連入連線，以及來自應用程式子網 VM 的輸出連線。
在這裡範例中，Azure 防火牆會自動部署數個實例，其中前端 IP 位址
192.168.100.4和內部位址192.168.100.0/26。 一般而言，Azure 系統管理員看不到這些實例。 不過，瞭解它們有助於針對網路問題進行疑難解答。如果流量來自內部部署虛擬專用網（VPN）或 Azure ExpressRoute 閘道，而不是因特網，用戶端會啟動 VM IP 位址的連線。 它不會啟動防火牆 IP 位址的連線，且防火牆預設不會執行來源 NAT。
建築
下圖顯示流量流程，並假設實例IP位址 192.168.100.7。
工作流程
用戶端會啟動連線至 Azure 防火牆的公用IP位址。
- 來源IP位址：
ClientPIP - 目的地 IP 位址：
AzFwPIP
- 來源IP位址：
對 Azure 防火牆公用 IP 位址的要求會散發至防火牆的後端實例，在此範例中
192.168.100.7。 Azure 防火牆 目的地網路位址轉換 （DNAT） 規則 將目的地 IP 位址轉譯至虛擬網路內的應用程式 IP 位址。 如果封包使用DNAT，Azure防火牆也會在封包上實作 來源網路位址轉換 （SNAT）。 如需詳細資訊，請參閱Azure 防火牆已知問題。 VM 會在傳入封包中看到下列 IP 位址： - 來源IP位址：
192.168.100.7 - 目的地 IP 位址：
192.168.1.4
- 來源IP位址：
VM 會回答應用程式要求，這會反轉來源和目的地IP位址。 輸入流程不需要 UDR，因為來源 IP 是 Azure 防火牆 IP 位址。
0.0.0.0/0圖表中的 UDR 適用於輸出連線，以確保公用因特網的封包通過 Azure 防火牆。- 來源IP位址：
192.168.1.4 - 目的地 IP 位址：
192.168.100.7
- 來源IP位址：
Azure 防火牆會復原 SNAT 和 DNAT 作業，並將響應傳遞給用戶端。
- 來源IP位址：
AzFwPIP - 目的地 IP 位址：
ClientPIP
- 來源IP位址：
僅限應用程式閘道的設計
此設計描述只有 Web 應用程式存在於虛擬網路中的案例，並檢查具有 NSG 的輸出流量足以保護因特網的輸出流量。
注意
不建議使用此設計，因為使用 Azure 防火牆來控制輸出流程，而不是只依賴 NSG，有助於防止數據外泄等攻擊案例。 使用 Azure 防火牆，您可以協助確保工作負載只會將數據傳送至已核准的 URL 清單。 此外，NSG 只會在第 3 層和第 4 層運作，且不支援 FQDN。
與先前僅限 Azure 防火牆的設計的主要差異在於，應用程式閘道不會作為具有 NAT 的路由裝置。 相反地，它會做為完整的反向應用程式 Proxy。 此方法表示應用程式閘道會停止來自用戶端的 Web 工作階段，並與其中一部後端伺服器建立個別的工作階段。 來自因特網的輸入 HTTP（S） 聯機會傳送至應用程式閘道的公用 IP 位址，而來自 Azure 或內部部署的聯機會使用閘道的私人 IP 位址。 從 Azure VM 傳回流量會遵循標準虛擬網路路由回到應用程式閘道。 如需詳細資訊，請參閱本文稍後的封包逐步解說。 來自 Azure VM 的輸出因特網流程會直接移至因特網。
下表摘要說明流量。
| 流 | 通過應用程式閘道/Web 應用程式防火牆 | 通過 Azure 防火牆 |
|---|---|---|
| 從因特網或內部部署到 Azure 的 HTTP（S） 流量 | 是的 | N/A |
| 從 Azure 到因特網或內部部署的 HTTP（S） 流量 | 不 | N/A |
| 從因特網或內部部署到 Azure 的非 HTTP（S） 流量 | 不 | N/A |
| 從 Azure 到因特網或內部部署的非 HTTP（S） 流量 | 不 | N/A |
建築
下列封包逐步解說範例示範用戶端如何從公用因特網存取 VM 裝載的應用程式。
工作流程
用戶端會啟動與應用程式閘道公用IP位址的連線。
- 來源IP位址：
ClientPIP - 目的地 IP 位址：
AppGwPIP
- 來源IP位址：
應用程式閘道公用IP位址的要求會散發至閘道的後端實例，在此範例中
192.168.200.7。 接收要求的應用程式閘道實例會停止來自客戶端的連線，並使用其中一個後端建立新的連線。 後端會將應用程式閘道實例視為來源IP位址。 應用程式閘道會插入具有原始用戶端IP位址的X-Forwarded-ForHTTP 標頭。- 來源IP位址，這是應用程式閘道實例的私人IP位址：
192.168.200.7 - 目的地 IP 位址：
192.168.1.4 -
X-Forwarded-For標頭：ClientPIP
- 來源IP位址，這是應用程式閘道實例的私人IP位址：
VM 會回答應用程式要求，並反轉來源和目的地 IP 位址。 VM 可以連線到應用程式閘道，因此不需要 UDR。
- 來源IP位址：
192.168.1.4 - 目的地 IP 位址：
192.168.200.7
- 來源IP位址：
應用程式閘道實例會回答用戶端。
- 來源IP位址：
AppGwPIP - 目的地 IP 位址：
ClientPIP
- 來源IP位址：
應用程式閘道會將元數據新增至封包 HTTP 標頭，例如包含原始用戶端 IP 位址的 X-Forwarded-For 標頭。 某些應用程式伺服器需要來源用戶端 IP 位址來提供地理位置特定內容，或用於記錄。 如需詳細資訊，請參閱 應用程式閘道的運作方式。
在此範例中，
192.168.200.7IP位址是應用程式閘道服務自動部署的其中一個實例。 具有內部、私人前端 IP 位址192.168.200.4。 Azure 系統管理員通常看不到這些個別實例。 但注意到差異可能很有用，例如當您針對網路問題進行疑難解答時。如果用戶端透過 VPN 或 ExpressRoute 閘道來自內部部署網路，則流程會類似。 差異在於用戶端會存取應用程式閘道的私人IP位址，而不是公用IP位址。
注意
如需 X-Forwarded-For 標頭以及如何在要求上保留主機名的詳細資訊，請參閱 保留原始 HTTP 主機。
Azure 防火牆和應用程式閘道平行設計
由於其簡單性和彈性，因此最好平行執行應用程式閘道和 Azure 防火牆。
如果虛擬網路中有 Web 和非 Web 工作負載，請實作此設計。 應用程式閘道中的 Web 應用程式防火牆可協助保護 Web 工作負載的輸入流量。 Azure 防火牆會檢查其他應用程式的輸入流量。 Azure 防火牆涵蓋這兩種工作負載類型的輸出流程。
來自因特網的輸入 HTTP（S） 連線應傳送至應用程式閘道的公用 IP 位址。 來自 Azure 或內部部署的 HTTP（S） 連線應傳送至其私人 IP 位址。 標準虛擬網路路由會將封包從應用程式閘道傳送至目的地 VM，以及從目的地 VM 傳回應用程式網關。 如需詳細資訊，請參閱本文稍後的封包逐步解說。
針對輸入非 HTTP（S） 連線，如果流量來自公用因特網，則流量應以 Azure 防火牆的公用 IP 位址為目標。 如果流量來自其他 Azure 虛擬網路或內部部署網路，則流量應透過 Azure 防火牆傳送。 來自 Azure VM 的所有輸出流程都會由 UDR 轉送至 Azure 防火牆。
下表摘要說明此案例的流量流程。
| 流 | 通過應用程式閘道/Web 應用程式防火牆 | 通過 Azure 防火牆 |
|---|---|---|
| 從因特網或內部部署到 Azure 的 HTTP（S） 流量 | 是的 | 不 |
| 從 Azure 到因特網或內部部署的 HTTP（S） 流量 | 不 | 是的 |
| 從因特網或內部部署到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 從 Azure 到因特網或內部部署的非 HTTP（S） 流量 | 不 | 是的 |
此設計提供比僅使用NSG更細微的輸出篩選。 例如，如果應用程式需要連線到特定的 Azure 記憶體帳戶，您可以使用 FQDN 型篩選器。 使用 FQDN 型篩選器時，應用程式不會將數據傳送至 Rogue 記憶體帳戶。 如果您只使用 NSG，就無法防止此案例。 當輸出流量需要 FQDN 型篩選時，通常會使用此設計。 其中一個案例是當您 限制來自 AKS 叢集的輸出流量時。
架構
下圖說明來自外部用戶端之輸入 HTTP（S） 連線的流量流程。
下圖說明從網路 VM 到因特網的輸出連線流量流程。 其中一個範例是連線到後端系統或取得作系統更新。
每個服務的封包流程步驟與先前的獨立設計選項相同。
Azure 防火牆設計前的應用程式閘道
此設計會在使用 Azure 防火牆和應用程式閘道的 Web 應用程式 零信任網路中更詳細地說明。 本文著重於與其他設計選項的比較。 在此拓撲中，輸入Web流量會同時通過 Azure 防火牆和 Web 應用程式防火牆。 Web 應用程式防火牆會在 Web 應用層提供保護。 Azure 防火牆可作為集中記錄和控制點，它會檢查應用程式閘道與後端伺服器之間的流量。 在此設計中，應用程式閘道和 Azure 防火牆不會平行放置，而是位於另一個防火牆前面。
透過 Azure 防火牆進階，此設計可支援端對端案例，其中 Azure 防火牆會套用 TLS 檢查，以在應用程式閘道與 Web 後端之間的加密流量上執行 IDPS。
這個設計適用於需要識別傳入用戶端來源IP位址的應用程式。 例如，它可以用來提供地理位置特定內容或記錄。 Azure 防火牆設計前的應用程式閘道會擷取 X-Forwarded-For 標頭中的傳入封包來源 IP 位址，讓網頁伺服器可以看到此標頭中的原始IP位址。 如需詳細資訊，請參閱 應用程式閘道的運作方式。
來自因特網的輸入 HTTP（S） 連線必須傳送至應用程式閘道的公用 IP 位址。 來自 Azure 或內部部署的 HTTP（S） 連線應傳送至其私人 IP 位址。 從應用程式閘道，UDR 可確保封包會透過 Azure 防火牆路由傳送。 如需詳細資訊，請參閱本文稍後的封包逐步解說。
針對輸入非 HTTP（S） 連線，如果流量來自公用因特網，則流量應以 Azure 防火牆的公用 IP 位址為目標。 如果流量來自其他 Azure 虛擬網路或內部部署網路，則流量應透過 Azure 防火牆傳送。 來自 Azure VM 的所有輸出流程都會由 UDR 轉送至 Azure 防火牆。
此設計的重要層面是 Azure 防火牆進階會查看來自應用程式閘道子網的來源 IP 位址流量。 如果此子網設定為私人IP位址（在 10.0.0.0/8、192.168.0.0/16、172.16.0.0/12或 100.64.0.0/10中），Azure 防火牆進階會將來自應用程式閘道的流量視為內部流量，且不會套用輸入流量的IDPS規則。 因此，建議您修改 Azure 防火牆原則中的 IDPS 私人前置詞。 這項修改可確保應用程式閘道子網不會被視為內部來源，允許將輸入和輸出 IDPS 簽章套用至流量。 您可以在 Azure 防火牆 IDPS 規則中找到 IDPS 規則方向和私人 IP 前綴的詳細資訊，。
下表摘要說明此案例的流量流程。
| 流 | 通過應用程式閘道/Web 應用程式防火牆 | 通過 Azure 防火牆 |
|---|---|---|
| 從因特網或內部部署到 Azure 的 HTTP（S） 流量 | 是的 | 是的 |
| 從 Azure 到因特網或內部部署的 HTTP（S） 流量 | 不 | 是的 |
| 從因特網或內部部署到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 從 Azure 到因特網或內部部署的非 HTTP（S） 流量 | 不 | 是的 |
針對從內部部署或從因特網到 Azure 的 Web 流量，Azure 防火牆會檢查 Web 應用程式防火牆允許的流程。 根據應用程式閘道是否加密後端流量，也就是從應用程式閘道到應用程式伺服器的流量，可能會發生不同的案例：
應用程式閘道會遵循零信任原則來加密流量，例如 端對端 TLS 加密，而 Azure 防火牆會收到加密的流量。 Azure 防火牆標準仍然可以使用 TLS 伺服器名稱指示 （SNI） 標頭來套用檢查規則，例如網路規則中的第 3 層和第 4 層篩選，或在應用程式規則中套用 FQDN 篩選。 Azure 防火牆進階 提供更深入的 TLS 檢查可見度，例如 URL 型篩選。
如果應用程式閘道將未加密的流量傳送至應用程式伺服器，Azure 防火牆會以純文本看到輸入流量。 Azure 防火牆中不需要 TLS 檢查。
如果在 Azure 防火牆中啟用 IDPS，它會驗證 HTTP 主機標頭是否符合目的地 IP 位址。 若要執行此驗證，它需要主機標頭中指定的 FQDN 名稱解析。 您可以使用 Azure DNS 私人區域和預設 Azure 防火牆 DNS 設定來執行此名稱解析。 您也可以使用需要在 Azure 防火牆設定中設定的自定義 DNS 伺服器來達成。 如果您沒有部署 Azure 防火牆之虛擬網路的系統管理存取權，則後者方法是您唯一的選項。 其中一個範例是部署在 Azure 虛擬 WAN 保護中樞的 Azure 防火牆實例。
建築
針對其餘的流程，包括輸入非 HTTP（S） 流量和任何輸出流量，Azure 防火牆會在適當情況下提供 IDPS 檢查和 TLS 檢查。 它也提供 以 FQDN 為基礎的篩選，以網路規則為基礎， 根據 DNS。
工作流程
來自公用因特網的網路流量會遵循此流程：
用戶端會啟動與應用程式閘道公用IP位址的連線。
- 來源IP位址：
ClientPIP - 目的地 IP 位址：
AppGwPIP
- 來源IP位址：
應用程式閘道公用IP位址的要求會散發至閘道的後端實例，在此範例中
192.168.200.7。 應用程式閘道實例會停止來自客戶端的連線，並建立與其中一個後端的新連線。 應用程式閘道子網中要192.168.1.0/24的 UDR 會將封包轉送至 Azure 防火牆，並將目的地 IP 位址保留至 Web 應用程式。- 來源IP位址，這是應用程式閘道實例的私人IP位址：
192.168.200.7 - 目的地 IP 位址：
192.168.1.4 -
X-Forwarded-For標頭：ClientPIP
- 來源IP位址，這是應用程式閘道實例的私人IP位址：
Azure 防火牆不會將 SNAT 套用至流量，因為流量會傳送至私人 IP 位址。 如果規則允許，它會將流量轉送至應用程式 VM。 如需詳細資訊，請參閱 Azure 防火牆 SNAT 私人 IP 位址範圍。 不過，如果流量在防火牆中叫用應用程式規則，工作負載就會看到處理封包的特定防火牆實例的來源IP位址，因為 Azure 防火牆 Proxy 會連線。
- 如果 Azure 防火牆網路規則允許流量，而且是其中一個應用程式閘道實例的私人 IP 位址，則來源 IP 位址：
192.168.200.7 - 如果 Azure 防火牆應用程式規則允許流量，而且是其中一個 Azure 防火牆實例的私人 IP 位址，則來源 IP 位址：
192.168.100.7 - 目的地 IP 位址：
192.168.1.4 -
X-Forwarded-For標頭：ClientPIP
- 如果 Azure 防火牆網路規則允許流量，而且是其中一個應用程式閘道實例的私人 IP 位址，則來源 IP 位址：
VM 會回答要求，這會反轉來源和目的地 IP 位址。 要
192.168.200.0/24UDR 會擷取傳回至應用程式閘道的封包、將它重新導向至 Azure 防火牆，並將目的地 IP 位址保留至應用程式閘道。- 來源IP位址：
192.168.1.4 - 目的地 IP 位址：
192.168.200.7
- 來源IP位址：
同樣地，Azure 防火牆不會將 SNAT 套用至流量，因為它會移至私人 IP 位址，並將流量轉送至應用程式閘道。
- 來源IP位址：
192.168.1.4 - 目的地 IP 位址：
192.168.200.7
- 來源IP位址：
應用程式閘道實例會回答用戶端。
- 來源IP位址：
AppGwPIP - 目的地 IP 位址：
ClientPIP
- 來源IP位址：
從 VM 到公用因特網的輸出流程會經過 Azure 防火牆，UDR 會定義 0.0.0.0/0。
在此設計中，您可以設定 Azure 防火牆中的私人 DNAT，讓應用程式工作負載將 Azure 防火牆實例的 IP 位址視為來源，而且不需要任何 UDR。 應用程式用戶端的來源IP位址已保留於應用程式閘道 X-Forwarded-For HTTP 標頭中。 因此，如果 Azure 防火牆將 DNAT 套用至流量，則不會遺失任何資訊。 如需詳細資訊，請參閱 使用 Azure 入口網站使用 Azure 入口網站篩選輸入因特網或內部網路流量與 Azure 防火牆原則 DNAT。
應用程式閘道設計前的 Azure 防火牆
此設計可讓 Azure 防火牆在到達應用程式閘道之前篩選和捨棄惡意流量。 例如，它可以套用威脅情報型篩選等功能。 另一個優點是，無論通訊協議為何，應用程式都會針對輸入和輸出流量取得相同的公用IP位址。 您理論上可以設定 Azure 防火牆的三種模式：
具有DNAT規則的 Azure 防火牆： Azure 防火牆只會交換IP位址層的IP位址，但不會處理承載。 因此，它不會變更任何 HTTP 標頭。
已停用應用程式規則和 TLS 檢查的 Azure 防火牆： Azure 防火牆可以查看 TLS 中的 SNI 標頭，但不會將其解密。 系統會從防火牆建立新的 TCP 連線到下一個躍點。 在此範例中，它是應用程式閘道。
已啟用應用程式規則和 TLS 檢查的 Azure 防火牆： Azure 防火牆會查看封包內容並加以解密。 它可作為 HTTP Proxy，並可設定 HTTP 標頭
X-Forwarded-For來保留 IP 位址。 不過，它會向用戶端呈現自我產生的憑證。 對於以因特網為基礎的應用程式，使用自我產生的憑證不是選項，因為安全性警告會從其瀏覽器傳送給應用程式用戶端。
在前兩個選項中，這是因特網型應用程式的唯一有效選項，Azure 防火牆會將 SNAT 套用至連入流量，而不設定 X-Forwarded-For 標頭。 因此，應用程式看不到 HTTP 要求的原始 IP 位址。 針對系統管理工作，例如疑難解答，您可以藉由將它與 Azure 防火牆的 SNAT 記錄相互關聯，以取得特定連線的實際用戶端 IP 位址。
此案例的優點有限，因為除非您使用 TLS 檢查，並將自我產生的憑證呈現給客戶端，否則 Azure 防火牆只會看到傳送至應用程式網關的加密流量。 此案例通常僅適用於內部應用程式。 不過，在某些情況下，此設計是慣用的。 其中一個案例是，如果網路稍早有另一個 Web 應用程式防火牆（例如，使用 Azure Front Door），這可以在 X-Forwarded-For HTTP 標頭中擷取原始來源 IP。 如果需要許多公用IP位址，因為應用程式閘道支援單一IP位址，您也可以偏好此設計。
來自公用因特網的 HTTP（S） 輸入流程應以 Azure 防火牆的公用 IP 位址為目標。 Azure 防火牆會將封包 DNAT 和 SNAT 傳送到應用程式閘道的私人IP位址。 從其他 Azure 虛擬網路或內部部署網路，HTTP（S） 流量應傳送至應用程式閘道私人 IP 位址，並使用 UDR 透過 Azure 防火牆轉送。 標準虛擬網路路由可確保使用DNAT規則時，從Azure VM傳回至應用程式閘道和從應用程式閘道傳回 Azure 防火牆的流量。 針對來自內部部署或 Azure 的流量，請使用應用程式閘道子網中的 UDR。 如需詳細資訊，請參閱本文稍後的封包逐步解說。 從 Azure VM 到因特網的所有輸出流量都會透過 UDR 透過 Azure 防火牆傳送。
下表摘要說明此案例的流量流程。
| 流 | 通過應用程式閘道/Web 應用程式防火牆 | 通過 Azure 防火牆 |
|---|---|---|
| 從因特網或內部部署到 Azure 的 HTTP（S） 流量 | 是的 | 是的 |
| 從 Azure 到因特網或內部部署的 HTTP（S） 流量 | 不 | 是的 |
| 從因特網或內部部署到 Azure 的非 HTTP（S） 流量 | 不 | 是的 |
| 從 Azure 到因特網或內部部署的非 HTTP（S） 流量 | 不 | 是的 |
針對輸入 HTTP（S） 流量，Azure 防火牆通常不會解密流量。 而是套用不需要 TLS 檢查的 IDPS 原則，例如 IP 位址型篩選或使用 HTTP 標頭。
建築
應用程式看不到 Web 流量的原始來源 IP 位址。 Azure 防火牆會將 SNAT 套用至傳入虛擬網路的封包。 若要避免此問題，請在防火牆前面使用 Azure Front Door。 Azure Front Door 會將用戶端的 IP 位址插入為 HTTP 標頭，再進入 Azure 虛擬網路。
工作流程
來自公用因特網的網路流量會遵循此流程：
用戶端會啟動連線至 Azure 防火牆的公用IP位址。
- 來源IP位址：
ClientPIP - 目的地 IP 位址：
AzFWPIP
- 來源IP位址：
對 Azure 防火牆公用 IP 位址的要求會散發至防火牆的後端實例，在此範例中
192.168.100.7。 Azure 防火牆會將DNAT套用至Web埠，通常是TCP 443，套用至應用程式閘道實例的私人IP位址。 當您執行 DNAT 時，Azure 防火牆也會套用 SNAT。 如需詳細資訊，請參閱Azure 防火牆已知問題。 - 來源IP位址，這是 Azure 防火牆實例的私人IP位址：
192.168.100.7 - 目的地 IP 位址：
192.168.200.4
- 來源IP位址，這是 Azure 防火牆實例的私人IP位址：
應用程式閘道會在實例之間建立新的工作階段，以處理連線和其中一部後端伺服器。 用戶端的原始IP位址不在封包中。
- 來源IP位址，這是應用程式閘道實例的私人IP位址：
192.168.200.7 - 目的地 IP 位址：
192.168.1.4 -
X-Forwarded-For標頭：192.168.100.7
- 來源IP位址，這是應用程式閘道實例的私人IP位址：
VM 會回答應用程式閘道，這會反轉來源和目的地 IP 位址：
- 來源IP位址：
192.168.1.4 - 目的地 IP 位址：
192.168.200.7
- 來源IP位址：
應用程式閘道會回復 Azure 防火牆實例的 SNAT 來源IP位址。 Azure 防火牆會將應用程式閘道的內部 IP 位址
.4視為來源 IP 位址，即使連線來自特定應用程式閘道實例，例如.7。- 來源IP位址：
192.168.200.4 - 目的地 IP 位址：
192.168.100.7
- 來源IP位址：
Azure 防火牆會復原 SNAT 和 DNAT，並回答用戶端。
- 來源IP位址：
AzFwPIP - 目的地 IP 位址：
ClientPIP
- 來源IP位址：
應用程式閘道需要公用IP位址，讓Microsoft可以管理它，即使它沒有針對應用程式設定的接聽程式也一樣。
注意
不支援指向 Azure 防火牆的應用程式閘道子網中 0.0.0.0/0 的預設路由，因為它會中斷應用程式閘道正常運作所需的控制平面流量。
內部部署用戶端
上述設計全都顯示來自公用因特網的連入應用程式用戶端。 內部部署網路也會存取應用程式。 先前大部分的資訊和流量都與因特網用戶端相同，但有一些顯著的差異：
VPN 閘道或 ExpressRoute 閘道位於 Azure 防火牆或應用程式閘道前方。
Web 應用程式防火牆會使用應用程式閘道的私人IP位址。
Azure 防火牆不支援私人 IP 位址的 DNAT，因此您必須使用 UDR 從 VPN 或 ExpressRoute 閘道將輸入流量傳送至 Azure 防火牆。
請務必針對 應用程式閘道 和 Azure 防火牆，確認 強制通道 周圍的注意事項。 即使您的工作負載不需要對公用因特網的輸出連線，您也無法插入指向內部部署網路的應用程式網關
0.0.0.0/0之類的預設路由，因為它會中斷控制流量。 針對應用程式閘道，預設路由必須指向公用因特網。
建築
下圖顯示應用程式閘道和 Azure 防火牆平行設計。 應用程式用戶端來自透過 VPN 或 ExpressRoute 連線至 Azure 的內部部署網路：
即使所有客戶端都位於內部部署或 Azure 中，應用程式閘道和 Azure 防火牆都需要有公用 IP 位址。 這些公用IP位址允許Microsoft管理服務。
中樞和輪輻拓撲
本文中的設計適用於 中樞與輪輻 拓撲。 中央中樞虛擬網路中的共享資源會透過虛擬網路對等互連連線到不同輪輻虛擬網路中的應用程式。
建築
考慮
此拓撲的一些考慮包括：
Azure 防火牆會部署在中央中樞虛擬網路中。 上圖顯示如何在中樞部署應用程式閘道。 應用程式小組通常會管理應用程式閘道或 API 管理閘道等元件。 在此案例中，這些元件會部署在輪輻虛擬網路中。
請特別注意輪輻網路中 UDR。 當輪輻中的應用程式伺服器接收來自特定 Azure 防火牆實例的流量時，例如先前範例中的
192.168.100.7IP 位址，它應該會將傳回流量傳回相同的實例。 如果輪輻中的 UDR 將尋址至中樞的下一個流量躍點設定為 Azure 防火牆 IP 位址（上圖中的192.168.100.4），則傳回封包最終可能會位於不同的 Azure 防火牆實例上。 這種情況會導致非對稱式路由。 如果您有輪輻虛擬網路中的 UDR，請務必透過 Azure 防火牆將流量傳送至中樞中的共用服務。 這些 UDR 不包含 Azure 防火牆子網的前置詞。上述建議同樣適用於應用程式閘道子網，以及可能部署在中樞虛擬網路中的任何其他 NVA 或反向 Proxy。
您無法透過具有下一個躍點類型的靜態路由，設定應用程式閘道或 Azure 防火牆子網的下一個躍點，
Virtual Network。 這個下一個躍點類型只有在本機虛擬網路中才有效，而不是跨虛擬網路對等互連。 如需 UDR 和下一個躍點類型的詳細資訊，請參閱 虛擬網路流量路由。
非對稱式路由
下圖顯示輪輻如何將 SNAT 流量傳回 Azure 防火牆的 Azure 負載平衡器。 此設定會導致非對稱式路由。
若要解決此問題，請在輪輻中定義沒有 Azure 防火牆子網的 UDR，並且只定義共用服務所在的子網。 在上圖中，輪輻中正確的 UDR 應該只包含 192.168.1.0/24。 它不應該包含整個範圍 192.168.0.0/16，其標示為紅色。
與其他 Azure 產品整合
您可以將 Azure 防火牆和應用程式閘道與其他 Azure 產品和服務整合。
API 管理閘道
將反向 Proxy 服務，例如 API 管理 閘道整合到先前的設計中，以提供 API 節流或驗證 Proxy 等功能。 API 管理閘道整合不會影響設計。 主要差異在於，與其單一應用程式網關反向 Proxy，而是彼此鏈結的兩個反向 Proxy。
如需詳細資訊，請參閱 設計指南，將 API 管理和應用程式閘道整合到虛擬網路中，以及微服務的應用程式模式 API 閘道。
AKS
針對在 AKS 叢集上執行的工作負載，您可以部署獨立於叢集的應用程式閘道。 或者，您可以使用 應用程式閘道輸入控制器，將其與 AKS 叢集整合。 當您在 Kubernetes 層級設定特定物件，例如服務和輸入時，應用程式閘道會自動調整，而不需要額外的手動步驟。
Azure 防火牆在 AKS 叢集安全性中扮演著重要的角色。 它提供必要功能，以根據 FQDN 篩選來自 AKS 叢集的輸出流量，而不只是 IP 位址。 如需詳細資訊，請參閱 在 AKS中使用 Azure 防火牆限制網路流量。
當您結合應用程式閘道和 Azure 防火牆來保護 AKS 叢集時，最好使用平行設計選項。 具有 Web 應用程式防火牆的應用程式閘道會處理叢集中 Web 應用程式的輸入連線要求。 Azure 防火牆只允許明確允許的輸出連線。 如需平行設計選項的詳細資訊，請參閱 AKS 叢集的基準架構。
Azure Front Door
Azure Front Door 具有與應用程式閘道重疊的功能。 這兩項服務都提供 Web 應用程式防火牆、SSL 卸除和 URL 型路由。 不過，主要差異在於，雖然應用程式閘道在虛擬網路內運作，但 Azure Front Door 是全域分散式服務。
您有時可以使用分散式 Azure Front Door 取代應用程式閘道，以簡化虛擬網路設計。 本文所述的大部分設計仍適用，但將 Azure 防火牆放在 Azure Front Door 前面的選項除外。
其中一個案例是在虛擬網路中的應用程式閘道前面使用 Azure 防火牆。 應用程式閘道會將 X-Forwarded-For 標頭插入防火牆實例的IP位址，而不是用戶端的IP位址。 因應措施是在防火牆前面使用 Azure Front Door，在流量進入虛擬網路並到達 Azure 防火牆之前，將用戶端的 IP 位址插入為 X-Forwarded-For 標頭。 您也可以使用 Azure Front Door Premium 中的 Azure Private Link ，保護您的來源。
如需兩個服務之間差異的詳細資訊，或何時使用每個服務，請參閱 Azure Front Door的常見問題。
其他 NVA
Microsoft產品並不是在 Azure 中實作 Web 應用程式防火牆或新一代防火牆功能的唯一選擇。 廣泛的Microsoft合作夥伴提供 NVA。 概念和設計基本上與本文相同，但有一些重要的考慮：
適用於新一代防火牆的合作夥伴 NVA 可能會為 Azure 防火牆不支援的 NAT 設定提供更多控制和彈性。 範例包括來自內部部署的DNAT，或來自因特網不含SNAT的DNAT。
相較於使用者需要處理許多設備間延展性和復原性的 NVA，Azure 受控 NVA 例如應用程式閘道和 Azure 防火牆可降低複雜度。
當您在 Azure 中使用 NVA 時，請使用 主動-主動 和 自動調整 設定，讓這些設備不會成為虛擬網路中執行應用程式的瓶頸。
貢獻
Microsoft維護本文。 下列參與者撰寫本文。
主體作者：
- 何塞·莫雷諾 |首席客戶工程師
若要查看非公開的 LinkedIn 頭像，請登入至 LinkedIn。
後續步驟
深入瞭解元件技術：
相關資源
探索相關的架構：
- 實作安全的混合式網路
- 安全管理的 Web 應用程式
- 保護 Microsoft Teams 通道 Bot 和防火牆後方的 Web 應用程式
- 在 Azure 上 多租使用者軟體即服務
- 使用 App Service Environment Enterprise 部署
- 使用 App Service Environment 高可用性企業部署