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

跨多个租户自动执行 Azure 登陆区域

如果组织在每个租户中有多个具有 Azure 登陆区域(ALZ)的 Microsoft Entra 租户,则自动化是关键。 自动化有助于在所有租户中大规模操作和维护 ALZ 部署。 可通过多种方法跨多个租户自动执行 ALZ 部署。 采用的方法取决于组织有多个 Microsoft Entra 租户的原因。

例如,如果你是独立的软件供应商,则可能有多个 Microsoft Entra 租户。 你可能希望将企业和 SaaS 解决方案 Microsoft Entra 租户分开。 影响其他租户的操作或部署的风险(无论是预期还是错误)会减少。

以下部分提供了有关可采用的方法的关系图和指南。 根据处理多个 Microsoft Entra 租户时自动执行 Azure 登陆区域部署的要求、注意事项和建议,选择哪种方法最适合你。

方法

可通过两种方法自动跨多个 Microsoft Entra 租户部署 Azure 登陆区域。

方法 1 – 完全隔离 是多租户方案中最常见的方法。 此方法在 Microsoft Entra 租户之间保持所需的分离和隔离,这是使用多租户方法时最常见的要求。

方法 2 – 与多个服务主体 共享应用程序注册(多租户)通常用于托管服务提供商(MSP)方案。 在此方法中, 可以使用部署戳记模式 在大规模多个租户中自动部署几乎相同的体系结构。

这两种方法都作为示例和灵感提供。 可以根据组织的要求混合和匹配部署中的方法。

重要

本文介绍如何将 Azure 登陆区域部署和操作自动化为组织拥有的每个 Microsoft Entra 租户中的平台。 本文 中的方法、建议和注意事项不应 由部署和操作其服务和应用程序的应用程序团队使用(订阅)。 有关不同类型的登陆区域的详细信息,请参阅 平台与应用程序登陆区域

方法 1 – 完全隔离

在此方法中,主要目标是使每个 Microsoft Entra 租户在所有自动化组件之间相互隔离,例如:

  • Git 存储库。
  • GitHub Actions 或 Azure Pipelines(包括自承载运行程序(如果使用)。
  • 用于从自动化执行任务的标识,例如分配给自承载运行程序、服务主体名称(SPN)、用户或管理员的托管标识。

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed using the complete isolation automation approach.

在此方法中,还有更多组件来管理每个 Microsoft Entra 租户重复的组件。 某些组织可能对其实施法规遵从性控制,这些控制强制实施此类隔离和隔离。

注意

如果组织仅允许使用托管标识实现平台自动化,则必须使用此方法或单独登录到每个租户的方法。 托管标识不支持跨租户方案。 有关详细信息,请参阅此常见问题解答

平台管理员和开发人员的标识 - 方法 1

在此方法中,还应在每个 Microsoft Entra 租户中隔离标识,这意味着每个平台管理员或开发人员都需要每个租户中的单独用户帐户才能在该租户中执行操作。 这些帐户还用于访问每个租户的开发人员工具,如 GitHub 或 Azure DevOps。 请仔细考虑遵循此方法的管理员和开发人员工作效率的影响。

可以使用 Microsoft Entra B2B 和/或 Azure Lighthouse,但此选项质疑具有单独的 Microsoft Entra 租户的原因。

方法 2 - 具有多个服务主体的共享应用程序注册(多租户)

在此方法中,在管理 Microsoft Entra 租户中创建应用程序注册。 在要管理的每个 Microsoft Entra 租户中,会基于应用程序注册在该租户中创建一个服务主体名称(SPN)。 此操作允许运行管道任务的辅助角色和步骤使用一组凭据登录到任何 Microsoft Entra 租户。

提示

有关应用程序注册与企业应用程序(服务原则)之间的关系的信息,请参阅 Microsoft Entra ID 中的应用程序和服务主体对象。

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed using the shared application registration (multi-tenant) with multiple service principals automation approach.

重要

在此方法中,应监视单个应用程序注册和关联的企业应用程序(服务主体),以监视安全信息和事件管理(SIEM)工具中的任何异常活动,因为这是一个高度特权的帐户。 它应发送警报,并可能根据警报严重性自动采取措施。

在前面的示例中,单个应用注册位于 contoso.onmicrosoft.com Microsoft Entra 租户中,企业应用程序位于链接到应用注册的每个 Microsoft Entra 租户中。 此设置允许管道使用单个应用注册对所有 Microsoft Entra 租户进行身份验证和授权。 有关详细信息,请参阅使应用程序成为多租户

使用集中式管道时,可能需要生成一个小型映射表,其中包含与 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 租户。 他们使用管理租户中的同一帐户,或者可能有单独的帐户,如 第一种方法中的示例。

后续步骤