blog
Data Encryption as a Shared Responsibility
One of the fundamental things to understand about cloud technologies is the shared responsibility model. Too often, individuals and corporations get carried away with the idea of “the cloud” and the convenience that comes with it and they use cloud services without conducting any due diligence. It is easy to think about the many benefits that the cloud provides, forgetting about the security of your data. At the point that you decide to use a cloud service to store your data, you ought to do your due diligence about the shared responsibility you have between you and the cloud provider. One of the protections that you may have to bank on is encryption and it can be shared responsibility as we will see in this article.
Stacking Up Responsibilities
According to McAfee, only 9.4% of cloud providers encrypt their customer’s data at rest. Evaluating the encryption controls for your data largely depends on many factors including the cloud service model that you have adopted on the cloud and the cloud provider in question. The three common service models in the cloud are Infrastructure-as-a-Service (IaaS), Platform-as-Service (PaaS), and Software-as-a-Service (SaaS). Regardless of the model that you decide to go with, data and access to that data are ultimately the customer’s responsibility and not the cloud providers. Different cloud providers may decide to take partial responsibility for encrypting your data by default. But it is up to you to do your homework to understand the protections provided by the cloud provider versus your own responsibilities. The section below looks at the available options for data encryption offered by the major cloud providers.
Shared Responsibility for Data Encryption At-Rest
| Cloud Providers | Encryption Schemes | Applicable types of Storage | Where are the encryption keys stored? | Shared responsibility for data encryption |
| Google Cloud Platform (GCP) | Data at rest is protected with AES256 or AES128. Data is chunked and encrypted before being written to disk. | Block storage Object storage | By default, Google encrypts all data at rest and stores the keys in its Key Management Infrastructure. However, customers can create and store their own Customer Supplied Encryption Keys (CSEK’s). | Yes |
| Amazon Web Service (AWS) | Data at rest is protected with AES256 or AES128. Encryption of data can be done using both asymmetric and symmetric encryption. | Block storage Object storage | By default, some AWS services encrypt your data with AWS owned or managed Customer Managed Keys (CMK’s) and store it in its Key Management Infrastructure. However, customers can create and manage their own CMK’s. | Yes |
| Digital Ocean (DO) | By default, object storage (Space) is encrypted on physical disks with 256-bit AES-XTS full-disk encryption. No encryption service or key management infrastructure is provided, unlike GCP and AWS. The customer has to encrypt their own data and manage the storage of the keys. | Block storage Object storage | Customers can create an encrypted filesystem on DO’s block storage volume using custom encryption specifications like LUKS. The customer has full responsibility for protecting those keys. | No |
| Scaleway | No encryption service or key management infrastructure is provided, unlike GCP and AWS. The customer has to encrypt their own data. | Block storage Object storage | Customers have the responsibility of encrypting data before storing their data on the cloud. | No |
Data Encryption for Different Service Models
Infrastructure-as-a-Service (Iaas)
IaaS comprises services running directly on physical or virtual hardware. At this level, you have control of the operating system all the way to the application as shown in the layers of the cloud illustration below. Considering this level of control you have when you use this service model, you have the liberty of placing additional encryption and access controls to protect your data-at-rest like file-system encryption.
Platform-as-a-Service (Paas)
At the platform level, you may have control over the application or data. In that case, it is prudent to think about the protections that have been applied at the lower layers and the additional encryption that need to be placed on your data at the application and data layers.
Software-as-a-Service (SaaS)
With the SaaS, you don’t have any control over any of the layers as shown below. If you use this model, you have to find out the protections that have been put in place across all the layers.
Data Encryption In-Transit
When using any one of the models above its imperative to think about encryption in-transit. You will probably not have access to the physical network and in that case, you have to consider placing encryption controls so you can control who has access to your data-in-motion.
Layers of the Cloud
Cloud Service Providers Access Policies
Another aspect that is equally important to consider when choosing a cloud service provider is its data access policy. It is essential to find out why your cloud provider may come close to accessing your data or may need to access your data for various reasons. Some of the reasons cloud providers may need to access your data may be for operational, organization-specific, legal, or regulatory reasons. Some of the reasons may touch on service maintenance, privacy laws, and regulations, or law enforcement issues. The access policy can be key in establishing your encryption needs for your data-at-rest and data-in-transit.
Conclusion
Much of the responsibility for securing your data in the cloud lies with you as the customer. When choosing any cloud service it is imperative to understand the shared responsibility between you and the cloud service provider with respect to security controls and implement the necessary controls to ensure that your data is safe.
