你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
跨多个租户自动化 Azure 登陆区域
如果你的组织有多个 Microsoft Entra 租户，每个租户都有一个或多个 Azure 登录区域 (ALZ)，则自动化是关键。 自动化有助于在所有租户中大规模操作和维护 ALZ 部署。 可通过多种方法跨多个租户自动执行 ALZ 部署。 采用的方法取决于组织有多个Microsoft Entra 租户的原因。
例如，如果你是独立的软件供应商，则可能有多个Microsoft Entra 租户。 你可能希望将企业和 SaaS 解决方案 Microsoft Entra 租户分开。 无论是有意还是失误，影响其他租户的操作或部署的风险都有所降低。
以下部分提供了关于可采取方法的图示和指导。 在处理多个 Microsoft Entra 租户时，根据自动化 Azure 登陆区域部署的要求、注意事项和建议，选择最适合你的方法。
注意
请先查看以下文章，大致了解 Microsoft Entra 租户：
方法
可通过两种方法跨多个 Microsoft Entra 租户自动部署 Azure 登陆区域。
方法 1 – 完全隔离 是多租户方案中最常见的方法。 此方法在 Microsoft Entra 租户之间保持所需的分离和隔离，这是使用多租户方法时最常见的要求。
方法 2 - 与多个服务主体共享应用程序注册（多租户）通常用于托管服务提供商 (MSP) 应用场景。 在此方法中，可以使用 部署样板模式 自动大规模地在多个租户中部署几乎完全相同的体系结构。
这两种方法都作为示例和灵感提供。 可以根据组织的要求灵活组合在部署中采用的方法。
重要
本文介绍如何自动部署和运行 Azure 登陆区域，将其作为组织拥有的每个 Microsoft Entra 租户中的平台。 本文中的方法、建议和注意事项不适用于将服务和应用程序部署到其登陆区域（订阅）并在其中运行的应用程序团队。 有关不同类型的登陆区域的详细信息，请参阅 平台与应用程序登陆区域。
方法 1 – 完全隔离
在此方法中，主要目标是使每个 Microsoft Entra 租户在所有自动化组件中彼此隔离，例如：
- Git 存储库。
- GitHub Actions 或 Azure Pipelines（包括使用的自承载运行器）。
- 用于执行自动化任务的标识，例如分配给自承载运行器、服务主体名称 (SPN)、用户或管理员的托管标识。
多个 Microsoft Entra 租户与使用完整的隔离自动化方法部署的 Azure 登陆区域的关系图。
在这种方法中，每个 Microsoft Entra 租户需要管理更多重复的组件。 某些组织可能受到合规性控制的影响，这些控制要求实施这种隔离。
注意
如果组织只允许使用托管标识进行平台自动化，则必须使用这种方法或单独登录每个租户的方法。 托管标识在目前的正式发布状态下不支持跨租户应用场景。 有关详细信息，请参阅此常见问题解答 。
不过，通过在自身和 Entra ID 多租户应用程序之间配置信任，现在可以在公共预览版中使用用户分配的托管标识。 有关对此进行配置的详细信息，请参阅配置应用程序以信任托管标识（预览版）。 现在，方法 2 - 具有多个服务主体的共享应用程序注册（多租户）可能成为你的部署的可行选择。
平台管理员和开发人员的标识 - 方法 1
在这种方法中，每个 Microsoft Entra 租户中的标识也应该是隔离的，这意味着每个平台管理员或开发人员在每个租户中都需要一个单独的用户帐户，才能在该租户中执行操作。 这些帐户还用于访问每个租户的开发人员工具，如 GitHub 或 Azure DevOps。 请仔细考虑遵循此方法的管理员和开发人员工作效率的影响。
可以使用 Microsoft Entra B2B 和/或 Azure Lighthouse，但这一选项会质疑拥有独立 Microsoft Entra 租户的理由。
方法 2 - 具有多个服务主体的共享应用程序注册（多租户）
在这种方法中，会在 Microsoft Entra 管理租户中创建应用程序注册。 在要管理的每个Microsoft Entra 租户中，会基于应用程序注册在该租户中创建服务主体名称（SPN）。 此操作允许运行管道任务和步骤的工作人员使用单组凭据登录到任何 Microsoft Entra 租户。
提示
有关应用程序注册和企业应用程序（服务原则）之间的关系的信息，请参阅Microsoft Entra ID中的
重要
在此方法中，应监视单个应用程序注册和关联的企业应用程序（服务主体），以监视安全信息和事件管理（SIEM）工具中的任何异常活动，因为这是一个高度特权的帐户。 它应发送警报，并可能根据警报严重性自动采取措施。
在前面的示例中，单个应用注册位于 contoso.onmicrosoft.com Microsoft Entra 租户中，企业应用程序位于链接到应用注册的每个Microsoft Entra 租户中。 此设置允许管道使用单个应用注册向所有Microsoft Entra 租户进行身份验证和授权。 有关详细信息，请参阅将应用程序设置为多租户和向应用程序授予租户范围的管理员许可。
提示
通过在自身和 Entra ID 多租户应用程序之间配置信任，处于公共预览版的用户分配的托管标识现在支持多租户应用场景。 有关对此进行配置的详细信息，请参阅配置应用程序以信任托管标识（预览版）。
使用集中式管道时，可能需要生成一个小型映射表，其中包含关联 Microsoft Entra 租户和其他元数据的数据，例如环境、关联的订阅、组织名称和用于身份验证和授权的标识对象 ID。 在管道运行过程中，可以在一个步骤中调用这些数据，该步骤使用一些逻辑和条件来控制将数据部署到哪个 Microsoft Entra 租户以及使用哪些标识。 数据可以存储在 Azure Cosmos DB 或 Azure 表存储等服务中。
处理多个环境（如开发、测试或生产）时，可以通过管道使用相同或不同的应用程序注册和企业应用程序，以相同的方式来管理这些环境。
你可能决定为每个 Microsoft Entra 租户使用单独的管道，或使用单个管道。 选择取决于你的需求。
注意
Azure Lighthouse 的工作方式与此方法类似，但 Azure Lighthouse 不允许分配具有 DataActions 权限的 RBAC 所有者、用户访问管理员和角色。 有关详细信息，请参阅 Azure Lighthouse 的角色支持。
所有 Azure 登陆区域部署方案中通常需要所有者和用户访问角色。 此要求消除了 Azure Lighthouse 作为 Azure 登陆区域整个平台自动化部署方面的选项，但在某些情况下仍很有用。 有关详细信息，请参阅 ALZ 多租户中的 Azure Lighthouse 使用情况。
平台管理员和开发人员的标识 - 方法 2
在这种方法中，平台管理员和开发人员通常只需要访问管理 Microsoft Entra 租户。 访问权限使他们可以使用所有租户都已部署并操作的开发人员工具，如 GitHub 或 Azure DevOps。
他们可能通过 Microsoft Entra B2B 或 Azure Lighthouse 访问其他 Microsoft Entra 租户。 他们使用与管理租户相同的帐户，也可以拥有单独的帐户，例如第一种方法中的示例。