In the Secure a cloud-native application on IBM Cloud for Financial Services code pattern, I showcase how to integrate IBM Cloud Hyper Protect Services in the Example Bank application to encrypt and secure data. To understand the process of integration, you must understand different terminologies such as bring your own key (BYOK), keep your own key (KYOK), key ceremony, database as a service (DBaaS) and envelope encryption. Although you can find information about these key concepts about the Hyper Protect Services scattered across the web, this blog post is my attempt to bring them together into one single point of reference.
Sensitive data should be stored encrypted in the cloud. However, the key that is used to encrypt and decrypt the data should also be protected. Setting up on-premises hardware security modules (HSMs) can sometimes be hard to manage if you’re not already familiar with it. An inexpensive solution is to use cloud-based storage, but that has its own challenges. In this approach, you can’t be sure that the data is secured as the key that is used to encrypt the data, also known as the data encryption key (DEK), is spread in multiple computers.
The solution that combines ease of use and cost effectiveness is to use a key management service (KMS) such as IBM Cloud Hyper Protect Crypto Services (HPCS). HPCS provides access to a FIPS 140-2 Level 4 HSM that protects the customer master key and all other keys that are used to encrypt data at rest in IBM Cloud Object Storage, IBM Cloud Hyper Protect DBaaS, IBM Cloud Block Storage, and similar.
Let’s go through some key terminologies that are used by the Hyper Protect Services.
IBM Key Protect and HPCS use envelope encryption to protect data. Envelope encryption is a practice of encrypting data with a DEK and then wrapping the DEK with a root key that you can fully manage by using crypto services. In HPCS, root keys are also encrypted by the master key that is uploaded by your administrators during the key ceremony process. The difference is that in Key Protect, the root key wraps the DEK, whereas in HPCS, the master key protects the root key, which is used to wrap the DEK to provide an extra layer of security.
It’s also a best practice to regularly rotate the keys that you use to encrypt. Root keys can be rotated manually or you can schedule the rotation (if you are the owner). To learn more about rotation, read the Key Protect product documentation.
IBM Key Protect and BYOK
Key Protect is a multitenant KMS that helps you to bring your keys to the cloud (BYOK) and manage them by using an IBM-controlled HSM. IBM provides operational assurance that it does not access the keys. Hence, the master key that you use to wrap the root keys is owned by IBM.
IBM Cloud Hyper Protect Crypto Services and KYOK
KYOK with HPCS is a dedicated KMS, which allows tenants to own your key (KYOK), built on tenant-controlled FIPS 140-2 Level 4 HSMs (the highest available certification). HPCS is built on IBM LinuxONE technology. In this implementation, IBM cannot access the keys. The key owned by the tenant is created and uploaded during the key ceremony process. In this implementation, the master key is created, in part, by customer representatives to initialize the HSM, thus maintaining complete control over the master key.
Key ceremony in IBM Cloud Hyper Protect Crypto Services
The key ceremony is a process of loading your own master key to your service instance (cloud account). During the initialization process, the HPCS sets up signature keys for crypto unit administrators, which ensures that the master key parts are loaded into the HSM without interception. Each master key has at least two key parts and each key part can be own by a custodian. To load the master key to the service instance, master key custodians must load their key parts separately by using their own administrator signature keys.
A signature key is composed of an asymmetric key pair, private and public. The private part is owned by the crypto unit administrator, while the public part is placed in a certificate that is used to define an administrator and never leaves the crypto unit. This design ensures that no one can get full access of the master key, even the crypto unit administrators.
By using the IBM Cloud Trusted Key Entry (TKE) CLI plug-in with the IBM Cloud CLI, you can create crypto units, add signatures, load master key parts, and commit and activate them.
Securing your data in IBM Cloud Hyper Protect DBaaS
Hyper Protect DBaaS is a public multitenant cloud DBaaS that implements security at all levels, such as workload isolation, data encryption (BYOK or KYOK), and identity and administration access control. Hyper Protect DBaaS for PostgreSQL uses the following methods to protect your data:
- Built on IBM Secure Service Container technology
- All Hyper Protect DBaaS for PostgreSQL connections use TLS/SSL encryption for data in transit. The current supported version of this encryption is TLS 1.2.
- Built in data encryption and scales vertically for greater performance.
- Integration with key management services that lead to higher data security: BYOK with Key Protect, and KYOK with HPCS.
- All Hyper Protect DBaaS for PostgreSQL storage is provided on storage encrypted with LUKS using AES-256. The default keys are managed within the locked down environment within secure service containers.
In this blog post, you got to know about key concepts and terminologies that are used to secure your data and applications such as BYOK, KYOK, and envelope encryption. You also learned about different IBM Cloud services that can help you protect your applications and data. Next, get hands-on experience with integrating Hyper Protect Services to encrypt your application data by following the steps of my code pattern: Secure a cloud-native application on IBM Cloud for Financial Services.