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 地址。 虚拟网络与服务之间的流量将通过 Microsoft Azure 主干网络传输，因此不会在公共 Internet 上泄露。 可以连接到 Azure 资源的实例，从而获得最高级别的访问控制粒度。 有关实施步骤，请参阅将 Key Vault 与 Azure 专用链接集成
TLS 和 HTTPS
- Key Vault 前端（数据平面）是多租户服务器。 这意味着不同客户的密钥保管库可以共享同一公共 IP 地址。 为实现隔离，每个 HTTP 请求均独立于其他请求进行身份验证和授权。
- HTTPS 协议允许客户端参与 TLS 协商。 客户端可强制实施 TLS 的版本，并且每当客户端执行此操作时，整个连接都将采用相应级别的保护。 Key Vault 支持 TLS 1.2 和 1.3 协议版本。
注意
可以通过使用此处的示例 Kusto 查询监视 Key Vault 日志来监视客户端使用的 TLS 版本。
Key Vault 身份验证选项
在 Azure 订阅中创建密钥保管库时，该密钥保管库自动与订阅的 Microsoft Entra 租户关联。 两个平面中的所有调用方都必须在此租户中注册并进行身份验证，然后才能访问该密钥保管库。 在这两种情况下，应用程序都可以通过三种方式来访问 Key Vault：
- 仅应用程序：该应用程序表示服务主体或托管标识。 对于需要定期从密钥保管库中访问证书、密钥或机密的应用程序而言，此标识是最常见的方案。 为了让这种方案起作用，必须在访问策略中指定应用程序的
objectId，并且不能指定applicationId，或者它必须为null。 - 仅用户：用户从租户中注册的任何应用程序访问密钥保管库。 此类访问的示例包括 Azure PowerShell 和 Azure 门户。 这了让这种该方案起作用，必须在访问策略中指定用户的
objectId，并且不能指定applicationId，或者它必须为null。 - 应用程序和用户（有时称为“复合标识”）：用户需要从特定应用程序访问密钥保管库，并且该应用程序必须使用代理身份验证 (OBO) 流来模拟用户。 要使此方案起作用，必须在访问策略中指定
applicationId和objectId。applicationId标识所需的应用程序，objectId标识用户。 目前，此选项不可用于数据平面 Azure RBAC。
在所有类型的访问中，应用程序都使用 Microsoft Entra ID 进行身份验证。 应用程序根据应用程序类型使用任何支持的身份验证方法。 应用程序通过获取平面中资源的令牌来授予访问权限。 资源是管理平面或数据平面中基于 Azure 环境的终结点。 应用程序使用令牌并向密钥保管库发送 REST API 请求。 若要了解详细信息，请查看整个身份验证流。
对这两种平面使用单一身份验证机制模型具有多个优点：
- 组织可以集中控制对其组织中的所有密钥保管库的访问。
- 离职的用户会立即失去对组织中所有密钥保管库的访问权限。
- 组织可以通过 Microsoft Entra ID 中的选项自定义身份验证（例如，启用多重身份验证以提高安全性）。
有关详细信息，请参阅 Key Vault 身份验证基础知识。
访问模型概述
可通过以下两个接口来控制对密钥保管库的访问：管理平面和数据平面。 管理平面用于管理密钥保管库本身。 此平面中的操作包括创建和删除密钥保管库、检索密钥保管库属性以及更新访问策略。 数据平面用于处理密钥保管库中存储的数据。 可以添加、删除和修改密钥、机密及证书。
两个平面均使用 Microsoft Entra ID 进行身份验证。 对于授权，管理平面使用 Azure 基于角色的访问控制 (Azure RBAC)，而数据平面则使用 Key Vault 访问策略和适用于 Key Vault 数据平面操作的 Azure RBAC。
若要在任一平面中访问密钥保管库，所有调用方（用户或应用程序）都必须进行适当的身份验证并拥有适当的授权。 身份验证可确定调用方的身份。 授权可确定调用方能够执行的操作。 使用 Key Vault 进行的身份验证可与 Microsoft Entra ID 结合使用，后者负责对任何给定安全主体的标识进行身份验证。
安全主体是一个对象，表示请求访问 Azure 资源的用户、组、服务或应用程序。 Azure 为每个安全主体分配唯一的对象 ID。
- 用户安全主体标识在 Microsoft Entra ID 中具有配置文件的个人。
- 组安全主体标识在 Microsoft Entra ID 中创建的一组用户。 分配给组的任何角色或权限都将授予组内的所有用户。
- 服务主体是一类安全主体，它标识应用程序或服务，即一段代码，而不是用户或组。 服务主体的对象 ID 称为其客户端 ID，作用类似于其用户名。 服务主体的客户端密码或证书的作用类似于其密码 。 许多 Azure 服务支持分配带有客户端 ID 和证书自动管理功能的托管标识。 对于在 Azure 中进行身份验证而言，托管标识是最安全的，建议选择这种方式。
若要详细了解如何向 Key Vault 进行身份验证，请参阅向 Azure Key Vault 进行身份验证。
条件性访问
密钥库为 Microsoft Entra 条件访问策略提供支持。 使用条件访问策略，可以在需要时对 Key Vault 应用适当的访问控制来确保组织的安全，并在不需要应用这些控制时，避免为用户造成阻碍。
有关详细信息，请参阅条件访问概述
特权访问
授权可确定调用方能够执行的操作。 Key Vault 中的授权针对管理平面使用 Azure 基于角色的访问控制 (Azure RBAC)，针对数据平面则使用 Azure RBAC 或 Azure Key Vault 访问策略。
可以通过两个接口或平面访问保管库。 这些平面为管理平面和数据平面。
- 管理平面是管理 Key Vault 本身的地方，也是用于创建和删除保管库的接口。 还可以读取密钥保管库属性并管理访问策略。
- 数据平面支持处理密钥保管库中存储的数据。 可以添加、删除和修改密钥、机密及证书。
应用程序通过终结点访问平面。 两个平面的访问控制独立运行。 若要授权应用程序使用密钥保管库中的密钥，请使用 Azure RBAC 或 Key Vault 访问策略授予数据平面访问权限。 若要授予用户对 Key Vault 属性和标记的读取访问权限，但不授予对数据（密钥、机密或证书）的访问权限，请使用 Azure RBAC 来授予管理平面访问权限。
下表显示了用于管理平面和数据平面的终结点。
| 访问平面 | 访问终结点 | 操作 | 访问控制机制 |
|---|---|---|---|
| 管理平面 | 由世纪互联运营的 Microsoft Azure： management.chinacloudapi.cn:443 |
创建、读取、更新和删除密钥保管库 设置密钥保管库访问策略 设置密钥保管库标记 |
Azure RBAC |
| 数据平面 | 由世纪互联运营的 Microsoft Azure： <vault-name>.vault.azure.cn:443 |
密钥：加密、解密、包装密钥、解包密钥、签名、验证、获取、列出、创建、更新、导入、删除、恢复、备份、还原、清除 证书：管理联系人、获取颁发者、列出颁发者、设置颁发者、删除颁发者、管理颁发者、获取、列出、创建、导入、更新、删除、恢复、备份、还原、清除 机密：获取、列出、设置、删除、恢复、备份、还原、清除 |
Key Vault 访问策略或 Azure RBAC |
管理对 Key Vault 的管理访问权限
在资源组中创建密钥保管库时，使用 Microsoft Entra ID 管理访问权限。 授予用户或组管理资源组中的密钥保管库的权限。 可以通过分配适当的 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 软删除概述。
在保管库中更新/删除/创建对象时，你还应定期备份保管库。