Over the last couple of weeks and months the focus in the news has been on S3 policy misconfiguration and the subsequent exposure of data. More often than not this has been called vulnerabilities (GhostWriter) but the exposure had no cause in the vendors services.
This post is not about the PaaS Storage services like S3, but how you can make sure the data in the IaaS side of the house, yes disks, is in order.
Azure, AWS and GCP have a Server/Storage Side Encryption feature (SSE) that you need to use. There are differences per cloud vendor that i'll explain further on.
Main take away: on Azure you can download a disk from a Storage Account and it will remove encryption on the fly, so the Azure SSE alone is not of much value when somebody has sufficient rights in the Azure Portal.
Take away 2: Azure diskencryption on Linux does not work as advertised.
Notabene: I am not covering the concept of keys and key management, all vendors have the option of using 'their' keys or you providing your own key.
In Azure you need to use 2 seperate features to make sure the data on your disks can not be seen by strangers:
This Storage Side Encryption encrypts only data stored in a Storage Account (so also Managed Disks) after it has been activated. Enable this in the portal or ARM template on creation.
This encryption can be deactivated and will be removed on the fly when you export a .VHD in the Azure Portal
Azure Disk Encryption (ADE and ADEfL)
To make sure the data is always encrypted you need to resort to ADE which uses Bitlocker on Windows and dm-crypt on Linux.
Both require several (2) restarts during deployment and are therefor not automation friendly scenarios.
The deployment of Bitlocker on Windows happens in the background and the VM can be used to install software etc during a provisioning step. The speed is not so important imo.
On Linux the measured speed is about 45 minutes for a (marketplace) RHEL 7.4 image with a 32GB datadisk. During the entire encryption process the VM can not be used (eg install software), as it drops to
init 1 for some parts.
On AWS, the SSE functionality is enough to prevent access data on a disk/volume outside a VM.
All disk-like storage in AWS is provided with the Elastic Block Store service. The encryption of data happens on the VM, they have the Intel AES New Instructions (AES-NI), to enable the encryption functionality at no performance cost.
Encryption can not be removed from volume; you need mount both the encrypted and an unencryption volume and
cp -r between them.
Enabling encryption can only be done on new volumes; you need to make asnapshot and copy that to an encrypted snapshot and delete the unencrypted snapshot afterwards.
Google Cloud Platform has encryption as the default, it can not be activated nor removed. In fact it encrypts at both hardware and storage service level.