Data Encryption Models in Microsoft Azure
Understanding the various encryption models and their pros and cons is essential to understand how various Azure service providers use encryption in Rest. These definitions are shared with all service providers at Azure to ensure common language and taxonomy.
There are three scenarios for server-side encryption:
Server-side encryption using Service-Managed keys.
- Azure Resource Providers perform the encryption and decryption operations
- Microsoft manages the keys
- Full cloud functionality
Server-side encryption using customer-managed keys in Azure Key Vault
- Azure Resource Providers perform the encryption and decryption operations
- Customer controls keys via Azure Key Vault
- Full cloud functionality
Server-side encryption using customer-managed keys on customer-controlled hardware
- Azure Resource Providers perform the encryption and decryption operations
- Customer controls keys on customer-controlled hardware
- Full cloud functionality
Server-side encryption models refer to encryption performed by Azure service. In that model, the Service Provider performs encryption functions and removes encryption. For example, Azure Storage can retrieve data from empty text operations and will perform encryption and decrypt encryption. Service Providers may use the encryption keys held by Microsoft or the customer depending on the configuration provided.
Each server-side encryption in the rest area suggests different key management features. This includes where and how encryption keys are created and stored with access models and important rotation processes.
For client-side encryption, consider the following:
- Azure services cannot see decrypted data
- Customers manage and store keys on-premises (or in other secure stores). Keys are not available to Azure services
- Reduced cloud functionality
Azure-based encryption models are divided into two main groups: “Client Encryption” and “Server-Side Encryption” as mentioned earlier. Independently of the encrypted model used, Azure services always recommend the use of secure transit features such as TLS or HTTPS. Therefore, transport encryption should be aligned with the transport protocol and should not be a major factor in determining which encryption model should be used.
Client encryption model
Client Encryption Module refers to encryption performed outside of the Service Provider or Azure with a call service or application. Encryption can be done through the Azure service application, or through an application running in the customer data center. In any case, when using this encryption model, Azure Service Provider gets encrypted data without the ability to clear encryption by any means or access encryption keys. In this model, key management is done by the phone/application service and is limited to the Azure service.
Server-side encryption using service-managed keys
For many customers, an important requirement is to ensure that data is encrypted whenever it is at rest. Server-side encryption using Service Managed Keys allows this model to allow customers to mark a specific application (Storage Account, SQL DB, etc.) for encryption and leave all important management features such as keystrokes, rotation, and backup copy to Microsoft. Many Azure encryption services at rest usually support this Azure key encryption loading model. The Azure service provider creates keys, puts them in a safe place, and returns them when needed. This means that the service has full key access and the service has full control over the verification cycle life control.
Server-side encryption using service-managed keys therefore quickly addresses the need to have encryption at rest with low overhead to the customer. When available a customer typically opens the Azure portal for the target subscription and resource provider and checks a box indicating, they would like the data to be encrypted. In some Resource Managers, server-side encryption with service-managed keys is on by default.
Key access
When the server-side encryption by service-controlled keys are used, key configuration, storage, and access to the service are all controlled by the service. Normally, basic Azure service providers will store Data Encryption Keys at a nearby data store that is quickly available and accessible while Key Encryption Keys are stored in a secure internal store.
Advantages
- Easy setup
- Microsoft manages key rotations, duplicate archiving, and duplication
- The customer has no costs associated with the implementation or risk of a custom key management system.
Disadvantages
- No customer control over encryption keys (key specification, life cycle, decryption, etc.)
- There is no ability to separate senior managers from the overall management model of the service
Server-side encryption using customer-managed keys in Azure Key Vault
In cases where the requirement is to encrypt data while resting and managing encryption keys, customers can use server-side encryption using Custom Managed Keys in Key Vault. Some apps can only store the root Encryption key in the Azure Key Vault and keep the Encrypted Data Key encoded in close proximity to the data. In that case, customers can bring their keys to Key Vault (BYOK — Bring Your Key), or generate new ones, and use them to encrypt the desired resources. While the Service Provider performs encryption and decryption functions, you use the default encryption key as the root key for all encryption functions.
Loss of encryption keys means data loss. For this reason, the keys should not be removed. The keys should be backed up whenever they are created or rotated. Soft-Delete and purge protection should be enabled in any encryption storage vault to prevent accidental or malicious cryptographic deletion. Instead of removing the key, it is recommended to set it to be enabled to lie on the key-encryption key.
Key Access
A server-side encryption model with customer-managed keys in Azure Key Vault includes a service that accesses encryption keys and removes typing as needed. Rest encryption keys are made accessible to the service through the access control policy. This policy gives service ownership access to the key. Azure service that works instead of related subscriptions can be configured manually in those subscriptions. The service can perform Azure Active Directory authentication and receive authentication tokens that identify themselves as the service that represents the subscription. That token might be sent to Key Vault to retrieve the key you have been given access to.
By working with encryption keys, service ownership can be granted access to any of the following functions: delete encryption, encryption, unwrapKey, wrap key, verify, sign, retrieve, list, update, create, import, delete, make a backup copy, and restore.
To get the key to use encryption or remove data encryption by relieving service ownership that the Service Manager service will work as it should be with UnwrapKey (to get the encryption key) and WrapKey (key in the key vault when you create a new. Key).
Advantages
- Full control of used keys — encryption keys are managed in the Custom Vault of the client under customer control.
- Ability to encrypt multiple services in one master
- It can separate senior managers from the overall management model of the service
- It can define service and location in all regions
Disadvantages
- The customer has full responsibility for managing critical access
- The customer has full responsibility for managing the life cycle
- Additional setup and further configuration
Server-side encryption using customer-managed keys in customer-controlled hardware
Some Azure apps enable the key management model Set Your Key (HYOK). This management mode is useful for situations where you need to encrypt data when resting and handling keys in a repository outside Microsoft. In this model, the service should return the key to the external site. Performance and availability guarantees are affected, and configuration is very complex. Additionally, as the service is able to access DEK during encryption and encryption operations the overall security guarantees for this model are the same as when the keys are held by the customer in Azure Key Vault. As a result, this model is not suitable for most organizations unless they have specific management requirements. Due to these limitations, many Azure services do not support server-side encryption using server-held keys in client-controlled hardware.
Key Access
When server-side encryption is used using customer-controlled hardware keys, the keys are stored in a custom-configured system. Azure services that support this model provide a way to establish secure connections in the key store provided by the customer
Advantages
- Full control over used root key — encryption keys managed by customer-provided store
- Ability to encrypt multiple services in one master
- It can separate senior managers from the overall management model of the service
- It can define service and location in all regions
Disadvantages
- Full responsibility for key storage, security, performance, and availability
- Full responsibility for critical access management
- Full responsibility for key lifecycle management
- Significant setup, configuration, and ongoing maintenance costs
- Increased dependency on network availability between the customer datacenter and Azure datacenters.
Future Work :
Encryption screens introduce the option to assign multiple encryption keys to a blog storage account. Previously, customers using a single storage account for multiple rental conditions were limited to using an encrypted key with account encryption for all data in the account. With encryption screens, you can now provide multiple encryption keys and choose to use encryption scales either at the container level (such as the default space for blocks in that container) or at the blob level.
A key that protects the encryption key may be a Microsoft-controlled key or a customer-held key in Azure Key Vault. You can choose to enable automatic rotation of client-held keys that protect the encryption range. When you produce a new version of the key in your Key Vault, Azure Storage will automatically update the key version that protects the encryption range, during the day.
References:
https://www.networkdatapedia.com/post/azure-encryption-explained
https://docs.microsoft.com/en-us/azure/security/fundamentals/encryption-models
