How does your data get encrypted within Microsoft Azure? How can I ensure that my data is safe on a cloud provider? Lately, I’ve been working with a lot of customers asking about how we can ensure that data is encrypted and to what extent data is encrypted?
When moving to a cloud-based environment and especially to a shared model using/building services with IaaS/PaaS services there are different options to choose from so let’s dig into the options.
Overview
There are five main levels where we can apply encryption
- At-rest (Where data is stored of the physical device)
- In-Transit (Communication flow between services or between user and service)
- Server-Side (Virtual Machine with OS has guest-based encryption)
- File-level encryption (Files stored within the virtual machine are encryption individually)
- In-Memory (All data that is currently stored within the working memory of the machine)
So let me explain the diverse levels a bit deeper.
- At-rest (means encryption of the data on the physical drives. This ensures that if someone smashes into the data center and rips out the disks, they are not able to read the content of the drives without decryption the data)
- In-Transit (means that communication between end-user and service in this example is running within an encryption session such as HTTPS so that no one can read or inspect the traffic flow)
- Server-Side (Even if we have at-rest encryption such as with Azure someone with access to an Azure environment can still use the API’s/Portal be able to download the virtual hard drive of the virtual machine and inspect the machine. Having a server-side encryption service such as BitLocker means that even if someone downloads the VHD they are not able to inspect the data without the encryption key)
- File-level Encryption (Means that file content running within the virtual machines or PaaS services are encrypted individually. This means that if someone has access to a running virtual machine, they can be able to copy individual files and or content and read the content. Such as with SQL databases or file servers. Having an encryption mechanism here means that data can be encrypted on a file-level and ensures that if data get exfiltrated they will not be able to read the content.
- In-Memory (Means that data that is contained within the memory on the virtual machine could be dumped and from there read) in theory Microsoft could dump the memory of a running virtual machine and read the content within. Now can we encrypt the data contained here? do we need to? (Well ill come back to that)
Now when dealing with encryption another issue that can come up, depending on what kind of requirements the customer has in terms of who has access to the keys? is it only Microsoft, is it both or can we bring our own keys?
But let’s explore the different services and options that we have available in terms of encryption.
At-Rest
Storage services in Azure such as Azure Blob Storage and Azure file Shares are using a service called Azure Storage Service Encryption (SSE) that uses AES-256 encryption. This feature is enabled by default for storage accounts and cannot be disabled and is transparent for users.
All storage within Azure is independent of computer clusters. 
With this service, Microsoft is responsible for managing the keys (also known as platform keys). It should be noted that even if we have encryption of data-at-rest this would only ensure that no one is able to decrypt the content of the physical disks within Azure.
The issue with this is that even if data is encrypted at rest I can still for instance export a VHD of a virtual machine directly from the portal and be able to inspect the content of this data.
Since this mechanism only applies to the physical storage and not the virtual VM. There are of course ways to ensure that someone is not able to inspect this content such as using
- Private Link for Disk Access
- Generate prober RBAC control mechanisms to ensure no one has access
But still, none of these two options can restrict the possibility. This also applies to other data services such as Azure Blob Storage and SQL as well.
We also have the option of additional encryption methods
- Azure Storage (with Infrastructure Encryption) which provides double key encryption to data stored at rest using either Microsoft Managed Keys or Customer Managed Keys (KeyVault or Azure KeyVault with Managed HSM) that is not enabled by default.
- Azure SQL (depending on if it is managed instance, SQL or Synapse) SQL uses a feature called TDE that provides at-rest encryption for newly created databases. Like SSE for at-rest encryption of data.) This feature has also supported two options either using TDE with a platform-managed key or using bring your own key which will need to be placed within Key Vault. An issue here is that still, that is in plaintext if you export the database from SQL Server, such as export a database to BACPAC file.
- Azure Virtual Machines (Also has different options to encryption data for at rest.) by default all managed disks are encrypted at rest using SSE. You also have the option to use SSE in combination with Customer Managed Keys (contained with Key Vault) or you can also use double encryption as well (using Microsoft and your own managed keys as well)
And I have an existing blog post going into more details on how this works
Encryption of virtual infrastructure within Microsoft Azure | Marius Sandbu (msandbu.org)
This table also mentions Azure Disk Encryption, which I will come back to later in this article.
One downside for all these encryption methods is two main things.
1: I cannot use my own keys (stored outside of Azure)
2: It still does not encrypt the data inside, so from the Azure Portal / CLI I can still download all the data contained and I’m able to decrypt it.
In-Transit
In terms of In-transit encryption, all traffic is encrypted by default with TLS 1.2 to protect data when it’s traveling between the cloud services and the users trying to connect to it. This applies to services such as Azure Blob Storage, Web Apps, and such. In the backend communication (between a VM to Blob Storage for instance) IEEE 802.1AE MAC Security Standards (also known as MACsec) is applied from point-to-point across the underlying network hardware. This MACsec encryption is on by default for all Azure traffic traveling within a region or between regions, and no action is required on the customers’ part to enable it.
Server-Side
As mentioned, when it comes to encrypting data at rest it still means that data is decrypted and readable when someone tries to download any of the virtual content. There we have server-side based encryption to ensure that the actual content of the data is encrypted, so if someone manages to get a hold of data within Azure either for a VM or PaaS service and download it, the data would not be directly readable.
Within Azure there are different options to provide server-side based encryption of the data.
- Azure Virtual Machines – We have Azure Disk Encryption which is a combination of Key Vault and In-Guest encryption using BitLocker (or DM-Crypt for Linux) or we have a new feature called Encryption at Host that provides the same level of guest VM encryption, but it is handled outside of the Operating system and done at a host level. Encryption at host is currently in preview but supports encryption with either customer managed keys (KeyVault) or with Platform Managed Keys.
- Azure SQL – We have a feature called Always Encrypted that helps protect sensitive data at rest on the server, during movement between client and server, and while the data is in use. That means that not even the SQL administrator is able to see what is happening inside the database and the data contained within.
There are also other encryption methods for other PaaS services within Azure, such as client-side encryption of blob content using the SDK Tutorial – Encrypt and decrypt blobs using Azure Key Vault – Azure Storage | Microsoft Docs
In-memory
Now, in theory, Microsoft could get access to virtual machines memory do a dump of the content and inspect data. Is there any actual way around this? Even if this is just a hypothetical scenario some might be concerned about it or might have requirements where it demands to encrypt as much as possible.
Or even changing the boot process to inject payload as part of the guest OS boot (or that you have malware that has been injected into the boot process)
There are two things that you should know about here.
1: Microsoft Azure has something called Generation 2 virtual machines, which are machines that are using UEFI Boot with a vTPM chip (compared to the regular BIOS-based boot mechanisms) combined with a feature called Secure Boot. However this is more aimed at stopping
- Firmware rootkits: these kits overwrite the firmware of the virtual machine’s BIOS, so the rootkit can start before the OS.
- Boot kits: these kits replace the OS’s bootloader so that the virtual machine loads the boot kit before the OS.
- Kernel rootkits: these kits replace a portion of the OS kernel so the rootkit can start automatically when the OS loads.
- Driver rootkits: these kits pretend to be one of the trusted drivers that OS uses to communicate with the virtual machine’s components.
2: Is Confidential Computing where we have virtual machines in Azure running AMD SEV-SNP enabled CPU’s. These AMD EPYC-CPU powered Azure VMs are fully encrypted at runtime. The encryption keys used for VM encryption are generated, and safeguarded, by a dedicated secure processor on the EPYC CPU. This helps ensure that no one, even cloud administrators—and by extension the workloads, apps, or data in the VMs—have access to these encryption keys. In addition, the Azure Attestation service collects evidence that the hardware environment is correct and then provides a cryptographic signal to Azure Managed HSM to securely release the decryption key for the virtual machine image only if the environment is in a known good state in a combination of Secure Boot.
Using this service, it means that we can have a completely encrypted virtual machine in Azure, without making any changes to the applications. There if of course a higher level of encryption that can be used as well where you have a secure enclave.
I have another blog post going into a bit more details on the confidential computing alternatives Google Cloud Confidential VMs vs Azure Confidential Computing | Marius Sandbu (msandbu.org)
Summary
In Summary, there are multiple encryption methods within Microsoft Azure. At-Rest encryption is enabled with platform-managed keys by default, but we also have different options to provide encryption at-rest with our own managed keys (using Key Vault) but limited options to use existing HSM or keys outside of Azure. We also have different options to encrypt server-side and even the virtual machine itself with Confidential Computing, all depending on your security/governance requirements.