Customer managed keys data encryption – Azure Database for MySQL – Flexible Server Preview

APPLIES TO: Azure Database for MySQL - Flexible Server

With data encryption with customer-managed keys for Azure Database for MySQL - Flexible Server Preview, you can bring your own key (BYOK) for data protection at rest and implement separation of duties for managing keys and data. With customer managed keys (CMKs), the customer is responsible for and in a full control of key lifecycle management (key creation, upload, rotation, deletion), key usage permissions, and auditing operations on keys.

Note

In the Public Preview, we can't enable geo redundancy on a flexible server that has CMK enabled, nor can we enable geo redundancy on a flexible server that has CMK enabled.

Benefits

Data encryption with customer-managed keys for Azure Database for MySQL Flexible server provides the following benefits:

  • Data-access is fully controlled by you by the ability to remove the key and making the database inaccessible
  • Full control over the key-lifecycle, including rotation of the key to align with corporate policies
  • Central management and organization of keys in Azure Key Vault
  • Ability to implement separation of duties between security officers, and DBA and system administrators

How does data encryption with a customer-managed key work?

Managed identities in Azure Active Directory (Azure AD) provide Azure services an alternative to storing credentials in the code by provisioning an automatically assigned identity that can be used to authenticate to any service supporting Azure AD authentication, such as Azure Key Vault (AKV). Azure Database for MySQL Flexible server currently supports only User-assigned Managed Identity (UMI). For more information, see Managed identity types in Azure.

To configure the CMK for an Azure Database for MySQL flexible server, you need to link the UMI to the server and specify the Azure Key vault, and key to use.

The UMI must have the following access to the key vault:

  • Get: For retrieving the public part and properties of the key in the key vault.
  • List: List the versions of the key stored in a Key Vault.
  • Wrap Key: To be able to encrypt the DEK. The encrypted DEK is stored in the Azure Database for MySQL Flexible server.
  • Unwrap Key: To be able to decrypt the DEK. Azure Database for MySQL Flexible server needs the decrypted DEK to encrypt/decrypt the data

Terminology and description

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 rest.

How it works

Data encryption with CMKs is set at the server level. For a given server, a CMK, called the key encryption key (KEK), is used to encrypt the data encryption key (DEK) used by the service. The KEK is an asymmetric key stored in a customer-owned and customer-managed Azure Key Vault instance. Key Vault is highly available and scalable secure storage for RSA cryptographic keys, optionally backed by FIPS 140-2 Level 2 validated hardware security modules (HSMs). Key Vault doesn't allow direct access to a stored key, but instead provides encryption/decryption services using the key to the authorized entities. The key can be generated by the key vault, imported, or transferred to the key vault from an on-premises HSM device.

When you configure a flexible server to use a CMK stored in the key vault, the server sends the DEK to the key vault for encryptions. Key Vault returns the encrypted DEK, which is stored in the user database. Similarly, when needed, the flexible server will send the protected DEK to the key vault for decryption.

Diagram of how data encryption with a customer-managed key work.

After logging is enabled, auditors can use Azure Monitor to review Key Vault audit event logs. To enable logging of Key Vault auditing events, see Monitoring your key vault service with Key Vault insights.

Note

Permission changes can take up to 10 minutes to impact the key vault. This includes revoking access permissions to the TDE protector in AKV, and users within this time frame may still have access permissions.

Requirements for configuring data encryption for Azure Database for MySQL Flexible server

Before you attempt to configure Key Vault, be sure to address the following requirements.

  • The Key Vault and Azure Database for MySQL flexible server must belong to the same Azure Active Directory (Azure AD) tenant. Cross-tenant Key Vault and flexible server interactions aren't supported. If you move Key Vault resources after performing the configuration, you’ll need to reconfigure data encryption.
  • The Key Vault and Azure Database for MySQL flexible server must reside in the same region.
  • Enable the soft-delete feature on the key vault with retention period set to 90 days to protect from data loss should an accidental key (or Key Vault) deletion occur. The recover and purge actions have their own permissions associated in a Key Vault access policy. The soft-delete feature is off by default, but you can enable it through the Azure portal or by using PowerShell or the Azure CLI.
  • Enable the Purge Protection feature on the key vault and set the retention period to 90 days. When purge protection is on, a vault or an object in the deleted state can't be purged until the retention period has passed. You can enable this feature by using PowerShell or the Azure CLI, and only after you've enabled soft-delete.

Before you attempt to configure the CMK, be sure to address the following requirements.

  • The customer-managed key to be used for encrypting the DEK can be only asymmetric, RSA 2048.
  • The key activation date (if set) must be a date and time in the past. The expiration date not set.
  • The key must be in the Enabled state.
  • The key must have soft delete with retention period set to 90 days. This implicitly sets the required key attribute recoveryLevel: “Recoverable”.
  • The key must have purge protection enabled.
  • If you're importing an existing key into the key vault, make sure to provide it in the supported file formats (.pfx, .byok, .backup).

Note

For detailed, step-by-step instructions about how to configure date encryption for an Azure Database for MySQL flexible server via the Azure portal, see Configure data encryption for MySQL Flexible server.

Recommendations for configuring data encryption

As you configure Key Vault to use data encryption by using a customer-managed key, keep in mind the following recommendations.

  • Set a resource lock on Key Vault to control who can delete this critical resource and prevent accidental or unauthorized deletion.
  • Enable auditing and reporting on all encryption keys. Key Vault provides logs that are easy to inject into other security information and event management tools. Azure Monitor Log Analytics is one example of a service that's already integrated.
  • Keep a copy of the customer-managed key in a secure place or escrow it to the escrow service.
  • If Key Vault generates the key, create a key backup before using the key for the first time. You can only restore the backup to Key Vault. For more information about the backup command, see Backup-AzKeyVaultKey.

Inaccessible customer-managed key condition

When you configure data encryption with a CMK in Key Vault, continuous access to this key is required for the server to stay online. If the flexible server loses access to the customer-managed key in Key Vault, the server begins denying all connections within 10 minutes. The flexible server issues a corresponding error message and changes the server state to Inaccessible. The server can reach this state for various reasons.

  • If you delete the KeyVault, the Azure Database for MySQL Flexible server will be unable to access the key, and will move to Inaccessible state. Recover the Key Vault and revalidate the data encryption to make the Flexible server Available.
  • If we delete the key from the KeyVault, the Azure Database for MySQL Flexible server will be unable to access the key, and will move to Inaccessible state. Recover the Key and revalidate the data encryption to make the Flexible server Available.
  • If the key stored in the Azure KeyVault expires, the key will become invalid, and the Azure Database for MySQL Flexible server will transition into Inaccessible state. Extend the key expiry date using CLI and then revalidate the data encryption to make the Flexible server Available.

Accidental key access revocation from Key Vault

It might happen that someone with sufficient access rights to Key Vault accidentally disables flexible server access to the key by:

  • Revoking the key vault's get, list, wrap key and unwrap key permissions from the server
  • Deleting the key
  • Deleting the key vault
  • Changing the key vault's firewall rules
  • Deleting the user managed identity used for encryption on the flexible server with a customer managed key in Azure AD

Monitor the customer-managed key in Key Vault

To monitor the database state, and to enable alerting for the loss of transparent data encryption protector access, configure the following Azure features:

  • Activity log: When access to the Customer Key in the customer-managed Key Vault fails, entries are added to the activity log. You can reinstate access as soon as possible if you create alerts for these events.
  • Action groups: Define these groups to send you notifications and alerts based on your preferences.

Replica with a customer managed key in Key Vault

Once Azure Database for MySQL flexible server is encrypted with a customer's managed key stored in Key Vault, any newly created copy of the server is also encrypted. When trying to encrypt Azure Database for MySQL flexible server with a customer managed key that already has a replica(s), we recommend configuring the replica(s) as well by adding the managed identity and key.

Restore with a customer managed key in Key Vault

When attempting to restore an Azure Database for MySQL flexible server, you're given the option to select the User managed identity, and Key to encrypt the restore server.

To avoid issues while setting up customer-managed data encryption during restore or read replica creation, it's important to follow these steps on the source and restored/replica servers:

  • Initiate the restore or read replica creation process from the source Azure Database for MySQL Flexible server.
  • On the restored/replica server, revalidate the customer-managed key in the data encryption settings to ensure that the User managed identity is given Get, List, Wrap key and Unwrap key permissions to the key stored in Key Vault.

Note

Using the same identity and key as on the source server is not mandatory when performing a restore.

Next steps