編輯

共用方式為

使用 Azure 防火牆和應用程式閘道的 Web 應用程式零信任網路

Azure 應用程式閘道
Azure 防火牆
Azure 虛擬網路
Azure 虛擬 WAN
Azure Web 應用程式防火牆

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

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

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

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

架構圖，顯示 Web 應用程式網路中在 Azure 防火牆進階版前使用應用程式網關的封包流程。

下載此架構的 Visio 檔案。

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

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

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

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

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

    • 加密封包
    • 使用網域名稱系統 （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 解決方案最適合運作，如後續章節所述。

注意

應用程式閘道不支援 HTTP 主機標頭中的埠號碼。 因此：

  • Azure 防火牆進階會假設預設 HTTPS TCP 連接埠為 443。
  • 應用程式閘道與 Web 伺服器之間的連線僅支援 TCP 連接埠 443，而不是非標準埠。

數字證書

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

架構圖表，顯示 Web 應用程式網路在防火牆前方負載平衡器時所使用的常見名稱和證書頒發機構單位。

TLS 連線

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

從用戶端到應用程式閘道

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

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

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

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

Azure 防火牆進階會建立與目的地 Web 伺服器的 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 防火牆進階會保護從應用程式閘道到 Web 伺服器的要求。 應用程式閘道信任 Azure 防火牆進階所使用的私人 CA。

路由和流量轉送

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

  • Azure 應用程式閘道一律會作為 Proxy 運作，而 Azure 防火牆進階在設定 TLS 檢查時也一樣：來自用戶端的 TLS 會話將會由應用程式閘道終止，而新的 TLS 會話將會建置至 Azure 防火牆。 Azure 防火牆會接收和終止從應用程式閘道來源的 TLS 會話，並將新的 TLS 會話建置至工作負載。 此事實對 Azure 防火牆進階的 IDPS 設定有影響，以下各節包含更多相關詳細數據。
  • 工作負載會看到來自 Azure 防火牆子網 IP 位址的連線。 原始用戶端 IP 位址會保留在應用程式閘道所插入 X-Forwarded-For HTTP 標頭中。
  • 從應用程式網關到工作負載的流量通常會使用 Azure 路由機制傳送至 Azure 防火牆，無論是在應用程式網關的子網中設定 User-Defined 路由，或是由 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 中的兩個子網之間的流量。 當應用程式閘道和目的地 Web 伺服器位於相同的虛擬網路時，這項限制就變得很明顯：虛擬 WAN 無法強制應用程式閘道與 Web 伺服器之間的流量通過 Azure 防火牆進階版（因應措施是在應用程式閘道和 Web 伺服器的子網中手動設定使用者定義的路由）。

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

架構圖，顯示中樞和輪輻網路中封包流程，其中包含負載平衡器、防火牆和虛擬 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 範圍（10.0.0.0/8、192.168.0.0/16 和 172.16.0.0/12）和 RFC 6598 範圍（100.64.0.0/10）中的每個預設私人 IP 位址視為內部 IP 位址。 因此，如本文中的圖表所示，應用程式閘道會部署在上述其中一個範圍的子網中（如上述範例中的172.16.0.0/24），Azure 防火牆進階會考慮應用程式閘道與工作負載之間的流量為內部，而且只會將標示為套用至內部流量的 IDPS 簽章，或是使用任何流量。 標示要套用至輸入或輸出流量的 IDPS 簽章不會套用至應用程式閘道與工作負載之間的流量。

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

貢獻

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

主體作者：

後續步驟

  • [使用網络層級分割保護及控管工作負載][使用網络層級分割保護及控管工作負載]
  • 實作安全的混合式網路
  • 在 Azure 中 中樞輪輻網路拓撲
  • 使用 Azure 虛擬 WAN 中樞輪輻網路拓撲