Data encryption at rest
Protecting data against unauthorized disclosure, modification or destruction throughout the data lifecycle is of paramount importance in the IBM Cloud for Financial Services. Cryptographic controls must be in place in all regions and availability zones to protect the confidentiality and integrity of data. Effective key management enables you to keep control of your own master and root encryption keys, that protect the keys used for data at rest encryption.
Data encryption at rest in IBM Cloud
Within IBM Cloud, you must encrypt data at rest using encryption keys that you manage. For systems having a high security categorization you must use Hyper Protect Crypto Services to manage encryption keys. Hyper Protect Crypto Services is a single tenant key management service and dedicated hardware security module (HSM) partition. Hyper Protect Crypto Services is the only service in the cloud industry that's built on FIPS 140-2 Level 4-certified hardware.
With Hyper Protect Crypto Services you can take ownership of the cloud HSM to fully manage your encryption keys and to perform cryptographic operations by using the Keep Your Own Key (KYOK) concept. This means you have full control and authority over encryption keys. No one except you (not even IBM) has access to your encryption keys.
Some organizations require the use of a dedicated HSM where the device can be initialized by their cryptography specialists. We offer Hyper Protect Crypto Services with Bring Your Own HSM to enable those organizations to manage their HSM over the network at a remote location. This solution does uses the Hyper Protect Crypto Services key manager that has been Financial Services Validated but as IBM has no control over the Bring Your Own HSM, this solution as a whole isn't Financial Services Validated.
Where you have systems not requiring a high security categorization, you have the option of using IBM® Key Protect for IBM Cloud® for your key management. Key Protect is a multi-tenant cloud service using the Bring Your Own Key (BYOK) concept. Many capabilities are common between Hyper Protect Crypto Services and Key Protect but the underlying security implementation is different as shown in Table 1.
Hyper Protect Crypto Services | Hyper Protect Crypto Services with Bring Your Own HSM [1] | Key Protect | |
---|---|---|---|
Cloud REST API | X | X | X |
Multi-Tenant Key Manager | X | ||
Provider-managed HSM | X | ||
Single-Tenant Key Manager | X | X | |
Key Manager in Secure Enclave | X | X | |
FIPS 140-2 Level 4 HSM | X | ||
Client-managed dedicated HSM partition | X | ||
HSM Smartcard key generation ceremony | X | ||
EP11 (PKCS#11) API | X | ||
MZR Availability | Selected | Selected | All |
Support for Satellite location | X | ||
UKO Key Generation [2] | X |
Note 1: Capability depends on functionality of Bring Your Own HSM.
Hyper Protect Crypto Services and Key Protect are both Financial Services Validated with the same level of security assurance. The strength of the security in Hyper Protect Crypto Services, as a single-tenant service with smartcards for the master key ceremony, is higher than Key Protect as a multi-tenant service.
Whether you use Hyper Protect Crypto Services or Key Protect, you must ensure that:
- Keys are created for a single purpose, and dedicated encryption keys are unique per consumer.
- Keys have a lifecycle that is defined and are rotated periodically based on IBM Cloud Framework for Financial Services controls.
- Recovery functions, if used, are accessible only by authorized personnel.
Setting up Hyper Protect Crypto Services
For the provisioning and configuration of an instance of Hyper Protect Crypto Services see Getting started with Hyper Protect Crypto Services for specific instructions.
For the highest level of security, you should use smart cards when initializing Hyper Protect Crypto Services. See Initializing service instances by using smart cards and the Management Utilities for more details.
For more background information and considerations, see:
- Components and concepts
- Bringing your encryption keys to the cloud
- Master key rotation
- Root key rotation
Continue with completing integration of Hyper Protect Crypto Services with the IBM Cloud services that are part of your deployment. Block Storage for VPC and Object Storage are common services that need data encrypted at rest, but there is an extended set of services that integrate. The Hyper Protect Crypto Services documentation includes a catalog of IBM Cloud services to integrate.
The master key within the Hyper Protect Crypto Services HSM and the root keys contained within Hyper Protect Crypto Services key manager need rotating with a new key at the frequency determined by your policy. If you don't have a policy, start with a 12 month rotation period. Consult the master key rotation process and root key rotation process for specific instructions.
For more background information and considerations, see:
Setting up Hyper Protect Crypto Services with Bring Your Own HSM
As an alternative to using the in-built FIPS 140-2 Level 4 Cloud HSM for Hyper Protect Crypto Services, there is an option to Bring Your Own Hardware Security Module (BYOHSM). Details on the integration and the configuration is contained in the Introducing Bring Your Own HSM documentation.
The Bring Your Own HSM option provides you with the the benefit of being able to physically initialize your own HSM device. We understands for some organizations this is a mandatory requirement and this solution will meet that requirement.
However to operational characteristics of Hyper Protect Crypto Services changes. Here are a few things to keep in mind when selecting to use the Bring Your Own HSM option:
- The Bring Your Own HSM may be FIPS 140-2 Level 3, which is a lower security level than the HSM used as default by Hyper Protect Crypto Services.
- With the standard Hyper Protect Crypto Services solution there is negligible latency between the Hyper Protect Crypto Services key manager and Cloud HSM as they're within the same system. Ensure you assess any impact from increased latency between the HPCS key manager and your Bring Your Own HSM.
- With the additional network hops between the Hyper Protect Crypto Services instance and the Bring Your Own HSM there may be a reduction in workload resilience. Review and understand the impact this change may have to your workload resiliency.
- Ensure you identify an effective cold start sequence for HPCS connecting to your Bring Your Own HSM and the services that depend on Hyper Protect Crypto Services key management. For example, if the the connection of HPCS to the Bring Your Own HSM is through a firewall appliance using block storage with a key from Hyper Protect Crypto Services, you may get into a situation where the Bring Your Own HSM can't communicate from the firewall not being able to decrypt the block storage. This is otherwise known as the "keys locked in the car" scenario.
For more background information and considerations, see:
Setting up Key Protect
For the provisioning and configuration an instance of Key Protect, consult the Getting started tutorial for specific instructions.
Continue with completing integration of Key Protect with the IBM Cloud services that are part of your deployment. Block Storage for VPC and Object Storage are common services that need data encrypted at rest, but there is an extended set of services that integrate. The Key Protect documentation includes a catalog of IBM Cloud services to integrate.
The root keys contained within Key Protect need rotating with a new key at the frequency determined by your policy. If you don't have a policy, start with a 12 month rotation period. Consult the root key rotation process for specific instructions.
For more background information and considerations, see:
Data encryption at rest in Satellite location
In an IBM Cloud Satellite location, the cloud services must use Key Protect on Satellite to connect to a user owned and managed hardware security module (HSM) for the encryption of data at rest. Consult About Key Protect on Satellite for specific information on the dedicated service.
You are responsible for providing the underlying virtual and physical storage that will be accessed by Satellite storage in your on-premises Satellite location. You should ensure your underlying physical storage is encrypted using keys managed by an on-premises FIPS 140-2 level 2 or higher hardware security module (HSM).
Related controls in IBM Cloud Framework for Financial Services
The following IBM Cloud Framework for Financial Services controls are most related to this guidance. However, in addition to following the guidance here, do your own due diligence to ensure you meet the requirements.
Family | Control |
---|---|
System and Communications Protection (SC) | SC-12 Cryptographic Key Establishment and Management SC-12 (2) Cryptographic Key Establishment and Management | Symmetric Keys SC-12 (3) Cryptographic Key Establishment and Management | Asymmetric Keys SC-13 Cryptographic Protection SC-28 Protection of Information At Rest SC-28 (1) Protection of Information at Rest | Cryptographic Protection |
In addition, you must follow the guidance found in Appendix A: Cryptographic Requirements within the "Control Implementation Overview Template for Application Providers Using IBM Cloud® Virtual Private Cloud".