共用方式為

多租用戶解決方案中的網路架構方法

  • 發行項

部署至 Azure 的所有解決方案都需要某種網路功能。 根據您的解決方案設計和工作負載，您與 Azure 網路服務互動的方式可能會有所不同。 在本文中，我們提供 Azure 上多租使用者解決方案網路層面的考慮和指引。 我們包含較低層級網路元件的相關信息，例如虛擬網路，透過較高層級和應用層方法。

注意

Azure 本身是多租用戶環境，而 Azure 的網路元件是針對多租用戶所設計。 雖然您不需要瞭解詳細數據，才能設計自己的解決方案，但您可以 深入瞭解 Azure 如何隔離虛擬網路流量與其他客戶的流量。

重要考慮和需求

基礎結構和平台服務

您對於網路元件的擔憂會根據您使用的服務類別而有所不同。

基礎結構服務

當您使用基礎結構服務，例如虛擬機或 Azure Kubernetes Service 時，您必須考慮並設計能支撐您服務連線的虛擬網路或 VNet。 您也需要考慮在設計中納入的其他安全性與隔離層級。 避免只依賴網路層控件。

平台服務

如果您使用 Azure 的平台服務，例如 App Service、Azure Cosmos DB 或 Azure SQL 資料庫，則您使用的特定架構將決定您需要的網路服務。

如果您需要將平臺服務與因特網隔離，則必須使用 VNet。 視您使用的特定服務而定，您可以使用私人端點或 VNet 整合式資源，例如 應用程式閘道。 不過，您也可以選擇透過其公用IP位址提供您的平台服務，並使用防火牆和身分識別控件等服務本身的保護。 在這些情況下，您可能不需要 VNet。

是否針對平台服務使用 VNet 的決定取決於許多需求，包括下列因素：

  • 合規性需求： 您可能需要符合特定的合規性標準。 某些標準需要以特定方式設定您的 Azure 環境。
  • 租使用者的需求： 即使您自己的組織沒有網路層隔離或控制的特定需求，您的租使用者也可能。 請確定您清楚瞭解租使用者將如何存取您的解決方案，以及其網路設計是否有任何假設。
  • 複雜度： 瞭解和使用虛擬網路可能更為複雜。 請確定您的小組清楚瞭解所涉及的原則，或您可能部署不安全的環境。

請確定您瞭解 使用專用網的影響。

重設大小子網

當您需要部署 VNet 時，請務必仔細考慮整個 VNet 和 VNet 內子網的大小和地址空間。

請確定您已清楚瞭解如何將 Azure 資源部署至 VNet，以及每個資源所耗用的 IP 位址數目。 如果您部署租使用者特定的計算節點、資料庫伺服器或其他資源，請確定您建立的子網足以讓預期的租用戶成長和 水平自動調整資源。

同樣地，當您使用受控服務時，請務必瞭解IP位址的取用方式。 例如，當您搭配使用 Azure Kubernetes Service 搭配 Azure 容器網路介面 （CNI）時，從子網取用的 IP 位址數目將取決於節點數目、水平調整方式，以及您使用的服務部署程式等因素。 當您搭配 VNet 整合使用 Azure App 服務 和 Azure Functions 時，取用的 IP 位址數目會以計劃實例數目為基礎。

規劃子網時，請檢閱子網分割指引 。

公用或私人存取

請考慮您的租使用者是否會透過因特網或私人IP位址存取您的服務。

針對以因特網為基礎的（公用）存取，您可以使用防火牆規則、IP 位址允許清單和拒絕清單、共用秘密和密鑰，以及身分識別型控件來保護您的服務。

如果您需要使用私人IP位址啟用服務連線能力，請考慮使用 Azure Private Link 服務 或 跨租使用者虛擬網路對等互連。 在某些有限的案例中，您也可以考慮使用 Azure ExpressRoute 或 Azure VPN 閘道 來啟用解決方案的私人存取。 只有在您擁有少量租使用者，併為每個租使用者部署專用 VNet 時，才建議您使用此方法。

存取租使用者的端點

請考慮您是否需要將數據傳送至租用戶網路內或 Azure 外部的端點。 例如，您需要叫用客戶提供的 Webhook，還是需要將即時訊息傳送給租使用者？

如果您需要將數據傳送至租使用者的端點，請考慮下列常見方法：

  • 透過因特網起始從解決方案到租用戶端點的連線。 請考慮連線是否必須源自 靜態IP位址。 視您使用的 Azure 服務而定，您可能需要部署 NAT 閘道、防火牆或負載平衡器。
  • 部署代理程式，以啟用 Azure 裝載服務與客戶網路之間的連線，而不論其所在位置為何。
  • 針對單向傳訊，請考慮使用像是 Azure 事件方格、具有或不含事件網域的服務。

要考慮的方法和模式

在本節中，我們會說明您可以在多租使用者解決方案中考慮的一些重要網路方法。 首先，我們會描述核心網路元件的較低層級方法，然後遵循您可以考慮用於 HTTP 和其他應用層考慮的方法。

租使用者特定的 VNet 與服務提供者選取的 IP 位址

在某些情況下，您必須代表租使用者在 Azure 中執行專用的 VNet 連線資源。 例如，您可以為每個租使用者執行虛擬機，或者您可能需要使用私人端點來存取租使用者特定的資料庫。

請考慮使用您控制的IP位址空間，為每個租使用者部署 VNet。 這種方法可讓您針對自己的目的將 VNet 對等互連，例如，如果您需要建立 中樞和輪輻拓撲 ，以集中控制流量輸入和輸出。

不過，如果租使用者需要直接連線到您建立的 VNet，例如使用 VNet 對等互連，則服務提供者選取的 IP 位址並不適用。 您選取的位址空間可能會與自己的位址空間不相容。

具有租使用者所選IP位址的租使用者特定 VNet

如果租使用者需要將自己的 VNet 與您代表其管理的 VNet 對等互連，請考慮使用租用戶選取的 IP 位址空間來部署租使用者特定的 VNet。 此系統可讓每個租使用者確保系統 VNet 中的 IP 位址範圍不會與自己的 VNet 重疊。 藉由使用非重疊的IP位址範圍，它們可確保其網路與對等互連相容。

不過，這種方法表示您不太可能將租使用者的 VNet 對等互連，或採用 中樞和輪輻拓撲，因為不同租使用者的 VNet 之間可能會有重疊的 IP 位址範圍。

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

中樞和輪輻 VNet 拓撲可讓您將具有多個輪輻 VNet 的集中式中樞 VNet 對等互連。 您可以集中控制 VNet 的流量輸入和輸出，並控制每個輪輻 VNet 中的資源是否可以彼此通訊。 每個輪輻 VNet 也可以存取共用元件，例如 Azure 防火牆，而且可能可以使用 Azure DDoS 保護等服務。

當您使用中樞和輪輻拓撲時，請確定您規劃限制， 例如對等互連的 VNet 數目上限，並確定您不會針對每個租使用者的 VNet 使用重疊的位址空間。

當您部署具有您所選取IP位址的租使用者特定 VNet 時，中樞和輪輻拓撲很有用。 每個租使用者的 VNet 都會變成輪輻，而且可以在中樞 VNet 中共用您的通用資源。 當您跨多個 VNet 調整共用資源以進行縮放用途，或使用部署戳記模式時，您也可以使用中樞和輪輻拓撲。

提示

如果您的解決方案跨多個地理區域執行，通常最好在每個區域中部署個別的中樞和中樞資源。 雖然這種做法會產生較高的資源成本，但會避免不必要地通過多個 Azure 區域的流量，這會增加要求的延遲，併產生全域對等互連費用。

靜態 IP 位址

請考慮您的租使用者是否需要您的服務，才能針對輸入流量、輸出流量或兩者使用靜態公用IP位址。 不同的 Azure 服務會以不同方式啟用靜態 IP 位址。

當您使用虛擬機和其他基礎結構元件時，請考慮針對輸入和輸出靜態IP位址使用負載平衡器或防火牆。 請考慮使用 NAT 閘道來控制輸出流量的 IP 位址。 如需在多租用戶解決方案中使用 NAT 閘道的詳細資訊，請參閱 多租使用者的 Azure NAT 閘道考慮。

當您使用平台服務時，您所使用的特定服務會決定是否控制IP位址，以及如何控制IP位址。 您可能需要以特定方式設定資源，例如將資源部署到 VNet，並使用 NAT 閘道或防火牆。 或者，您可以要求服務用於輸出流量的目前IP位址集。 例如， App Service 提供 API 和 Web 介面，以取得您應用程式的目前輸出 IP 位址。

客服專員

如果您需要讓租使用者接收解決方案所起始的訊息，或如果您需要存取存在於租使用者本身網路中的數據，請考慮提供代理程式（有時稱為 內部部署網關），讓他們可以在其網路內部署。 無論您的租用戶網路位於 Azure、另一個雲端提供者或內部部署中，此方法都可以運作。

代理程式會起始您指定和控制端點的輸出連線，並讓長時間執行的連線保持運作，或間歇性輪詢。 請考慮使用 Azure 轉寄 來建立和管理從代理程式到您服務的連線。 當代理程式建立連線時，它會驗證並包含租使用者標識碼的一些資訊，讓您的服務可以將連線對應至正確的租使用者。

代理程式通常會簡化租用戶的安全性設定。 開啟輸入埠可能會很複雜且有風險，尤其是在內部部署環境中。 代理程式可避免租使用者需要承擔此風險。

提供代理程式以連線至租用戶網路的 Microsoft 服務 範例包括：

Azure Private Link 服務 提供從租使用者的 Azure 環境到解決方案的私人連線。 租使用者也可以使用 Private Link 服務搭配自己的 VNet，從內部部署環境存取您的服務。 Azure 會使用私人IP位址安全地將流量路由傳送至服務。

如需 Private Link 和多租使用者的詳細資訊，請參閱 多租使用者和 Azure Private Link。

功能變數名稱、子域和 TLS

當您在多租用戶解決方案中使用功能變數名稱和傳輸層安全性 （TLS）時，有一些考慮。 檢閱多租使用者和功能變數名稱的考慮。

網關路由和網關卸除模式

網關 路由模式 和 網關卸除模式 牽涉到部署第 7 層反向 Proxy 或 閘道。 閘道有助於為多租使用者應用程式提供核心服務，包括下列功能：

  • 將要求路由傳送至租使用者特定的後端或部署戳記。
  • 處理租使用者特定的功能變數名稱和 TLS 憑證。
  • 使用 Web 應用程式防火牆 （WAF） 檢查安全性威脅的要求。
  • 快取回應以改善效能。

Azure 提供數個服務，可用來達成部分或全部目標，包括 Azure Front Door、Azure 應用程式閘道 和 Azure API 管理。 您也可以使用 NGINX 或 HAProxy 等軟體來部署自己的自訂解決方案。

如果您打算為解決方案部署閘道，最佳做法是先建置包含您所需所有功能的完整原型，並確認應用程式元件會如預期般繼續運作。 您也應該瞭解閘道元件如何調整，以支援您的流量和租用戶成長。

靜態內容裝載模式

靜態 內容裝載模式 涉及從雲端原生記憶體服務提供 Web 內容，以及使用內容傳遞網路 （CDN） 快取內容。

您可以將 Azure Front Door 或其他 CDN 用於解決方案的靜態元件，例如單頁 JavaScript 應用程式，以及影像檔案和檔等靜態內容。

根據解決方案的設計方式，您也可以快取 CDN 內的租使用者特定檔案或數據，例如 JSON 格式的 API 回應。 這種做法可協助您改善解決方案的效能和延展性，但請務必考慮租使用者特定數據是否完全隔離，以避免在租用戶之間洩漏數據。 請考慮您打算如何從快取清除租使用者特定內容，例如數據更新或部署新的應用程式版本時。 藉由在 URL 路徑中包含租使用者識別碼，您可以控制是否清除特定檔案、與特定租使用者相關的所有檔案，或所有租使用者的所有檔案。

要避免的反模式

無法規劃 VNet 連線

藉由將資源部署到 VNet，您可以充分掌控流量流經解決方案元件的方式。 不過，VNet 整合也導入了您需要考慮的其他複雜度、成本和其他因素。 此效果特別適用於平臺即服務 （PaaS） 元件。

請務必測試及規劃您的網路策略，以便在生產環境中實作之前發現任何問題。

未規劃限制

Azure 會強制執行一些會影響網路資源的限制。 這些限制包括 Azure 資源限制 和基本通訊協議和平臺限制。 例如，當您在平臺服務上建置大規模多租用戶解決方案，例如 Azure App 服務 和 Azure Functions 時，您可能需要考慮 TCP 連線和 SNAT 連接埠的數目。 當您使用虛擬機和負載平衡器時，也必須考慮輸出規則和 SNAT 埠的限制。

小型子網

請務必考慮每個子網的大小，以允許您將部署的資源或資源實例數目，特別是當您調整時。 當您使用平臺即服務 （PaaS） 資源時，請確定您瞭解資源的設定和規模將如何影響其子網中所需的 IP 位址數目。

網路分割不當

如果您的解決方案需要虛擬網路，請考慮如何設定 網路分割 ，讓您能夠控制輸入和輸出（南北）流量，以及解決方案（東西方）內的流量。 決定租使用者是否應該有自己的 VNet，或您是否將在共用 VNet 中部署共用資源。 變更方法可能會很困難，因此請確定您考慮所有需求，然後選取一個將適用於未來成長目標的方法。

僅依賴網路層安全性控制

在現代解決方案中，請務必將網路層安全性與其他安全性控件結合，而且您不應只依賴防火牆或網路分割。 這有時稱為 零信任網路。 使用身分識別型控件來驗證解決方案每一層的用戶端、呼叫者或使用者。 請考慮使用可讓您新增額外保護層級的服務。 可用的選項取決於您所使用的 Azure 服務。 在 AKS 中，請考慮使用服務網狀結構進行相互 TLS 驗證，以及 控制東西向流量的網路 原則。 在 App Service 中，請考慮使用 內建支援來進行驗證和授權 和 存取限制。

重寫主機標頭而不進行測試

當您使用 閘道卸除模式時，可能會考慮重寫 Host HTTP 要求的標頭。 這種做法可以將自定義網域和 TLS 管理卸除至閘道，以簡化後端 Web 應用程式服務的設定。

不過， Host 標頭重寫可能會導致某些後端服務發生問題。 如果您的應用程式發出 HTTP 重新導向或 Cookie，主機名中的不相符可能會中斷應用程式的功能。 特別是當您使用本身為多租使用者的後端服務時，可能會發生此問題，例如 Azure App 服務、Azure Functions 和 Azure Spring Apps。 如需詳細資訊，請參閱 主機名保留最佳做法。

請務必使用您打算使用的閘道組態來測試應用程式的行為。

參與者

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

主體作者：

  • John Downs |適用於 Azure 的主要客戶工程師 FastTrack

其他投稿人：

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步