Zdieľať cez

Data encryption for Azure Database for MySQL by using the Azure portal

  • Článok

APPLIES TO: Azure Database for MySQL - Single Server

Important

Azure Database for MySQL single server is on the retirement path. We strongly recommend that you upgrade to Azure Database for MySQL flexible server. For more information about migrating to Azure Database for MySQL flexible server, see What's happening to Azure Database for MySQL Single Server?

Learn how to use the Azure portal to set up and manage data encryption for your Azure Database for MySQL.

Prerequisites for Azure CLI

  • You must have an Azure subscription and be an administrator on that subscription.

  • In Azure Key Vault, create a key vault and a key to use for a customer-managed key.

  • The key vault must have the following properties to use as a customer-managed key:

    • Soft delete

      az resource update --id $(az keyvault show --name \ <key_vault_name> -o tsv | awk '{print $1}') --set \ properties.enableSoftDelete=true

    • Purge protected

      az keyvault update --name <key_vault_name> --resource-group <resource_group_name>  --enable-purge-protection true

    • Retention days set to 90 days

      az keyvault update --name <key_vault_name> --resource-group <resource_group_name>  --retention-days 90

  • The key must have the following attributes to use as a customer-managed key:

    • No expiration date
    • Not disabled
    • Perform get, wrap, unwrap operations
    • recoverylevel attribute set to Recoverable (this requires soft-delete enabled with retention period set to 90 days)
    • Purge protection enabled

    You can verify the above attributes of the key by using the following command:

    az keyvault key show --vault-name <key_vault_name> -n <key_name>

  • The Azure Database for MySQL - Single Server should be on General Purpose or Memory Optimized pricing tier and on general purpose storage v2. Before you proceed further, refer limitations for data encryption with customer managed keys.

Set the right permissions for key operations

  1. In Key Vault, select Access policies > Add Access Policy.

  2. Select Key permissions, and select Get, Wrap, Unwrap, and the Principal, which is the name of the MySQL server. If your server principal can't be found in the list of existing principals, you need to register it. You're prompted to register your server principal when you attempt to set up data encryption for the first time, and it fails.

  3. Select Save.

Set data encryption for Azure Database for MySQL

  1. In Azure Database for MySQL, select Data encryption to set up the customer-managed key.

  2. You can either select a key vault and key pair, or enter a key identifier.

  3. Select Save.

  4. To ensure all files (including temp files) are fully encrypted, restart the server.

Using Data encryption for restore or replica servers

After Azure Database for MySQL is encrypted with a customer's managed key stored in Key Vault, any newly created copy of the server is also encrypted. You can make this new copy either through a local or geo-restore operation, or through a replica (local/cross-region) operation. So for an encrypted MySQL server, you can use the following steps to create an encrypted restored server.

  1. On your server, select Overview > Restore.

    Or for a replication-enabled server, under the Settings heading, select Replication.

  2. After the restore operation is complete, the new server created is encrypted with the primary server's key. However, the features and options on the server are disabled, and the server is inaccessible. This prevents any data manipulation, because the new server's identity hasn't yet been given permission to access the key vault.

  3. To make the server accessible, revalidate the key on the restored server. Select Data encryption > Revalidate key.

    Note

    The first attempt to revalidate will fail, because the new server's service principal needs to be given access to the key vault. To generate the service principal, select Revalidate key, which will show an error but generates the service principal. Thereafter, refer to these steps earlier in this article.

    You will have to give the key vault access to the new server. For more information, see Assign a Key Vault access policy.

  4. After registering the service principal, revalidate the key again, and the server resumes its normal functionality.

Next steps