Encryption At Rest

When we talk about encryption at rest, we are talking about encrypting data that is only stored and not currently being transferred or processed in memory – if the data is physically stored on the storage device (disk). We want to prevent anyone from connecting to the disk and starting to read the data without our permission – so we have the data encrypted with an encryption key as soon as it is written to the storage and decrypted as soon as it is read from the storage. The encryption key is stored elsewhere than the data. Same purpose as the BitLocker you have on your laptop. Without the encryption key, an attacker would not be able to read the data (within a reasonable time, unless there is a flaw in the encryption mechanism).

Azure recognizes two modes of encryption – client-side encryption (encryption is done outside of Azure and Azure works with encrypted data it doesn’t understand) and server-side encryption, where the encryption is managed within Azure.

Server-side Encryption

Server-side encryption encrypts data automatically during storage on disk. But what encryption key is used for this? Microsoft offers two options, its platform-managed keys and customer-managed keys (CMK, sometimes referred to as BYOK – Bring Your Own Key).

Platform keys are managed end-to-end by Azure and you don’t have to worry about anything – all the necessary key-related activities – generation, rotation, etc. are delegated to Microsoft. This solution is suitable for most workloads, but some workloads handling sensitive data must implement CMK by regulation. This increased security brings all key management tasks to the customer.

What’s really good is that Azure has security in its DNA and encrypts with platform-managed keys the data for almost all services offered – from Azure Storage (including disks for virtual machines), Azure SQL Database (search for TDE feature), or perhaps Azure Database for MySQL and more. There is no additional charge for encryption and encryption cannot be turned off, it is enforced by default.

More info about Encryption at the rest can be found here.

Encryption In Transit

Usually we need to exchange data between some applications or send it to the user – this is another place where we need to be careful about data protection. Sometimes this area is called “data in motion”. When communicating over an unencrypted channel, any attacker can listen and/or modify the content of the data along the way. This is why, in 2022, we use the secured HTTPS protocol (via TLS protocol) to access any website (and our browser verifies the website’s certificate, otherwise it will drop the connection).

To manage any resource in Azure (via the REST API or portal), Azure enforces a connection via an encrypted connection.

Almost every Azure service provides the same level of security (if the protocol of given service supports it), so you can consume a service over a secure connection.

Some services allow you to use also unsecured versions of protocols, so make sure you disable them. A great example of this is the Azure Web App, where HTTP out of the box is enabled. To disable unencrypted connections, just enable the “HTTPS Only” option in the “TLS/SSL settings” section of the Web App.

I also recommend setting the minimum TLS version to 1.2 (as of March 2022, Azure does not yet support the higher TLS version 1.3).

More details about Azure encryption in transit can be found here.

Least Privilege Strategy

Another important level of security for Azure resources is restricting permissions for users, administrators, service accounts – for everybody. Give them only the permissions they need to do their jobs, nothing more.

Azure has a lot of built-in roles that you can assign a user to a given resource, see here.

In next article I would like to cover networking isolation and key management.

Do you like this format of Cloud Cold Starts articles? Do you have any topic you would like to cover here? Please share your idea in the comments!