All the data managed by an Azure Database for PostgreSQL flexible server flexible is always encrypted at rest. That data includes all system and user databases, server logs, write-ahead log segments, and backups. Encryption is handled by the underlying storage through Server-side encryption of Azure Disk Storage.
Encryption at Rest with Service (SMK) or Customer Managed Keys (CMK)Azure Database for PostgreSQL flexible server supports two modes of data encryption at rest: service managed keys (SMK) and customer managed keys (CMK). Data encryption with service managed keys is the default mode for Azure Database for PostgreSQL flexible server. In this mode, the service automatically manages the encryption keys used to encrypt your data. You don't need to take any action to enable or manage encryption in this mode.
In the customer managed keys mode, you can bring your own encryption key to encrypt your data. This mode gives you more control over the encryption process, but it also requires you to manage the encryption keys yourself. You must deploy your own Azure Key Vault or Azure Key Vault Managed Hardware Security Module (HSM) and configure it to store the encryption keys used by your Azure Database for PostgreSQL flexible server.
The mode can only be selected at server creation time. It can't be changed from one mode to another for the lifetime of the server.
To achieve the encryption of your data, Azure Database for PostgreSQL flexible server uses Azure Storage encryption for data at rest. When using CMK, the customer is responsible for providing keys for encrypting and decrypting data in Blob Storage and Azure Files services. These keys must be stored in Azure Key Vault or Azure Key Vault Managed Hardware Security Module (HSM). For more information, see customer-managed keys for Azure Storage encryption.
Benefits provided by each mode (SMK or CMK)Data encryption with service managed keys for Azure Database for PostgreSQL flexible server provides the following benefits:
Data encryption with customer managed keys for Azure Database for PostgreSQL flexible server provides the following benefits:
With customer managed encryption key you assume all the responsibility. Hence, you must deploy your own Azure Key Vault or Azure Key Vault HSM. You must generate or import your own key. You must grant required permissions on the Key Vault, so that your Azure Database for PostgreSQL flexible server can perform the necessary actions on the key. You have to take care of configuring all networking aspects of the Azure Key Vault in which the key is kept, so that your Azure Database for PostgreSQL flexible server can access the key. Auditing access to the key is also your responsibility. Finally, you're responsible for rotating the key and, when required, updating the configuration of your Azure Database for PostgreSQL flexible server so that it references the rotated version of the key.
When you configure customer-managed keys for a storage account, Azure Storage wraps the root data encryption key (DEK) for the account with the customer-managed key in the associated key vault or managed HSM. The protection of the root encryption key changes, but the data in your Azure Storage account remains encrypted always. There's no extra action required on your part to ensure that your data remains encrypted. Protection by customer-managed keys takes effect immediately.
Azure Key Vault is a cloud-based, external key management system. It's highly available and provides scalable, secure storage for RSA cryptographic keys, optionally backed by FIPS 140 validated hardware security modules (HSMs). It doesn't allow direct access to a stored key, but provides encryption and decryption services to authorized entities. Key Vault can generate the key, import it, or receive it transferred from an on-premises HSM device.
Following is the list of requirements to configure data encryption for Azure Database for PostgreSQL flexible server:
.pfx, .byok, or .backup).CMK can be configured with manual key rotation and updates or with automatic key version updates after a manual or automatic key rotation in the Key Vault.
For details see Configure data encryption with customer managed key during server provisioning.
Important
When you rotate the key to a new version, you must keep the old key available for the reencryption to succeed. While most reencryptions should happen within 30 minutes, we recommend that you wait at least 2 hours before disabling access to the old key version.
Manual key rotation and updatesWhen you configure CMK with manual key updates, you must manually update the key version in the Azure Database for PostgreSQL flexible server after a manual or automatic key rotation in the Key Vault. The server will continue to use the old key version until you update it. You provision this mode by specifying a key URI including the version GUID in the URI. For example, https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Until recently this was the only option available.
Whenever you manually rotate the key or AKV auto-rotates the key based on its rotation policy, you had to update the CMK property on your PostgreSQL instance. This approach proved to be error-prone work for the operators or required a custom script to handle the rotation, especially when using Key Vault's automatic rotation feature.
Automatic key version updatesTo enable automatic key version updates, use a version-less key URI. This eliminates the need to update the CMK's version property in your PostgreSQL instance after a key rotation. PostgreSQL will automatically pick up the new key version and reencrypt the data encryption key. This is a huge simplification in your key lifecycle management, especially when combined with Key Vault auto-rotation.
To implement using ARM, Bicep, Terraform, Azure PowerShell or Azure CLI, simply omit the version GUID from your key URI.
In the Portal select the checkbox to guide the UI to suppress version GUIDs during interactive selection and when validating the URI.
RecommendationsWhen you're using a customer managed key for data encryption, follow these recommendations to configure Key Vault:
Note
After you select Disable public access and Allow trusted Microsoft services to bypass this firewall, you might get an error similar to the following when you try to use public access to administer Key Vault via the portal: "You have enabled the network access control. Only allowed networks have access to this key vault." This error doesn't preclude the ability to provide keys during customer managed key setup or fetch keys from Key Vault during server operations.
Someone with sufficient access rights to Key Vault, might accidentally disable server access to the key by:
To monitor the database state, and to turn on alerts for the loss of access to the data encryption protector, configure the following Azure features:
After Azure Database for PostgreSQL flexible server is encrypted with a customer managed key stored in Key Vault, any newly created server copy is also encrypted. You can make this new copy through a point-in-time restore (PITR) operation or read replicas.
When you're setting up data encryption with customer managed key, during operation like restore of a backup or creation of a read replica, you can avoid problems by following these steps on the primary and restored or replica servers:
Hardware security modules (HSMs) are tamper-resistant hardware devices that help secure cryptographic processes by generating, protecting, and managing keys used for encrypting data, decrypting data, creating digital signatures, and creating digital certificates. HSMs are tested, validated, and certified to the highest security standards, including FIPS 140 and Common Criteria.
Azure Key Vault Managed HSM is a fully managed, highly available, single-tenant, standards-compliant cloud service. You can use it to safeguard cryptographic keys for your cloud applications through FIPS 140-3 validated HSMs.
When you're creating new Azure Database for PostgreSQL flexible server instances in the Azure portal with the customer managed key, you can choose Azure Key Vault Managed HSM as a key store, as an alternative to Azure Key Vault. The prerequisites, in terms of user-defined identity and permissions, are the same as with Azure Key Vault (as listed earlier in this article). For more information on how to create a Managed HSM instance, its advantages and differences from a shared Key Vault-based certificate store, and how to import keys into Managed HSM, see What is Azure Key Vault Managed HSM?.
Inaccessible customer managed key conditionWhen you configure data encryption with a customer managed key stored in Key Vault, continuous access to this key is required for the server to stay online. If that's not the case, the server changes its state to Inaccessible and begins denying all connections.
Some of the possible reasons why the server state might become Inaccessible are:
Cause Resolution Any of the encryption keys pointed by the server had an expiry date and time configured, and that date and time is reached. You must extend the expiry date of the key. Then you must wait for the service to revalidate the key and automatically transition the server state to Ready. Only when the server is back on Ready state you can rotate the key to a newer version or create a new key, and update the server so that it refers to that new version of the same key or to the new key. You rotate the key and forget to update the instance of Azure Database for PostgreSQL flexible server so that it points to the new version of the key. The old key, to which the server is pointing, expires and turns the server state into Inaccessible. To avoid this situation, every time you rotate the key, make sure you also update the instance of your server to point to the new version. To do that, you can use theaz postgres flexible-server update, following the example that describes "Change key/identity for data encryption. Data encryption can't be enabled post server creation, this will only update the key/identity.". If you prefer to update it using the API, you can invoke the Servers - Update endpoint of the service. You delete the Key Vault instance, the Azure Database for PostgreSQL flexible server instance can't access the key and moves to an Inaccessible state. Recover the Key Vault instance and wait for the service to run the periodical revalidation of the key, and automatically transition the server state to Ready. You delete, from Microsoft Entra ID, a managed identity that's used to retrieve any of the encryption keys stored in Key Vault. Recover the identity and wait for the service to run the periodical revalidation of the key, and automatically transition the server state to Ready. Your Key Vault permission model is configured to use role-based access control. You remove the Key Vault Crypto Service Encryption User RBAC role assignment from the managed identities that are configured to retrieve any of the keys. Grant the RBAC role again to the managed identity and wait for the service to run the periodical revalidation of the key, and automatically transition the server state to Ready. An alternative approach consists on granting the role on the Key Vault to a different managed identity, and update the server so that it uses this other managed identity to access the key. Your Key Vault permission model is configured to use access policies. You revoke the list, get, wrapKey, or unwrapKey access policies from the managed identities that are configured to retrieve any of the keys. Grant the RBAC role again to the managed identity and wait for the service to run the periodical revalidation of the key, and automatically transition the server state to Ready. An alternative approach consists on granting the required access policies on the Key Vault to a different managed identity, and update the server so that it uses this other managed identity to access the key. You set up overly restrictive Key Vault firewall rules, so that your Azure Database for PostgreSQL flexible server can't communicate with the Key Vault to retrieve your keys. When you configure a Key Vault firewall, make sure that you select the option to allow trusted Microsoft services so that your Azure Database for PostgreSQL flexible server can bypass the firewall.
Note
When a key is disabled, deleted, expired, or not reachable, a server that has data encrypted with that key becomes Inaccessible, as stated earlier. The server state doesn't change to Ready again until it can revalidate the encryption keys.
Generally, a server becomes Inaccessible within 60 minutes after a key is disabled, deleted, expired, or not reachable. After the key becomes available, the server might take up to 60 minutes to become Ready again.
Recovering from managed identity deletionIf the user assigned managed identity used to access the encryption key stored in Key Vault is deleted in Microsoft Entra ID, you should follow these steps to recover:
Important
Simply creating new Entra ID identity with the same name as deleted identity doesn't recover from managed identity deletion.
Using data encryption with customer managed keys and geo-redundant business continuity featuresAzure Database for PostgreSQL flexible server supports advanced data recovery features, such as replicas and geo-redundant backup. Following are requirements for setting up data encryption with CMKs and these features, in addition to basic requirements for data encryption with CMKs:
These are the current limitations for configuring the customer managed key in an Azure Database for PostgreSQL flexible server:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4