編輯

共用方式為

將要求對應至多租使用者方案中的租使用者

Azure

每當要求送達您的應用程式時，您必須判斷要求所要的租使用者。 當您有甚至可能裝載在不同地理區域中的租使用者特定基礎結構時，您必須將傳入要求與租使用者相符。 然後，您必須將要求轉送至裝載該租用戶資源的實體基礎結構，如下所示：

此圖顯示將租使用者的要求對應至部署。

在此頁面上，我們會提供技術決策者的指引，說明您可以考慮將要求對應至適當租使用者的方法，以及方法所涉及的取捨。

注意

此頁面主要討論 HTTP 型應用程式，例如網站和 API。 不過，許多相同的基本原則適用於使用其他通訊協定的多租用戶應用程式。

識別租使用者的方法

您可以透過多種方式來識別傳入要求的租使用者。

網域名稱

如果您使用 租使用者特定網域或子域名稱，則要求可能會使用 Host 標頭輕鬆對應至租使用者，或是包含每個要求原始主機名的另一個 HTTP 標頭。

不過，請考慮下列問題：

  • 使用者如何知道要用來存取服務的功能變數名稱？
  • 您是否有集中進入點，例如登陸頁面或登入頁面，讓所有租使用者都使用？ 如果您這麼做，使用者將如何識別他們需要存取的租使用者？
  • 您使用哪些其他信息來驗證租使用者的存取權，例如授權令牌？ 授權令牌是否包含租使用者特定的功能變數名稱？

HTTP 要求屬性

如果您未使用租使用者特定功能變數名稱，您仍然可以使用 HTTP 要求的各個層面來識別特定要求所針對的租使用者。 例如，請考慮將租用戶名稱識別為 tailwindtraders的 HTTP 要求。 這可能使用下列項目進行通訊：

  • URL 路徑結構，例如 https://app.contoso.com/tailwindtraders/。
  • URL 中的查詢字串 ，例如 https://contoso.com/app?tenant=tailwindtraders。
  • 自訂 HTTP 要求標頭，例如 Tenant-Id: tailwindtraders。

重要

自定義 HTTP 要求標頭不適用於從網頁瀏覽器發出 HTTP GET 要求，或要求是由某些 Web Proxy 類型處理的位置。 當您建置 API 時，應該只針對 GET 作業使用自定義 HTTP 標頭，或控制發出要求的用戶端，且要求處理鏈結中未包含任何 Web Proxy。

使用此方法時，您應該考慮下列問題：

  • 使用者會知道如何存取服務嗎？ 例如，如果您使用查詢字串來識別租使用者，中央登陸頁面是否需要藉由新增查詢字串，將使用者導向正確的租使用者？
  • 您是否有集中進入點，例如登陸頁面或登入頁面，讓所有租使用者都使用？ 如果您這麼做，使用者將如何識別他們需要存取的租使用者？
  • 您的應用程式是否提供 API？ 例如，您的 Web 應用程式是單頁應用程式（SPA）還是具有 API 後端的行動應用程式？ 如果是，您可以使用 API 閘道 或 反向 Proxy 來執行租用戶對應。

令牌宣告

許多應用程式都使用宣告型驗證和授權通訊協定，例如 OAuth 2.0 或 SAML。 這些通訊協定會將授權令牌提供給用戶端。 令牌包含一組 宣告，這些宣告是用戶端應用程式或使用者的相關信息片段。 宣告可用來傳達資訊，例如使用者的電子郵件位址。 您的系統接著可以包含使用者的電子郵件位址、查閱使用者對租用戶對應，然後將要求轉送至適當的部署。 或者，您甚至可以在身分識別系統中包含租用戶對應，並將租使用者標識碼宣告新增至令牌。

如果您使用宣告將要求對應至租使用者，您應該考慮下列問題：

  • 您是否會使用宣告來識別租使用者？ 您將使用哪個宣告？
  • 使用者是否可以成為多個租用戶的成員？ 如果可行，則使用者會如何選取他們想要使用的租使用者？
  • 是否有所有租使用者的集中驗證和授權系統？ 如果沒有，您如何確定所有令牌授權單位都會發出一致的令牌和宣告？

API 金鑰

許多應用程式都會公開 API。 這些可能是供組織內部使用，或供合作夥伴或客戶外部使用。 API 的一般驗證方法是使用 API 金鑰。 API 金鑰會隨每個要求提供，而且可用來查閱租使用者。

API 金鑰可以透過數種方式產生。 常見的方法是產生密碼編譯隨機值，並將它與租使用者標識符一起儲存在查閱表格中。 收到要求時，您的系統會在查閱表格中尋找 API 金鑰，然後將它與租使用者識別碼相符。 另一種方法是建立有意義的字串，其中包含租使用者標識碼，然後使用 HMAC 之類的方法，以數位方式簽署密鑰。 當您處理每個要求時，請確認簽章，然後擷取租用戶標識碼。

注意

API 金鑰不提供高階的安全性，因為它們需要手動建立和管理，而且因為它們不包含宣告。 更現代化且安全的方法是使用宣告型授權機制搭配短期令牌，例如 OAuth 2.0 或 OpenID Connect。

請考量下列問題：

  • 您如何產生併發出 API 金鑰？
  • 您的 API 用戶端如何安全地接收和儲存 API 金鑰？
  • 您需要 API 金鑰在一段時間後到期嗎？ 如何輪替用戶端的 API 金鑰，而不會造成停機時間？
  • 是否只依賴客戶推出 API 金鑰，為您的 API 提供適當的安全性層級？

注意

API 金鑰與密碼不同。 API 金鑰必須由系統產生，而且它們在所有租使用者中都必須是唯一的，因此每個 API 金鑰都可以唯一對應至單一租使用者。 AZURE API 管理 等 API 閘道可以產生和管理 API 金鑰、驗證傳入要求的金鑰，以及將金鑰對應至個別 API 訂閱者。

用戶端憑證

用戶端憑證驗證，有時稱為相互 TLS （mTLS），通常用於服務對服務通訊。 用戶端憑證提供驗證用戶端的安全方式。 與令牌和宣告類似，用戶端憑證會提供 可用來判斷租用戶的屬性 。 例如， 憑證的主體 可能包含使用者的電子郵件位址，可用來查閱租使用者。

規劃使用用戶端憑證進行租用戶對應時，請考慮下列事項：

  • 如何安全地發行並更新服務信任的客戶端憑證？ 客戶端憑證可能很複雜，因為其需要特殊的基礎結構來管理及發行憑證。
  • 客戶端憑證只會用於初始登入要求，或附加至您服務的所有要求嗎？
  • 當您有大量用戶端時，發行和管理憑證的程式是否會變成無法管理？
  • 如何實作客戶端憑證與租用戶之間的對應？

反向 Proxy

反向 Proxy 也稱為應用程式 Proxy，可用來路由 HTTP 要求。 反向 Proxy 接受來自輸入端點的要求，而且可以將要求轉送至其中一個後端端點。 反向 Proxy 對於多租使用者應用程式很有用，因為它們可以執行某些要求資訊之間的對應，從應用程式基礎結構卸除工作。

許多反向 Proxy 可以使用要求的屬性來決定租使用者路由。 他們可以檢查目的地功能變數名稱、URL 路徑、查詢字串、HTTP 標頭，甚至是令牌內的宣告。

Azure 中會使用下列常見的反向 Proxy：

  • Azure Front Door 是全域負載平衡器和 Web 應用程式防火牆。 它會使用Microsoft全域邊緣網路來建立快速、安全且高度可調整的 Web 應用程式。
  • Azure 應用程式閘道 是受控 Web 流量負載平衡器，您部署至與後端服務相同的實體區域。
  • Azure API 管理 已針對 API 流量進行優化。
  • 商業和開放原始碼技術（您自己裝載）包括 nginx、Traefik 和 HAProxy。

要求驗證

您的應用程式必須驗證它所接收的任何要求都已獲授權給租使用者。 例如，如果您的應用程式使用自定義域名將要求對應至租使用者，則您的應用程式仍必須檢查應用程式收到的每個要求是否獲得該租用戶的授權。 即使要求包含功能變數名稱或其他租使用者標識碼，但這並不表示您應該自動授與存取權。 當您使用 OAuth 2.0 時，會檢查 對象 和 範圍 宣告來執行驗證。

注意

這是Microsoft Azure Well-Architected Framework 中假設零信任安全性設計原則的一部分。

實作要求驗證時，您應該考慮下列事項：

  • 您要如何授權應用程式的所有要求？ 不論您用來將要求對應至實體基礎結構的方法為何，您都需要授權要求。
  • 使用受信任、廣泛使用且維護良好的驗證和授權架構和中間件，而不是自行實作所有驗證邏輯。 例如，請勿建置令牌簽章驗證邏輯或客戶端憑證加密連結庫。 請改用已驗證和測試的應用程式平臺功能（或已知的受信任套件）。

效能

租用戶對應邏輯可能會對您的應用程式的每個要求執行。 請考慮隨著您的解決方案成長，租用戶對應程序的規模會如何調整。 例如，如果您查詢資料庫數據表作為租用戶對應的一部分，資料庫是否支援大量的負載？ 如果您的租用戶對應需要解密令牌，計算需求是否會隨著時間而變得太高？ 如果您的流量相當溫和，則這並不會影響您的整體效能。 不過，當您有大規模的應用程式時，此對應所涉及的額外負荷可能會變得相當重要。

工作階段親和性

減少租用戶對應邏輯效能額外負荷的其中一種方法是使用 會話親和性。 不要在每個要求上執行對應，請考慮只計算每個會話之第一個要求的資訊。 您的應用程式接著會提供 會話 Cookie 給用戶端。 用戶端會將會話 Cookie 傳回您的服務，其中包含該會話內的所有後續用戶端要求。

注意

Azure 中的許多網路和應用程式服務都可以使用會話親和性發出會話 Cookie，並以原生方式路由要求。

請考量下列問題：

  • 您可以使用會話親和性來減少將要求對應至租用戶的額外負荷嗎？
  • 您使用哪些服務將要求路由傳送至每個租用戶的實體部署？ 這些服務是否支援以 Cookie 為基礎的會話親和性？

租用戶移轉

租使用者通常需要移至新的基礎結構，作為租使用者生命週期的一部分。 當租使用者移至新的部署時，他們存取的 HTTP 端點可能會變更。 發生這種情況時，請考慮您的租用戶對應程式需要更新。 您可能需要考慮下列事項：

  • 如果您的應用程式使用功能變數名稱進行對應要求，則在移轉時可能也需要 DNS 變更。 根據 DNS 服務中 DNS 專案的存留時間而定，DNS 變更可能需要時間傳播至用戶端。
  • 如果您的移轉在移轉過程中變更任何端點的位址，請考慮暫時將租使用者的要求重新導向至自動重新整理的維護頁面。

參與者

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

主體作者：

其他投稿人：

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

下一步

瞭解 在多租用戶應用程式中使用功能變數名稱時的考慮。