使用分割腦 DNS 組態在 Azure 中裝載 Web 應用程式

Azure Front Door
Azure 應用程式閘道
Azure ExpressRoute
Azure DNS

管理工作負載的小組通常會依賴完整域名 （FQDN） 進行客戶存取。 FQDN 通常會與傳輸層安全性 （TLS） 伺服器名稱指示 （SNI） 結合。 透過這種方法，當公用客戶從公用因特網或企業客戶存取工作負載時，內部存取工作負載時，對應用程式的路由可能會遵循固定路徑，並具有各種層級的安全性或服務品質（QoS）。

以下架構示範一種方法，用於根據網域名稱系統（DNS）以及客戶是否來自網際網路或公司網路來區分流量的處理方式。

Architecture

應用程式主機架構示意圖。

下載此架構的 Visio 檔案 。

下列工作流程區段描述兩個組態：公用因特網工作流程和私人工作流程。 結合這兩個工作流程來實現分裂腦式主機架構。

公用因特網工作流程

公開網路工作流程示意圖。

下載此架構的 Visio 檔案 。

  1. 客戶會透過公用因特網傳送 app.contoso.com 應用程式的要求。

  2. Azure DNS 區域已針對 contoso.com 網域進行設定。 為 Azure Front Door 端點設定適當的 規範名稱 (CNAME) 項目。

  3. 外部客戶可透過 Azure Front Door Standard 或 Premium 存取網頁應用程式，該版本同時具備全球負載平衡器及網頁應用防火牆（WAF）。

    • 在 Azure Front Door 中，app.contoso.com 透過已設定端點上的路由指派為 FQDN。 Azure Front Door 也會裝載應用程式的 TLS SNI 憑證。

      Note

      Azure Front Door 不支援自我簽署憑證。

    • Azure Front Door 會根據客戶的 Host HTTP 標頭，將要求路由傳送至已設定的來源群組。

    • 來源群組會透過應用閘道的公共 IP 位址指向 Azure 應用程式閘道 實例。

  4. 網路安全組（NSG） 在 AppGW 子網 上被設定為允許來自 AzureFrontDoor.Backend 服務標籤的埠 80 和埠 443 的輸入存取。 NSG 不允許來自因特網服務標籤的埠 80 和埠 443 上的輸入流量。

    Note

    AzureFrontDoor.Backend 服務標籤不會只限制流量只限於你的 Azure Front Door 實例。 驗證會在下一個階段進行。

  5. 應用閘道實例在埠口 443 有一個 監聽器 。 流量會根據接聽程式中指定的主機名路由傳送至後端。

    • 為了確保流量來自 你的 Azure Front Door 設定檔，請設定 自訂的 WAF 規則 來檢查 X-Azure-FDID 標頭值。

    • Azure 會為每個 Azure Front Door 配置檔產生唯一標識符。 唯一識別碼為位於Azure入口網站總覽頁面上的Azure Front Door ID值。

  6. 流量會到達應用程式閘道中設定為後端集區的計算資源。

私人企業工作流程

私人企業工作流程示意圖。

下載此架構的 Visio 檔案 。

  1. 客戶會從內部部署環境提出 app.contoso.com 應用程式的要求。

  2. 應用程式 FQDN 是在本機 DNS 提供者上配置的。 此 DNS 提供者可為本地 Active Directory 網域服務（AD DS）、DNS 伺服器或其他合作夥伴解決方案。 每個應用程式 FQDN 的 DNS 項目都會設定為指向應用程式閘道實例的私有 IP 位址。

  3. Azure ExpressRoute 線路或站對站 VPN 有助於存取應用程式閘道。

  4. 在 AppGW 子網路上配置 NSG，以允許來自本地用戶端網路的私人請求，該流量源自這些網路。 此設定可確保其他私人流量來源無法直接連線到應用程式閘道的私人IP位址。

  5. Application Gateway 有一個監 聽器 ，分別設定在 80 埠和 443 埠。 流量會根據接聽程式中指定的主機名路由傳送至後端。

  6. 只有專用網路流量會到達在應用程式閘道中設定為後端資源池的計算資源。

Components

  • DNS 是一種將網域名稱映射到 IP 位址的系統，讓用戶端能夠定位並連接服務。 在此架構中，若要使用公共網際網路工作流程，必須設定一個公共 DNS 區域，並設定 Azure Front Door 端點 FQDN 的正確 CNAME。 在私有（企業）端，設定本地 DNS 提供者（AD DS DNS 或合作夥伴解決方案）將每個應用程式的 FQDN 指向應用閘道的私有 IP 位址。

  • Azure DNS Private Resolver 是一項全託管服務，能在本地環境與 Azure 間實現 DNS 解析，無需部署自訂 DNS 伺服器。 在此架構中，DNS Private Resolver 能解決本地用戶端，企業用戶可使用此分腦 DNS 解決方案，無需穿越公共網際網路即可存取應用程式。

  • Azure Front Door 是一款全球負載平衡器與 WAF，能為全球客戶提供快速且安全的網頁應用程式交付。 在此架構中，Azure Front Door Standard 或 Premium 會將外部客戶導向 Application Gateway 實例，並提供快取與優化選項以提升客戶體驗。

  • 應用閘道 是一個區域負載平衡器與 WAF，為網頁應用程式提供高可用性、可擴展性與安全性。 在此架構中，應用程式閘道會將外部和內部客戶要求路由傳送至後端計算，並保護 Web 應用程式免於常見的 Web 攻擊。

    Azure Front Door 和應用程式閘道都提供 WAF 功能，但此解決方案中的私人工作流程不會使用 Azure Front Door。 因此，兩種架構都使用應用閘道的 WAF 功能。

  • ExpressRoute 是一項服務，透過由連接服務提供者建立的私有連線，將本地網路延伸至雲端。 在此架構中，ExpressRoute 促進了本地用戶端與應用閘道的私密連接。

Alternatives

作為替代方案，你可以移除 Azure Front Door Standard 或 Premium，改為將公開 DNS 紀錄指向 Application Gateway 的公共 IP 位址。 根據此架構的需求，你必須在進入Azure的入口點快取並優化流量。 因此，你無法使用這種替代方案。 欲了解更多資訊，請參閱 成本優化。

替代分腦 DNS 託管架構的示意圖。

下載此架構的 Visio 檔案 。

此架構中公用輸入流量的其他可能替代方案包括：

  • Azure 流量管理員：流量管理員是 DNS 型流量路由服務，可將流量分散到各種區域和端點。 你可以用 Traffic Manager 取代 Azure Front Door Standard 或 Premium 來將外部客戶路由到最近的 Application Gateway 實例。 不過，Azure Front Door 提供的功能，例如 WAF 功能、快取和會話親和性。 流量管理員不提供這些功能。

  • Azure Load Balancer：Azure Load Balancer 是網路負載平衡器，可為傳輸控制通訊協定 （TCP） 和用戶數據報通訊協定 （UDP） 流量提供高可用性和延展性。 您可以使用 Load Balancer，而不是應用程式閘道，將外部和內部客戶要求路由傳送至後端網頁伺服器。 不過，應用程式閘道提供 WAF 功能、安全套接字層 （SSL） 終止和 Cookie 型會話親和性等功能。 Load Balancer 不提供這些功能。

案例詳細資料

此案例可解決裝載服務外部和內部客戶的 Web 應用程式的問題。 此架構可確保流量會根據客戶的來源遵循適當的路徑。 這個架構：

  • 為全球非企業客戶提供快速且可靠的網路存取網頁應用程式。

  • 提供企業客戶在不周遊公用因特網的情況下存取應用程式的能力。

  • 保護 Web 應用程式免於常見的 Web 攻擊和惡意流量。

潛在的使用案例

針對需要下列情況的案例，請使用此架構：

  • Split-brain DNS： 此解決方案對外部客戶使用Azure Front Door，內部客戶使用應用閘道，並為每個服務提供不同的 DNS 記錄。 此方法可協助優化各種客戶的網路效能、安全性和可用性。

  • 應用程式可擴展性： 此解決方案使用 Application Gateway，可將流量分配至已設定的後端運算資源。 這種方法有助於改善應用程式效能和可用性，並支援水平調整。

Considerations

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

Reliability

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。

  • 找出失敗點。 在這種分腦 DNS 架構中，可靠性取決於關鍵元件的正確運作，例如 Azure Front Door、Application Gateway 和 DNS 設定。 您必須識別潛在的失敗點，例如設定錯誤、SSL 憑證問題或容量多載。

  • 評估影響。 你必須評估失敗的影響。 對於外部客戶，任何作為閘道的 Azure Front Door 中斷都可能會影響全球存取。 對於內部客戶而言，應用程式閘道的任何中斷都可能會妨礙企業作業。

  • 實作風險降低策略。 為降低風險，應在 多個可用區域間實施冗餘，使用 健康探針 進行即時監控，並確保外部與內部流量的 DNS 路由配置正確。 請確定您定期更新 DNS 記錄，並有災害復原計劃。

  • 持續監測。 為了密切關注你的系統健康狀況，可以使用Azure 監視器功能。 設定 異常的警示，並備妥事件回應計劃，以及時解決潛在問題。

遵循這些原則，以確保能夠承受挑戰並維護服務持續性的健全且可靠的系統。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性的設計檢閱檢查清單。

  • 採用 零信任 方法。 在分腦 DNS 設定中，採用 零信任 方法。 明確驗證客戶的身分識別，無論是來自因特網還是公司網路。 此方法確保只有受信任的實體能執行授權操作。

  • 有效實施身份與存取控制。 實作 Microsoft Entra ID 以強化身份管理。 使用Microsoft Entra 條件式存取原則，根據客戶內容、裝置健康情況和位置強制執行嚴格的訪問控制。

    • 評估你的安全措施。 評估雙重存取工作量安全措施的有效性，可實施以下措施：

      • 定期評估你的防禦性投資。 定期評估 Azure Front Door 和 Application Gateway 的效能。 請確定它們能針對威脅提供有意義的保護。

      • 限制潛在違規行為的影響範圍。 確保你能在有限範圍內控制安全漏洞。 例如，有效地隔離外部和內部流量。

  • 假設入侵總是有可能發生的。 承認攻擊者可能會突破安全控管。 準備這類情境。

  • 全面實施安全措施。 實施網路分段、微分段及 NSG。 假設攻擊者可能會取得存取權，並據此設計補償控件。

將這些安全性原則整合到您的分割腦 DNS 架構中，以建立健全且具彈性的系統，以保護您的工作負載內部和外部存取。

其他安全性增強功能

  • 應用閘道器： 你可以在應用閘道使用 WAF ，保護你的網頁應用程式免受常見的網路漏洞與攻擊。 您也可以使用 Azure Private Link 從應用程式閘道安全地存取後端應用程式伺服器，而不需將其公開至公用因特網。

  • Azure 防火牆： 你可以在樞紐虛擬網路中新增一個Azure firewall，並使用 Azure 防火牆 威脅情報來阻擋來自已知惡意 IP 位址和網域的惡意流量。 您也可以使用 Azure 防火牆作為 DNS Proxy 來攔截和檢查 DNS 流量，並套用 DNS 篩選規則。

  • Azure Front Door： 你可以使用 Azure Web 應用程式防火牆 來保護你的網頁應用程式免受常見的網頁漏洞和邊緣漏洞攻擊。 你也可以使用 Private Link 搭配 Azure Front Door Premium 層級，從 Azure Front Door 安全存取你的後端應用伺服器，而不會暴露於公共網路。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。

  • 後端運算： 許多因素，如 SKU 選擇、副本數量及區域，都會影響後端運算服務的成本。 在選擇最適合你工作負載的方案之前，務必考慮計算 資源 的所有元素。

  • 應用閘道器： 應用閘道的成本取決於實例數量、實例大小及處理資料量。 你可以利用 自動擴展 來根據流量需求調整實例數量來優化成本。 你也可以在可用性區域部署區域冗餘的 SKU，以減少對高可用性額外實例的需求。

  • Azure Front Door： Azure Front Door 成本取決於路由規則數量、HTTP 或 HTTPS 請求數量，以及傳輸資料量。 你可以使用 Azure Front Door Standard 或 Premium，獲得統一的 Azure 內容傳遞網路、Azure Web 應用程式防火牆 和 Private Link 體驗。 您也可以使用 Azure Front Door 規則引擎功能 來自定義流量管理和優化效能和成本。

如果您的案例不需要全域存取或 Azure Front Door 的額外功能，您可以只搭配應用程式閘道使用此解決方案。 您可以將所有公用 DNS 記錄指向應用程式閘道接聽程式上設定的公用 IP 位址。

請參閱 此解決方案的範例 ，此解決方案會大致瞭解此架構中元件的一般使用方式。 調整成本以符合您的案例。

Contributors

本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。

主要作者：

其他貢獻者：

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

後續步驟