With the growth in the cloud transformation by organizations globally, there is a growing concern of the security and control of the data stored in cloud. Until now, Azure Database for MySQL encrypted all data at rest using Azure managed key. However, customers wanted more control of this security and manage their resources based on the organizations policies.
Today help solve this problem, we are excited to announce the preview of Data encryption using customer managed key support for the Azure database for MySQL.
Often referred to as Bring your own key (BYOK), this functionality lets you create, own, and manage encryption for their data at rest for your Azure Database for MySQL. You are responsible for, and in a full control of, the key's lifecycle, key usage permissions, and auditing of operations on keys. Now, you can use customer managed key to help protect your data, comply to your organization’s policies, and meet regulatory requirements.
Data encryption key (DEK): A symmetric AES256 key used to encrypt a partition or block of data. Encrypting each block of data with a different key makes crypto analysis attacks more difficult. Access to DEKs is needed by the resource provider or application instance that is encrypting and decrypting a specific block. When you replace a DEK 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 DEKs. A KEK that never leaves Key Vault allows the DEKs themselves to be encrypted and controlled. The entity that has access to the KEK might be different than the entity that requires the DEK. 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 DEKs, encrypted with the KEKs, are stored separately. Only an entity with access to the KEK can decrypt these DEKs. For more information, see Security in encryption at rest.
In order to use encryption using for your Azure Database for MySQL using customer-managed keys stored in Key Vault, a Key Vault administrator gives the necessary permissions to the server:
The key vault administrator can also enable logging of Key Vault audit events, so they can be audited later. When the server is configured to use the customer-managed key stored in the key vault, the server sends the DEK to the key vault for encryption. Key Vault returns the encrypted DEK, which is stored in the user database. Similarly, when needed, the server sends the protected DEK to the key vault for decryption. Auditors can use Azure Monitor to review Key Vault audit event logs, if logging is enabled.
Data encryption using customer managed key for Azure Database for MySQL provides the following benefits
The process of enabling encryption for your Azure database for MySQL is seamless and does not require downtime, and it does not degrade performance. You can use Azure portal, Azure CLI and ARM templates for perform this operation. Once set you can verify the data encryption.
For Azure Database for MySQL, the support for encryption of data at rest using customers managed key (CMK) has some limitation
You can find more details on the Data encryption for Azure Database for MySQL here. You can give the Azure Data encryption using customer managed key a try today. This functionality is still in preview and should not be used for production workloads. If you have questions, please reach out to us AskAzureDBforMySQL@service.microsoft.com alias.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.