Introduction
Azure Service Bus messages may contain sensitive business information. This sensitive information should be accessible only to the intended receivers of the message. This information must be protected from the attackers when the messages are in transit and at rest. This blog will brief you how Azure handles the default encryption of data at rest and how we can use our own keys to encrypt the Service Bus data at transit.
Encryption at rest
Most of the time, data stored in Azure data centres are encrypted using Azure’s own encryption mechanisms. The data is encrypted to prevent attackers from accessing the information that is being stored. Encryption at rest is the encryption or encoding of data that is persisted in Azure Storage.
- Azure usually encrypts a large amount of data that is being persisted using a simple methodology.
- All the data are being encrypted and decrypted using the asymmetric encryption algorithm.
- If the data are stored in different partitions, then different keys are used for different partitions.
- All these keys must be stored in a secure location with Identity Based Access Control and audit logs.
- All these encryption keys are further encrypted with a Key Encryption Key in Azure Key Vault to restrict the access to these keys.
Need for Encryption at rest
Usually, all the data in Azure are stored in physical hard drives. An attacker may get physical access to these drives. He may remove the hard drives from the Azure environment and attach it to a computer and try accessing the data. This may be a serious issue when the data stored is unencrypted. When the data is encrypted and stored in the hard drive without any key to decrypt the data, the attempt to decrypt the data requires more time and resources than accessing the unencrypted data.
For this purpose, encryption at rest is highly recommended and it is one of the important requirements of most of the organisations.
Azure Key Vault
The storage location and access control of the encryption keys is central to encryption at rest model. The keys need to be highly secured but accessible to the specified users. The keys must also be available to specific services. For Azure services, Azure Key Vault is the recommended key storage solution. It serves as a common management service across multiple services. Keys can be stored and managed in key vaults. Access to a key vault can be restricted to specific users or services. Azure Key Vault allows customers to create keys or import customer keys for use in customer-managed encryption key scenarios.
Key Hierarchy
More than one encryption key can be used in encryption at rest implementation. Encryptions at rest models use a key hierarchy made up of the following types of keys:
Data Encryption Key (DEK)
Asymmetric AES256 key is used for encrypting a partition or block of data. A single resource might have multiple partitions and Data Encryption Keys. Encrypting each block of data with a different key makes cryptoanalysis attacks more difficult. Access to DEKs is needed by the resource provider or application instance that is encrypting and decrypting a specific block. When a DEK is replaced with a new key only the data in its associated block must be re-encrypted with the new key.
Key Encryption Key (KEK)
An encryption key used to encrypt the Data Encryption Keys is known as the Key Encryption Key. Key Encryption Keys are used only inside the Azure Key Vault. The entity that has access to the KEK may be different than the entity that requires the DEK. An entity may provide broker access to the DEK to limit the access of each DEK to a specific partition. Since the KEK is required to decrypt the DEKs, the KEK is effectively a single point by which DEKs can be effectively deleted by deletion of the KEK.
The Data Encryption Keys, encrypted with the Key Encryption Keys are stored separately and only an entity with access to the Key Encryption Key can decrypt these Data Encryption Keys. Different models of key storage are supported.
Azure Service Bus Message
Service Bus Queues and Topic Subscriptions are used to establish communication among the components involved in solving the business problem. These components communicate by sending and receiving messages to the Service Bus Queue and Topic Subscriptions. The message format can be JSON, XML, plain text, etc.
The message will be either in transit or rest state in the Azure infrastructure until the message is received by the destination application.
Default Encryption by Azure
The messages are encrypted by Azure with default symmetric encryption in transit and at rest. This encryption doesn’t serve the security requirement of some of the organisations.
Custom Encryption
Some of the users of Service Bus, encrypt the messages with their own encryption algorithms and encryption keys before sending them to the queues or topic subscriptions. The messages must be decrypted after receiving the message from the queue. This causes overhead in both the sender side and the receiver side.
To overcome this overhead, Azure now offers encryption of Service Bus data at rest using our own keys. This encryption is commonly known as Bring Your Own Keys (BYOK).
BYOK
In this mechanism, we can use our own keys to encrypt and decrypt the Service Bus data at rest. The keys can be stored in the Azure Key Vault.
Azure Service Bus encrypts your data using Azure Storage encryption for data at rest and automatically decrypts it for you as you access it.
A Microsoft-managed key is used for the encryption of the data in a Service Bus namespace. Service Bus namespace can also be managed with customer-managed keys, which gives the flexibility to create, rotate, disable and revoke access controls.
Requirements for Customer-managed key encryption
- Customer-managed key encryption at rest can only be enabled on empty namespaces.
- If enabled, the namespace will be granted get, wrap and unwrap permissions on keys from the specified Key Vaults.
- Soft delete and purge protection will be enabled on the Key Vaults and cannot be disabled.
Need for Premium namespace
Customer-managed key encryption is currently supported only in the Premium namespaces. It is not available in the Standard and Basic tier.
Steps in Configuring Encryption at rest for Service Bus Namespace
Create a Premium namespace
As mentioned previously, encryption at rest using customer-managed keys can be configured only for empty namespaces.
So, create a Service Bus Namespace in the Premium tier in the required region.
Enable customer-managed encryption
This can be done by clicking the Encryption menu in the side menu.
Enable the customer-managed encryption checkbox
Adding encryption key
This can be done by clicking the Add key button.
Select the existing Azure key vault if present
Creating a new key vault
- This can be done by clicking the add new link present below the Azure Key Vault dropdown
- Enter the key vault name
- Provide the required Resource Group name and location
Saving the configuration
Once all these configurations are done, click on the Save button
Once this is done, all the messages sent to this Service Bus Namespace will be encrypted at rest using the selected key in the key vault.
Rotate your encryption keys
Keys in the key vault can be rotated using the Azure Key Vaults rotation mechanism. Activation and expiration dates can also be used to automate key rotation. The Service Bus service will detect new key versions and start using them automatically.
Revoke access to keys
Once the access to the encryption keys is revoked, it won’t purge the data from Service Bus. It just makes the data inaccessible from the Service Bus namespace. The encryption key can be revoked through access policy or by deleting the key. Once the encryption key is revoked, the Service Bus service on the encrypted namespace will become inoperable. If the access to the key is enabled or the deleted key is restored, Service Bus service can access the key. Now the data from the encrypted Service Bus namespace can be accessed by the message receiver.
Hope, this blog helps you understand how your own keys can be used for encrypting the Service Bus data at rest.
