Want Data Security in the Public Cloud? Bring Your Own Encryption Keys
We look at why using encryption keys that you generate and use yourself is the only way to guarantee data security in a public cloud, and how it helps achieve compliance.
Join the DZone community and get the full member experience.Join For Free
As application development teams adopt a cloud-native model, they use container platforms to deploy apps as independent but interoperable microservices within a broad microservices architecture. Being portable, easily duplicated and scaled, containers promote DevOps efficiencies that free developers to focus more on creating value for end users.
Almost 85% of professionals in an Intel Security survey reported storing some or all of their sensitive data in the public cloud (1). In such situations, to protect against unauthorized access by both outsiders breaking into cloud systems and operators inside the cloud vendor organization, app data security must involve pervasive encryption.
Using encryption keys that you generate and use yourself is the only way to guarantee data security in a public cloud. Beyond data security, in evaluating what security cloud providers offer, it helps to have a guide to cloud security more broadly.
For Data Security, Bring Your Own Encryption Keys
Data associated with cloud applications may move in and out of object stores and data services, and even across multiple clouds. For a DevOps team, the only way to maintain data securely across environments is to have full control over encryption keys. A bring-your-own-keys (BYOK) model gives the team continuous ownership and control of data both on-premise and in the cloud. It's also well-suited to enterprises that have their own key management system or hardware security module, which cloud platform providers should provide ways to integrate.
In the BYOK model, a key management system that's on-premise generates a key and passes it to the cloud provider's key management service. Since the root keys never leave the boundaries of the key management system, the cloud provider never touches them. This gives the home organization to audit all key-related activities. Deciding not to continue running workloads at a service provider requires simply deleting keys.
This approach covers data-at-rest encryption across storage types such as block, object, and data services. Encryption software writes an encrypted version of the data to the data store and then decrypts the data upon retrieval. For data in transit, Transport Layer Security/Secure Sockets Layer (TLS/SSL) with the ability to manage SSL certificates is an excellent choice to secure communication and transfer.
Data Security and GDPR?
Key control is necessary to run and scale containerized workloads that require data locality. For example, sovereignty requirements may mean certain kinds of data can't leave the country in which they originated. To comply with General Data Protection Regulations (GDPR), for example, you will need to manage the encryption keys for your workload so that the data can only be decrypted in the country where a workload was placed.
Together with the key management system, a container orchestration system like Kubernetes can help verify that keys are not usable outside the geographical location where they're supposed to be available. Setting key management policies within Kubernetes can scale security policies as new containers deploy.
To ensure cloud-based workloads are properly encrypted, expect cloud providers to offer BYOK options. Ask a provider about encrypting data at rest and data in motion. Ideally, a provider should support encrypting container images in a private repository. In any case, managing your own keys will keep data from being decrypted unless, when, and where you say so.
1 "Building Trust in a Cloudy Sky: The state of cloud adoption and security," Intel Security, February 2017, https://www.mcafee.com/us/solutions/lp/cloud-security-report.html
Published at DZone with permission of Doug Paris White, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.