Compartir a través de

Azure Lighthouse 方案中的租户、用户和角色

在将客户加入 Azure Lighthouse 之前,请务必了解 Microsoft Entra 租户、用户和角色的工作原理以及如何在 Azure Lighthouse 方案中使用它们。

租户是专用且受信任的 Microsoft Entra ID 实例。 通常,每个租户表示一个组织。 Azure Lighthouse 支持将资源从一个租户逻辑投影到另一个租户。 这样一来,管理租户中的用户(例如属于服务提供商的用户)可以访问客户租户中的委派资源,或者让具有多个租户的企业集中其管理操作

为了实现此逻辑投影,必须将客户租户中的订阅(或订阅中的一个或多个资源组)加入 Azure Lighthouse。 可以通过 Azure 资源管理器模板将公共或私有产品/服务发布到 Azure 市场来完成此加入过程。

无论使用哪种加入方法,都需要定义授权。 每个授权都包含一个与内置角色组合的 principalId(Microsoft Entra 用户、组或服务主体),该内置角色定义将为委派资源授予的特定权限

注意

除非显式指定,否则 Azure Lighthouse 文档中对“用户”的提及可能会适用于授权中的 Microsoft Entra 用户、组或服务主体。

定义用户和角色的最佳做法

创建授权时,建议使用以下最佳做法:

  • 在大多数情况下,需要将权限分配给 Microsoft Entra 用户组或服务主体,而不是分配给一系列单独的用户帐户。 这样做可通过租户的 Microsoft Entra ID 添加或移除单个用户的访问权限,而不必在每次个人访问要求发生更改时更新委派
  • 遵循最小特权原则。 为了减少无意中出错的可能性,用户只应拥有执行其特定工作所需的权限。 有关详细信息,请参阅建议的安全做法
  • 包括具有托管服务注册分配删除角色的授权,以便在需要时移除对委派的访问权限。 如果未分配此角色,则只能由客户租户中的用户移除对委派资源的访问权限。
  • 确保需要查看 Azure 门户中的“我的客户”页的所有用户都具有读取者角色(或者包含读取者访问权限的其他内置角色)。

重要

若要为 Microsoft Entra 组添加权限,“组类型”必须设置为“安全”。 此选项是在创建组时选择的。 有关详细信息,请参阅使用 Microsoft Entra ID 创建基本组并添加成员

Azure Lighthouse 的角色支持

定义授权时,必须为每个用户帐户分配一个 Azure 内置角色。 不支持自定义角色和经典订阅管理员角色

Azure Lighthouse 目前支持所有内置角色,但有以下例外:

  • 不支持所有者角色。

  • 支持用户访问管理员角色,但仅限用于向客户租户中的托管标识分配角色。 此角色通常会授予的其他权限不适用。 如果定义具有此角色的用户,则还必须指定该用户可分配给托管标识的角色。

  • 不支持具有 DataActions 权限的任何角色。

  • 不支持包含下列任何操作的角色:

    • */write
    • */delete
    • Microsoft.Authorization/*
    • Microsoft.Authorization/*/write
    • Microsoft.Authorization/*/delete
    • Microsoft.Authorization/roleAssignments/write
    • Microsoft.Authorization/roleAssignments/delete
    • Microsoft.Authorization/roleDefinitions/write
    • Microsoft.Authorization/roleDefinitions/delete
    • Microsoft.Authorization/classicAdministrators/write
    • Microsoft.Authorization/classicAdministrators/delete
    • Microsoft.Authorization/locks/write
    • Microsoft.Authorization/locks/delete
    • Microsoft.Authorization/denyAssignments/write
    • Microsoft.Authorization/denyAssignments/delete

重要

分配角色时,请务必查看为每个角色指定的操作。 尽管不支持具有 DataActions 权限的角色,但在某些情况下,支持的角色中包含的操作可能允许访问数据。 当数据通过访问密钥公开,而不是通过用户标识进行访问时,通常会发生这种情况。 例如,虚拟机参与者角色包括 Microsoft.Storage/storageAccounts/listKeys/action 操作,该操作返回可用于检索某些客户数据的存储帐户访问密钥。

在某些情况下,之前受 Azure Lighthouse 支持的角色可能会变得不可用。 例如,如果将 DataActions 权限添加到以前没有该权限的角色,则在载入新委派时不能再使用该角色。 已分配有该角色的用户仍能够处理以前委派的资源,但他们无法执行使用 DataActions 权限的任何任务。

向 Azure 添加新的适用内置角色后,可以在使用 Azure 资源管理器模板加入客户时分配该角色。 发布托管服务套餐时,新添加的角色在合作伙伴中心变得可用之前可能会有延迟。 同样,如果某个角色变得不可用,在一段时间内可能仍会在合作伙伴中心看到该角色;但无法使用此类角色发布新产品/服务。

在 Microsoft Entra 租户之间传输委托订阅

如果订阅转移到另一个 Microsoft Entra 租户帐户,则将保留通过 Azure Lighthouse 加入流程创建的注册定义和注册分配资源。 这意味着,通过 Azure Lighthouse 授予管理租户的访问权限对该订阅(或该订阅中的委派资源组)仍然有效。

唯一的例外情况是订阅转移到之前已委派给的 Microsoft Entra 租户。 在这种情况下,将移除该租户的委派资源,并且通过 Azure Lighthouse 授予的访问权限不再适用,因为订阅现在直属于该租户(而非通过 Azure Lighthouse 委派给该租户)。 但是,如果该订阅也委派给了其他管理租户,则其他管理租户将保留对订阅的相同访问权限。

后续步骤