Working with sensitive customer data adds extra responsibility to a lot of our corporate clients that utilize Azure Database for PostgreSQL - Flexible Server. Need to store sensitive data is crucial to our customers in financial, professional services, as well as e-commerce space. In the face of escalating and evolving cyber threats, IT professionals must, therefore, devise a strategy based on best practices to secure data at rest, data in use and data in motion.
Data encryption transforms your data into unreadable code (ciphertext) using a cryptographic algorithm. Encryption encodes data, so only programs that know how to decode it can read it. It uses an algorithm—a set of ordered steps—to alter the information so that the receiving party can't read it without applying a similar algorithm to return it to its original state.
In order for unauthorized users to decode and access sensitive information, they need to first decrypt the ciphertext using a cryptographic key – a secret key randomly generated by an algorithm. Corporations, governments, and individuals use encryption to safeguard data stored on their computing systems as well as information that moves in and out of their organizations. Apart from security, there can be other reasons like compliance to certain industry standards and government regulations such as HIPAA, PCI and FedRAMP, etc.
Encryption plays really important role throughout all data states, whether protecting data at rest and in motion or encrypting files before storing them to offer an extra layer of protection against assaults on its internal servers.
The service uses the AES 256-bit cipher included in Azure storage encryption, and the keys are system managed. This is similar to other at-rest encryption technologies, like transparent data encryption in SQL Server or Oracle databases. Storage encryption is always on and can't be disabled.
In this blog post I will focus on encrypting data at rest and additional security that customer managed keys (CMK) feature provides.
At the most basic level, the data on-disk is encrypted with an azure internal key referred to as Data Encryption Key (DEK). To achieve that goal secure key creation, storage, access control, and management of the encryption keys must be provided. Though details may vary, Azure services Encryption at Rest implementations can be described in terms illustrated in the following diagram.
Figure 1. Azure encryption at rest design diagram
The storage location of the encryption keys and access control to those keys is central to an encryption at rest model. The keys need to be highly secured but manageable by specified users and available to specific services. For Azure services, Azure Key Vault (AKV) is the recommended key storage solution and provides a common management experience across services. Keys are stored and managed in AKV, and access to a key vault can be given to users or services. Azure Key Vault supports customer creation of keys or import of customer keys for use in customer-managed encryption key scenarios. Permissions to use the keys stored in Azure Key Vault, either to manage or to access them for Encryption at Rest encryption and decryption, can be given to Azure Active Directory accounts.
Many organizations require full control on access to the data using a customer-managed key. Data encryption with customer-managed keys for Azure Database for PostgreSQL Flexible server - Preview enables you to bring your own key (BYOK) for data protection at rest. It also allows organizations to implement separation of duties in the management of keys and data. With customer-managed encryption, you are responsible for, and in a full control of, a key's lifecycle, key usage permissions, and auditing of operations on keys.
Data encryption with customer-managed keys for Azure Database for PostgreSQL Flexible server - Preview, is set at the server-level. For a given server, a customer-managed key, called the key encryption key (KEK), is used to encrypt the symmetric AES256 key 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. 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.
Figure 2. PostgreSQL Preview CMK design diagram
For a PostgreSQL server to use customer-managed keys stored in Key Vault for encryption of the DEK, a Key Vault administrator gives the following access rights 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 encryptions. 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.
To monitor the database state, and to enable alerting for the loss of transparent data encryption protector access, configure the following Azure features:
Now after all the theory lets setup data encryption with CMK (Preview) on new Azure Database for PostgreSQL - Flexible Server
Before we begin setting up CMK, we need to make sure following prerequisites are done:
Once you are done with prerequisites, we can navigate to Azure Database for PostgreSQL - Flexible Server create blade via Azure portal. Start creation of new server and let's fill out required information on Basics and Networking tabs
Figure 3. Basic Tab for PostgreSQL Flexible Server create server workflow.
After you fill out required information on Basic and Networking tabs, navigate to Security(preview) tab. On the screen, provide Azure Active Directory (Azure AD) identity that has access to the Key Vault and Key in Key Vault in the same region where you're creating this server.
Figure 4. Security Tab for PostgreSQL - Flexible Server creation workflow
On Review Summary tab, make sure that you provided correct information in Security section and press Create button. Finally, once creation is finished, you should be able to navigate to Data Encryption (preview) screen for the server and update identity or key if necessary.
We look forward to hearing about your’ experience with this new CMK feature in Preview on Flexible server. We’re always eager to hear customer feedback, so please reach out to us at Ask Azure DB for PostgreSQL.
To learn more about our Flexible Server managed service, see the Azure Database for PostgreSQL service page.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.