【Azure Redis 缓存】关于Azure Cache for Redis 服务在传输和存储键值对(Key/Value)的加密问题

问题描述

Azure Cache for Redis 服务在传输和存储数据时是如何加密呢?

 

问题回答

一:关于Azure cache for Redis服务在数据传输过程中是如何加密的?

  • 为了确保在Azure cache for Redis和客户端应用程序之间传输的数据安全,需要启用TLS加密。Azure缓存Redis启用SSL,默认使用TLS 1.2。
  • Azure数据中心与连接到Azure服务的客户端系统协商TLS连接。TLS提供强大的身份验证、消息私密性和完整性(支持检测消息篡改、拦截和伪造)、互操作性、算法灵活性以及易于部署和使用。

二:关于Azure cache for Redis服务中的静态数据是如何加密的?

Azure cache for Redis服务中存储的静态数据在VM内存中是不被加密的。在Standard C1及以上定价层(包括Premium定价层),每个Redis节点都运行在一个专用VM上;在Standard C0及以下定价层(包含Basic定价层),Redis实例运行在一个共享环境,同一个VM会被多个Redis实例共用,但是由于进程与进程之间是隔离的,这样会防止某个进程被其它进程破坏或读取数据。

 

参考资料

 

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.

 
 
posted @ 2022-10-21 19:46  路边两盏灯  阅读(68)  评论(0编辑  收藏  举报