Data Security Encryption Approaches Deliver Varying Levels of Multi-Cloud Data Security

According to Gartner, 81 percent of businesses are adopting a hybrid cloud and multi-cloud strategy. The challenges of protecting data and using encryption across public/private cloud, SaaS, and on-premises environments increase complexity, cost and security risk. New data security encryption technologies make it possible for organizations to gain the benefits of the public cloud while maintaining control over sensitive and private data, critical to securing public cloud deployments and successful digital transformation.

There is a range of encryption approaches leveraging the data security functions of public cloud providers to address public cloud data protection across multiple clouds.

Cloud-Native Encryption

Cloud-native encryption relies on the cloud provider to secure data and is typically offered as the default data encryption scheme. Under this approach, cloud providers generate and own the keys for encrypting data at rest in the cloud. This approach is easiest to implement and has the benefit of integration with other cloud-native services, but it does not offer customers any control or management of the encryption keys. It comes with a number of security downsides, including:

1. The cloud provider has access to the encryption keys, and thus the data stored in the cloud.
2. Customers are not able to delete keys and remove access immediately when needed, for example if there is a breach and access needs to be cut off for compliance.
3. If a key is lost, the customer has no way to recover the key or ever access their data.
4. Customers cannot use the same key to encrypt different blocks of data. For example, they may need to encrypt different data under the same key so they can act on that data in a consistent way.
5. Customers do not have a consistent way of setting fine-grained controls over key management policies across multi-cloud.
6. Customers do not get a single pane of glass for multi-cloud key management. The policy framework and auditing will be different for every cloud.

Cloud Platform Key Management

Cloud platform key management also lets the cloud provider generate, own and manage the data encryption keys, but using the cloud-native key management service to generate and manage master keys or “key encryption keys” (KEKs). These master keys are used to encrypt the “data encryption keys” (DEKs) to secure the DEKs before they are stored in the cloud. The cloud provider internally manages all the DEKs and performs encryption of the data. This approach offers an additional level of security and control – for example, customers can delete the master keys to prevent anyone from accessing the data in the cloud. While more secure than cloud native encryption, this approach also has some data security red flags, including:

1. If a master key is deleted, there is no way to get that key back. Any data encrypted under that key is lost.
2. The cloud provider still owns the master key and has access to the encrypted data. This requires a level of trust in the cloud provider and its employees that may violate internal security policy and/or external regulations.
3. Deployments storing data across multiple cloud regions cannot use the same key, complicating access for critical applications.

Bring Your Own Key (BYOK)

Bring Your Own Key (BYOK) is a commonly used method to enhance security in the public cloud. Under this approach, customers bring or import their own master key, which the cloud provider stores in their key management system (KMS). The cloud KMS generates many DEKs to encrypt cloud data and protects the DEKs by wrapping them with the customer’s master key.

The approach allows customers to retain ownership of the master key, addressing some of the shortcomings of cloud platform key management. If a key needs to be deleted to stop a breach in progress, it can be imported back into the cloud KMS later to reclaim the data. If the stored master key is ever lost, a copy is available so the customer can retrieve their data. The same key can be used across multiple accounts and regions when data residing in different locations needs to be processed by the same application. These capabilities can, however, add management complexity. While more secure than cloud platform key management, BYOK still gives the cloud provider access to the master keys, so the compliance and security risks of a third-party having access remains.

Bring Your Own KMS (BYOKMS)

Bring your own KMS (BYOKMS) offers one of the most secure ways to protect keys and cloud data, while also providing strong integration with cloud-native services. Under this approach, a key management service entirely outside of the cloud provider’s platform generates and manages the master keys used by the cloud provider. The master keys are always securely stored in the customer’s own off-cloud KMS/HSM. Unlike BYOK, the cloud provider never has access to the master key. For in-cloud encryption/decryption of data, the encryption keys get wrapped/un-wrapped with a customer’s own master key. Access to the master key can be revoked at any time, making data immediately inaccessible in the cloud platform. Although this solution offers customers complete and real-time control over their master keys, the cloud provider still has access to the data encryption keys.

Bring Your Own Encryption

Bring your own encryption is the most secure way to protect keys and cloud data but may affect integration with other cloud-native services. This approach provides the same level of protection offered in a datacenter, but with the ease of operations and scalability of the cloud. Customers provide all data encryption keys and perform encryption of the data in the cloud.

The obstacle to this approach has been that data encrypted by customer-owned data encryption keys cannot be freely consumed by other cloud-native services. These services are unable to decrypt the data since they do not have access to the data encryption keys. An effective bring your own encryption solution requires four primary components:

1. A customer-operated key management and encryption solution running on the chosen public cloud platform.
2. A customer-operated key management system running on premises to provide client-side encryption of data before it is sent to and stored in the cloud.
3. Integration between the customer’s cloud KMS and on-premise KMS so they can share keys and encrypt/decrypt data that has been encrypted/decrypted by the other KMS.
4. Integration between the customer’s cloud KMS and the cloud platform’s native KMS. When client-side encrypted data stored in the cloud needs to be consumed by cloud-native services, the customer’s KMS should transparently transform data from client-side encryption (DEK owned by customer) to server-side encryption (KEK owned by the cloud provider). Cloud-native services can then consume the data and perform required operations before the data is re-encrypted using the customer’s keys.

Developing a strategy to deal with multi-cloud data security is now a necessity. Most likely, your existing data security deployment was built to protect on-premises data within the control of a traditional data center. As more infrastructure, workloads and data move to the cloud, it’s important to rethink data security as part of the migration process. The approach that most organizations have taken to protect on-premises data does not easily migrate to public cloud infrastructure and workloads. Keep in mind that different workloads and classifications of data can use different data security approaches (Cloud-native, BYOK, BYOKMS, BYOE) to reach the best balance of cloud integration and risk mitigation. For many organizations, bring your own KMS, and bring your own encryption are new approaches that can help simplify the process of migrating data to the public cloud and managing multiple cloud data security systems.