Overview:

Questions about security and privacy data in Azure Cache for Redis are legitim and can be a concern. Azure in general offers some different ways to encrypt data depending of the services used.

We will discuss below some of that options in Azure Cache for Redis service.

 

Encryption in Transit

To secure data in transit between Azure Cache for Redis and client applications requires TLS encryption enabled. 

Azure Cache for Redis enable SSL and uses TLS 1.2 by default. Also supports TLS 1.0 and 1.1 but will be retired soon as described here.

Please be aware that non-SSL (not secure, not encrypted connection) is also supported for test proposes, but disabled by default and not recommended for production. 

The recommendation is to use only TLS 1.2, to maintain all the communications secure and encrypted in transit.

 

Microsoft gives customers the ability to use Transport Layer Security (TLS) protocol to protect data in transit, when it’s traveling between the cloud services and client applications. Microsoft datacenters negotiate a TLS connection with client systems that connect to Azure services.

TLS provides strong authentication, message privacy, and integrity (enabling detection of message tampering, interception, and forgery), interoperability, algorithm flexibility, and ease of deployment and use.

Please see more about Azure encryption overview.

 

 

Encryption at Rest

On Azure Cache for Redis, all data stays in the Virtual Machine memory all the time.

Any attempt to encrypt Redis data and using encrypt/decrypt hashes on server side will use the Virtual Machine memory at the same way, having the same exposure.

For that reason, Redis encryption at rest is not implemented and is not supported.

 

On Standard C1 and above tiers (Premium tier included) each Redis node runs on a dedicated Virtual Machine; on Standard C0 and below (Basic tier included), the Redis instances remains in a shared environment and the same Virtual Machine is used by more than one Redis instance.

In any case, only the Redis process assigned to some memory segments can access it, maintaining all data private without any possibility to externally access it. Is the operating system that guarantees that.

 

Each process on Windows has a virtual address space and all threads of a process can access its virtual address space. However, threads cannot access memory that belongs to another process, which protects a process from being corrupted or data read by another process.

See more about Memory Management:

https://docs.microsoft.com/en-us/windows/win32/memory/about-memory-management

 

To maintain the host Virtual Machines updated and secure, Microsoft updates the Redis hosts periodically.

 

Encryption on Persistent Redis

Redis Persistence allows you to persist data stored in Redis. This is supported on Redis Premium tiers only. You can also take snapshots and back up the data, which you can load in case of a hardware failure. Because these data will be saved externally this needs some special attention related to data security and encryption.

Redis Persistence writes Redis data into an Azure Storage account that you own and manage. Azure Storage automatically encrypts data when it is persisted, and is encrypted with Microsoft-managed keys by default. You can continue to rely on Microsoft-managed keys for the encryption of your data, or you can manage encryption with your own keys.

Data in Azure Storage is encrypted and decrypted transparently using 256-bit AES encryption, one of the strongest block ciphers available, and is FIPS 140-2 compliant. Azure Storage encryption is similar to BitLocker encryption on Windows.

 

Encryption on Client side

Despite any client application can encrypt Redis data before sending data to Redis Service and decrypt after receiving data from Redis Service, this will add more processing time and client CPU usage to process the encrypt/decrypt data.

Redis acts as a memory cache and for that reason, the time to process any request is expected to be very short. Adding more processing time to encrypt/decrypt on client side will invalidate all the advantages of having cache (encrypt/decrypt process is typical heavy in time and CPU consuming).

 

Conclusion:

Despite Azure have some different ways to encrypt and secure data, for Azure Cache for Redis Service encryption in transit using SSL/TLS 1.2 is the recommended way. Encryption at rest is not needed as the Virtual Machine that hosts the Redis node already guarantees the security and privacy of data in memory, and Redis persistence is guaranteed by Storage encryption. Any attempt to encrypt/decrypt Redis data on client side will add more time to process and client CPU needs, losing the advantage of having a quick Cache service with very low latency.