修改 Azure 登陸區域架構，以符合多個位置的需求
許多產業中的組織都受限於法規需求，包括資料落地、資料安全性和資料主權需求。 某些組織必須符合多個地理位置的衝突法規。 在此情況下，他們需要根據所有適用的法規修改其 Azure 登陸區域架構。
例如，可能有兩個相互衝突的法規：法規 A 和法規 B。法規 A 可能需要在國家或地區 A 中的資料落地，而法規 B 可能需要在國家或地區 B 中的資料落地。
這類法規衝突適用于：
跨國公司或非政府組織（非政府組織）等跨國組織必須遵守其經營國家和地區的當地法規。
為多個位置的組織提供解決方案的獨立軟體廠商（ISV），解決方案必須符合每個位置的當地法規。
ISV 提供解決方案給需要符合其運作之每個國家/地區之當地法規的跨國組織。
如果您只需要符合一組法規需求，請參閱 量身打造 Azure 登陸區域架構以符合需求 。
法規考慮
法規需求通常與資料保護、資料落地、資料傳輸、隔離或人員清除有關。 這些需求可能會與多個地理位置衝突。 例如，歐盟（EU）法規可能需要在歐盟國家/地區進行資料落地，而英國法規可能需要英國的資料落地。
如果法規導致原則控制衝突，您必須據以調整 Azure 登陸區域架構和原則指派。 如需詳細資訊，請參閱 本文中的<需要修改 的案例>一節。
套用多個法規時，您不需要在下列情況下修改 Azure 登陸區域架構：
多個法規需要相同的Azure 原則指派。
一個法規中的控制是另一個法規的超集合。 超集合控制項會自動套用至這兩個法規。
多個法規中的控制項不會重迭。 當您實作多個控制集時，單一實作涵蓋所有法規。 Azure 原則指派是互補的。
各種法規都有不同類型的實作。 從法規的觀點來看，您所選擇的實作並不重要。 例如，可能有兩個法規都有不同的授權模型，但兩個授權模型都是可接受的。 您可以選擇最適合您組織的實作。
提示
您應該儘量少指派原則和例外狀況或豁免。
ISV 的考慮
ISV 有三 種部署模型。
純軟體即服務 （SaaS） ：ISV 提供解決方案即服務。
客戶已 部署：客戶會在自己的環境中部署解決方案。
雙重部署 SaaS ：此模型結合了客戶部署的模型和純 SaaS 模型。
在純 SaaS 模型中 ，ISV 負責代表客戶管理合規性。 ISV 必須向客戶展示合規性，並可能向稽核員或監管機構展示合規性。 如果您使用 SaaS 模型，您的架構可能會受限於可能會衝突的多個法規。 ISV 必須管理這些各種法規的合規性。 如需詳細資訊，請參閱 本文中的<需要修改 的案例>一節。
在客戶部署的模型中 ，客戶負責管理合規性。 針對此模型，ISV 不需要修改登陸區域。 不過，解決方案會部署在客戶部署的登陸區域中，包括任何原則控制和自訂原則。
提示
ISV 可以針對特定合規性需求以原則計畫為目標，以測試解決方案。 這種做法有助於將客戶用來符合其合規性需求的原則衝突的機會降到最低。
在雙部署 SaaS 模型中 ，客戶部署和純 SaaS 模型的所有考慮皆適用。
跨國組織的考慮
跨國組織會使用各種結構來組織其 IT 治理。
分散式結構 ：IT 函式會控管在每個地理位置的本機。
集中式結構 ：IT 功能會從集中式位置進行控管，通常是組織的總部。
混合式結構 ：全域 IT 函式會集中提供，而只有本機所需的 IT 函式會控管在每個地理位置。
在分散式 案例中，本機 IT 小組負責管理合規性，並可據以量身打造其登陸區域。
在集中式 案例中，中央 IT 小組負責管理合規性，並確保解決方案符合跨國組織運作的所有地理位置的本機合規性需求。 各種地理位置的合規性需求可能會衝突，而且可能需要修改登陸區域。
在混合式 案例中，適用于分散式和集中式案例的考慮。 集中式組織提供本機組織在其環境中部署的解決方案。 集中式組織也會測試這些解決方案會部署在本機組織的所有登陸區域中。
需要修改的案例
如果有指派給各種部署的衝突原則集，您可能需要修改登陸區域。 可能有多個解決方案或單一解決方案需要提供給各種地理位置或資料分類。
所需的修改量取決於法規所要求的隔離程度。 監管條件越多，登陸區就越需要修改。 例如，如果法規需要已清除的人員、各種識別提供者或目錄、個別管理基礎結構或個別的連線基礎結構等條件，登陸區域需要大量修改。 如果法規只需要隔離應用程式和連線基礎結構，登陸區域需要最少的修改。
Microsoft Entra 租用戶
我們建議 針對大部分案例使用單一 Microsoft Entra 租使用者 ，包括跨國案例。 不過，在某些情況下，您可能會偏好或要求多個 Microsoft Entra 租使用者，例如：
如果您需要 將公司 Microsoft Entra 租使用者與 SaaS Microsoft Entra 租 使用者區隔開，以改善安全性和商務營運之間的明確界限。
如果適用衝突的法規，而且您需要針對不同的法規制度個別的 Microsoft Entra 租使用者。 例如，法規可能有需要 Microsoft Entra 租使用者之間 完整隔離的許可和國籍需求，或需要個別租 使用者的資料落地需求。 常見案例包括需要部署 SaaS 解決方案隔離實例的 ISV，或需要部署相同解決方案隔離實例的跨國組織。
當您跨多個 Microsoft Entra 租使用者共同作業時，您必須仔細規劃重大挑戰和需求。 只建立您需要符合作業或法規需求的 Microsoft Entra 租使用者數目下限。 您可以使用管理群組和 Azure 角色型存取控制 （RBAC）來管理單一租使用者下訂用帳戶和資源存取權，如下一節所述。
提示
您為登陸區域選取的 Microsoft Entra 租使用者不會影響您的應用程式層級驗證。 不論您選擇的租使用者為何，您仍然可以使用其他識別提供者。 針對受管制產業的公共部門客戶和客戶，當您與已核准的身分識別提供者整合時，通常會提供使用者身分識別，例如政府擁有或認證的身分識別提供者。
下圖顯示可用來組織 Microsoft Entra 租使用者的選項。
提示
如果您有多個 Microsoft Entra 租使用者以符合法規需求，請根據地理位置而非特定法規來命名租使用者，例如 範例圖表中的 contoso-ops-us.com 。
如需詳細資訊，請參閱 Azure 登陸區域和多個 Microsoft Entra 租使用者 和 Azure 登陸區域的 ISV 考慮。
管理群組
如果您不需要個別的 Microsoft Entra 租使用者以提供嚴格的隔離，您應該在單一 Microsoft Entra 租使用者中部署多個 Azure 登陸區域。 您可以調整管理群組階層，以解決衝突法規的需求。
您可以針對您想要分隔的每個法規集，部署完整的登陸區域架構。 此模型需要最少的自訂，並可讓您利用現有的自動化進行部署。
注意
此圖表不會顯示所有管理群組。
共用平臺管理群組
如果法規允許，則可以共用平臺管理群組。 您可以針對需要分隔的每個法規集，在登陸區域管理群組下建立個別的管理群組。 您可以將適當的原則指派給每個應用程式管理群組。 應用程式登陸區域會共用平臺管理群組底下的管理群組。 應用程式管理群組中的資源也可以依訂用帳戶或資源群組分隔。
此管理群組階層是一種簡單且符合成本效益的設計，可隔離具有衝突法規的應用程式。 不過，在此設計中，連線、身分識別/安全性和管理的平臺管理群組必須共用相同的原則集。 如果法規對共用連線基礎結構、身分識別服務、金鑰管理服務或整個環境所管理基礎結構的限制，您可能需要針對每個平臺管理群組的不同原則集。
隔離身分識別和安全性
如果法規無法共用身分識別和金鑰管理基礎結構，您可以分割平臺管理群組。 讓管理群組在共用平臺管理群組中保持連線和管理，並擁有與每組法規相關聯的身分識別和安全性管理群組。
此管理群組階層比完全共用平臺管理群組複雜得多，因為您必須部分複寫平臺管理群組。 若要限制複雜性，您可以為每個法規集和共用環境部署完整的階層，並忽略或刪除多餘的管理群組。
隔離連線能力
許多法規都有與處理和儲存特定地理位置資料相關的需求，而使用者如何連線到應用程式的需求很少。 針對這些法規，您可以共用連線管理，如先前的架構所示。 可能沒有任何法規要求您在多個區域中複製基礎結構，但您可能需要進行延遲。 指派的原則必須支援在多個區域中複製基礎結構。
當法規有衝突的連線需求時，您可以建立與每組法規相關聯的連線管理群組。 此結構類似于先前的架構，可將身分識別和安全性管理群組與每組法規產生關聯。
如果連線能力與身分識別和安全性的法規衝突，您可以使用下列設計。
