设计用于管理机密、密钥和证书的解决方案
在 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。