Azure Key Vault 中的身份验证

使用 Key Vault 进行身份验证与 Microsoft Entra ID 结合使用，该 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 访问密钥保管库的公共终结点。
   • 调用方是 Key Vault 受信任的服务，允许它绕过防火墙。
   • 调用方按 IP 地址、虚拟网络或服务终结点在防火墙中列出。
   • 调用方可以通过配置的专用链接连接访问密钥保管库。

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

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

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

下图演示了调用 Key Vault“获取机密”API 的应用程序的过程：

在应用程序代码中向 Key Vault 进行身份验证

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

Azure 标识客户端库

有关最佳做法和开发人员示例的详细信息，请参阅 代码中的 Key Vault 身份验证

后续步骤

• Key Vault 开发人员指南

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

• 将 Azure RBAC 角色分配到 Key Vault

• Key Vault 访问策略故障排除

• Key Vault REST API 错误代码

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