Secure PostgreSQL Flex Server data with encryption and customer managed keys (Preview)
Published Oct 18 2022 04:55 PM 1,825 Views
Microsoft

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 restdata in use and data in motion.

 

cybersecurity-5642004_1920.jpg

 

What is data encryption? 

 

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 for various data states 

 

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.

 

  • Data in transit refers to information that is traveling from one point to another. This includes email, collaborative tools, instant messengers, and nearly any public communication channel. Given its accessibility over the internet or private business network as it travels from one location to another, this data is often less secure than inactive data. As a result, data in transit is a potential target for hackers.  To protect data in transit, Azure Database for PostgreSQL encrypts in-transit data with Secure Sockets Layer and Transport Layer Security (SSL/TLS). Encryption is enforced by default. See this guide for more details. 
  • Data at rest refers to data that is not actively traveling between devices or networks. Because this data is often kept or preserved, it is less risky than data in transit. Data at rest can be information saved in a database or data kept on a hard drive, computer, or portable device.  Therefore, encryption at rest provides additional important defense-in-depth mechanism in case other security measures fail. For storage encryption, Azure Database for PostgreSQL uses the FIPS 140-2 validated cryptographic module. Data is encrypted on disk, including backups and the temporary files created while queries are running.

    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. 

How does Microsoft Azure encrypt data at rest

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.

 

azure-security-encryption-atrest-fig1.png

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.

 

Introducing Customer Managed Key in PostgreSQL Flexible Server in Preview

 

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.

 

postgresql-data-encryption-overview.png

 

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:

  • get: For retrieving the public part and properties of the key in the key vault.
  • list: For listing\iterating through keys in the key vault.
  • wrapKey: To be able to encrypt the DEK. The encrypted DEK is stored in the Azure Database for PostgreSQL.
  • unwrapKey: To be able to decrypt the DEK. Azure Database for PostgreSQL needs the decrypted DEK to encrypt/decrypt the data

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.

 

Monitor encryption key access in Azure 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:

  • Azure Resource Health: An inaccessible database that has lost access to the Customer Key shows as "Inaccessible" after the first connection to the database has been denied.
  • 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 if you create alerts for these events as soon as possible.
  • Action groups: Define these groups to send you notifications and alerts based on your preferences.

Now after all the theory lets setup data encryption with CMK (Preview) on new Azure Database for PostgreSQL - Flexible Server

 

Setting up Customer Managed Key during Flexible server creation

 

Before we begin setting up CMK, we need to make sure following prerequisites are done:

  •  Azure Active Directory (Azure AD) user managed identity in region where Postgres Flex Server will need be created. Follow this tutorial to create identity.
  • Key Vault with key in region where Postgres Flex Server will be created. Follow this tutorial to create Key Vault and generate key.  Please follow these requirements when creating Key Vault with encryption key. 

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

 

Screenshot-cmk-creation-main.png

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.

 

Screenshot-cmk-security-tab.png

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.

 

Additional Resources

 

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.

 

Co-Authors
Version history
Last update:
‎Oct 29 2022 02:36 PM
Updated by: