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

使用 Key Vault 进行的身份验证可与 Microsoft Entra ID 结合使用，后者负责对任何给定安全主体的标识进行身份验证。

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

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

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

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

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

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

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

  有关详细信息，请参阅托管标识概述。 另请参阅支持托管标识的 Azure 服务，其链接到介绍如何为特定服务（例如应用服务、Azure Functions、虚拟机等）启用托管标识的文章。

• 如果不能使用托管标识，请改为将应用程序注册到 Microsoft Entra 租户，如快速入门：在 Azure 标识平台中注册应用程序中所述。 注册操作还会创建第二个应用程序对象，该对象在所有租户中标识该应用。

Key Vault 身份验证方案

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

• 仅限应用程序：应用程序表示服务主体或托管标识。 对于定期需要从密钥保管库访问证书、密钥或机密的应用程序，此标识是最常见的方案。 若要在使用访问策略（旧版）时使用此方案，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 请求发送到 Key Vault。 若要了解详细信息，请查看 整个身份验证流。

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

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

配置密钥保管库防火墙

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

有关详细信息，请参阅访问防火墙保护下的 Azure 密钥保管库。

包括身份验证的密钥保管库请求操作流

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

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

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

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

3. 通过密钥保管库的终结点 (URI) 调用密钥保管库 REST API。

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

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

5. 如果防火墙允许该调用，则 Key Vault 会调用 Microsoft Entra ID 来验证安全主体的访问令牌。

6. 密钥保管库会检查安全主体是否对请求的操作拥有所需的权限。 如果没有，则密钥保管库会返回禁止访问响应。

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

下面的关系图说明应用程序调用密钥保管库“获取机密”API 的过程：

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

密钥保管库 SDK 使用 Azure 标识客户端库，通过该库可以使用相同的代码跨环境对密钥保管库进行无缝身份验证

Azure 标识客户端库

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

后续步骤

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

• 使用 Azure 门户分配 Key Vault 访问策略

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

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

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

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