Azure Key Vault 安全性

Azure Key Vault 保护云中的加密密钥、证书(以及与证书关联的私钥)和机密(例如连接字符串和密码)。 存储敏感数据和关键业务数据时,必须采取措施以最大限度提高保管库及其中存储的数据的安全性。

本文概述了 Azure Key Vault 的安全功能和最佳做法。

注意

若要获取基于 Azure Key Vault 安全建议的完整列表,请参阅 Azure Key Vault 的安全基线

网络安全性

可以通过指定哪些 IP 地址有权访问来减少保管库的曝光。 通过 Azure Key Vault 的虚拟网络服务终结点可将访问限制为指定虚拟网络。 此外,还可通过这些终结点将访问限制为一系列 IPv4(Internet 协议版本 4)地址范围。 任何从外部连接到 Key Vault 的用户都无法访问这些资源。 有关完整的详细信息,请参阅适用于 Azure Key Vault 的虚拟网络服务终结点

防火墙规则生效后,仅当用户请求来自允许的虚拟网络或 IPv4 地址范围时,才能读取 Key Vault 中的数据。 从 Azure 门户访问 Key Vault 时,这同样适用。 虽然用户可从 Azure 门户浏览到 Key Vault,但如果其客户端计算机不在允许列表中,则可能无法列出密钥、机密或证书。 有关实施步骤,请参阅配置 Azure Key Vault 防火墙和虚拟网络

使用 Azure 专用链接服务,可以通过虚拟网络中的专用终结点访问 Azure Key Vault 和 Azure 托管的客户服务/合作伙伴服务。 Azure 专用终结点是一个网络接口,可以通过私密且安全的方式将你连接到 Azure 专用链接支持的服务。 专用终结点使用 VNet 中的专用 IP 地址将服务有效接入 VNet 中。 发往服务的所有流量都可以通过专用终结点路由,因此不需要网关、NAT 设备、ExpressRoute 或 VPN 连接或公共 IP 地址。 虚拟网络与服务之间的流量将通过 Azure 主干网络,因此不会从公共 Internet 泄露。 可以连接到 Azure 资源的实例,从而获得最高级别的访问控制粒度。 有关实施步骤,请参阅将 Key Vault 与 Azure 专用链接集成

TLS 和 HTTPS

  • Key Vault 前端(数据平面)是多租户服务器。 这意味着不同客户的密钥保管库可以共享同一公共 IP 地址。 为实现隔离,每个 HTTP 请求均独立于其他请求进行身份验证和授权。
  • 可以标识较旧版本的 TLS 来报告漏洞,但由于公共 IP 地址是共享的,因此密钥保管库服务团队无法在传输级别为单个密钥保管库禁用较旧版本的 TLS。
  • HTTPS 协议允许客户端参与 TLS 协商。 客户端可以强制实施最新版的 TLS,并且当客户端执行此操作时,整个连接将采用相应级别的保护。 如果与 Azure Active Directory 通信或对其进行身份验证的应用程序无法使用 TLS 1.2 或最新版本进行通信,那么这些应用程序可能无法正常工作。
  • 尽管 TLS 协议中存在已知漏洞,但在已知的攻击中,当攻击者使用存在漏洞的 TLS 版本启动某个连接时,尚无法通过恶意代理从密钥保管库中提取任何信息。 攻击者仍需要进行身份验证和授权,并且只要有权限的客户端始终连接最新版 TLS,凭据就不会通过旧版 TLS 的漏洞泄漏。

注意

对于 Azure Key Vault,请确保访问 Keyvault 服务的应用程序应在支持 TLS 1.2 或最新版本的平台上运行。 如果应用程序依赖于 .NET Framework,则还应更新该应用程序。 你还可进行本文中所述的注册表更改,在 OS 级别上明确允许 .NET Framework 使用 TLS 1.2。 为了满足合规性义务和改善安全状况,密钥保管库通过 TLS 1.0 & 1.1 建立的连接被视为安全风险,2023 年将禁止使用旧 TLS 协议的任何连接。

警告

Azure Active Directory 已弃用 TLS 1.0 和 1.1,访问密钥保管库的令牌可能不再对使用已弃用协议请求令牌的用户或服务进行颁发。 这可能会导致无法访问 Key Vault。 有关 AAD TLS 支持的详细信息,请参阅 Azure AD TLS 1.1 和 1.0 弃用

Key Vault 身份验证选项

在 Azure 订阅中创建密钥保管库时,该密钥保管库自动与订阅的 Azure AD 租户关联。 两个平面中的所有调用方都必须在此租户中注册并进行身份验证,然后才能访问该密钥保管库。 在这两种情况下,应用程序都可以通过三种方式来访问 Key Vault:

  • 仅应用程序:该应用程序表示服务主体或托管标识。 对于需要定期从密钥保管库中访问证书、密钥或机密的应用程序而言,此标识是最常见的方案。 为了让这种方案起作用,必须在访问策略中指定应用程序的 objectId,并且不能指定 applicationId,或者它必须为 null
  • 仅用户:用户从租户中注册的任何应用程序访问密钥保管库。 此类访问的示例包括 Azure PowerShell 和 Azure 门户。 这了让这种该方案起作用,必须在访问策略中指定用户的 objectId,并且不能指定 applicationId,或者它必须为 null
  • 应用程序和用户(有时称为“复合标识”):用户需要从特定应用程序访问密钥保管库,并且该应用程序必须使用代理身份验证 (OBO) 流来模拟用户。 要使此方案起作用,必须在访问策略中指定 applicationIdobjectIdapplicationId 标识所需的应用程序,objectId 标识用户。 目前,此选项不可用于数据平面 Azure RBAC。

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

对这两种平面使用单一身份验证机制模型具有多个优点:

  • 组织可以集中控制对其组织中的所有密钥保管库的访问。
  • 离职的用户会立即失去对组织中所有密钥保管库的访问权限。
  • 组织可以通过 Azure AD 中的选项自定义身份验证(例如,启用多重身份验证以提高安全性)。

有关详细信息,请参阅 Key Vault 身份验证基础知识

访问模型概述

可通过以下两个接口来控制对密钥保管库的访问:管理平面数据平面。 管理平面用于管理密钥保管库本身。 此平面中的操作包括创建和删除密钥保管库、检索密钥保管库属性以及更新访问策略。 数据平面用于处理密钥保管库中存储的数据。 可以添加、删除和修改密钥、机密及证书。

这两个平面都使用 Azure Active Directory (Azure AD) 来进行身份验证。 对于授权,管理平面使用 Azure 基于角色的访问控制 (Azure RBAC),而数据平面则使用 Key Vault 访问策略适用于 Key Vault 数据平面操作的 Azure RBAC

若要在任一平面中访问密钥保管库,所有调用方(用户或应用程序)都必须进行适当的身份验证并拥有适当的授权。 身份验证可确定调用方的身份。 授权可确定调用方能够执行的操作。 使用密钥保管库进行的身份验证可与 Azure Active Directory (Azure AD) 结合使用,后者负责对任何给定安全主体的标识进行身份验证。

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

  • 用户安全主体标识在 Azure Active Directory 中具有配置文件的个人。
  • 组安全主体标识在 Azure Active Directory 中创建的一组用户。 分配给组的任何角色或权限都将授予组内的所有用户。
  • 服务主体是一类安全主体,它标识应用程序或服务,即一段代码,而不是用户或组。 服务主体的对象 ID 称为其客户端 ID,作用类似于其用户名。 服务主体的客户端密码或证书的作用类似于其密码 。 许多 Azure 服务支持分配带有客户端 ID证书自动管理功能的托管标识。 对于在 Azure 中进行身份验证而言,托管标识是最安全的,建议选择这种方式。

若要详细了解如何向 Key Vault 进行身份验证,请参阅向 Azure Key Vault 进行身份验证

条件性访问

Key Vault 提供了对 Azure Active Directory 条件访问策略的支持。 使用条件访问策略,可以在需要时对 Key Vault 应用适当的访问控制来确保组织的安全,并在不需要应用这些控制时,避免为用户造成阻碍。

有关详细信息,请参阅条件访问概述

特权访问

授权可确定调用方能够执行的操作。 Key Vault 中的授权针对管理平面使用 Azure 基于角色的访问控制 (Azure RBAC),针对数据平面则使用 Azure RBAC 或 Azure Key Vault 访问策略。

可以通过两个接口或平面访问保管库。 这些平面为管理平面和数据平面。

  • 管理平面是管理 Key Vault 本身的地方,也是用于创建和删除保管库的接口。 还可以读取密钥保管库属性并管理访问策略。
  • 数据平面支持处理密钥保管库中存储的数据。 可以添加、删除和修改密钥、机密及证书。

应用程序通过终结点访问平面。 两个平面的访问控制独立运行。 若要授权应用程序使用密钥保管库中的密钥,请使用 Azure RBAC 或 Key Vault 访问策略授予数据平面访问权限。 若要授予用户对 Key Vault 属性和标记的读取访问权限,但不授予对数据(密钥、机密或证书)的访问权限,请使用 Azure RBAC 来授予管理平面访问权限。

下表显示了用于管理平面和数据平面的终结点。

访问平面 访问终结点 操作 访问控制机制
管理平面 Azure 中国世纪互联:
management.chinacloudapi.cn:443
创建、读取、更新和删除密钥保管库

设置密钥保管库访问策略

设置密钥保管库标记
Azure RBAC
数据平面 Azure 中国世纪互联:
<vault-name>.vault.azure.cn:443
密钥:加密、解密、包装密钥、解包密钥、签名、验证、获取、列出、创建、更新、导入、删除、恢复、备份、还原、清除

证书:管理联系人、获取颁发者、列出颁发者、设置颁发者、删除颁发者、管理颁发者、获取、列出、创建、导入、更新、删除、恢复、备份、还原、清除

机密:获取、列出、设置、删除、恢复、备份、还原、清除
Key Vault 访问策略或 Azure RBAC

管理对 Key Vault 的管理访问权限

在资源组中创建密钥保管库时,使用 Azure AD 管理访问权限。 授予用户或组管理资源组中的密钥保管库的权限。 可以通过分配适当的 Azure 角色在特定范围级别授予访问权限。 若要授予用户管理密钥保管库的访问权限,请为特定范围的用户分配预定义的 key vault Contributor 角色。 可以将以下范围级别分配给 Azure 角色:

  • 订阅:在订阅级别分配的 Azure 角色适用于该订阅中的所有资源组和资源。
  • 资源组:在资源组级别分配的 Azure 角色适用于该资源组中的所有资源。
  • 特定资源:为特定资源分配的 Azure 角色适用于该资源。 在这种情况下,资源是特定的密钥保管库。

有多种预定义角色。 如果预定义角色不符合需求,可以定义自己的角色。 有关详细信息,请参阅 Azure RBAC:内置角色

重要

使用访问策略权限模型时,如果用户具有密钥保管库管理平面的 Contributor 权限,则该用户可以通过设置密钥保管库访问策略来授予自己对数据平面的访问权限。 应通过访问策略权限模型严格控制具有密钥保管库的 Contributor 角色访问权限的人员,从而确保只有获得授权的人员才能访问和管理密钥保管库、密钥、机密和证书。 建议使用新的基于角色的访问控制 (RBAC) 权限模型来避免出现此问题。 使用 RBAC 权限模型,权限管理仅限于“所有者”和“用户访问管理员”角色,这允许在安全操作和常规管理操作的角色之间实现职责分离。

控制对 Key Vault 数据的访问

可以使用 Azure RBAC 或 Key Vault 访问策略来控制对 Key Vault 密钥、证书和机密的访问。

有关详细信息,请参阅

日志记录和监视

Key Vault 日志记录会保存保管库中所执行活动的相关信息。 有关完整详细信息,请参阅 Key Vault 日志记录

你可以将 Key Vault 与事件网格集成,以便在密钥保管库中存储的密钥、证书或机密的状态发生更改时收到通知。

还必须监视密钥保管库的运行状况,以确保服务按预期运行。 若要了解如何执行此操作,请参阅 Azure Key Vault 的监视和警报

备份和恢复

Azure Key Vault 软删除和清除保护允许你恢复已删除的保管库和保管库对象。 有关完整的详细信息,请参阅 Azure Key Vault 软删除概述

在保管库中更新/删除/创建对象时,你还应定期备份保管库。

后续步骤