Remove a Transparent Data Encryption (TDE) protector using PowerShell

Prerequisites

Note

This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install Azure PowerShell.

Important

The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. For these cmdlets, see AzureRM.Sql. The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

  • You must have an Azure subscription and be an administrator on that subscription
  • You must have Azure PowerShell installed and running.
  • This how-to guide assumes that you are already using a key from Azure Key Vault as the TDE protector for an Azure SQL Database or Data Warehouse. See Transparent Data Encryption with BYOK Support to learn more.

Overview

This how-to guide describes how to respond to a potentially compromised TDE protector for an Azure SQL Database or Data Warehouse that is using TDE with customer-managed keys in Azure Key Vault - Bring Your Own Key (BYOK) support. To learn more about BYOK support for TDE, see the overview page.

The following procedures should only be done in extreme cases or in test environments. Review the how-to guide carefully, as deleting actively used TDE protectors from Azure Key Vault can result in data loss.

If a key is ever suspected to be compromised, such that a service or user had unauthorized access to the key, it’s best to delete the key.

Keep in mind that once the TDE protector is deleted in Key Vault, all connections to the encrypted databases under the server are blocked, and these databases go offline and get dropped within 24 hours. Old backups encrypted with the compromised key are no longer accessible.

The following steps outline how to check the TDE Protector thumbprints still in use by Virtual Log Files (VLF) of a given database. The thumbprint of the current TDE protector of the database, and the database ID can be found by running: SELECT [database_id],       [encryption_state], [encryptor_type], /asymmetric key means AKV, certificate means service-managed keys/ [encryptor_thumbprint], FROM [sys].[dm_database_encryption_keys]

The following query returns the VLFs and the encryptor respective thumbprints in use. Each different thumbprint refers to different key in Azure Key Vault (AKV): SELECT * FROM sys.dm_db_log_info (database_id)

The PowerShell command Get-AzureRmSqlServerKeyVaultKey provides the thumbprint of the TDE Protector used in the query, so you can see which keys to keep and which keys to delete in AKV. Only keys no longer used by the database can be safely deleted from Azure Key Vault.

This how-to guide goes over two approaches depending on the desired result after the incident response:

  • To keep the Azure SQL databases / Data Warehouses accessible
  • To make the Azure SQL databases / Data Warehouses inaccessible

To keep the encrypted resources accessible

  1. Create a new key in Key Vault. Make sure this new key is created in a separate key vault from the potentially compromised TDE protector, since access control is provisioned on a vault level.

  2. Add the new key to the server using the Add-AzSqlServerKeyVaultKey and Set-AzSqlServerTransparentDataEncryptionProtector cmdlets and update it as the server’s new TDE protector.

    # Add the key from Key Vault to the server  
    Add-AzSqlServerKeyVaultKey `
    -ResourceGroupName <SQLDatabaseResourceGroupName> `
    -ServerName <LogicalServerName> `
    -KeyId <KeyVaultKeyId>
    
    # Set the key as the TDE protector for all resources under the server
    Set-AzSqlServerTransparentDataEncryptionProtector `
    -ResourceGroupName <SQLDatabaseResourceGroupName> `
    -ServerName <LogicalServerName> `
    -Type AzureKeyVault -KeyId <KeyVaultKeyId> 
    
  3. Make sure the server and any replicas have updated to the new TDE protector using the Get-AzSqlServerTransparentDataEncryptionProtector cmdlet.

    Note

    It may take a few minutes for the new TDE protector to propagate to all databases and secondary databases under the server.

    Get-AzSqlServerTransparentDataEncryptionProtector `
    -ServerName <LogicalServerName> `
    -ResourceGroupName <SQLDatabaseResourceGroupName>
    
  4. Take a backup of the new key in Key Vault.

    <# -OutputFile parameter is optional; 
    if removed, a file name is automatically generated. #>
    Backup-AzKeyVaultKey `
    -VaultName <KeyVaultName> `
    -Name <KeyVaultKeyName> `
    -OutputFile <DesiredBackupFilePath>
    
  5. Delete the compromised key from Key Vault using the Remove-AzKeyVaultKey cmdlet.

    Remove-AzKeyVaultKey `
    -VaultName <KeyVaultName> `
    -Name <KeyVaultKeyName>
    
  6. To restore a key to Key Vault in the future using the Restore-AzKeyVaultKey cmdlet:

    Restore-AzKeyVaultKey `
    -VaultName <KeyVaultName> `
    -InputFile <BackupFilePath>
    

To make the encrypted resources inaccessible

  1. Drop the databases that are being encrypted by the potentially compromised key.

    The database and log files are automatically backed up, so a point-in-time restore of the database can be done at any point (as long as you provide the key). The databases must be dropped before deletion of an active TDE protector to prevent potential data loss of up to 10 minutes of the most recent transactions.

  2. Back up the key material of the TDE protector in Key Vault.

  3. Remove the potentially compromised key from Key Vault

Next steps