托管标识的最佳做法建议

Azure 资源的托管标识是 Microsoft Entra ID 的一项功能。 支持 Azure 资源的托管标识的每个 Azure 服务都受其自己的时间线限制。 在开始之前，请务必查看资源的托管标识的可用性状态以及已知问题。

选择系统分配还是用户分配的托管标识

与系统分配的托管标识相比，用户分配的托管标识适用的方案范围更加广泛。 参阅下表，了解适用于用户分配或系统分配的一些方案和建议。

用户分配的标识可供多个资源使用，但其生命周期与和其关联的资源的生命周期保持分离。 查阅支持托管标识的资源。

在此生命周期，你可以分离资源创建和标识管理职责。 可以预先配置用户分配的标识及其角色分配，然后再配置需要这些项目的资源。 创建资源的用户只需要访问权限即可分配用户分配的标识，无需创建新的标识或角色分配。

由于创建和删除系统分配标识的同时也会创建和删除相关资源，因此无法提前创建角色分配。 如果创建资源的用户也没有创建角色分配的权限，则此序列可能会导致基础结构部署失败。

如果你的基础结构要求多个资源需可访问相同资源，则可以为这些资源分配用户分配的标识。 这样可降低管理开销，因为要管理的不同标识和角色分配较少。

若你要求每个资源都有其自己的标识或其中包含需要唯一权限集的资源，并且你希望在删除资源时也删除相应标识，则应当使用系统分配的标识。

使用用户分配的标识来减少管理工作

下方关系图将演示分别使用系统分配标识和用户分配标识来允许多个虚拟机访问两个存储帐户时出现的差异。

此图显示使用系统分配标识的四个虚拟机。 每个虚拟机获分配的角色完全相同，以使其可以访问两个存储帐户。

若将用户分配的标识与四个虚拟机关联，则只需进行 2 次角色分配，而使用系统分配标识将需进行 8 次角色分配。 如果虚拟机的标识需要更多角色分配，则这些角色将获得与此标识相关联的所有资源的访问权限。

你还可以使用安全组来减少所需的角色分配次数。 此图显示使用系统分配标识的四个虚拟机，其中这些标识已添加到安全组，而角色分配也已添加到该组而不是系统分配标识。 虽然结果很类似，但此配置不提供与用户分配标识相同的资源管理器模板功能。

多个托管标识

支持托管标识的资源可以同时使用一个系统分配标识和一个或多个用户分配标识。

此模型可让你灵活使用共享的用户分配标识，并在需要时应用精细权限。

在下方示例中，“虚拟机 3”和“虚拟机 4”可以访问存储帐户和密钥保管库，具体取决于在进行身份验证时使用的用户分配标识。

在下方示例中，“虚拟机 4”还使用可允许其访问存储帐户和密钥保管库的用户分配标识，具体取决于在进行身份验证时使用的标识。 系统分配标识的角色分配应根据相应虚拟机的情况进行。

限制

查看托管标识以及自定义角色和角色分配的限制。

授予访问权限时遵循最低特权原则

授予任何标识（包括托管标识）访问服务的权限时，始终授予执行所需操作所需的最低权限。 例如，如果使用托管标识从存储帐户读取数据，则无需允许该标识权限也向存储帐户写入数据。 授予额外的权限（例如，在不需要托管标识时使托管标识成为 Azure 订阅上的参与者）会增加与标识关联的安全冲击半径。 必须始终尽量减少安全冲击半径，这样在泄漏标识时可以最大限度地降低危害。

考虑将托管标识分配给 Azure 资源和/或向用户授予分配权限的影响

必须注意的是，为 Azure 资源（例如 Azure 逻辑应用、Azure 函数或虚拟机等）分配托管标识时，授予托管标识的所有权限现在都可供 Azure 资源使用。 这一点很重要，因为如果用户有权在此资源上安装或执行代码，则用户有权访问分配给/关联到 Azure 资源的所有标识。 托管标识的目的是向 Azure 资源上运行的代码提供对其他资源的访问权限，而无需开发人员直接处理凭据或直接将凭据放入代码中来获取该访问权限。

例如，如果已授予托管标识 (ClientId = 1234) 对 StorageAccount7755 的读/写访问权限，并且已将其分配给 LogicApp3388，则 Alice（对存储帐户没有直接访问权限，但有权在 LogicApp3388 中执行代码）也可以通过执行使用托管标识的代码从 StorageAccount7755 读取数据或向其中写入数据。

同样，如果 Alice 有权自行分配托管标识，则她可以将其分配给另一 Azure 资源，并可访问供该托管标识使用的所有权限。

一般情况下，授予用户对可以执行代码（如逻辑应用）且具有托管标识的资源的管理访问权限时，请考虑分配给用户的角色能否在资源上安装或运行代码，如果可以，则仅在用户真正需要时分配该角色。

维护

系统分配标识会在删除资源时自动删除，而用户分配标识的生命周期独立于与之关联的任何资源。

如果不再需要用户分配标识，则需要手动将其删除（即使没有任何资源与之关联）。

删除系统分配或用户分配的托管标识后，相关角色分配不会自动删除。 因此，应当手动删除这些角色分配，以免超出每个订阅的角色分配数上限。

在门户中查看时，与已删除的托管标识关联的角色分配将会显示“找不到标识”。 了解详细信息。

对于不再与用户或服务主体关联的角色分配，其 ObjectType 值将显示为 Unknown。 若要删除它们，你可以通过管道将几个 Azure PowerShell 命令连接在一起，以首先获取所有角色分配，仅筛选出 ObjectType 值为 Unknown 的角色分配，然后从 Azure 中删除这些角色分配。

Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment 

使用托管标识进行授权的限制

使用 Microsoft Entra ID 组授予对服务的访问权限是一个可简化授权过程的好方法。 思路很简单 - 向组授予权限，并将标识添加到组，以便它们继承相同的权限。 这是来自各种本地系统的成熟模式，并在标识代表用户时效果良好。 在 Microsoft Entra ID 中控制授权的另一种方法是使用应用角色，通过此方法，可声明特定于应用的角色（而不是目录中作为全局概念的组）。 然后，可将应用角色分配给托管标识（以及用户或组）。

在这两种情况下，对于非人类标识（例如 Microsoft Entra 应用程序和托管标识），有关如何将此授权信息呈现给应用程序的确切机制在当今并不是很适合。 目前使用 Microsoft Entra ID 和 Azure 基于角色的访问控制 (Azure RBAC) 的实现使用 Microsoft Entra ID 颁发的访问令牌来对每个标识进行身份验证。 如果该标识已添加到组或角色中，则表示为 Microsoft Entra ID 颁发的访问令牌中的声明。 Azure RBAC 使用这些声明来进一步评估用于允许或拒绝访问的授权规则。

假设标识的组和角色是访问令牌中的声明，则在刷新令牌之前，任何授权更改都不会生效。 针对人类用户，这通常不是问题，因为他们可以通过注销并再次登录（或等待令牌生存期到期，默认为 1 小时）来获取新的访问令牌。 另一方面，托管标识令牌由底层 Azure 基础结构缓存，以保证性能和复原能力：托管标识的后端服务会在 24 小时内维护每个资源 URI 的缓存。 这意味着对托管标识的组或角色成员身份的更改可能需要几个小时才能生效。 目前，无法在托管标识的令牌到期前对其强制执行刷新。 如果更改某个托管标识的组或角色成员身份以添加或删除权限，则可能需要等待几个小时才能让使用该标识的 Azure 资源获得正确的访问权限。

如果由于项目需求而无法接受延迟，请考虑改用令牌中的组或角色。 为确保对托管标识的权限所做的更改快速生效，建议使用用户分配的托管标识对 Azure 资源进行分组，并将权限直接应用于标识，而不是在具有权限的 Microsoft Entra 组中添加或删除托管标识。 用户分配的托管标识可以像组一样使用，因为可以将它分配给一个或多个 Azure 资源来进行使用。 分配操作可以使用托管标识参与者和托管标识操作员角色进行控制。