在 Microsoft Entra ID 中的单个租户中保护资源隔离
可以在单个租户中实现许多隔离方案。 在可能的情况下，建议将管理委派给单个租户中的独立环境，以获得最佳生产力和协作体验。
结果
资源隔离：要限制对用户、组和服务主体的资源访问，可以使用 Microsoft Entra 目录角色、安全组、条件访问策略、Azure 资源组、Azure 管理组、管理单元 (AU) 和其他控制。 启用单独的管理员来管理资源。 使用单独的用户、权限和访问要求。
如果存在以下情况，请在多个租户中使用隔离：
- 需要租户范围设置的资源集
- 对租户成员未经授权访问所带来的风险的承受能力极低
- 配置更改导致产生不必要的影响
配置隔离 - 在某些情况下，应用程序之类的资源依赖于租户范围的配置，例如身份验证方法或命名位置。 隔离资源时考虑依赖项。 全局管理员可以配置影响资源的资源设置和租户范围设置。
如果一组资源需要唯一的租户范围设置，或者租户设置由其他实体管理，则必须在多个租户中使用隔离。
管理隔离：使用 Microsoft Entra ID 委派管理，可以隔离对应用程序和 API、用户和组、资源组以及条件访问策略等资源的管理。
全局管理员可以发现并获取对信任资源的访问权限。 针对经过身份验证的管理员对资源的更改设置审核和警报。
在 Microsoft Entra ID 中使用管理单元 (AU) 进行管理隔离。 AU 将角色中的权限限制为你定义的组织的一部分。 使用 AU 将支持管理员角色委派给区域支持专家。 然后他们可以管理他们支持的区域中的用户。
使用 AU 隔离用户、组和设备对象。 使用动态成员资格组规则分配单元。
通过 Privileged Identity Management (PIM)，选择一个人来批准对高特权角色的请求。 例如，选择需要身份验证管理员访问权限的管理员来更改用户身份验证方法。
注意
使用 PIM 需要每个用户都有 Microsoft Entra ID P2 许可证。
要确认身份验证管理员无法管理资源，请使用单独的身份验证管理员将资源隔离在单独的租户中。 使用此方法进行备份。 有关示例，请参阅多用户授权指南。
常见用法
将多个环境置于单个租户中的一个常见用途是将生产资源与非生产资源隔离开来。 在租户中，开发团队和应用程序所有者创建和管理一个单独的环境，其中包含测试应用、测试用户和组，以及针对这些对象的测试策略。 同样，团队也创建 Azure 资源和可信应用的非生产实例。
将非生产 Azure 资源和 Microsoft Entra 集成应用程序的非生产实例与等效的非生产目录对象结合使用。 目录中的非生产资源用于测试。
注意
避免在单个 Microsoft Entra 租户中使用多个 Microsoft 365 环境。 但可以在单个 Microsoft Entra 租户中使用多个 Dynamics 365 环境。
在单个租户中隔离的另一种方案是，在位置、子公司或分层管理之间进行隔离。 请参阅企业访问模型。
使用 Azure 基于角色的访问控制 (Azure RBAC) 分配对 Azure 资源进行有限管理。 同样，通过多种功能启用 Microsoft Entra ID 对 Microsoft Entra ID 信任应用程序的管理。 示例包括条件访问、用户和组筛选、管理单元分配，以及应用程序分配。
要确保对 Microsoft 365 服务进行隔离（包括暂存组织级别的配置），请选择多租户隔离。
Azure 资源的限定范围的管理
使用 Azure RBAC 设计具有精细范围和外围区域的管理模型。 请考虑以下示例中的管理层次结构：
注意
可以根据组织的要求、约束和目标来定义管理层次结构。 有关详细信息，请参阅云采用框架指南，了解如何组织 Azure 资源。
- 管理组：可以将角色分配给管理组，使它们不影响其他管理组。 在上面的方案中，HR 团队可以定义一个 Azure Policy 来审核跨所有 HR 订阅部署资源的区域。
- 订阅：可以将角色分配给订阅，以防止其影响其他资源组。 在上面的方案中，HR 团队可以为权益订阅分配读取者角色，这样就不会读取任何其他 HR 订阅，也不会读取其他团队的订阅。
- 资源组：可以将角色分配给资源组，以防止其影响其他资源组。 权益工程团队将参与者角色分配给某个用户来管理测试数据库和测试 Web 应用，或添加更多资源。
- 单个资源：将角色分配给资源，使其不会影响其他资源。 权益工程团队为数据分析师分配 Azure Cosmos DB 数据库测试实例的 Cosmos DB 帐户读取者角色。 此任务不会干扰测试 Web 应用或生产资源。
有关详细信息，请参阅 Azure 内置角色和什么是 Azure 基于角色的访问控制 (Azure RBAC)？。
结构为分层结构。 因此，在层次结构中所处的级别越高，其范围、可见性和对较低级别的影响就越大。 顶级范围会影响 Microsoft Entra 租户边界中的所有 Azure 资源。 可以在多个级别应用权限。 此操作会引入风险。 在层次结构上层分配角色可能会比预期提供更大的访问权限和范围（相对于下层而言）。 Microsoft Entra 提供可见性和修正来帮助降低风险。
- 根管理组定义那些将应用于订阅和资源的 Azure 策略和 RBAC 角色分配
- 全局管理员可以提升对订阅和管理组的访问权限
监视顶级范围。 规划资源隔离的其他维度（例如网络）非常重要。 有关 Azure 网络的指南，请参阅 Azure 网络安全最佳做法。 基础结构即服务 (IaaS) 工作负载具有特殊方案，其中的标识和资源隔离需要是设计和策略的一部分。
请考虑根据 Azure 登陆区域概念体系结构隔离敏感资源或测试资源。 例如，将标识订阅分配给单独的管理组。 用于沙盒管理组中开发的单独订阅。 可在企业规模文档中找到更多详细信息。 在参考体系结构的管理组层次结构中考虑租户中的测试分离。
Microsoft Entra ID 信任应用程序的作用域管理
以下部分介绍了对 Microsoft Entra ID 信任应用程序的管理进行范围限定的模式。
Microsoft Entra ID 支持针对同一个进行独立用户分配的目录配置自定义应用和 SaaS 应用的多个实例，但大多数 Microsoft 服务除外。 上一个示例包含旅行应用的生产和测试版本。 要实现特定于应用的配置和策略分离，请针对公司租户部署预生产版本。 此操作使工作负载所有者能够使用其公司凭据执行测试。 非生产目录对象（例如测试用户和测试组）与对这些对象拥有独立所有权的非生产应用程序相关联。
有一些租户范围的方面会影响 Microsoft Entra 租户边界中的信任应用程序，其中包括：
- 全局管理员可以管理所有租户范围的设置
- 其他目录角色（如用户管理员、应用程序管理员和条件访问管理员）可以在角色范围内管理租户范围的配置。
身份验证方法、混合配置、域的 B2B 协作允许列表、命名位置等配置设置属于租户范围。
注意
Microsoft Graph API 权限和同意权限的范围不能限定为组或 AU 成员。 这些权限在目录级别进行分配。 只有特定于资源的同意才允许将范围限定在资源级别（目前限于 Microsoft Teams 聊天权限）。
重要
Microsoft SaaS 服务的生命周期（如 Office 365、Microsoft Dynamics 和 Microsoft Exchange）绑定到 Microsoft Entra 租户。 因此，这些服务的多个实例需要多个 Microsoft Entra 租户。