在許多多租使用者 Web 應用程式中,功能變數名稱可用來識別租用戶、協助將要求路由傳送至正確的基礎結構,以及為客戶提供品牌體驗。 兩個常見的方法是使用子域和自定義功能變數名稱。 在此頁面上,我們會提供技術決策者關於您可以考慮的方法及其取捨的指引。
子域
每個租使用者可能會使用類似 tenant.provider.com
的格式,在通用共用功能變數名稱下取得唯一的子域。
讓我們考慮 Contoso 所建置的範例多租用戶解決方案。 客戶購買 Contoso 的產品,以協助管理其發票產生。 所有 Contoso 的租使用者都可以在功能變數名稱下 contoso.com
指派自己的子域。 或者,如果 Contoso 使用區域部署,它們可能會指派 和 eu.contoso.com
網域下的us.contoso.com
子域。 在本文中,我們會將這些稱為 字幹定義域。 每位客戶都會在您的字幹定義域下取得自己的子域。 例如,可能會指派 tailwind.contoso.com
Tailwind Toys,而且在區域部署模型中,可能會指派 adventureworks.us.contoso.com
Adventure Works 。
注意
許多 Azure 服務都使用此方法。 例如,當您建立 Azure 記憶體帳戶時,會指派一組子域供您使用,例如 <your account name>.blob.core.windows.net
。
管理您的網域命名空間
當您在自己的功能變數名稱下建立子域時,您必須注意,您可能會有多個具有類似名稱的客戶。 因為它們共用單一字幹定義域,因此第一個取得特定網域的客戶會取得其慣用的名稱。 然後,後續客戶必須使用替代子域名稱,因為完整域名必須是全域唯一的。
通配符 DNS
請考慮使用通配符 DNS 專案來簡化子域的管理。 您可以改為建立tailwind.contoso.com
adventureworks.contoso.com
通配符專案,並將所有子域導向至單一IP位址(A 記錄)或標準名稱(CNAME 記錄),而不是建立、 等等的 DNS 專案*.contoso.com
。 如果您使用區域字幹定義域,您可能需要多個通配符專案,例如 *.us.contoso.com
和 *.eu.contoso.com
。
注意
如果您打算依賴這項功能,請確定您的 Web 層服務支援通配符 DNS。 許多 Azure 服務,包括 Azure Front Door 和 Azure App 服務,都支援通配符 DNS 專案。
具有多部分詞幹網域的子域
許多多租用戶解決方案會分散到多個實體部署。 當您需要符合數據落地需求,或想要藉由在地理位置更接近使用者的資源來提供更佳的效能時,這是常見的方法。
即使在單一區域內,您也可能需要將租使用者分散到獨立部署,以支援您的調整策略。 如果您打算針對每個租使用者使用子域,您可能會考慮多部分子域結構。
以下是範例:Contoso 會為其四個客戶發佈多租用戶應用程式。 Adventure Works 和 Tailwind Traders 位於 美國 中,其數據會儲存在 Contoso 平臺的共用美國實例上。 Fabrikam 和 Worldwide Importers 位於歐洲,其數據會儲存在歐洲實例上。
如果 Contoso 選擇針對所有客戶使用單一字幹定義域,contoso.com,以下是其外觀:
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 可以使用部署或區域特定的字幹網域,如下所示:
然後,藉由使用通配符 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 |
從名稱解析的觀點來看,此記錄鏈正確解析 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 的關聯性如何變更:
- Fabrikam 已決定不再與 Contoso 合作,因此他們已終止其業務關係。
- Contoso 已卸除 Fabrikam 租使用者,並要求
fabrikam.contoso.com
他們不再運作。 不過,Fabrikam 忘記刪除 的invoices.fabrikam.com
CNAME 記錄。 - 惡意動作專案會建立新的 Contoso 帳戶,並為其命名
fabrikam
。 - 攻擊者會將自定義功能變數名稱
invoices.fabrikam.com
上線至其新租使用者。 由於 Contoso 會執行 CNAME 型網域驗證,因此會檢查 Fabrikam 的 DNS 伺服器。 他們看到 DNS 伺服器會傳invoices.fabrikam.com
回 的 CNAME 記錄,其指向fabrikam.contoso.com
。 Contoso 會將自定義網域驗證視為成功。 - 如果有任何 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 良好架構架構。