From aircraft and car manufacturers to pharmaceutical and high-tech companies, military institutions and suppliers – various industries fear espionage. While most of us are too irrelevant in the global struggle for economic and technological dominance, some companies and institutions are less relaxed. It is a real risk that foreign secret services might steal their business secrets and pass them to competitors.
Can (and should) they move their data to the cloud? How does encryption help them? In the following, we discuss four approaches to handling data-at-rest encryption in the cloud after elaborating on three basic patterns for integrating cloud (storage) services in enterprise application landscapes.
Three Architectural Patterns for Encryption in the Cloud
The first pattern is cloud-storage encryption (Figure 1, left), in which the cloud has one simple purpose: to be a reliable, cost-effective, scalable storage solution. The customers abstain from running VMs in the cloud or building on cloud-native platform-as-a-service (PaaS) services such as Azure Functions or Amazon Textract. All applications run on on-premise virtual machines (VMs). When applications write data to the cloud, the on-premise encryption module encrypts the data before it ends in the cloud.
The encryption module can be as simple as a Java library or, on the other extreme, a Hardware Security Module (HSM) designed to withstand the NSA. With encrypted data at rest in the cloud but no keys, attackers with access to the cloud infrastructure cannot access cloud customer data. All data is safe.
Figure 1 -- Architectural patterns for encryption in the cloud. Green: under the control of the customers. Red: managed and controlled by the cloud provider.
The cloud-workloads-with-own-encryption pattern (Figure 1, middle) tries to achieve the security of the on-premise world while giving up on-premise data centers. In this pattern, the business logic remains on VMs. Customers do not use PaaS services and continue relying on their own encryption module to perform the data-at-rest encryption before writing data to cloud storage.
However, the VMs and the encryption module do not run on-premise but rather in the cloud. Attackers, criminal employees, or governmental agencies with access to the cloud infrastructure can access customer data, but only by extracting information from the VMs. This is a viable but technically more advanced undertaking for encrypting data at rest.
The cloud-workloads-with-cloud-native-encryption pattern combines encryption and using cloud-native PaaS services (Figure 1, right). The motto: benefit from PaaS services for crafting solutions quicker than ever. Consequently, data encryption relies on cloud-native services. In this pattern, cloud customers have to trust their cloud provider to act reasonably and not be forced by governments or law-enforcement agencies to act against their customers. That is an easy assumption for US corporations on Amazon’s AWS, Microsoft’s Azure, or Google’s GCP; for German federal organizations having workload on the German "Bundescloud”; or for Chinese companies running on the Alibaba cloud.
For many other cases, however, this assumption does not hold. To address any skepticism that might hurt their business, cloud providers came up with variants for cloud-native encryption reflecting the criticality of different workloads. The variants are service-managed keys, customer-managed keys, bring-your-own keys, and hold-your-own keys (Figure 2).
Figure 2 -- Key hierarchies and master key management variants for encryption
All four variants encrypt data at rest in the cloud with specific data encryption keys. All use different keys for encrypting different data buckets to reduce the blast radius when a key is leaked. All variants store these data encryption keys in the cloud. What differs is the encryption of the data encryption keys, for which all variants rely on master encryption keys.
Four Approaches to Handling Data-at-Rest Encryption in the Cloud
The four variants for managing the master encryption keys are:
- Service-managed keys (SMK). The cloud encryption service encrypts all users' data (precisely: their data encryption keys) in one service with the same master encryption key. So, there is one key, for example, for the complete storage service or a specific database-as-a-service offering. Cloud providers must ensure that employees or hackers cannot misuse such keys. Customers simply have to trust them. If authorities demand access to the data, cloud providers can decrypt all data.
- Customer-managed keys (CMK) are customer-specific master encryption keys with a twist. In this variant, different cloud customers do not rely on the same master encryption key but can have dedicated ones. All keys stay in the cloud, so cloud employees or authorities might use the keys to decrypt the stored data. However, the hope is that attackers breaking into the cloud fail to get access to all keys. Plus, customer-specific keys allow more sophisticated access control mechanisms because users need access to the data, and they need access to the specific key.
- The bring-your-own key (BYOK) encryption variant is nearly the same as customer-managed encryption keys with one (nearly) neglectable variation: customers create master encryption keys themselves in their own infrastructure; e.g., an on-premise HSM. Then, they load their keys into the cloud. Thus, customers can ensure to create keys without anyone tampering or interfering with the key creation. The disadvantage: the customer has to run and secure its own key creation infrastructure; e.g., by buying, running, and maintaining an HSM. And nothing changes regarding (mis)use of keys by employees or authorities.
- The hold-your-own key (HYOK) encryption variant is the highly appraised solution to protect your data in the cloud against all evil forces. The master encryption key stays on customer infrastructure. Obviously, separating your master key from your data adds an extra level of protection. If the cloud works as designed, the master keys are 100% safe from the authorities and cloud employees. So, the HYOK variant adds additional technical features to make you trust a cloud infrastructure whose owner you cannot trust; e.g., due to the CloudAct. There are just two limitations. First, not all clouds offer such a HYOK feature. GCP, for example, excels in this area, Azure not. Second, a perfect algorithm and a super-save encryption key do not help if attackers (or federal agencies) can circumvent encryption, at least for high-profile cases worth extra effort. How can you be sure that there is no backdoor rerouting traffic of "highly interesting" cloud customers to servers and storage without working encryption?
Figure 3 -- Cloud encryption variants overview
In the end, neither naivete nor paranoia help when deciding about storing and processing data in the cloud. Cloud architects might find Figure 3 helpful during the design process because it orders all patterns and variants linearly for security and efficiency. However, ultimately, when it comes to encryption in the cloud, companies must balance the ability to develop and deploy business functionality quickly, the need to fulfill mandatory legal and regulatory obligations, and the wish to protect business secrets. And it is not an all-or-nothing decision. Companies can rely on cloud-native encryption for not-so-important data while keeping business secrets away from the cloud.
About the author
Klaus Haller works as a Senior IT Security Architect. His areas of expertise span public clouds (Google Cloud Platform and Microsoft Azure) and how to secure them, technical project and project management, IT operations, information management, analytics, and artificial intelligence. He's also the author of "Managing AI in the Enterprise."
