你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

多个 Microsoft Entra 租户的方案

组织可能需要或可能需要调查多个 Microsoft Entra 租户的原因有多种。 最常见的方案包括:

合并和收购

随着组织随着时间的推移而增长,他们可能会收购其他公司或组织。 这些收购可能已建立现有的 Microsoft Entra 租户来托管和提供服务,例如 Microsoft 365(Exchange Online、SharePoint、OneDrive 或 Teams)、Dynamics 365 和 Microsoft Azure。

通常,在收购中,这两个 Microsoft Entra 租户合并到单个 Microsoft Entra 租户中。 这种整合减少了管理开销,提高了协作体验,并向其他公司和组织提供单一品牌标识。

重要

自定义域名(例如, contoso.com)一次只能与一个 Microsoft Entra 租户相关联。 因此,合并租户是首选,因为合并或收购方案发生时,所有标识都可以使用单个自定义域名。

由于将两个 Microsoft Entra 租户合并为一个租户的复杂性,有时租户单独保留,并长时间保持独立。

当组织或公司希望保持独立时,也可能发生这种情况,因为其他组织将来可能会收购其公司。 如果组织使 Microsoft Entra 租户保持隔离,并且它们不会合并它们,则如果将来合并或收购单个实体,则工作较少。

法规或国家/地区合规性要求

某些组织具有严格的法规或国家/地区合规性控制和框架(例如,英国官方、萨班斯·奥克斯利(SOX)或 NIST)。 组织可能会创建多个 Microsoft Entra 租户以满足并遵守这些框架。

一些具有更严格数据驻留法规的世界各地的办公室和用户的组织也可能创建多个 Microsoft Entra 租户。 但是,此特定要求通常使用 Microsoft 365 多地理位置功能在单个 Microsoft Entra 租户中解决。

另一种情况是,组织需要Azure 政府(美国政府)Azure 中国(由世纪互联运营)。 这些国家/地区 Azure 云实例需要自己的 Microsoft Entra 租户。 Microsoft Entra 租户仅用于该国家/地区 Azure 云实例,并用于该 Azure 云实例中的 Azure 订阅标识和访问管理服务。

提示

有关 Azure 国家/地区云标识方案的详细信息,请参阅:

与在前面的方案中一样,如果你的组织具有符合法规或国家/地区合规性框架,则可能不需要多个 Microsoft Entra 租户作为默认方法。 大多数组织都可以使用 Privileged Identity Management管理员istrative 单元等功能来遵守单个 Microsoft Entra 租户中的框架。

业务部门或组织隔离和自治要求

某些组织可能具有跨多个业务部门的复杂内部结构,或者可能需要在组织的各个部分之间实现高度隔离和自治。

出现此方案时,单个租户中的资源隔离中的工具和指南无法提供所需的隔离级别,可能需要部署、管理和操作多个 Microsoft Entra 租户。

在这种情况下,更常见的情况是,没有负责部署、管理和操作这些多个租户的集中式函数。 相反,他们将完全移交给独立的业务部门或组织的一部分,以运行和管理。 集中式体系结构、策略或 CCoE 样式团队可能仍提供有关必须在单独的 Microsoft Entra 租户中配置的最佳做法的指导和建议。

警告

具有运营角色和职责的组织在运营组织的 Microsoft Entra 租户的团队之间产生挑战。 Azure 应优先创建和同意两个团队之间的明确 RACI。 此操作可确保两个团队都能工作并向组织提供服务,并及时向业务提供价值。

某些组织具有使用 Azure 的云基础结构和开发团队。 组织依赖于一个标识团队,该团队可以控制企业 Microsoft Entra 租户的服务主体创建或组创建和管理。 如果没有商定的 RACI,团队之间往往缺乏流程和理解,这会导致团队与整个组织之间的摩擦。 一些组织认为,多个 Microsoft Entra 租户是克服这一挑战的唯一途径。

但是,多个 Microsoft Entra 租户为最终用户带来挑战,增加了保护、管理和管理多个租户的复杂性,并可能会增加许可成本。 许可证(如 Microsoft Entra ID P1 或 P2)不会跨越多个 Microsoft Entra 租户。 有时, Microsoft Entra B2B 的使用可以缓解某些功能和服务的许可重复。 如果计划在部署中使用 Microsoft Entra B2B,请查看每个功能和服务的许可条款以及 Microsoft Entra B2B 资格支持性。

在这种情况下,组织应解决运营挑战,以确保团队可以在单个 Microsoft Entra 租户中协同工作,而不是创建多个 Microsoft Entra 租户作为解决方法。

从 Azure 交付 SaaS 应用程序的独立软件供应商 (ISV)

将 SaaS(软件即服务)产品交付给客户的 ISV 可能受益于拥有多个 Microsoft Entra 租户供其 Azure 使用。

如果你是 ISV,则可能是企业 Microsoft Entra 租户(包括 Azure 使用情况)之间的分离,适用于企业常规活动,例如电子邮件、文件共享和内部应用程序。 你可能还有一个单独的 Microsoft Entra 租户,其中 Azure 订阅托管并向最终客户提供的 SaaS 应用程序。 此方法很常见且合理,因为它可保护你和你的客户免受安全事件。

有关详细信息,请参阅 Azure 登陆区域的独立软件供应商 (ISV) 注意事项。

租户级别测试 /Microsoft 365 测试

Microsoft 云产品、服务和产品/服务中的某些活动和功能只能在单独的 Microsoft Entra 租户中进行测试。 一些示例如:

  • Microsoft 365 – Exchange Online、SharePoint 和 Teams
  • Microsoft Entra ID – Microsoft Entra 连接、Microsoft Entra ID 保护 风险级别和 SaaS 应用程序
  • 测试使用 Microsoft Graph API 的脚本,并可以对生产进行更改并进行更改

如果要像前面的方案一样执行测试,单独的 Microsoft Entra 租户是唯一的选择。

但是,单独的 Microsoft Entra 租户 不适用于 托管包含工作负荷的 Azure 订阅,而不考虑环境,例如开发/测试。 即使是开发/测试环境也应包含在常规的“生产”Microsoft Entra 租户中。

提示

有关如何在 Azure 登陆区域环境中处理测试 Azure 登陆区域和 Azure 工作负荷或资源的信息,请参阅:

草根/ 影子 IT / 初创企业

如果团队想要快速创新,他们可能会创建单独的 Microsoft Entra 租户,帮助他们尽快移动。 他们可能会有意或无意地避免中心/平台团队的过程和指导,以便访问 Azure 环境以执行其创新。

此方案在初创公司中很常见,即他们设置自己的 Microsoft Entra 租户,以便从中运行、托管和运营业务和服务。 这通常是预期的,但当获得初创企业时,额外的 Microsoft Entra 租户会创建一个决策点,即获取组织的 IT 团队决定今后要做什么。

有关如何导航此方案的详细信息,请参阅 本文中的“合并和收购 ”和 “独立软件供应商”(ISV)从 Azure 部分交付 SaaS 应用程序。

重要

我们强烈建议平台团队具有易于访问且高效的流程,使团队能够访问组织企业或主要 Microsoft Entra 租户中驻留的 Azure 沙盒订阅或订阅。 此过程可防止影子 IT 方案发生,并防止将来各方面临挑战。

有关沙盒的详细信息,请参阅 资源组织设计区域中的管理组指南。

总结

如方案中详述,组织可能需要多个 Microsoft Entra 租户的原因有多种。 但是,当你创建多个租户以满足这些方案中的要求时,它会增加复杂性和操作任务来维护多个租户,并可能会增加许可要求的成本。 有关详细信息,请参阅 多租户方案中 Azure 登陆区域的注意事项和建议。

后续步骤