虛擬網路的防火牆和應用程式閘道

若要保護 Azure 應用程式工作負載，您應該在應用程式本身使用防護措施，例如驗證和加密。 您也可以將安全性層級新增至裝載應用程式的虛擬網路 （VNet）。 這些安全性層級可保護應用程式的輸入流程不受非預期的使用率。 它們也會將輸出流量限制為只有應用程式所需的端點。 本文說明 Azure 虛擬網路 安全性服務，例如 Azure DDoS 保護、Azure 防火牆和 Azure 應用程式閘道、何時使用每個服務，以及結合這兩者的網路設計選項。

• Azure DDoS 保護，結合應用程式設計最佳做法，提供增強的 DDoS 風險降低功能，以提供更多防禦 DDoS 攻擊。 您應該在任何周邊虛擬網路上啟用 Azure DDOS 保護。
• Azure 防火牆 是一種受控新一代防火牆，可提供 網路地址轉換 （NAT）。 Azure 防火牆會根據因特網通訊協定 （IP） 位址和傳輸控制通訊協定和用戶數據報通訊協定 （TCP/UDP） 埠，或以應用程式為基礎的 HTTP（S） 或 SQL 屬性進行封包篩選。 Azure 防火牆也會套用Microsoft威脅情報來識別惡意IP位址。 如需詳細資訊，請參閱 Azure 防火牆檔。
• Azure 防火牆進階 包含 Azure 防火牆標準和其他功能的所有功能，例如 TLS 檢查和入侵檢測和保護系統（IDPS）。
• Azure 應用程式閘道 是受控 Web 流量負載平衡器和 HTTP（S） 完整反向 Proxy，可進行安全套接字層 （SSL） 加密和解密。 應用程式閘道會在 X-Forwarded-For HTTP 標頭中保留原始用戶端 IP 位址。 應用程式閘道也會使用 Web 應用程式防火牆來檢查 Web 流量，並偵測 HTTP 層的攻擊。 如需詳細資訊，請參閱 應用程式閘道檔案。
• Azure Web 應用程式防火牆 （WAF） 是 Azure 應用程式閘道的選擇性新增專案。 它會檢查 HTTP 要求，並防止 Web 層的惡意攻擊，例如 SQL 插入式或跨網站腳本。 如需詳細資訊，請參閱 Web 應用程式防火牆檔。

這些 Azure 服務是互補的。 一個或另一個可能最適合您的工作負載，或者您可以使用它們在網路和應用層的最佳保護。 使用下列判定樹和本文中的範例來判斷應用程式虛擬網路的最佳安全性選項。

Azure 防火牆和 Azure 應用程式閘道使用不同的技術，並支援不同流程的證券化：

根據應用程式所需的網路流程，每個應用程式的設計可能會有所不同。 下圖提供簡化的判定樹，可協助為應用程式選擇建議的方法。 決策取決於應用程式是透過 HTTP（S） 或其他通訊協議發行：

本文將涵蓋流程圖中廣泛建議的設計，以及較不常見案例適用的其他設計：

• 當虛擬網路中沒有任何 Web 應用程式時，單獨Azure 防火牆。 它會控制應用程式和輸出流量的輸入流量。
• 僅 應用程式閘道時，只有 Web 應用程式位於虛擬網路中，且 網路安全組 （NSG） 提供足夠的輸出篩選。 Azure 防火牆所提供的功能可以防止許多攻擊案例（例如數據外泄、IDPS 等等）。 基於這個原因，應用程式網關單獨案例通常不建議使用，因此不會記載，而且不在上述流程圖中。
• Azure 防火牆和應用程式閘道平行，這是最常見的設計之一。 當您想要讓 Azure 應用程式閘道保護 HTTP（S） 應用程式免受 Web 攻擊，以及 Azure 防火牆來保護所有其他工作負載並篩選輸出流量時，請使用這個組合。
• 當您想要 Azure 防火牆檢查所有流量、WAF 保護 Web 流量，以及應用程式知道用戶端的來源 IP 位址時，Azure 防火牆前的應用程式閘道。 透過 Azure 防火牆進階和 TLS 檢查，此設計也支援端對端 SSL 案例。
• 應用程式閘道前方的 Azure 防火牆，當您想要 Azure 防火牆在到達應用程式閘道之前檢查和篩選流量。 因為 Azure 防火牆不會解密 HTTPS 流量，所以新增至應用程式閘道的功能有限。 上述流程圖中並未記載此案例。

在本文中的最後一個部分中，會說明先前基本設計的變化。 這些變化包括：

• 內部部署應用程式用戶端。
• 中樞和輪輻網路。
• Azure Kubernetes Service （AKS） 實作。

您可以新增其他反向 Proxy 服務，例如 API 管理 閘道，或 Azure Front Door。 或者，您可以將 Azure 資源取代為第三方 網路虛擬裝置。

僅限 Azure 防火牆

如果虛擬網路中沒有可從 WAF 獲益的 Web 型工作負載，您只能使用 Azure 防火牆。 在此情況下，設計很簡單，但檢閱封包流程將有助於瞭解更複雜的設計。 在此設計中，所有輸入流量都會透過使用者定義的路由傳送至 Azure 防火牆，以取得來自內部部署或其他 Azure VNet 的連線。 此位址會尋址至來自公用因特網之連線的 Azure 防火牆公用 IP 位址，如下圖所示。 來自 Azure VNet 的輸出流量會透過 UDR 傳送至防火牆，如下列對話框所示。

下表摘要說明此案例的流量流程：

Azure 防火牆不會檢查輸入 HTTP（S） 流量。 但它將能夠套用第 3 層 & 第 4 層規則和 FQDN 型應用程式規則。 Azure 防火牆會根據 Azure 防火牆層，以及您是否設定 TLS 檢查，來檢查輸出 HTTP（S） 流量：

• Azure 防火牆標準只會檢查網路規則中封包的第 3 層 & 第 4 層屬性，以及應用程式規則中的主機 HTTP 標頭。
• Azure 防火牆進階新增功能，例如檢查其他 HTTP 標頭（例如 User-Agent），以及啟用 TLS 檢查以進行更深入的封包分析。 Azure 防火牆不等於 Web 應用程式防火牆。 如果您的虛擬網路中有 Web 工作負載，強烈建議您使用 WAF。

下列封包逐步解說範例示範用戶端如何從公用因特網存取 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的流量流程。

工作流程

1. 用戶端會啟動連線至 Azure 防火牆的公用 IP 位址：
   • 來源IP位址：ClientPIP
   • 目的地 IP 位址：AzFwPIP
2. 對 Azure 防火牆公用 IP 的要求會散發至防火牆的後端實例，在此案例中為 192.168.100.7。 Azure 防火牆 目的地 NAT （DNAT） 規則 會將目的地 IP 位址轉譯為虛擬網路內的應用程式 IP 位址。 如果封包執行 DNAT，Azure 防火牆也會 來源 NAT（SNAT） 封包。 如需詳細資訊，請參閱Azure 防火牆已知問題。 VM 會在傳入封包中看到下列 IP 位址：
   • 來源IP位址：192.168.100.7
   • 目的地 IP 位址：192.168.1.4
3. VM 會回答應用程式要求、反轉來源和目的地IP位址。 輸入流程不需要 用戶定義的路由 （UDR），因為來源 IP 是 Azure 防火牆的 IP 位址。 0.0.0.0/0 圖表中的 UDR 適用於輸出連線，以確保公用因特網的封包通過 Azure 防火牆。
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.100.7
4. 最後，Azure 防火牆會復原 SNAT 和 DNAT 作業，並將響應傳遞給用戶端：
   • 來源 IP 位址：AzFwPIP
   • 目的地 IP 位址：ClientPIP

僅限應用程式閘道

此設計涵蓋虛擬網路中只有 Web 應用程式存在的情況，並檢查具有 NSG 的輸出流量足以保護流向因特網的輸出流量。

與先前設計只有 Azure 防火牆的主要差異在於應用程式閘道不會作為具有 NAT 的路由裝置。 其行為是完整的反向應用程式 Proxy。 也就是說，應用程式閘道會停止來自用戶端的 Web 工作階段，並與其中一部後端伺服器建立個別的工作階段。 來自因特網的輸入 HTTP（S） 連線必須傳送至應用程式閘道的公用 IP 位址、從 Azure 或內部部署連線到閘道的私人 IP 位址。 從 Azure VM 傳回流量會遵循標準 VNet 路由回到應用程式閘道（如需詳細資訊，請參閱封包進一步逐步解說）。 來自 Azure VM 的輸出因特網流程會直接移至因特網。

下表摘要說明流量：

建築

下列封包逐步解說範例示範用戶端如何從公用因特網存取 VM 裝載的應用程式。

工作流程

1. 用戶端會啟動連線至 Azure 應用程式閘道的公用 IP 位址：
   • 來源IP位址：ClientPIP
   • 目的地 IP 位址：AppGwPIP
2. 應用程式閘道公用IP的要求會散發至閘道的後端實例，在此案例中為192.168.200.7。 接收要求的應用程式閘道實例會停止來自客戶端的連線，並建立與其中一個後端的新連線。 後端會將應用程式閘道實例視為來源IP位址。 應用程式閘道會插入具有原始用戶端IP位址的 X-Forwarded-For HTTP 標頭。
   • 來源 IP 位址：192.168.200.7（應用程式閘道實例的私人 IP 位址）
   • 目的地 IP 位址：192.168.1.4
   • X-Forwarded-For 標頭：ClientPIP
3. VM 會回答應用程式要求、反轉來源和目的地IP位址。 VM 已經知道如何連線到應用程式閘道，因此不需要 UDR。
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.200.7
4. 最後，應用程式閘道實例會回答用戶端：
   • 來源IP位址：AppGwPIP
   • 目的地 IP 位址：ClientPIP

Azure 應用程式閘道會將元數據新增至封包 HTTP 標頭，例如包含原始用戶端 IP 位址的 X-Forwarded-For 標頭。 某些應用程式伺服器需要來源用戶端 IP 位址來提供地理位置特定內容，或用於記錄。 如需詳細資訊，請參閱 應用程式閘道的運作方式。

• IP 位址 192.168.200.7 是 Azure 應用程式閘道服務所部署的其中一個實例，此處包含內部私人前端 IP 位址 192.168.200.4。 Azure 系統管理員通常看不到這些個別實例。 但注意到差異在某些情況下很有用，例如針對網路問題進行疑難解答時。

• 如果用戶端透過 VPN 或 ExpressRoute 閘道來自內部部署網路，則流程會類似。 差異在於用戶端會存取應用程式閘道的私人IP位址，而不是公用位址。

防火牆和應用程式閘道平行

由於其簡單性和彈性，因此平行執行應用程式閘道和 Azure 防火牆通常是最佳案例。

如果虛擬網路中混合了 Web 和非 Web 工作負載，請實作此設計。 Azure 應用程式閘道中的 Azure WAF 可保護 Web 工作負載的輸入流量，而 Azure 防火牆會檢查其他應用程式的輸入流量。 Azure 防火牆將涵蓋這兩種工作負載類型的輸出流程。

來自因特網的輸入 HTTP（S） 連線應傳送至應用程式閘道的公用 IP 位址、從 Azure 或內部部署到其私人 IP 位址的 HTTP（S） 連線。 標準 VNet 路由會將封包從應用程式閘道傳送至目的地 VM，以及從目的地 VM 傳回應用程式閘道（如需詳細資訊，請參閱封包逐步解說）。 針對輸入非 HTTP（S） 連線，流量應以 Azure 防火牆的公用 IP 位址為目標（如果來自公用因特網），否則會透過 AZURE 防火牆傳送 UDR（如果來自其他 Azure VNet 或內部部署網路）。 來自 Azure VM 的所有輸出流程都會由 UDR 轉送至 Azure 防火牆。

下表摘要說明此案例的流量流程：

此設計提供比 NSG 更細微的輸出篩選。 例如，如果應用程式需要連線到特定的 Azure 記憶體帳戶，您可以使用 完整功能變數名稱 （FQDN）型篩選。 使用 FQDN 型篩選，應用程式不會將數據傳送至流氓記憶體帳戶。 只能使用 NSG 來防止該案例。 此設計通常用於輸出流量需要以 FQDN 為基礎的篩選。 其中一個範例情況是 限制來自 Azure Kubernetes Services 叢集的輸出流量。

架構

下圖說明來自外部客戶端的輸入 HTTP（S） 連線流量：

下圖說明從網路 VM 到因特網的輸出連線流量流程。 其中一個範例是連線到後端系統或取得作業系統更新：

每個服務的封包流程步驟與先前的獨立設計選項相同。

防火牆前的應用程式閘道

此設計會在使用 Azure 防火牆和應用程式閘道的 Web 應用程式 零信任網路中更詳細地說明，本檔將著重於與其他設計選項的比較。 在此拓撲中，輸入Web流量會同時通過 Azure 防火牆和 WAF。 WAF 會在 Web 應用層提供保護。 Azure 防火牆可作為集中記錄和控制點，它會檢查應用程式閘道與後端伺服器之間的流量。 應用程式閘道和 Azure 防火牆不是平行的，而是一個接一個。

透過 Azure 防火牆進階，此設計可支援端對端案例，其中 Azure 防火牆會套用 TLS 檢查，以在應用程式閘道與 Web 後端之間的加密流量上執行 IDPS。

此設計適用於需要知道連入用戶端來源IP位址的應用程式，例如提供地理位置特定內容或記錄。 Azure 防火牆前面的應用程式閘道會擷取傳入封包的來源 IP 位址，x-forwarded-for 標頭，因此網頁伺服器可以看到此標頭中的原始 IP 位址。 如需詳細資訊，請參閱 應用程式閘道的運作方式。

來自因特網的輸入 HTTP（S） 連線必須傳送至應用程式閘道的公用 IP 位址、從 Azure 或內部部署到私人 IP 位址的 HTTP（S） 連線。 從應用程式閘道 UDR 可確保封包會透過 Azure 防火牆路由傳送（如需詳細資訊，請參閱封包進一步逐步解說）。 針對輸入非 HTTP（S） 連線，流量應以 Azure 防火牆的公用 IP 位址為目標（如果來自公用因特網），否則會透過 AZURE 防火牆傳送 UDR（如果來自其他 Azure VNet 或內部部署網路）。 來自 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 規則指示和 IDPS 的私人 IP 前置詞的詳細資訊。 因此，建議修改 Azure 防火牆原則中的 IDPS 私人前置詞，讓應用程式閘道子網不會被視為內部來源，以將輸入和輸出 IDPS 簽章套用至流量。

下表摘要說明此案例的流量流程：

針對從內部部署或因特網到 Azure 的 Web 流量，Azure 防火牆會檢查 WAF 已允許的流程。 根據應用程式閘道是否加密後端流量（從應用程式閘道到應用程式伺服器的流量），您將有不同的潛在案例：

1. 應用程式閘道會遵循零信任原則來加密流量（端對端 TLS 加密），而 Azure 防火牆將會收到加密的流量。 不過，Azure 防火牆標準可以套用檢查規則，例如網路規則中的第 3 層 & 第 4 層篩選，或使用 TLS 伺服器名稱指示 （SNI） 標頭在應用程式規則中篩選 FQDN。 Azure 防火牆進階 提供更深入的 TLS 檢查可見度，例如 URL 型篩選。
2. 如果應用程式閘道將未加密的流量傳送至應用程式伺服器，Azure 防火牆將會以純文本顯示輸入流量。 Azure 防火牆中不需要 TLS 檢查。
3. 如果在 Azure 防火牆中啟用 IDPS，則會確認 HTTP 主機標頭符合目的地 IP。 如此一來，它將需要主機標頭中指定的 FQDN 名稱解析。 您可以使用 Azure DNS 私人區域和使用 Azure DNS 的預設 Azure 防火牆 DNS 設定來達成此名稱解析。 您也可以使用需要在 Azure 防火牆設定中設定的自定義 DNS 伺服器來達成。 （如需詳細資訊，請參閱 Azure 防火牆 DNS 設定。如果部署 Azure 防火牆的虛擬網路沒有系統管理存取權，則後者方法是唯一的可能性。 其中一個範例是部署在虛擬 WAN 安全中樞的 Azure 防火牆。

建築

針對其餘流量（輸入非 HTTP（S） 流量和任何輸出流量，Azure 防火牆會在適當時提供 IDPS 檢查和 TLS 檢查。 它也提供 以 FQDN 為基礎的篩選，以網路規則為基礎， 根據 DNS。

工作流程

來自公用因特網的網路流量會遵循此流程：

1. 用戶端會啟動連線至 Azure 應用程式閘道的公用 IP 位址：
   • 來源IP位址：ClientPIP
   • 目的地 IP 位址：AppGwPIP
2. 應用程式閘道公用IP的要求會散發至閘道的後端實例，在此案例中為192.168.200.7。 應用程式閘道實例會停止來自客戶端的連線，並建立與其中一個後端的新連線。 應用程式閘道子網中要 192.168.1.0/24 的 UDR 會將封包轉送至 Azure 防火牆，同時保留 Web 應用程式的目的地 IP：
   • 來源 IP 位址：192.168.200.7（應用程式閘道實例的私人 IP 位址）
   • 目的地 IP 位址：192.168.1.4
   • X-Forwarded-For 標頭：ClientPIP
3. Azure 防火牆不會 SNAT 流量，因為流量會移至私人 IP 位址。 如果規則允許，它會將流量轉送至應用程式 VM。 如需詳細資訊，請參閱 Azure 防火牆 SNAT。 不過，如果流量在防火牆中叫用應用程式規則，則工作負載會看到處理封包的特定防火牆實例的來源IP位址，因為 Azure 防火牆會 Proxy 連線：
   • 如果 Azure 防火牆網路規則允許流量，則來源 IP 位址：192.168.200.7（其中一個應用程式網關實例的私人 IP 位址）。
   • 如果 Azure 防火牆應用程式規則允許流量，則來源 IP 位址：192.168.100.7（其中一個 Azure 防火牆實例的私人 IP 位址）。
   • 目的地 IP 位址：192.168.1.4
   • X-Forwarded-For 標頭：ClientPIP
4. VM 會回答要求、反轉來源和目的地 IP 位址。 要 192.168.200.0/24 的 UDR 會擷取傳回應用程式閘道的封包，並將它重新導向至 Azure 防火牆，同時將目的地 IP 保留至應用程式閘道。
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.200.7
5. 同樣地，Azure 防火牆不會 SNAT 流量，因為它會移至私人 IP 位址，並將流量轉送至應用程式閘道。
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.200.7
6. 最後，應用程式閘道實例會回答用戶端：
   • 來源IP位址：AppGwPIP
   • 目的地 IP 位址：ClientPIP

從 VM 到公用因特網的輸出流程會通過 Azure 防火牆，如 UDR 所定義，以 0.0.0.0/0。

防火牆之後的應用程式閘道

此設計可讓 Azure 防火牆在到達應用程式閘道之前篩選和捨棄惡意流量。 例如，它可以套用威脅情報型篩選等功能。 另一個優點是，無論通訊協議為何，應用程式都會針對輸入和輸出流量取得相同的公用IP位址。 不過，Azure 防火牆 SNAT 連入流量，因此應用程式將無法看見 HTTP 要求的原始 IP 位址。 從系統管理的觀點來看，例如針對疑難解答目的，您可以藉由將它與 Azure 防火牆的 SNAT 記錄相互關聯，以取得特定連線的實際用戶端 IP。

此案例有有限的權益，因為 Azure 防火牆只會看到將加密流量傳送至應用程式閘道。 在某些情況下，此設計是慣用的。 其中一個案例是，如果網路稍早有另一個 WAF （例如，使用 Azure Front Door），這可能會擷取 X-Forwarded-For HTTP 標頭中的原始來源 IP。 或者，如果需要許多公用IP位址，則建議使用設計。

來自公用因特網的 HTTP（S） 輸入流程應以 Azure 防火牆的公用 IP 位址為目標，而 Azure 防火牆會將封包 DNAT （和 SNAT） 封包傳送到應用程式網關的私人 IP 位址。 從其他 Azure VNet 或內部部署網路，HTTP（S） 流量應傳送至應用程式閘道的私人 IP，並使用 UDR 透過 Azure 防火牆轉送。 標準 VNet 路由可確保從 Azure VM 傳回流量回到應用程式閘道，並在使用 DNAT 規則時從應用程式閘道傳回至 Azure 防火牆。 如需來自應用程式閘道子網內部部署或 Azure UDR 的流量，應使用 （如需詳細資訊，請參閱封包進一步逐步解說）。 從 Azure VM 到因特網的所有輸出流量都會由 UDR 透過 Azure 防火牆傳送。

下表摘要說明此案例的流量流程：

針對輸入 HTTP（S） 流量，Azure 防火牆通常不會解密流量。 它會改為套用不需要 TLS 檢查的 IDPS 原則，例如 IP 型篩選或使用 HTTP 標頭。

建築

應用程式看不到 Web 流量的原始來源 IP 位址;Azure 防火牆 SNAT 封包傳入虛擬網路時。 若要避免此問題，請在防火牆前面使用 Azure Front Door。 Azure Front Door 會將用戶端的 IP 位址插入為 HTTP 標頭，再進入 Azure 虛擬網路。

工作流程

來自公用因特網的網路流量會遵循此流程：

1. 用戶端會啟動連線至 Azure 防火牆的公用 IP 位址：
   • 來源IP位址：ClientPIP
   • 目的地 IP 位址：AzFWPIP
2. 對 Azure 防火牆公用 IP 的要求會散發至防火牆的後端實例，在此案例中為 192.168.100.7。 Azure 防火牆 DNAT Web 埠，通常是 TCP 443 到應用程式網關實例的私人 IP 位址。 執行 DNAT 時，Azure 防火牆也會使用 SNAT。 如需詳細資訊，請參閱 Azure 防火牆已知問題：
   • 來源 IP 位址：192.168.100.7（Azure 防火牆實例的私人 IP 位址）
   • 目的地 IP 位址：192.168.200.4
3. 應用程式閘道會在處理連線的實例與其中一部後端伺服器之間建立新的工作階段。 用戶端的原始 IP 位址不在封包中：
   • 來源 IP 位址：192.168.200.7（應用程式閘道實例的私人 IP 位址）
   • 目的地 IP 位址：192.168.1.4
   • X-Forwarded-For 標頭：192.168.100.7
4. VM 會回答應用程式閘道、反轉來源和目的地 IP 位址：
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.200.7
5. 應用程式閘道會回復 Azure 防火牆實例的 SNAT 來源IP位址。 即使連線來自特定應用程式閘道實例，例如 .7，Azure 防火牆仍會將應用程式網關的內部IP位址視為來源IP .4：
   • 來源IP位址：192.168.200.4
   • 目的地 IP 位址：192.168.100.7
6. 最後，Azure 防火牆會復原 SNAT 和 DNAT，並回答用戶端：
   • 來源 IP 位址：AzFwPIP
   • 目的地 IP 位址：ClientPIP

即使應用程式閘道沒有針對應用程式設定的接聽程式，它仍然需要公用IP位址，因此Microsoft可以管理它。

內部部署用戶端

上述設計全都顯示來自公用因特網的應用程式用戶端。 內部部署網路也會存取應用程式。 上述大部分的資訊和流量都與因特網用戶端相同，但有一些顯著的差異：

• VPN 閘道或 ExpressRoute 閘道位於 Azure 防火牆或應用程式閘道前方。
• WAF 會使用應用程式閘道的私人IP位址。
• Azure 防火牆不支援私人 IP 位址的 DNAT。 這就是為什麼您必須使用 UDR 從 VPN 或 ExpressRoute 閘道將輸入流量傳送至 Azure 防火牆的原因。
• 請務必針對 Azure 應用程式閘道 和 Azure 防火牆，確認 強制通道 周圍的注意事項。 即使您的工作負載不需要對公用因特網進行輸出連線，您也無法為指向內部部署網路的應用程式網關插入預設路由，例如 0.0.0.0/0，或是中斷控制流量。 針對 Azure 應用程式閘道，預設路由必須指向公用因特網。

建築

下圖顯示 Azure 應用程式閘道和 Azure 防火牆平行設計。 應用程式用戶端來自透過 VPN 或 ExpressRoute 連線至 Azure 的內部部署網路：

即使所有客戶端都位於內部部署或 Azure 中，Azure 應用程式閘道和 Azure 防火牆都需要有公用 IP 位址。 公用IP位址允許Microsoft管理服務。

中樞和輪輻拓撲

本文中的設計仍適用於 中樞和輪輻 拓撲。 中央中樞虛擬網路中的共享資源會透過虛擬網路對等互連連線到不同輪輻虛擬網路中的應用程式。

建築

考慮

此拓撲的一些考慮包括：

• Azure 防火牆會部署在中央中樞虛擬網路中。 上圖顯示在中樞部署應用程式閘道的做法。 不過，應用程式小組通常會管理 Azure 應用程式閘道或 Azure API 管理閘道等元件。 在此情況下，這些元件會部署在輪輻虛擬網路中。
• 特別注意輪輻網路中 UDR：當輪輻中的應用程式伺服器接收來自特定 Azure 防火牆實例的流量時，例如先前範例中的 192.168.100.7 位址，它應該會將傳回流量傳回相同的實例。 如果輪輻中的 UDR 將尋址至中樞的下一個流量躍點設定為 Azure 防火牆 IP 位址（上圖中的192.168.100.4），則傳回封包最終可能會位於不同的 Azure 防火牆實例上，導致非對稱路由。 請確定您在輪輻 VNet 中有 UDR 可透過 Azure 防火牆將流量傳送至中樞內的共用服務，這些 UDR 不會包含 Azure 防火牆子網的前置詞。
• 上述建議同樣適用於應用程式閘道子網，以及可能部署於中樞 VNet 的任何其他網路虛擬設備或反向 Proxy。
• 您無法透過具有下一個躍點類型的靜態路由，設定應用程式閘道或 Azure 防火牆子網的下一個躍點，Virtual Network。 這個下一個躍點類型只在本機 VNet 中有效，而且不適用於 VNet 對等互連。 如需使用者定義路由和下一個躍點類型的詳細資訊，請參閱 虛擬網路流量路由。

非對稱式路由

下圖顯示輪輻如何將 SNATted 流量傳回 Azure 防火牆的 ALB。 此設定會導致非對稱路由：

若要解決此問題，請在輪輻中定義沒有 Azure 防火牆子網的 UDR，但只定義共用服務所在的子網。 在此範例中，輪輻中的正確 UDR 應該只包含 192.168.1.0/24。 它不應該包含整個 192.168.0.0/16，如紅色標示。

與其他 Azure 產品整合

您可以將 Azure 防火牆和 Azure 應用程式閘道與其他 Azure 產品和服務整合。

API 管理閘道

將反向 Proxy 服務，例如 API 管理 閘道整合到先前的設計中，以提供 API 節流或驗證 Proxy 等功能。 整合 API 管理閘道並不會大幅改變設計。 主要差異在於，與其單一應用程式網關反向 Proxy，而是彼此鏈結的兩個反向 Proxy。

如需詳細資訊，請參閱 設計指南，將 API 管理和應用程式閘道整合到虛擬網路中，以及適用於微服務的應用程式模式 API 閘道。

Azure Kubernetes Service

針對在 AKS 叢集上執行的工作負載，您可以部署獨立於叢集的 Azure 應用程式閘道。 或者，您可以使用 Azure 應用程式閘道輸入控制器，將其與 AKS 叢集整合。 在 Kubernetes 層級設定特定物件時（例如服務和輸入），應用程式閘道會自動調整，而不需要額外的手動步驟。

Azure 防火牆在 AKS 叢集安全性中扮演著重要的角色。 它提供必要功能，以根據 FQDN 篩選來自 AKS 叢集的輸出流量，而不只是 IP 位址。 如需詳細資訊，請參閱 控制 AKS 叢集節點的輸出流量。

當您結合應用程式閘道和 Azure 防火牆來保護 AKS 叢集時，最好使用平行設計選項。 具有 WAF 應用程式閘道會處理叢集中 Web 應用程式的輸入連線要求。 Azure 防火牆只允許明確允許的輸出連線。 如需平行設計選項的範例，請參閱 azure Kubernetes Service （AKS） 叢集 的 基準架構。

Azure Front Door

Azure Front Door 功能部分與 Azure 應用程式閘道重疊。 例如，這兩項服務都提供 Web 應用程式防火牆、SSL 卸除和 URL 型路由。 其中一個主要差異是，雖然 Azure 應用程式閘道位於虛擬網路內，但 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中使用 Private Link 保護您的原始來源。

如需兩個服務之間差異的詳細資訊，或何時使用每個服務，請參閱 azure Front Door的常見問題 。

其他網路虛擬設備

Microsoft產品並不是在 Azure 中實作 Web 應用程式防火牆或新一代防火牆功能的唯一選擇。 廣泛的Microsoft合作夥伴提供網路虛擬設備（NVA）。 概念和設計基本上與本文相同，但有一些重要的考慮：

• 適用於新一代防火牆的合作夥伴 NVA 可能會為 Azure 防火牆不支援的 NAT 設定提供更多控制和彈性。 範例包括來自內部部署的DNAT，或來自因特網不含SNAT的DNAT。
• 相較於使用者需要處理許多設備間延展性和復原性的 NVA，Azure 管理的 NVA（例如應用程式閘道和 Azure 防火牆）可降低複雜度。
• 在 Azure 中使用 NVA 時，請使用 主動-主動 和 自動調整 設定，因此這些設備對於在虛擬網路中執行的應用程式來說不是瓶頸。

貢獻

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主體作者：

• 何塞·莫雷諾 |首席客戶工程師

後續步驟

深入瞭解元件技術：

• 什麼是 Azure 應用程式閘道？
• 什麼是 Azure 防火牆？
• 什麼是 Azure Front Door？
• Azure Kubernetes Service
• 什麼是 Azure 虛擬網路？
• 什麼是 Azure Web 應用程式防火牆？

相關資源

探索相關的架構：

• 實作安全的混合式網路
• 安全管理的 Web 應用程式
• 保護防火牆後方的 Microsoft Teams 頻道 Bot 和 Web 應用程式
• Azure 中高敏感 IaaS 應用程式的安全性考慮
• Azure 上的多租使用者 SaaS
• 使用 App Services 環境 企業部署
• 使用 App Services 環境 高可用性企業部署
• Azure Kubernetes Service （AKS） 叢集的基準架構