设计用于管理机密、密钥和证书的解决方案
在 Azure 中,加密密钥可以由平台管理,也可以由客户管理。
平台管理的密钥(PMK)是完全由 Azure 生成、存储和管理的加密密钥。 客户不会与 PMK 交互。 例如,用于 Azure 数据静态加密的密钥默认就是 PMK。
另一方面,客户管理的密钥(CMK)是可以读取、创建、删除、更新和/或由一个或多个客户管理的密钥。 存储在客户拥有的密钥保管库或硬件安全模块 (HSM) 中的密钥是 CMK。 创建自己的密钥 (BYOK) 是一种 CMK 方案,在其中,客户将密钥从外部存储位置导入(引入)Azure 密钥管理服务(请参阅 Azure 密钥保管库:创建自己的密钥规范)。
特定类型的客户管理的密钥是“密钥加密密钥”(KEK)。 KEK 是一种主密钥,用于控制对一个或多个本身已加密的加密密钥的访问。
客户管理的密钥可以存储在本地,但更常见的是存储在云密钥管理服务中。
Azure 密钥管理服务
Azure 提供了多种用于在云中存储和管理密钥的选项,包括 Azure Key Vault、Azure 托管 HSM、专用 HSM 和付款 HSM。 这些选项在 FIPS 合规性级别、管理开销和目标应用方面有所不同。
Azure Key Vault(标准层):FIPS 140-2 级别 1 验证的多租户云密钥管理服务,该服务还可用于存储机密和证书。 Azure 密钥保管库中存储的密钥受软件保护,可用于静态加密和自定义应用程序。 Key Vault 提供新式 API,以及区域部署和与 Azure 服务的集成范围最广。 有关详细信息,请参阅关于 Azure 密钥保管库。
Azure Key Vault (高级层):FIPS 140-2 级别 2 验证的多租户 HSM 产品/服务,可用于将密钥存储在安全硬件边界中。 Microsoft 将管理和操作基础 HSM,存储在 Azure 密钥保管库高级层中的密钥可用于静态加密和自定义应用程序。 Key Vault Premium 还提供新式 API 以及区域部署和与 Azure 服务集成的最广度。 有关详细信息,请参阅关于 Azure 密钥保管库。
Azure 托管 HSM:FIPS 140-2 级别 3 验证的单租户 HSM 产品/服务,使客户能够完全控制用于静态加密、无密钥 SSL 和自定义应用程序的 HSM。 客户会收到一个由三个 HSM 分区组成(一起充当一个逻辑高可用性 HSM 设备)的池,该服务通过 Key Vault API 公开加密功能。 Microsoft 将处理 HSM 的预配、修补、维护和硬件故障转移,但无权访问密钥本身,因为该服务在 Azure 的机密计算基础结构中执行。 托管 HSM 与 Azure SQL、Azure 存储和 Azure 信息保护 PaaS 服务集成,并支持 F5 和 Nginx 的无密钥 TLS。 有关详细信息,请参阅什么是 Azure 密钥保管库托管 HSM?
Azure 专用 HSM:FIPS 140-2 级别 3 验证的裸机 HSM 产品/服务,可让客户租用驻留在Microsoft数据中心的常规用途 HSM 设备。 客户拥有 HSM 设备的完整和总所有权,并负责在需要时修补和更新固件。 Microsoft 对该设备不拥有任何权限,也无权访问关键材料,并且专用 HSM 未与任何 Azure PaaS 产品/服务集成。 客户可以使用 PKCS#11、JCE/JCA 和 KSP/CNG API 来与 HSM 交互。 此服务最适合用于传统的直接迁移工作负载、PKI、SSL 卸载和无密钥 TLS(支持的集成包括 F5、Nginx、Apache、Palo Alto、IBM GW 等)、OpenSSL 应用程序、Oracle TDE 和 Azure SQL TDE IaaS。 有关详细信息,请参阅什么是 Azure 密钥保管库托管 HSM?
Azure 付款 HSM:一种通过 FIPS 140-2 第 3 级别、PCI HSM v3 验证的裸机产品/服务,它支持客户租用 Microsoft 数据中心的付款 HSM 设备来进行付款操作,包括付款处理、付款凭据颁发、保护密钥和身份验证数据,以及敏感数据保护。 该服务符合 PCI DSS 和 PCI 3DS。 Azure 付款 HSM 提供单租户 HSM,客户拥有完全管理控制权,并对该 HSM 拥有独占访问权限。 将 HSM 分配给客户后,Microsoft 无权访问客户数据。 同样,在不再需要 HSM 时,客户数据将在解除 HSM 后立即归零并擦除,以确保全面保持数据的隐私性和安全性。 有关详细信息,请参阅关于 Azure 付款 HSM。
有关可在密钥保管库中使用机密、密钥和证书类型的概述,请参阅 Azure Key Vault 密钥、机密和证书概述
使用 Key Vault 的最佳做法
使用单独的密钥保管库
我们的建议是在每个区域中对每个环境(开发、预生产和生产)的每个应用程序使用一个保管库。 这有助于不跨环境和区域共享机密。 它还将减少威胁,以防出现违规。
为什么建议使用单独的密钥保管库
密钥保管库为存储的机密定义安全边界。 将机密分组到同一保管库会增加安全事件的冲击半径,因为攻击可能能够跨关注点访问机密。 若要缓解跨关注点的访问,请考虑特定应用程序 应 有权访问哪些机密,然后根据此描述分隔密钥保管库。 将密钥保管库按应用程序分离是最常见的界限。 但是,对于大型应用程序(例如,每组相关服务),安全边界可能更为精细。
控制对保管库的访问权限
证书、连接字符串和密码等加密密钥和机密敏感且业务关键。 需要通过仅允许授权的应用程序和用户来保护对密钥保管库的访问。 Azure Key Vault 安全功能 概述了 Key Vault 访问模型。 它说明了身份验证和授权。 它还介绍了如何保护对密钥保管库的访问。
关于保管库访问控制的建议如下:
- 锁定对订阅、资源组和密钥保管库的访问权限(基于角色的访问控制(RBAC))。
- 为每个保管库创建访问策略。
- 使用最低特权原则来授予访问权限。
- 启用防火墙和虚拟网络服务终结点。
为保管库启用数据保护
启用清除保护功能,以防止在启用软删除后,机密和密钥保管库遭到恶意或意外删除。
有关详细信息,请参阅 Azure Key Vault 软删除概述
启用日志
备份
清除保护可防止恶意和意外删除保管库对象,最长可达 90 天。 在清除保护不是可能的选项的情况下,我们建议备份保管库对象,这些对象无法从保管库中生成的加密密钥等其他源重新创建。
有关备份的详细信息,请参阅 Azure Key Vault 备份和还原
多租户解决方案和密钥保管库
多租户解决方案基于一种体系结构构建,其中组件用于为多个客户或租户提供服务。 多租户解决方案通常用于支持软件即服务(SaaS)解决方案。 如果要构建包含 Key Vault 的多租户解决方案,请查看 Multitenancy 和 Azure Key Vault。