適用於 Web 應用程式具有 Azure 防火牆和應用程式閘道的 零信任網路

本指南概述針對 Web 應用程式實 作零信任 安全性以進行檢查和加密的策略。 零信任架構包含許多其他概念，例如持續驗證執行者身分識別，或將隱含信任區域的大小降到最低。 本文指的是從公用因特網輸入流量之零信任架構的加密和檢查元件。 如需安全部署應用程式的其他層面，請參閱其他 零信任檔 ，例如驗證。 基於本文的目的，多層式方法最適合使用，其中網路安全性構成零信任模型的其中一層。 在此層中，網路設備會檢查封包，以確保只有合法的流量到達應用程式。

一般而言，不同類型的網路設備會檢查網路封包的不同層面：

• Web 應用程式防火牆會尋找指出 Web 應用層攻擊的模式。
• 新一代防火牆也可以尋找一般威脅。

在某些情況下，您可以結合不同類型的網路安全性設備來增加保護。 虛擬網路的個別指南防火牆和 應用程式閘道 說明可用來排列各種設備的設計模式。 本檔著重於將安全性最大化的常見模式，其中 Azure 應用程式閘道 在 Azure 防火牆 進階版 之前運作。 下圖說明此模式：

下載此架構的 Visio 檔案。

此架構會使用傳輸層安全性 （TLS） 通訊協定來加密每個步驟的流量。

• 用戶端會將封包傳送至負載平衡器 應用程式閘道。 它會使用選擇性新增 Azure Web 應用程式防火牆 執行。

• 應用程式閘道 解密封包，並搜尋 Web 應用程式的威脅。 如果找不到任何威脅，則會使用零信任原則來加密封包。 然後它會釋放它們。

• Azure 防火牆 進階版 執行安全性檢查：

  • 傳輸層安全性 （TLS） 檢查 會解密並檢查封包。
  • 入侵檢測和保護 功能會檢查封包是否有惡意意圖。

• 如果封包通過測試，Azure 防火牆 進階版 採取下列步驟：

  • 加密封包
  • 使用網域名稱系統 （DNS） 服務來判斷應用程式虛擬機 （VM）
  • 將封包轉送至應用程式 VM

此架構中的各種檢查引擎可確保流量完整性：

• Web 應用程式防火牆 使用規則來防止 Web 層的攻擊。 攻擊的範例包括 SQL 程式代碼插入和跨網站文稿。 如需規則和Open Web Application Security Project （OWASP） 核心規則集的詳細資訊，請參閱 Web 應用程式防火牆 CRS 規則群組和規則。
• Azure 防火牆 進階版 使用一般入侵檢測和預防規則。 這些規則有助於識別以 Web 應用程式為目標的惡意檔案和其他威脅。

此架構支援不同類型的網路設計，本文將討論：

• 傳統中樞和輪輻網路
• 使用 Azure 虛擬 WAN 作為平台的網路
• 使用 Azure 路由伺服器簡化動態路由的網路

Azure 防火牆 進階版和名稱解析

檢查惡意流量時，Azure 防火牆 進階版 確認 HTTP 主機標頭是否符合封包 IP 位址和 TCP 連接埠。 例如，假設 應用程式閘道 將 Web 封包傳送至 IP 位址 172.16.1.4 和 TCP 連接埠 443。 HTTP 主機標頭的值應該解析為該IP位址。

HTTP 主機標頭通常不包含IP位址。 相反地，標頭包含符合伺服器數位證書的名稱。 在此情況下，Azure 防火牆 進階版 會使用 DNS 將主機名解析為 IP 位址。 網路設計會決定哪一個 DNS 解決方案最適合運作，如後續章節所述。

數位憑證

下圖顯示架構的 TLS 會話和憑證使用的一般名稱 （CN） 和證書頒發機構單位 ：.

TLS 連線

此架構包含三個不同的 TLS 連線。 數位憑證會驗證每個憑證：

從用戶端到 應用程式閘道

在 應用程式閘道 中，您會部署用戶端看到的數字證書。 已知 CA，例如 DigiCert 或 Let's Encrypt 通常會發出這類憑證。

從 應用程式閘道 到 Azure 防火牆 進階版

若要解密和檢查 TLS 流量，Azure 防火牆 進階版 動態產生憑證。 Azure 防火牆 進階版 也會以網頁伺服器的形式呈現 應用程式閘道。 私人 CA 會簽署 Azure 防火牆 進階版 產生的憑證。 如需詳細資訊，請參閱 Azure 防火牆 進階版 憑證。 應用程式閘道 需要驗證這些憑證。 在應用程式的 HTTP 設定中，您可以設定 Azure 防火牆 進階版 使用的根 CA。

從 Azure 防火牆 進階版 到網頁伺服器

Azure 防火牆 進階版 會建立與目的地網頁伺服器的 TLS 工作階段。 Azure 防火牆 進階版 確認已知的 CA 簽署網頁伺服器 TLS 封包。

元件角色

應用程式閘道 和 Azure 防火牆 進階版 處理憑證的方式彼此不同，因為它們的角色不同：

• 應用程式閘道 是反向 Web Proxy。 它藉由攔截 HTTP 和 HTTPS 要求來保護網頁伺服器免於惡意用戶端。 您會使用其IP位址或完整功能變數名稱，宣告位於 應用程式閘道後端集區中的每個受保護伺服器。 合法的客戶端應該能夠存取每個應用程式。 因此，您可以使用公用 CA 簽署的數位證書來設定 應用程式閘道。 使用任何 TLS 用戶端將接受的 CA。
• Azure 防火牆 進階版 是轉寄 Web Proxy，或者只是 Web Proxy。 它會攔截來自受保護用戶端的 TLS 呼叫，以保護用戶端免受惡意網頁伺服器的攻擊。 當受保護的用戶端提出 HTTP 要求時，轉寄 Proxy 會藉由產生數位證書並將其呈現給用戶端，模擬目標 Web 伺服器。 Azure 防火牆 進階版 會使用私人 CA 來簽署動態產生的憑證。 您可以將受保護的客戶端設定為信任該私人 CA。 在此架構中，Azure 防火牆 進階版 保護來自網頁伺服器 應用程式閘道 的要求。 應用程式閘道 信任 Azure 防火牆 進階版 使用的私人 CA。

路由和流量轉送

根據網路設計的拓撲，路由會稍有不同，下列各節將詳細說明中樞和輪輻、虛擬 WAN 和路由伺服器拓撲範例的詳細數據。 不過，所有拓撲都有一些常見的層面：

• Azure 應用程式閘道 一律會作為 Proxy 運作，而且 Azure 防火牆 進階版 在設定 TLS 檢查時也一樣：來自用戶端的 TLS 會話將會由 應用程式閘道 終止，而新的 TLS 會話將會建置至 Azure 防火牆。 Azure 防火牆 會接收和終止從 應用程式閘道 來源的 TLS 會話，並將新的 TLS 會話建置至工作負載。 此事實對 Azure 防火牆 進階版 的 IDPS 設定有影響，以下各節包含更多有關此設定的詳細數據。
• 工作負載會看到來自 Azure 防火牆 子網IP位址的連線。 原始用戶端 IP 位址會保留在由 應用程式閘道 插入的 HTTP 標頭中X-Forwarded-For。
• 從 應用程式閘道 到工作負載的流量通常會使用 Azure 路由機制傳送至 Azure 防火牆，不論是在 應用程式閘道 的子網中設定的使用者定義路由，或是 Azure 虛擬 WAN 或 Azure 路由伺服器所插入的路由。 雖然在 應用程式閘道 的後端集區中明確定義 Azure 防火牆 的私人IP位址是可行的，但從技術上來說，不建議這麼做，因為它會帶走 Azure 防火牆的某些功能，例如負載平衡和黏性。

下列各節會詳細說明一些與 Azure 防火牆 和 應用程式閘道 搭配使用的最常見拓撲。

中樞與輪幅拓撲 \(部分機器翻譯\)

一般而言，中樞和輪輻設計會在中樞虛擬網路和輪輻中的應用程式特定元件中部署共用網路元件。 在大部分系統中，Azure 防火牆 進階版 是共用資源。 但 Web 應用程式防火牆 可以是共用網路裝置或應用程式特定的元件。 基於下列原因，最好將 應用程式閘道 視為應用程式元件，並將其部署在輪輻虛擬網路中：

• 針對 Web 應用程式防火牆 警示進行疑難解答可能很困難。 您通常需要深入瞭解應用程式，以判斷觸發這些警示的訊息是否合法。
• 如果您將 應用程式閘道 視為共享資源，可能會超過 Azure 應用程式閘道 限制。
• 如果您在中樞部署 應用程式閘道，可能會面臨角色型訪問控制問題。 當小組管理不同的應用程式，但使用相同的 應用程式閘道 實例時，就會出現這種情況。 然後，每個小組都能夠存取整個 應用程式閘道 組態。

使用傳統中樞和輪輻架構，DNS 私人區域提供簡單的 DNS 使用方式：

• 設定 DNS 私人區域。
• 將區域連結至包含 Azure 防火牆 進階版 的虛擬網路。
• 請確定 應用程式閘道 用於流量和健康情況檢查的值存在 A 記錄。

下圖顯示 應用程式閘道 位於輪輻虛擬網路中的封包流程。 在此情況下，用戶端會從公用因特網連線。

1. 用戶端會將要求提交至網頁伺服器。
2. 應用程式閘道 攔截用戶端封包並檢查它們。 如果封包通過檢查，則 應用程式閘道 會將封包傳送至後端 VM。 當封包叫用 Azure 時，應用程式閘道 子網中的使用者定義路由會將封包轉送至 Azure 防火牆 進階版。
3. Azure 防火牆 進階版 對封包執行安全性檢查。 如果他們通過測試，Azure 防火牆 進階版 將封包轉送至應用程式 VM。
4. VM 會回應並將目的地 IP 位址設定為 應用程式閘道。 VM 子網中的 UDR 會將封包重新導向至 Azure 防火牆 進階版。
5. Azure 防火牆 進階版 將封包轉送至 應用程式閘道。
6. 應用程式閘道 回答用戶端。

流量也可以從內部部署網路抵達，而不是公用因特網。 流量會流經站對站虛擬專用網（VPN）或透過 ExpressRoute。 在此案例中，流量會先到達中樞中的虛擬網路網關。 網路流程的其餘部分與上一個案例相同。

1. 內部部署用戶端會連線到虛擬網路閘道。
2. 閘道會將用戶端封包轉送至 應用程式閘道。
3. 應用程式閘道 會檢查封包。 如果他們通過檢查，應用程式閘道 子網中的 UDR 會將封包轉送至 Azure 防火牆 進階版。
4. Azure 防火牆 進階版 對封包執行安全性檢查。 如果他們通過測試，Azure 防火牆 進階版 將封包轉送至應用程式 VM。
5. VM 會回應並將目的地 IP 位址設定為 應用程式閘道。 VM 子網中的 UDR 會將封包重新導向至 Azure 防火牆 進階版。
6. Azure 防火牆 進階版 會將封包轉送至 應用程式閘道。
7. 應用程式閘道將封包傳送至虛擬網路閘道。
8. 閘道會回答用戶端。

虛擬 WAN 拓撲

您也可以在此架構中使用網路服務 虛擬 WAN 。 此元件提供許多優點。 例如，它不需要輪輻虛擬網路中用戶維護的UDR。 您可以改為在虛擬中樞路由表中定義靜態路由。 您連線到中樞的每個虛擬網路程式設計會包含這些路由。

當您使用虛擬 WAN 作為網路平臺時，會產生兩個主要差異：

• 您無法將 DNS 私人區域連結至虛擬中樞，因為 Microsoft 會管理虛擬中樞。 身為訂用帳戶擁有者，您沒有連結私人 DNS 區域的許可權。 因此，您無法將 DNS 私人區域與包含 Azure 防火牆 進階版 的安全中樞產生關聯。 若要實作 Azure 防火牆 進階版 的 DNS 解析，請改用 DNS 伺服器：

  • 將 Azure 防火牆 DNS 設定 設定為使用自定義 DNS 伺服器。
  • 在連線到虛擬 WAN 的共用服務虛擬網路中部署伺服器。
  • 將 DNS 私人區域連結至共用服務虛擬網路。 DNS 伺服器接著可以解析 HTTP 主機標頭中 應用程式閘道 使用的名稱。 如需詳細資訊，請參閱 Azure 防火牆 DNS 設定。

• 如果前置詞比虛擬網路前置詞短（較不明確），您只能使用虛擬WAN 來規劃輪輻中的路由。 例如，在輪輻 VNet 上方的圖表中，有前置詞 172.16.0.0/16：在此案例中， 虛擬 WAN 無法插入符合 VNet 前綴的路由（172.16.0.0/16）或任何子網 （172.16.0.0/24,172.16.1.0/24）。 換句話說，虛擬 WAN 無法吸引位於相同 VNet 中的兩個子網之間的流量。 當 應用程式閘道 和目的地網頁伺服器位於相同的虛擬網路時，這項限制就變得很明顯：虛擬 WAN 無法強制 應用程式閘道 與網頁伺服器之間的流量通過 Azure 防火牆 進階版（因應措施是在 應用程式閘道 的子網中手動設定使用者定義的路由和網頁伺服器。

下圖顯示使用虛擬 WAN 的案例中的封包流程。 在此情況下，應用程式閘道的存取權來自內部部署網路。 站對站 VPN 或 ExpressRoute 會將該網路連線到虛擬 WAN。 從因特網存取很類似。

1. 內部部署用戶端會連線到 VPN。
2. VPN 會將用戶端封包轉送至 應用程式閘道。
3. 應用程式閘道 會檢查封包。 如果他們通過檢查，應用程式閘道 子網會將封包轉送至 Azure 防火牆 進階版。
4. Azure 防火牆 進階版 從共用服務虛擬網路中的 DNS 伺服器要求 DNS 解析。
5. DNS 伺服器會回答解析要求。
6. Azure 防火牆 進階版 對封包執行安全性檢查。 如果他們通過測試，Azure 防火牆 進階版 將封包轉送至應用程式 VM。
7. VM 會回應並將目的地 IP 位址設定為 應用程式閘道。 應用程式子網會將封包重新導向至 Azure 防火牆 進階版。
8. Azure 防火牆 進階版 會將封包轉送至 應用程式閘道。
9. 應用程式閘道 將封包傳送至 VPN。
10. VPN 會回答用戶端。

透過此設計，您可能需要修改中樞公告至輪輻虛擬網路的路由。 具體而言，應用程式閘道 v2 僅支援指向因特網的0.0.0.0/0路由。 沒有指向因特網的路由會中斷 Microsoft 管理 應用程式閘道 所需的連線。 如果您的虛擬中樞公告 0.0.0.0/0 路由，請採取下列步驟，防止該路由傳播至 應用程式閘道 子網：

• 使用 0.0.0.0/0 的路由和 的下一個躍點類型 Internet建立路由表。 將該路由與您部署 應用程式閘道 的子網產生關聯。
• 如果您在專用輪輻中部署 應用程式閘道，請在虛擬網路連線的設定中停用預設路由的傳播。

路由伺服器拓撲

路由伺服器 提供另一種方式，以自動在輪輻中插入路由。 透過這項功能，您可以避免維護路由表的系統管理額外負荷。 路由伺服器結合了虛擬 WAN 和中樞和輪輻變體：

• 使用路由伺服器，客戶會管理中樞虛擬網路。 因此，您可以將中樞虛擬網路連結至 DNS 私人區域。
• 路由伺服器與虛擬 WAN 在 IP 位址前綴方面的限制相同。 如果前置詞比虛擬網路前置詞短（較不明確），您只能將路由插入輪輻。 由於這項限制，應用程式閘道 和目的地 Web 伺服器必須位於不同的虛擬網路中。

下圖顯示路由伺服器簡化動態路由時的封包流程。 請注意下列幾點：

• 路由伺服器目前需要插入路由的裝置，才能透過邊界網關通訊協定 （BGP） 傳送路由。 由於 Azure 防火牆 進階版 不支援 BGP，請改用第三方網路虛擬設備 （NVA）。
• 中樞 NVA 的功能會決定您的實作是否需要 DNS。

1. 內部部署用戶端會連線到虛擬網路閘道。
2. 閘道會將用戶端封包轉送至 應用程式閘道。
3. 應用程式閘道 會檢查封包。 如果他們通過檢查，應用程式閘道 子網會將封包轉送至後端計算機。 路由伺服器插入的 ApplicationGateway 子網中的路由會將流量轉送至 NVA。
4. NVA 會在封包上執行安全性檢查。 如果他們通過測試，NVA 會將封包轉送至應用程式 VM。
5. VM 會回應並將目的地 IP 位址設定為 應用程式閘道。 路由伺服器插入 VM 子網的路由會將封包重新導向至 NVA。
6. NVA 會將封包轉送至 應用程式閘道。
7. 應用程式閘道將封包傳送至虛擬網路閘道。
8. 閘道會回答用戶端。

如同虛擬 WAN，當您使用路由伺服器時，您可能需要修改路由。 如果您公告 0.0.0.0/0 路由，它可能會傳播至 應用程式閘道 子網。 但 應用程式閘道 不支援該路由。 在此情況下，請為 應用程式閘道 子網設定路由表。 包含 0.0.0.0/0 的路由，以及該數據表中的下一個躍點類型 Internet 。

IDPS 和私人IP位址

如 Azure 防火牆 IDPS 規則中所述，Azure 防火牆 進階版 會根據封包的來源和目的地 IP 位址來決定要套用的 IDPS 規則。 Azure 防火牆 會將 RFC 1918 範圍 （和172.16.0.0/12） 和 RFC 6598 範圍 （100.64.0.0/1010.0.0.0/8192.168.0.0/16） 中的每個預設私人 IP 位址視為內部 IP 位址。 因此，如本文中的圖表所示，應用程式閘道 會部署在下列其中一個範圍的子網中（172.16.0.0/24在上述範例中），Azure 防火牆 進階版 會考慮 應用程式閘道 與工作負載之間的流量為內部，而且只會將標示為要套用至內部流量的 IDPS 簽章或使用任何流量。 標示要套用至輸入或輸出流量的 IDPS 簽章將不會套用至 應用程式閘道 與工作負載之間的流量。

強制將IDPS輸入簽章規則套用至 應用程式閘道 與工作負載之間流量的最簡單方式，就是將 應用程式閘道 放在具有私人範圍外前置詞的子網中。 您不一定需要使用此子網的公用IP位址，但您可以自訂 #D43064F92E2B3454CA595961C45A3EE8A ！#DA5C32100530641D4A8335A2D651478CD 視為IDPS內部的IP位址。 例如，如果您的組織未使用100.64.0.0/10範圍，您可以從IDPS的內部前置詞清單中排除此範圍（如需如何執行此動作的詳細資訊，請參閱 Azure 防火牆 進階版 私人IPDS範圍），並在設定IP位址的子網中100.64.0.0/10部署 應用程式閘道。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

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

下一步

• 使用零信任保護網路
• 虛擬網路流量路由 \(部分機器翻譯\)
• 應用程式閘道的運作方式

相關資源

• 透過網路層級分割來保護和管理工作負載
• 實作安全的混合式網路
• Azure 中的中樞輪輻網路拓撲
• 具有 Azure 虛擬 WAN 的中樞輪幅網路拓撲