Azure 密钥保管库 中的身份验证

使用 密钥保管库 进行身份验证可与 Microsoft Entra ID 结合使用，该身份验证负责验证任何给定的 安全主体的身份。

安全主体是表示请求访问Azure资源的用户、组、服务或应用程序的对象。 Azure为每个安全主体分配唯一的 object ID。

• user 安全主体标识具有Microsoft Entra ID配置文件的个人。

• group 安全主体标识在Microsoft Entra ID中创建的一组用户。 分配给组的任何角色或权限都将授予组内的所有用户。

• 服务主体是一类安全主体，它标识应用程序或服务，即一段代码，而不是用户或组。 服务主体的对象 ID 的作用类似于其用户名；服务主体的“客户端密码”的作用类似于其密码。

对于应用程序，有两种获取服务主体的方法：

• 建议：为应用程序启用系统分配的托管标识。

  使用托管标识，Azure内部管理应用程序的服务主体，并使用其他Azure服务自动对应用程序进行身份验证。 托管身份可用于部署在各种服务上的应用程序。

  有关详细信息，请参阅托管身份概述。 另请参阅Azure支持托管标识的服务，这些链接指向描述如何为特定服务（如应用服务、Azure Functions、虚拟机等）启用托管标识的文章。

• 如果无法使用托管标识，请改为使用 Microsoft Entra 租户注册应用程序，如 Quickstart：向 Azure 标识平台注册应用程序中所述。 注册操作还会创建第二个应用程序对象，该对象在所有租户中标识该应用。

密钥保管库身份验证方案

在Azure订阅中创建密钥保管库时，它会自动与订阅的Microsoft Entra租户相关联。 这两个平面中的所有调用方都必须在此租户中注册并进行身份验证才能访问密钥保管库。 应用程序可以通过三种方式访问密钥保管库：

• 仅限应用程序：应用程序表示服务主体或托管标识。 对于定期需要从密钥保管库访问证书、密钥或机密的应用程序，此标识是最常见的方案。 若要在使用访问策略（旧版）时使用此方案，objectId必须在访问策略中指定应用程序，并且applicationId不得指定或必须null指定。 使用 Azure RBAC 时，请将适当的角色分配给应用程序的托管标识或服务主体。

• 仅限用户：用户从租户中注册的任何应用程序访问密钥保管库。 此类访问的示例包括Azure PowerShell和Azure门户。 若要在使用访问策略（旧版）时使用此方案，必须在访问策略中指定用户的objectId，并且applicationId不得指定或必须为null。 使用 Azure RBAC 时，向用户分配适当的角色。

• 应用程序加用户 （有时称为 复合标识）：用户需要从特定应用程序访问密钥保管库， 应用程序 必须使用代表身份验证（OBO）流来模拟用户。 为了使此方案与访问策略（旧版）一起工作，必须在访问策略中指定applicationId和objectId。 applicationId 用于识别所需的应用程序，objectId 用于识别用户。 目前，此选项不适用于数据平面Azure RBAC。

在所有类型的访问中，应用程序使用Microsoft Entra ID进行身份验证。 应用程序使用基于应用程序类型的任何 受支持的身份验证方法 。 应用程序获取资源所在平面的访问令牌以授予访问权限。 资源是管理或数据平面中的终结点，基于Azure环境。 应用程序使用令牌并将 REST API 请求发送到密钥保管库。 若要了解详细信息，请查看 整个身份验证流。

向这两个平面进行身份验证的单一机制的模型具有以下优势：

• 组织可以集中控制对其组织中所有密钥保管库的访问。
• 如果用户离开，他们将立即失去对组织中所有密钥保管库的访问权限。
• 组织可以使用Microsoft Entra ID中的选项来自定义身份验证，例如启用多重身份验证以实现添加的安全性。

配置密钥保管库防火墙

默认情况下，密钥保管库允许通过公共 IP 地址访问资源。 为了提高安全性，还可以限制对特定 IP 范围、服务终结点、虚拟网络或专用终结点的访问。

有关详细信息，请参阅防火墙后面的 Access Azure 密钥保管库。

带身份验证的密钥保管库请求操作流程

密钥保管库身份验证是密钥保管库上每个请求操作的一部分。 检索令牌后，可将其重用于后续调用。 身份验证流示例：

1. 有令牌请求使用 Microsoft Entra ID 进行身份验证，例如：

   • 具有托管标识的虚拟机或应用服务应用程序等Azure资源会与 REST 终结点联系以获取访问令牌。
   • 用户使用用户名和密码登录到Azure门户。

2. 如果通过 Microsoft Entra ID 进行身份验证成功，则向安全主体授予 OAuth 令牌。

3. 通过密钥保管库终结点（URI）调用 密钥保管库 REST API。

4. 密钥保管库防火墙检查以下条件。 如果满足任何条件，则允许调用。 否则，调用将被阻止并返回禁止访问响应。

   • 防火墙已禁用，密钥保管库的公共终结点可从公共 Internet 访问。
   • 调用方是密钥保管库受信任的服务，允许它绕过防火墙。
   • 调用方按 IP 地址、虚拟网络或服务终结点在防火墙中列出。
   • 调用方可以通过配置的专用链接连接访问密钥保管库。

5. 如果防火墙允许调用，密钥保管库调用Microsoft Entra ID来验证安全主体的访问令牌。

6. 密钥保管库检查安全主体是否具有请求的操作所需的权限。 如果不是这样，密钥保管库返回禁止响应。

7. 密钥保管库执行请求的操作并返回结果。

下图演示了调用密钥保管库“获取机密”API 的应用程序的过程：

在应用程序代码中对密钥保管库进行身份验证

密钥保管库 SDK 使用 Azure Identity 客户端库，这使相同代码可以在不同环境中无缝进行 密钥保管库 身份验证。

Azure标识客户端库

有关最佳做法和开发人员示例的详细信息，请参阅 在代码中对 密钥保管库 进行身份验证

后续步骤

• 密钥保管库开发人员指南

• 使用 Azure 门户分配密钥保管库访问策略

• 将 Azure RBAC 角色分配给 密钥保管库

• 密钥保管库访问策略故障排除

• 密钥保管库 REST API 错误代码

• Azure什么是基于角色的访问控制（Azure RBAC）？