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

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

子域

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

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

管理您的網域命名空間

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

通配符 DNS

請考慮使用通配符 DNS 專案來簡化子域的管理。 您可以改為建立tailwind.contoso.comadventureworks.contoso.com通配符專案，並將所有子域導向至單一IP位址（A 記錄）或標準名稱（CNAME 記錄），而不是建立、 等等的 DNS 專案*.contoso.com。 如果您使用區域字幹定義域，您可能需要多個通配符專案，例如 *.us.contoso.com 和 *.eu.contoso.com。

具有多部分詞幹網域的子域

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

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

以下是範例：Contoso 會為其四個客戶發佈多租用戶應用程式。 Adventure Works 和 Tailwind Traders 位於 美國 中，其數據會儲存在 Contoso 平臺的共用美國實例上。 Fabrikam 和 Worldwide Importers 位於歐洲，其數據會儲存在歐洲實例上。

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

DNS 專案（支援此組態所需的專案）可能如下所示：

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

或者，Contoso 可以使用部署或區域特定的字幹網域，如下所示：

然後，藉由使用通配符 DNS，此部署的 DNS 專案可能如下所示：

Contoso 不需要為每個客戶建立子域記錄。 相反地，每個地理位置的部署都有單一通配符 DNS 記錄，以及在該幹底下新增的任何新客戶都會自動繼承 CNAME 記錄。

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

自訂網域名稱

您可能想要讓客戶攜帶自己的功能變數名稱。 有些客戶認為這是品牌的重要層面。 自定義功能變數名稱可能也需要符合客戶的安全性需求，特別是如果需要提供自己的 TLS 憑證。 雖然讓客戶能夠攜帶自己的功能變數名稱似乎很微不足道，但這種方法有一些隱藏的複雜性，而且需要深思熟慮的考慮。

名稱解析

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

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

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

主機標頭解析

名稱解析只是問題的一半。 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.comCNAME 記錄。
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.comTLS 憑證，以及的 *.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。

下一步

返回架構考慮概觀。 或者，請檢閱 Microsoft Azure 良好架構架構。