常见问题: 安全性与合规性
阅读以获取有关 IBM Cloud® Hyper Protect Crypto Services中数据安全性问题的答案。
如何管理用户对服务实例的访问权? IBM 是否有权访问我的实例?
IBM 或任何第三方用户都无权访问您的服务实例或密钥。 通过将主密钥装入到服务实例，可以获取云 HSM 的所有权，并且可以独占控制由 Hyper Protect Crypto Services管理的资源。
Hyper Protect Crypto Services 遵循 IBM Cloud Identity and Access Management (IAM) 标准。 您可以 通过分配不同的 IAM 角色来管理用户访问权 和 授予对特定密钥的访问权 以启用更精细的访问控制。
IBM 如何为服务初始化 (密钥仪式) 提供独特且安全的流程?
Hyper Protect Crypto Services 在服务初始化过程中为加密单元管理员设置签名密钥，以确保在不进行拦截的情况下将主密钥部件装入 HSM。
主密钥由两个或三个主密钥部分组成。 每个主密钥管理人都拥有一个加密的主密钥部件。 在大多数情况下，主密钥管理人也可以是加密单元管理员。 为了将主密钥装入到服务实例，主密钥管理人需要使用自己的管理员签名密钥单独装入其密钥部件。
签名密钥由非对称密钥对组成。 签名密钥的专用部分由加密单元管理员拥有，而公用部分放在用于定义管理员的证书中，并且从不离开加密单元。
此设计确保任何人都无法获得主密钥的完全访问权，即使是加密单元管理员也是如此。
什么是 140-2 FIPS 4 级认证？如何对其进行验证？
联邦信息处理标准 (FIPS) 出版物 140-2 是美国政府用于批准加密模块的计算机安全标准。
FIPS 140-2 1 级、2 级、3 级和 4 级有什么差别？
-
1 级：最低安全级别。 在安全级别 1 的加密模块中，除了对生产级组件的基本需求外，不需要特定的物理安全机制。
-
级别 2: 通过要求显示篡改证据的功能部件 (包括防篡改涂层或封条) 来改进级别 1 加密模块的物理安全机制，这些涂层或封条必须损坏才能在模块内实现对明文密钥和关键安全参数 (CSP) 的物理访问，或者在盖或门上设置防撬锁以防止未经授权的物理访问。 安全级别 2 至少要求基于角色的认证，即加密模块对操作员拥有特定角色并执行一组对应服务的权限进行认证。
-
级别 3: 提供检测和响应对加密模块的物理访问，使用或修改的尝试的高概率。 物理安全机制可以包括使用强机柜和篡改检测和响应电路，当打开加密模块的可移动外盖或门时，将所有纯文本 CSP 归零。 安全级别 3 需要基于身份的认证机制，从而增强针对安全级别 2 指定的基于角色的认证机制所提供的安全性。
-
4 级：最高安全级别。 在此安全级别，物理安全性机制围绕加密模块提供完整的保护边界，旨在检测所有未授权的物理访问尝试并对其做出响应。 从任何方向穿透加密模块机柜都有很高的概率被检测到，从而导致所有纯文本 CSP 立即归零。
安全级别 4 加密模块适用于没有物理保护的环境中的操作。 安全级别 4 也会防止因为环境状况不利或者模块电压和温度波动到正常运作范围之外而破坏加密模块的安全性。 攻击者可能通过故意偏离正常运作范围来使加密模块的防御机制失效。
加密模块需要包括用于检测波动和删除 CSP 的特殊环境保护功能，或者执行环境故障测试，以确保模块不受正常运作范围之外波动的影响，这类波动会破坏模块的安全性。 在此安全级别，物理安全性机制围绕加密模块提供完整的保护边界，旨在检测所有未授权的物理访问尝试并对其做出响应。
Hyper Protect Crypto Services 是公共云市场中唯一基于 HSM (旨在满足 FIPS 140-2 级别 4 认证需求) 构建的云 HSM。 该证书列示在 加密模块验证程序(CVMP)已验证模块列表上。
如何了解 Hyper Protect Crypto Services KYOK 的密钥层次结构?
下表列出了 Hyper Protect Crypto Services“保留自己的密钥”(KYOK) 功能所需的密钥。
| 密钥类型 | 个算法 | 函数 |
|---|---|---|
| 签名密钥 (signature key) | P521 椭圆曲线 (EC) | 当您 初始化 Hyper Protect Crypto Services 实例 以装入主密钥时，需要使用签名密钥向加密单元发出命令。 签名密钥的专用部分用于创建签名并存储在客户端。 公共部件放置在存储在目标加密单元中的证书中，以定义加密单元管理员。 |
| 主密钥 | 256 位 AES | 您需要将主密钥装入到加密单元以获取云 HSM 的所有权，并拥有用于加密整个加密密钥层次结构的信任根，包括密钥管理密钥库中的根密钥和标准密钥，以及 EP11 密钥库中的 Enterprise PKCS #11 (EP11) 密钥。 根据 用于装入主密钥的方法，主密钥存储在不同的位置。 |
| 根密钥 | 256 位 AES | 根密钥是 Hyper Protect Crypto Services 中的主资源，受主密钥保护。 它们是对称密钥打包密钥，用作信任的根，用于打包 (加密) 和解包 (解密) 存储在数据服务中的其他数据加密密钥 (DEK)。 根密钥加密的这种做法也称为包络加密。 有关更多信息，请参阅 使用包络加密保护数据。 |
| 数据加密密钥 (DEK) | 由数据服务控制 | 数据加密密钥用于加密由其他客户拥有的应用程序或数据服务存储和管理的数据。 您在 Hyper Protect Crypto Services 中管理的根密钥用作包装密钥以保护 DEK。 对于支持集成 Hyper Protect Crypto Services 以进行包络加密的服务，请参阅 将 IBM Cloud 服务与 Hyper Protect Crypto Services 集成。 |
EP11 与 PKCS #11有何不同?
企业 PKCS #11 (EP11) 在概念和功能方面与 PKCS #11 保持一致。 经验丰富的 PKCS #11 开发者可以轻松开始使用 EP11 功能。 但是，它们存在以下主要差异:
- 构建 EP11 是为了通过设计实现高可用性和可伸缩性。
- EP11 是无状态协议，而 PKCS #11 是有状态的。 EP11 的无状态设计允许使用外部密钥库以及缩放到多个后端。
- EP11 over gRPC (GREP11) 定义可在云应用程序中直接使用的网络协议。
有关更多信息，请参阅 将 PKCS #11 API 与 GREP11 API 进行比较。
GREP11 功能支持哪些 EP11 机制?
机制可能因加密卡中的固件级别而异，请参阅 支持的机制。 有关 EP11 机制的更多信息，请参阅 IBM 4768 Enterprise PKCS #11(EP11)Library structure guide 和 IBM 4769 Enterprise PKCS #11(EP11)库结构指南。
Hyper Protect Crypto Services 符合哪些合规标准?
Hyper Protect Crypto Services 满足全球，行业和区域合规标准 (例如 GDPR，HIPAA 和 ISO) 的控制。 作为 Hyper Protect Crypto Services使用的 HSM，IBM 4768 或 IBM 4769 加密卡也通过 Common Criteria EAL4 和 FIPS 140-2 Level 4 认证。 有关更多信息，请参阅 安全性与合规性。
我是否可以监视服务实例?
可以，您可以通过 IBM Cloud Activity Tracker 来监视服务实例的状态。