In last week’s post, we covered a BitLocker implementation for Azure virtual machines. But as mentioned in that post, because BitLocker doesn’t fully satisfy the Payment Card Industry Data Security Standard (PCI DSS) requirement (specifically, 3.4 and 3.5.2) for data encryption at rest, we also implemented SQL Transparent Data Encryption (TDE) for all databases. TDE does fulfill that requirement, because all of the client’s cardholder data (CHD) is stored at rest in SQL databases, and this fifth post in the Azure Secure Cloud Migration series describes the TDE implementation. For an overview of the Azure Secure Cloud Migration blog series and a list of the topics being covered, see the introductory post, Preparing to Migrate to a Secure Cloud, and for more information on the PCI DSS encryption and key management requirements that drove our BitLocker and TDE implementations, and how organizations can meet them, see Encrypt All The Things – PCI DSS and Cryptography.
As with BitLocker, TDE is not unique to Azure, but it does have some implementation differences. Interestingly, the Azure process, which leverages a Hardware Security Module (HSM) backed key vault, is actually simpler than the “normal” process of implementing TDE. A good illustration of the two processes is the image below, from the SQL Server Security Blog:
In an implementation without an HSM, there is a chain of keys and certificates, all managed by the OS, that encrypt the data. However, using an HSM backed key vault cuts a few steps out of that process. You’re left with just a strong Database Master Key (DMK) in the key vault, which is used to encrypt the individual Database Encryption Keys (DEKs), which are then stored in the unencrypted boot page of each database.
Setup is a little more involved than with BitLocker:
- Create and configure an HSM backed Azure Key Vault (AKV)
- Create an asymmetric key (the DMK) and store it in the hardware portion of the key vault
- Create and configure an Azure Active Directory (AAD) application and secret, granting it permissions on the HSM backed AKV
- Install a small piece of connector software on each SQL server, allowing it to interface with the AKV
- Run SQL scripts on each SQL instance to create a cryptographic provider, create credentials, and connect to the AKV
- Run some SQL scripts on each database to create DEKs and enable TDE
We had more significant data portability concerns with TDE than we did with BitLocker – while it’s unusual to move a hard drive from one server to another, it’s commonplace to be mounting databases on other SQL servers and restoring backups to other SQL instances. For this reason, we used a single DMK for our entire Cardholder Data Environment (CDE), ensuring that any database could be restored to any SQL instance.
Microsoft’s documentation also stresses that you should protect your DMK very carefully, and even goes as far as recommending that you not generate it inside of the AKV. This is because the asymmetric key, when generated internally to the AKV, is difficult if not impossible to extract in a usable format. If the AKV is ever unavailable or is lost, along with it goes any way to unwrap the DEKs and access the databases. Unfortunately, generating the asymmetric key externally comes along with significant process burdens in a PCI DSS compliant environment – for example, the need to have dual control when creating the key, as well as the need for secure, audited, and logged storage of the key external to the vault.
To mitigate this risk, we actually leveraged two AKVs – one in each of two Azure regions, but both in the same Azure subscription. Microsoft provides PowerShell functions to export an HSM-backed asymmetric key, and import it in to a second AKV. This export is unusable outside of a key vault, and can only be imported in to a key vault in the same subscription, minimizing the risk that it can be maliciously used outside of the intended environment. During a disaster affecting one Azure region, minimal SQL configuration can be performed to repoint SQL instances to the alternate vault. Since the same DMK exists in both vaults, database access is automatically restored.
If you opt to use the AKV to store keys, whether for BitLocker, TDE, or anything else, be sure to secure them appropriately. We placed all the key vaults in their own resource groups, and granted permissions to those resource groups (and thus, the AKV objects themselves) to as small a number of people as possible – for BitLocker and TDE purposes, only the Azure AD applications being used needed permissions on the objects. Users will never directly interact with the vaults once configuration is complete. We also kept the number of people with ownership permissions on the subscriptions as low as possible, since inherited permissions in Azure cannot be removed or blocked like you may be used to in something like NTFS. Finally, we granted rights on the functions within the AKV (such as wrap, unwrap, and list) as sparingly as possible to limit the number of users or principals that can gain access to the keys and secrets stored within.
Between BitLocker and TDE, data in Azure Infrastructure as a Service VMs can be just as secure as it is when stored in traditional on-premises environments. Hopefully these implementation guidelines help you when planning and deploying your environment to meet the PCI DSS’s data encryption requirements.