你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

将您的 Azure 密钥保管库 进行安全防护

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

本文中的安全建议实施零信任原则：“显式验证”、“使用最低特权访问”和“假设违规”。 有关全面的零信任指南，请参阅 零信任指南中心。

本文提供了有助于保护 Azure 密钥保管库 部署的安全建议。

特定于服务的安全性

Azure 密钥保管库 具有与保管库体系结构相关的独特安全注意事项，以及合理使用服务来存储加密资料。

  • 分别为每个应用程序、区域和环境使用一个 密钥保管库：为开发环境、预生产环境和生产环境创建单独的 密钥保管库，以减少违规的影响。

    密钥保管库为存储的机密定义安全边界。 将机密分组到同一保管库会增加安全事件的冲击半径，因为攻击可能能够跨关注点访问机密。 若要缓解跨关注点访问机密这一情况，请考虑特定应用程序应有权访问哪些机密，然后根据此描述分离密钥保管库。 将密钥保管库按应用程序分离是最常见的界限。 但是，对于大型应用程序（例如，每组相关服务），安全边界可能更为精细。

  • 在多租户解决方案中为每个租户使用一个 密钥保管库：对于多租户 SaaS 解决方案，请为每个租户使用单独的 密钥保管库 来维护数据隔离。 此方法提供客户数据和工作负载的安全隔离。 有关更多信息，请参阅 多租户和 Azure 密钥保管库。

  • 请勿将密钥保管库用作客户或服务配置的数据存储：服务应将Azure 存储用于静态加密或Azure 应用程序配置。 对于配置方案，这些选项的性能更高。

  • 不要将证书（客户或服务拥有）存储为机密：将服务拥有的证书存储为密钥保管库证书，并将其配置为自动轮换。 有关详细信息，请参阅 Azure 密钥保管库：证书 和 了解 Azure 密钥保管库中的自动轮换。

  • 不要将客户内容存储在密钥保管库中：密钥保管库不是数据存储，也不会构建为像数据存储一样缩放。 请改用Azure Cosmos DB或Azure 存储。 想要自带密钥（BYOK）进行静态加密的客户可以将包装密钥存储在Azure 密钥保管库中，并将其用于加密Azure 存储中的数据。

网络安全

减少网络暴露对于保护 Azure 密钥保管库 免受未经授权的访问至关重要。 根据组织的要求和用例配置网络限制。 有关详细信息和分步配置说明，请参阅 为 Azure 密钥保管库 配置网络安全。

这些网络安全功能从限制最多的功能到限制最少的功能依次列出。 选择最适合组织用例的配置。

  • 禁用公用网络访问并仅使用专用终结点：部署 Azure 专用链接以建立从虚拟网络到 Azure 密钥保管库 的专用接入点，并防止对公共 Internet 公开。 禁用公共访问会阻止数据平面上的连接；保管库的公共 DNS 记录根据设计仍然可以解析（请参阅 私钥保管库的公共 DNS 可见性）。 有关实施步骤，请参阅将 密钥保管库 与 Azure 专用链接集成。

  • 启用 密钥保管库 防火墙：限制对公共静态 IP 地址或虚拟网络的访问。 有关完整详细信息，请参阅 “配置网络安全：防火墙设置”。

    • 一些客户场景要求受信任的 Microsoft 服务绕过防火墙，在这种情况下，可能需要将保管库配置为允许受信任的 Microsoft 服务。 此选项仅允许“受信任的服务”表中的服务；未列在该列表中的 Microsoft 服务（例如 Azure DevOps）仍需要防火墙 IP 规则、虚拟网络规则或专用终结点。

  • 使用网络安全外围：为部署在组织的虚拟网络外围和/或公共静态 IP 地址外部的 PaaS 资源（例如 Azure 密钥保管库、Azure 存储和 SQL 数据库）定义逻辑网络隔离边界。 有关完整详细信息，请参阅 “配置网络安全：网络安全外围”。

    • publicNetworkAccess: SecuredByPerimeter 覆盖“允许受信任的 Microsoft 服务绕过防火墙”设置，这意味着某些依赖信任的场景将无法正常工作。

  • 对客户端强制实施 TLS 版本控制：Azure 密钥保管库支持 TLS 1.2 和 1.3。 由于密钥保管库前端是一项多租户服务，来自不同客户的保管库可以共享相同的公共 IP 地址，因此，每个 HTTPS 请求都会独立进行身份验证和授权。 客户端参与 TLS 协商，因此请将客户端固定到 TLS 1.2 或 1.3，以确保每个连接都使用相应的保护级别。 有关更多信息，请参阅密钥保管库 日志记录，其中提供了用于监视客户端所用 TLS 版本的 Kusto 示例查询。

标识和访问管理

Azure 密钥保管库 使用 Microsoft Entra ID 进行身份验证。 访问通过两个接口进行控制：控制平面（用于管理 密钥保管库 本身）和数据平面（用于使用密钥、机密和证书）。 有关访问模型和终结点的详细信息，请参阅 用于 密钥保管库 数据平面操作的 Azure RBAC。

  • 启用托管标识：对所有与 Azure 密钥保管库 的应用和服务连接使用 Azure 托管标识来消除硬编码凭据。 托管标识有助于保护身份验证，同时不再需要显式凭据。 有关身份验证方法和方案，请参阅 Azure 密钥保管库 身份验证。

  • 使用基于角色的访问控制：使用 Azure 基于角色的访问控制 (RBAC) 来管理对 Azure 密钥保管库 的访问。 有关详细信息，请参阅用于 密钥保管库 数据平面操作的 Azure RBAC。

    RBAC 权限模型允许为持久访问分配保管库级别的角色，并为特权操作分配符合条件的 (JIT) 角色。 对象范围分配仅支持读取操作；而管理操作（例如：网络访问控制、监视和对象管理）需要保管库级别的权限。 若要跨应用程序团队进行安全隔离，请为每个应用程序使用一个 密钥保管库。

  • 分配实时（JIT）特权角色：使用 Azure Privileged Identity Management （PIM）为 密钥保管库 的管理员和操作员分配符合条件的 JIT Azure RBAC 角色。 有关详细信息，请参阅Privileged Identity Management（PIM）概述。

  • 启用 Microsoft Entra 条件访问策略：密钥保管库 支持 Microsoft Entra 条件访问策略，根据用户位置或设备等条件应用访问控制。 有关详细信息，请参阅条件访问概述。

  • 应用最小特权原则：限制具有管理角色的用户数，并确保仅向用户授予其角色所需的最低权限。 有关详细信息，请参阅 使用最低特权原则增强安全性。

数据保护

保护 Azure 密钥保管库 中存储的数据需要启用软删除、清除保护并实现加密材料的自动轮换。

日志记录和监控

全面的日志记录和监视功能可检测可疑活动和符合审核要求。

合规性和治理

定期合规性审核和治理策略可确保 密钥保管库 部署符合安全标准和组织要求。

备份和恢复

定期备份可确保业务连续性并防止数据丢失，防止意外删除或恶意删除数据。

  • 为 Azure 密钥保管库 启用本机备份：配置并使用 Azure 密钥保管库 本机备份功能来备份机密、密钥和证书，从而确保可恢复性。 有关详细信息，请参阅Azure 密钥保管库备份。

  • 确保备份无法重新创建的机密：备份无法从其他源重新创建的 密钥保管库 对象（例如加密密钥）。 有关详细信息，请参阅Azure 密钥保管库备份。

  • 测试备份和恢复过程：若要验证备份过程的有效性，请定期测试 密钥保管库 机密、密钥和证书的恢复效果。 有关详细信息，请参阅Azure 密钥保管库备份。

  • 了解备份复制独立性：从备份还原到另一个保管库的密钥完全独立于原始保管库。 禁用、删除或清除原始密钥不会影响任何还原的副本。 禁用或删除密钥也会使所有依赖数据服务脱机（例如，SQL TDE 数据库变得不可访问，并且具有客户管理的密钥的存储帐户返回错误）。 如果怀疑密钥遭到入侵，请在禁用旧密钥之前轮换到新密钥并迁移依赖服务。 有关完整详细信息，请参阅 备份安全注意事项 和 密钥泄露响应。

有关特定于密钥、机密和证书的安全最佳做法，请参阅：

后续步骤

  • Last updated on