Azure SQL with TDE - How to secure backups when TDE Protector key has been compromised

Question

I am aware of the basic process that we need to perform when a key has been compromised, which basically involves rotating the key and revoking the compromised one - as per steps detailed in https://learn.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-remove-tde-protector

However in Azure SQL, the LTRR backups are managed within the service - stored on a storage account that isn't directly accessible by the customer. My understanding are these backups are still encrypted with the old key.

Should the bad actor who has a copy of the key get hold of these backups, they could in theory then have access to the data contained correct?

Therefore what then, is the process to secure these old backups that have been encrypted with the old key?

Answer 1

Hi, @Daniel H Welcome to the Microsoft Q&A forum, Thanks for posting your question.

I understand you want to know about how the long-term retention backups (LTRR) that are managed within the Azure SQL service, are stored in a storage account that is not directly accessible and encrypted with the old key. correct me if my understanding is wrong.

As long as you need the old backups you have to keep the old key in case you want to restore it.

If the bad actor gets access to the key, old or new, there is a security problem.

Regards

Geetha

Answer 2

@Daniel H what is the process to mitigate this issue with respect to LTRR backups that were made using the old key?

We recommend you to immediately restore the backup, change the key, take another backup, and delete the old backup and key from the key vault.

If it is a managed key or service managed key?

• If it's a customer-managed key, compromising the key is not sufficient to access the data, the attacker needs access to the storage account with the storage account key since the storage account that store the backup is encrypted by default.
• The attacker needs access to the managed identity that has permission to the key. This includes the Application Id and the MSI certificate. The MSI certificate is also encrypted by another service-managed certificate which would be difficult for the attacker to gain access to it and decrypt.
• Overall accessing backup is harder than you think.  But to mitigate this issue,  as I said above we recommend you to immediately restore the backup, change the key, take another backup, and delete the old backup and key from the key vault.

 The same logic would apply to service managed key,  

• To get to the LTR backup customer need to gain access to the service-managed certificate which is also encrypted by another service certificate.
• The attacker also needs to access the storage account that is encrypted to steal the customer data and decrypt it.
• We provide a service guarantee that any access to the customer data requires high-privilege access  (JIT) and all requests are reviewed and audited.

I hope this information helps, please let me know if you have any additional questions.

Regards

Geetha