編輯

共用方式為


在多租使用者解決方案中使用功能變數名稱時的考慮

Azure

在許多多租使用者 Web 應用程式中,功能變數名稱可用來識別租使用者、協助將要求路由傳送至正確的基礎結構,以及為客戶提供品牌體驗。 兩個常見的方法是使用子域和自訂功能變數名稱。 在此頁面上,我們會針對您可以考慮的方法及其取捨,為技術決策者提供指引。

子領域

每個租使用者都可以使用類似 tenant.provider.com 的格式,在一般共用功能變數名稱下取得唯一的子域。

讓我們考慮 Contoso 所建置的範例多租使用者解決方案。 客戶購買 Contoso 的產品,以協助管理其發票產生。 所有 Contoso 的租使用者都可以在功能變數名稱下 contoso.com 指派自己的子域。 或者,如果 Contoso 使用區域部署,他們可能會指派 和 eu.contoso.com 網域下的 us.contoso.com 子域。 在本文中,我們會將這些定義為 字幹定義域。 每個客戶都會在字幹定義域下取得自己的子域。 例如,可能會指派 tailwind.contoso.com Tailwind Toys,而 Adventure Works 可能會被 adventureworks.contoso.com 指派 。

注意

許多 Azure 服務都使用此方法。 例如,當您建立 Azure 儲存體帳戶時,系統會指派一組子域供您使用,例如 <your account name>.blob.core.windows.net

管理您的網域命名空間

當您在自己的功能變數名稱下建立子域時,您必須注意,您可能有多個具有類似名稱的客戶。 由於他們共用單一字幹定義域,因此取得特定網域的第一個客戶將取得其慣用的名稱。 然後,後續客戶必須使用替代子功能變數名稱稱,因為完整功能變數名稱必須是全域唯一的。

萬用字元 DNS

請考慮使用萬用字元 DNS 專案來簡化子域的管理。 您可以改為針對 、 adventureworks.contoso.com 等建立 DNS 專案 tailwind.contoso.com ,而是建立萬用字元專案 *.contoso.com ,並將所有子域導向至單一 IP 位址, (A 記錄) 或標準名稱 (CNAME 記錄) 。

注意

如果您打算依賴此功能,請確定您的 Web 層服務支援萬用字元 DNS。 許多 Azure 服務,包括 Azure Front Door 和Azure App 服務,都支援萬用字元 DNS 專案。

具有多部分字幹定義域的子域

許多多租使用者解決方案會分散到多個實體部署。 當您需要符合資料落地需求,或想要藉由在地理位置更接近使用者的資源來提供更佳效能時,這是常見的方法。

即使在單一區域內,您可能也需要將租使用者分散到獨立部署,以支援您的調整策略。 如果您打算針對每個租使用者使用子域,您可能會考慮多部分子域結構。

以下是範例:Contoso 會為其四個客戶發佈多租使用者應用程式。 Adventure Works 和 Tailwind Traders 位於美國中,且其資料會儲存在 Contoso 平臺的共用美國實例上。 Fabrikam 和全球匯入工具位於歐洲,其資料會儲存在歐洲實例上。

如果 Contoso 選擇針對其所有客戶使用單一字幹定義域 contoso.com,以下是其外觀:

此圖顯示 Web 應用程式的美國和歐盟部署,每個客戶的子域都有單一字幹網域。

支援此設定所需的 DNS 專案 () 看起來可能如下所示:

子網域 CNAME 至
adventureworks.contoso.com us.contoso.com
tailwind.contoso.com us.contoso.com
fabrikam.contoso.com eu.contoso.com
worldwideimporters.contoso.com eu.contoso.com

每個上線的新客戶都需要新的子域,而子域的數目會隨著每個客戶成長。

或者,Contoso 可以使用部署或區域特定的字幹定義域,如下所示:

此圖顯示 Web 應用程式的美國和歐盟部署,其中包含多個字幹網域。

然後,藉由使用萬用字元 DNS,此部署的 DNS 專案看起來可能如下所示:

子網域 CNAME 至
*.us.contoso.com us.contoso.com
*.eu.contoso.com eu.contoso.com

Contoso 不需要為每個客戶建立子域記錄。 相反地,他們針對每個地理位置的部署都有單一萬用字元 DNS 記錄,以及在該字幹底下新增的任何新客戶都會自動繼承 CNAME 記錄。

每個方法都有優點和缺點。 使用單一字幹網域時,您上線的每個租使用者都需要建立新的 DNS 記錄,這會產生更多的操作額外負荷。 不過,您可以彈性地在部署之間移動租使用者,因為您可以變更 CNAME 記錄,將其流量導向至另一個部署。 這項變更不會影響任何其他租使用者。 使用多個字幹定義域時,管理額外負荷較低。 此外,您可以跨多個區域字幹定義域重複使用客戶名稱,因為每個字幹定義域實際上都代表自己的命名空間。

自訂網域名稱

您可能想要讓客戶攜帶自己的功能變數名稱。 有些客戶會將這視為其商標的重要層面。 自訂功能變數名稱可能也需要符合客戶的安全性需求,特別是需要提供自己的 TLS 憑證時。 雖然讓客戶能夠攜帶自己的功能變數名稱似乎很簡單,但這種方法有一些隱藏的複雜度,而且需要仔細考慮。

名稱解析

最後,每個功能變數名稱都必須解析為 IP 位址。 如您所見,名稱解析發生的方法取決於您部署單一實例或解決方案的多個實例。

讓我們回到我們的範例。 其中一個 Contoso 的客戶 Fabrikam 要求使用 invoices.fabrikam.com ,作為其自訂功能變數名稱,以存取 Contoso 的服務。 因為 Contoso 有多個平臺部署,所以他們決定使用子域和 CNAME 記錄來達成其路由需求。 Contoso 和 Fabrikam 會設定下列 DNS 記錄:

名稱 記錄類型 設定者
invoices.fabrikam.com CNAME fabrikam.eu.contoso.com Fabrikam
*.eu.contoso.com CNAME eu.contoso.com Contoso
eu.contoso.com A (Contoso 的 IP 位址) Contoso

從名稱解析的觀點來看,此記錄鏈結會正確地將 的要求 invoices.fabrikam.com 解析為 Contoso 歐洲部署的 IP 位址。

主機標頭解析

名稱解析只是問題的一半。 Contoso 歐洲部署內的所有 Web 元件都必須注意如何處理在其要求標頭中使用 Host Fabrikam 功能變數名稱送達的要求。 根據 Contoso 使用的特定 Web 技術,這可能需要針對每個租使用者的功能變數名稱進一步設定,這會增加租使用者上線的額外作業額外負荷。

您也可以考慮重寫主機標頭,如此一來,無論傳入要求的 Host 標頭為何,網頁伺服器都會看到一致的標頭值。 例如,Azure Front Door 可讓您重寫 Host 標頭,因此不論要求為何,您的應用程式伺服器都會收到單 Host 一標頭。 Azure Front Door 會傳播標頭中的 X-Forwarded-Host 原始主機標頭,讓您的應用程式可以檢查它,然後查閱租使用者。 不過,重寫 Host 標頭可能會導致其他問題。 如需詳細資訊,請參閱主機名稱保留

網域驗證

將自訂網域上線之前,請務必先驗證自訂網域的擁有權。 否則,您就會不小心或惡意 地將功能變數名稱停 駐在一起。

讓我們考慮 Contoso 的 Adventure Works 上執行緒序,他們要求使用 invoices.adventureworks.com 作為其自訂功能變數名稱。 可惜的是,有人嘗試將自訂功能變數名稱上線時進行錯字,而他們錯過了 。 因此,他們會將其設定為 invoices.adventurework.com 。 流量不僅不會針對 Adventure Works 正確流動,也會在名為 Adventure Work 的另一家公司嘗試將其自訂網域新增至 Contoso 的平臺時,系統會告知功能變數名稱已在使用中。

使用自訂網域時,特別是在自助或自動化程式中,通常需要網域驗證步驟。 這可能需要先設定 CNAME 記錄,才能新增網域。 或者,Contoso 可能會產生隨機字串,並要求 Adventure Works 新增具有字串值的 DNS TXT 記錄。 這會防止新增功能變數名稱,直到驗證完成為止。

懸空 DNS 和子域接管攻擊

當您使用自訂功能變數名稱時,可能會容易受到一類攻擊,稱為 懸置 DNS子域接管。 當客戶將其自訂功能變數名稱與您的服務解除關聯,但不會從其 DNS 伺服器刪除記錄時,就會發生此攻擊。 此 DNS 進入接著會指向不存在的資源,而且容易受到接管。

讓我們考慮 Fabrikam 與 Contoso 的關聯性可能會變更:

  1. Fabrikam 已決定不再與 Contoso 合作,因此他們已終止其業務關係。
  2. Contoso 已將 Fabrikam 租使用者下架,並要求 fabrikam.contoso.com 他們不再運作。 不過,Fabrikam 忘記刪除 的 invoices.fabrikam.com CNAME 記錄。
  3. 惡意執行者會建立新的 Contoso 帳戶,並提供名稱 fabrikam
  4. 攻擊者會將自訂功能變數名稱 invoices.fabrikam.com 上架到新的租使用者。 由於 Contoso 會執行以 CNAME 為基礎的網域驗證,因此他們會檢查 Fabrikam 的 DNS 伺服器。 他們看到 DNS 伺服器傳回 的 invoices.fabrikam.com CNAME 記錄,指向 fabrikam.contoso.com 。 Contoso 會將自訂網域驗證視為成功。
  5. 如果任何 Fabrikam 員工嘗試存取網站,則要求看起來會正常運作。 如果攻擊者使用 Fabrikam 的品牌設定其 Contoso 租使用者,員工可能會被誘人存取網站並提供敏感性資料,攻擊者接著可以存取這些資料。

防止 DNS 攻擊的常見策略如下:

  • 必須先 刪除 CNAME 記錄,才能從租使用者的帳戶中移除功能變數名稱。
  • 禁止重複使用租使用者識別碼,也要求租使用者建立名稱符合功能變數名稱的 TXT 記錄,以及隨機產生的值,這會針對每個上線嘗試變更。

TLS/SSL 憑證

使用新式應用程式時,傳輸層安全性 (TLS) 是不可或缺的元件。 它可為 Web 應用程式提供信任和安全性。 TLS 憑證的擁有權和管理是需要仔細考慮多租使用者應用程式的內容。

一般而言,功能變數名稱的擁有者將負責發行和更新其憑證。 例如,Contoso 負責發行和更新 的 us.contoso.com TLS 憑證,以及 的 *.contoso.com 萬用字元憑證。 同樣地,Fabrikam 通常會負責管理網域的任何記錄 fabrikam.com ,包括 invoices.fabrikam.com 。 CAA (憑證授權單位單位授權) DNS 記錄類型可供網域擁有者使用。 CAA 記錄可確保只有特定授權單位可以建立網域的憑證。

如果您打算讓客戶攜帶自己的網域,請考慮您計畫代表客戶發行憑證,還是客戶必須攜帶自己的憑證。 每個選項都有優點和缺點。

  • 如果您為客戶發出憑證,您可以處理憑證的更新,因此客戶不需要記得保持更新。 不過,如果客戶在其功能變數名稱上有 CAA 記錄,他們可能需要授權您代表他們發行憑證。
  • 如果您預期客戶應該發出並提供自己的憑證,您必須負責以安全的方式接收和管理私密金鑰,而且您可能必須在憑證到期之前提醒客戶更新憑證,以避免服務中斷。

數個 Azure 服務支援自動管理自訂網域的憑證。 例如,Azure Front Door 和 App Service提供自訂網域的憑證,而且會自動處理更新程式。 這會從您的作業小組中移除管理憑證的負擔。 不過,您仍然需要考慮擁有權和授權的問題,例如 CAA 記錄是否有效且已正確設定。 此外,您必須確定客戶的網域已設定為允許由平臺管理的憑證。

參與者

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

主體作者:

  • John Downs |適用于 Azure 的 FastTrack 首席客戶工程師

其他參與者:

若要查看非公用LinkedIn設定檔,請登入 LinkedIn。

下一步

提示

許多服務會使用 Azure Front Door 來管理功能變數名稱。 如需如何在多租使用者解決方案中使用 Azure Front Door 的詳細資訊,請參閱 在多租使用者解決方案中使用 Azure Front Door

返回 架構考慮概觀。 或者,檢閱 Microsoft Azure Well-Architected Framework