Compartilhar via

TDE (Transparent Data Encryption) com chaves gerenciadas pelo cliente no nível do banco de dados

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

Este artigo descreve a Transparent Data Encryption (TDE) com chaves gerenciadas pelo cliente no nível do banco de dados para o banco de dados SQL do Azure.

Observação

A CMK de TDE no nível do banco de dados está disponível para o Banco de Dados SQL do Azure (todas as edições do Banco de Dados SQL). Ela não está disponível para a Instância Gerenciada de SQL do Azure, SQL Servers locais, VMs do Azure e Azure Synapse Analytics [pools de SQL dedicados (antigo SQL DW)].

Observação

O Microsoft Entra ID era anteriormente conhecido como Azure Active Directory (Azure AD).

Visão geral

O SQL do Azure oferece a funcionalidade de criptografia de dados inativos aos clientes por meio da TDE (Transparent Data Encryption). A ampliação da TDE com a CMK (chave gerenciada pelo cliente) permite a proteção de dados inativos em que o protetor de TDE (a chave de criptografia) é armazenado em um Azure Key Vault que criptografa as chaves de criptografia do banco de dados. No momento, a TDE com CMK é definida no nível do servidor e é herdada por todos os bancos de dados associados a esse servidor. Esse novo recurso permite definir o protetor de TDE como uma chave gerenciada pelo cliente individualmente para cada banco de dados dentro do servidor. Qualquer recurso Microsoft.Sql/servers/databases com uma propriedade encryptionProtector válida e não vazia é configurado com chaves gerenciadas pelo cliente no nível do banco de dados.

Nesse cenário, uma chave assimétrica armazenada em um AKV (Azure Key Vault) pertencente ao cliente e gerenciada por ele pode ser usada individualmente para cada banco de dados em um servidor a fim de criptografar a DEK (chave de criptografia de banco de dados), chamada de protetor de TDE. Há uma opção para adicionar chaves, remover chaves e alterar a UMI (identidade gerenciada atribuída pelo usuário) para cada banco de dados. Para saber mais sobre identidades, confira Tipos de identidade gerenciada no Azure.

A seguinte funcionalidade está disponível:

  • Identidade gerenciada atribuída pelo usuário: você pode atribuir uma só identidade gerenciada atribuída pelo usuário ao banco de dados. Essa identidade pode ser usada para acessar o Azure Key Vault e gerenciar as chaves de criptografia.
  • Gerenciamento de chaves de criptografia: você pode habilitar uma ou mais chaves de criptografia a serem adicionadas no nível do banco de dados e definir uma das chaves adicionadas como o protetor de TDE. As chaves de criptografia adicionadas usam a identidade gerenciada atribuída pelo usuário já atribuída ao banco de dados para acessar o Azure Key Vault.
  • Identidade federada do cliente: você também pode habilitar uma chave gerenciada pelo cliente (CMK) do Azure Key Vault em um locatário diferente do Microsoft Entra, a ser definido como protetor de TDE no nível do banco de dados, utilizando a identidade federada do cliente definida no banco de dados SQL do Azure. Isso permite que você gerencie a TDE com chaves armazenadas no Azure Key Vault de um locatário diferente.

Observação

Não há suporte para a identidade gerenciada atribuída pelo sistema no nível do banco de dados.

Benefícios da TDE gerenciada pelo cliente no nível do banco de dados

À medida que mais provedores de serviços, também conhecidos como ISVs (fornecedores independentes de software), usam o Banco de Dados SQL do Azure para criar serviços, muitos adotam pools elásticos para distribuir os recursos de computação com eficiência entre vários bancos de dados. Colocando cada um dos bancos de dados dos clientes em um pool elástico compartilhado, os ISVs podem aproveitar a capacidade do pool de otimizar a utilização de recursos e, ao mesmo tempo, garantir que cada banco de dados tenha recursos adequados.

No entanto, há uma limitação significativa dessa abordagem. Quando vários bancos de dados são hospedados no mesmo servidor lógico do SQL do Azure, eles compartilham o protetor de TDE no nível do servidor. Os ISVs não podem oferecer funcionalidades reais de CMK (chaves gerenciadas pelo cliente) aos clientes. Sem a capacidade de gerenciar as próprias chaves de criptografia, os clientes talvez hesitem em confiar dados confidenciais ao serviço do ISV, principalmente quando os regulamentos de conformidade exigem que eles mantenham controle total sobre as chaves de criptografia.

Com a CMK de TDE no nível do banco de dados, os ISVs podem oferecer a capacidade de CMK aos clientes e obter isolamento de segurança, pois o protetor de TDE de cada banco de dados pode ser de propriedade do respectivo cliente do ISV em um cofre de chaves da mesma propriedade. O isolamento de segurança obtido para os clientes do ISV ocorre em termos da chave e da identidade usada para acessar a chave.

O diagrama a seguir resume a nova funcionalidade indicada acima. São apresentados dois locatários separados do Microsoft Entra. O locatário Best Services que contém o servidor lógico do SQL do Azure com dois bancos de dados, DB 1 e DB 2, e o Azure Key Vault 1 com um Key 1 acessando o banco de dados DB 1 usando UMI 1. UMI 1 e Key 1 representam a configuração de nível de servidor. Por padrão, todos os bancos de dados criados inicialmente nesse servidor herdam essa configuração de TDE com CMK. O locatário Contoso representa um locatário cliente que contém Azure Key Vault 2 com um Key 2 avaliando o banco de dados DB 2 em todo o locatário como parte do suporte entre locatários da CMK no nível do banco de dados usando Key 2 e UMI 2 configurados para esse banco de dados.

Configuração e funcionamento da TDE gerenciada pelo cliente no nível do banco de dados

Para obter mais informações sobre a configuração de identidade entre locatários, veja o documento no nível do servidor Chaves gerenciadas pelo cliente entre locatários com Transparent Data Encryption.

Cenários de gerenciamento de chaves com suporte

Na seção a seguir, vamos supor que haja um servidor que consista em três bancos de dados (por exemplo Database1, Database2 e Database3).

Cenário existente

Key1 é configurado como a chave gerenciada pelo cliente no nível do servidor lógico. Todos os bancos de dados nesse servidor herdam a mesma chave.

  • Servidor – Key1 definida como CMK
  • Database1 – Key1 usada como CMK
  • Database2 – Key1 usada como CMK
  • Database3 – Key1 usada como CMK

Novo cenário com suporte: servidor lógico configurado com chave gerenciada pelo cliente

Key1 é configurado como a chave gerenciada pelo cliente no nível do servidor lógico. Uma chave gerenciada pelo cliente diferente (Key2) pode ser configurada no nível do banco de dados.

  • Servidor – Key1 definida como CMK
  • Database1 – Key2 usada como CMK
  • Database2 – Key1 usada como CMK
  • Database3 – Key1 usada como CMK

Observação

Se o servidor lógico estiver configurado com chaves gerenciadas pelo cliente para TDE, um banco de dados individual nesse servidor lógico não poderá aceitar o uso da chave gerenciada pelo serviço para Transparent Data Encryption.

Novo cenário com suporte: servidor lógico configurado com chave gerenciada pelo serviço

O servidor lógico é configurado com a SMK (chave gerenciada pelo serviço) para TDE. Uma chave gerenciada pelo cliente diferente (Key2) pode ser configurada no nível do banco de dados.

  • Servidor – Conjunto de chaves gerenciadas pelo serviço como o protetor de TDE
  • Database1 – Key2 definida como CMK
  • Database2 – Conjunto de chaves gerenciadas pelo serviço como o protetor de TDE
  • Database3 – Conjunto de chaves gerenciadas pelo serviço como o protetor de TDE

Reverter para criptografia no nível do servidor

Database1 é configurado com uma chave gerenciada pelo cliente no nível do banco de dados para TDE enquanto o servidor lógico é configurado com a chave gerenciada pelo serviço. O Database1 pode ser revertido para usar a chave gerenciada pelo serviço no nível do servidor lógico.

Observação

Se o servidor lógico estiver configurado com CMK para TDE, o banco de dados configurado com CMK no nível do banco de dados não poderá ser revertido para a criptografia no nível do servidor.

Embora só haja suporte para a operação de reversão quando o servidor lógico está configurado com a chave gerenciada pelo serviço ao usar a TDE, um banco de dados configurado com CMK no nível do banco de dados poderá ser restaurado para um servidor configurado com CMK, desde que o servidor tenha acesso a todas as chaves usadas pelo banco de dados de origem com uma identidade válida.

Cofre de chaves e requisitos de identidade gerenciada

Os mesmos requisitos para configurar chaves do AKV (Azure Key Vault) e identidades gerenciadas, incluindo configurações de chave e permissões concedidas à identidade que se aplicam ao recurso CMK (chave gerenciada pelo cliente) no nível do servidor também se aplicam à CMK no nível do banco de dados. Para obter mais informações, confira TDE (Transparent Data Encryption) com CMK e Identidades Gerenciadas com CMK.

Gerenciamento de chaves

A rotação do protetor de TDE de um banco de dados significa alternar para uma nova chave assimétrica que protege o banco de dados. A rotação de chave é uma operação online e só deve levar apenas alguns segundos para ser concluída. A operação só descriptografa e criptografa novamente a chave de criptografia do banco de dados, não todo o banco de dados. Depois que uma identidade gerenciada atribuída pelo usuário válida for atribuída a um banco de dados, a rotação da chave no nível do banco de dados será uma operação CRUD de banco de dados que envolve a atualização da propriedade de protetor de criptografia do banco de dados. Set-AzSqlDatabase e a propriedade -EncryptionProtector podem ser usadas para fazer a rotação das chaves. Para criar um banco de dados configurado com a CMK no nível do banco de dados, New-AzSqlDatabase pode ser usado com os parâmetros -EncryptionProtector, -AssignIdentity e -UserAssignedIdentityId.

Novas chaves podem ser adicionadas e chaves existentes podem ser removidas do banco de dados usando solicitações semelhantes e modificando a propriedade keys do recurso de banco de dados. O comando Set-AzSqlDatabase com o parâmetro -KeyList e -KeysToRemove pode ser usado para essas operações. Para recuperar a configuração de protetor de criptografia, identidade e chaves, o comando Get-AzSqlDatabase pode ser usado. O recurso Microsoft.Sql/servers/databases do Azure Resource Manager por padrão mostra apenas o protetor de TDE e a identidade gerenciada configurados no banco de dados. Para expandir a lista completa de chaves, outros parâmetros como -ExpandKeyList são necessários. Além disso, -KeysFilter "current" e um valor de momento (por exemplo, 2023-01-01) podem ser usado para recuperar as chaves atuais usadas e as chaves usadas no passado em um momento específico.

Rotação automática de chaves

A rotação automática de chave está disponível no nível do banco de dados e pode ser usada com chaves do Azure Key Vault. A rotação é acionada quando uma nova versão da chave é detectada, e será girada automaticamente em até de 24 horas. Para obter informações sobre como configurar a rotação automática de chave usando o portal do Azure, o PowerShell ou a CLI do Azure, confira Rotação automática da chave no nível de banco de dados.

Permissão para gerenciamento de chave

Dependendo do modelo de permissão do cofre de chaves (política de acesso ou RBAC do Azure), o acesso ao cofre de chaves pode ser concedido criando uma política de acesso no cofre de chaves ou criando uma nova atribuição de função do RBAC do Azure.

Modelo de permissão de política de acesso

Para que o banco de dados use o protetor de TDE armazenado no AKV para criptografia de DEK, o administrador do cofre de chaves precisa conceder os seguintes direitos de acesso à identidade gerenciada atribuída pelo usuário do banco de dados, usando a identidade exclusiva do Microsoft Entra:

  • get – Para recuperar a parte pública e as propriedades da chave no Azure Key Vault.
  • wrapKey – Para proteger (criptografar) a DEK.
  • unwrapKey – Para desproteger (descriptografar) a DEK.

Modelo de permissão do RBAC do Azure

Para que o banco de dados use o protetor TDE armazenado no AKV para criptografia da DEK, uma nova atribuição de função de RBAC do Azure com a função Key Vault Crypto Service Encryption User deve ser adicionada para a identidade gerenciada atribuída pelo usuário do banco de dados usando sua identidade exclusiva do Microsoft Entra.

Chaves gerenciadas pelo cliente entre locatários

Chaves gerenciadas pelo cliente entre locatários com Transparent Data Encryption descrevem como configurar uma ID do cliente federada para CMK no nível do servidor. Uma configuração semelhante precisa ser feita para a CMK no nível do banco de dados e a ID do cliente federada precisa ser adicionada como parte das solicitações de API Set-AzSqlDatabase ou New-AzSqlDatabase.

Observação

Se o aplicativo multilocatário não tiver sido adicionado à política de acesso do cofre de chaves com as permissões necessárias (Get, Wrap Key, Unwrap Key), usando um aplicativo para federação de identidade no portal do Azure mostrará um erro. Verifique se as permissões foram configuradas corretamente antes de configurar a identidade do cliente federado.

Um banco de dados configurado com a CMK no nível do banco de dados poderá ser revertido para a criptografia no nível do servidor se o servidor lógico estiver configurado com uma chave gerenciada pelo serviço usando Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

No caso de um protetor de TDE inacessível, conforme descrito em TDE (Transparent Data Encryption) com CMK, depois que o acesso à chave for corrigido, Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation poderá ser usado para que o banco de dados fique acessível.

Observação

O gerenciamento de identidades e chaves para TDE com chaves gerenciadas pelo cliente no nível do banco de dados descreve as operações de gerenciamento de identidade e chave para CMK no nível do banco de dados, juntamente com exemplos do Powershell, da CLI do Azure e da API REST.

Considerações adicionais

  • Se a TDE com CMK já estiver habilitada no nível do servidor, a definição da CMK para um banco de dados específico substituirá a configuração de CMK no nível do servidor (a DEK do banco de dados será criptografada novamente com o protetor de TDE no nível do banco de dados).
  • As alterações ou rotações de chave no nível do servidor lógico não afetam as configurações de CMK no nível do banco de dados e o banco de dados continua a usar a própria configuração de CMK.
  • A CMK no nível do banco de dados não é compatível com T-SQL (Transact-SQL).
  • A UMI (identidade gerenciada atribuída pelo usuário) do servidor lógico pode ser usada no nível do banco de dados. No entanto, é recomendável usar uma UMI designada para a CMK no nível do banco de dados.
  • As configurações de CMK entre locatários no nível do servidor não afetam os bancos de dados individuais configurados com a CMK no nível do banco de dados e continuam a usar o próprio locatário único ou configuração entre locatários.
  • Somente uma identidade gerenciada atribuída pelo usuário pode ser definida no nível do banco de dados.

Observação

As identidades gerenciadas no banco de dados precisam ser reatribuídas se o banco de dados for renomeado.

Migração de bancos de dados existentes para CMK no nível do banco de dados

Novos bancos de dados podem ser configurados com a CMK no nível do banco de dados durante a criação e os bancos de dados existentes em servidores configurados com chaves gerenciadas pelo serviço podem ser migrados para a CMK no nível do banco de dados usando as operações descritas em Gerenciamento de identidades e chaves da TDE com chaves gerenciadas pelo cliente no nível do banco de dados. Para migrar bancos de dados configurados com uma CMK de nível de servidor ou replicação geográfica, outras etapas serão necessárias, conforme descrito nas seções a seguir.

Banco de dados configurado com uma CMK no nível do servidor sem replicação geográfica

  1. Use sys.dm_db_log_info (Transact-SQL) – SQL Server para o banco de dados e procure VLFs (arquivos de log virtual) que estejam ativos.
  2. Para todos os VLFs ativos, registre o vlf_encryptor_thumbprint do resultado sys.dm_db_log_info.
  3. Use a exibição sys.dm_database_encryption_keys (Transact-SQL) – SQL Server do banco de dados para verificar encryptor_thumbprint. Registre o encryptor_thumbprint.
  4. Use o cmdlet Get-AzSqlServerKeyVaultKey para obter todas as chaves no nível do servidor configuradas no servidor lógico. Nos resultados, escolha os que têm a mesma impressão digital que corresponde à lista do resultado acima.
  5. Faça uma chamada à API de atualização do banco de dados que você deseja migrar, juntamente com o protetor de identidade e criptografia. Passe as chaves acima como chaves no nível do banco de dados usando Set-AzSqlDatabase com os parâmetros -UserAssignedIdentityId, -AssignIdentity, -KeyList, -EncryptionProtector (e, se necessário, -FederatedClientId).

Importante

A identidade usada na solicitação de atualização do banco de dados precisa ter acesso a todas as chaves passadas como entrada.

Banco de dados configurado com CMK no nível do servidor com replicação geográfica

  1. Siga as etapas (1) a (4) mencionadas na seção anterior para recuperar a lista de chaves que serão necessárias para a migração.
  2. Faça uma chamada à API de atualização dos bancos de dados primário e secundário que você deseja migrar, juntamente com a identidade e as chaves acima como chaves no nível do banco de dados usando Set-AzSqlDatabase e o parâmetro -KeyList. Não defina o protetor de criptografia ainda.
  3. A chave no nível do banco de dados que você deseja usar como o protetor primário nos bancos de dados precisa ser adicionada primeiro ao banco de dados secundário. Use Set-AzSqlDatabase com -KeyList para adicionar essa chave ao banco de dados secundário.
  4. Depois que a chave de protetor de criptografia for adicionada ao banco de dados secundário, use Set-AzSqlDatabase para defini-la como o protetor de criptografia no banco de dados primário usando o parâmetro -EncryptionProtector.
  5. Defina a chave como o protetor de criptografia no banco de dados secundário, conforme descrito em (4) para concluir a migração.

Importante

Para migrar bancos de dados configurados com uma chave gerenciada pelo serviço no nível do servidor e a replicação geográfica, siga as etapas (3), (4) e (5) desta seção.

Replicação geográfica e alta disponibilidade

Em cenários de replicação geográfica ativa e grupos de failover, os servidores primários e secundários envolvidos podem ser vinculados ao mesmo cofre de chaves (em qualquer região) ou a cofres de chaves separados. Se cofres de chaves separados forem vinculados aos servidores primário e secundário, o cliente será responsável por manter a consistência do material de chave nos cofres de chaves, de modo que o secundário geográfico esteja em sincronia e possa assumir o uso da mesma chave do cofre de chaves vinculado, caso o servidor primário fique inacessível devido a uma interrupção na região e um failover seja disparado. Até quatro servidores secundários podem ser configurados, e não há suporte para o encadeamento (secundários de secundários).

Para estabelecer a replicação geográfica ativa para um banco de dados que foi configurado com a CMK no nível do banco de dados, uma réplica secundária precisa ser criada com uma identidade gerenciada atribuída pelo usuário válida e uma lista de chaves atuais sendo usadas pelo banco de dados primário. A lista de chaves atuais pode ser recuperada do banco de dados primário usando filtros e parâmetros de consulta necessários ou usando o PowerShell e a CLI do Azure. As etapas necessárias para configurar uma réplica geográfica desse banco de dados são:

  1. Preencha a lista de chaves usadas pelo banco de dados primário com o comando Get-AzSqlDatabase e os parâmetros -ExpandKeyList e -KeysFilter "current". Exclua -KeysFilter se você quiser recuperar todas as chaves.
  2. Selecione a identidade gerenciada atribuída pelo usuário (e a ID do cliente federada se estiver configurando o acesso entre locatários).
  3. Crie um banco de dados como um secundário usando New-AzSqlDatabaseSecondary e forneça a lista preenchida de chaves obtidas do banco de dados de origem e a identidade acima (e a ID do cliente federada para configurar o acesso entre locatários) na chamada à API usando os parâmetros -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (e, se necessário, -FederatedClientId).
  4. Use New-AzSqlDatabaseCopy para criar uma cópia do banco de dados com os mesmos parâmetros na etapa anterior.

Importante

Um banco de dados configurado com a CMK no nível do banco de dados precisa ter uma réplica (ou cópia) configurada com a CMK no nível do banco de dados. A réplica não pode usar as configurações de criptografia no nível do servidor.

Para usar um banco de dados configurado com a CMK no nível do banco de dados em um grupo de failover, as etapas acima para criar um réplica secundária com o mesmo nome que a réplica primária precisam ser usadas no servidor secundário. Depois que esse réplica secundária for configurada, os bancos de dados poderão ser adicionados ao grupo de failover.

Os bancos de dados configurados com a CMK no nível do banco de dados não dão suporte à criação automatizada do secundário quando adicionados a um grupo de failover.

O artigo Configurar a replicação geográfica e restauração de backup para Transparent Data Encryption com chaves gerenciadas pelo cliente no nível do banco de dados descreve como configurar a replicação geográfica e grupos de failover usando APIs REST, o PowerShell e a CLI do Azure.

Observação

Todas as práticas recomendadas sobre replicação geográfica e alta disponibilidade realçadas em TDE (Transparent Data Encryption) com CMK para CMK no nível do servidor se aplicam à CMK no nível do banco de dados.

Backup e restauração para bancos de dados usando TDE com chave gerenciada pelo cliente no nível do banco de dados

Depois que um banco de dados for criptografado com a TDE usando uma chave do Azure Key Vault, todos os backups gerados também serão criptografados com o mesmo protetor de TDE. Quando o protetor de TDE é alterado, os backups antigos do banco de dados não são atualizados para usar o protetor de TDE mais recente. Para restaurar um backup criptografado com um protetor de TDE do Azure Key Vault configurado no nível do banco de dados, verifique se o material da chave está disponível no servidor de destino. É recomendável manter todas as versões antigas do protetor de TDE no Key Vault para que os backups do banco de dados possam ser restaurados.

Importante

Somente um protetor de TDE pode ser definido para um banco de dados. No entanto, várias chaves adicionais podem ser passadas a um banco de dados durante a restauração sem serem marcadas como protetor de TDE. Essas chaves não são usadas para proteger a DEK, mas poderão ser usadas durante a restauração de um backup se o arquivo de backup estiver criptografado com a chave com a impressão digital correspondente.

Recuperação pontual

As seguintes etapas são necessárias para uma restauração pontual de um banco de dados configurado com chaves gerenciadas pelo cliente no nível do banco de dados:

  1. Preencha a lista de chaves usadas pelo banco de dados primário com o comando Get-AzSqlDatabase e os parâmetros -ExpandKeyList e -KeysFilter "2023-01-01". 2023-01-01 é um exemplo de momento para o qual você deseja restaurar o banco de dados. Exclua -KeysFilter se você quiser recuperar todas as chaves.
  2. Selecione a identidade gerenciada atribuída pelo usuário (e a ID do cliente federada se estiver configurando o acesso entre locatários).
  3. Use Restore-AzSqlDatabase com o parâmetro -FromPointInTimeBackup e forneça a lista preenchida de chaves obtida nas etapas acima e a identidade acima (e a ID do cliente federada para configurar o acesso entre locatários) na chamada à API usando os parâmetros -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (e, se necessário, -FederatedClientId).

Observação

A redefinição de um banco de dados sem a propriedade -EncryptionProtector com todas as chaves válidas vai redefini-lo para usar a criptografia no nível do servidor. Isso pode ser útil para reverter uma configuração de chave gerenciada pelo cliente no nível do banco de dados para a configuração de chave gerenciada pelo cliente no nível do servidor.

Restauração de banco de dados removido

As seguintes etapas são necessárias para uma restauração de banco de dados removido de um banco de dados configurado com chaves gerenciadas pelo cliente no nível do banco de dados:

  1. Preencha a lista de chaves usadas pelo banco de dados primário usando o comando Get-AzSqlDeletedDatabaseBackup e o parâmetro -ExpandKeyList. É recomendável passar todas as chaves que o banco de dados de origem estava usando, mas, como alternativa, a restauração também pode ser tentada com as chaves fornecidas pelo tempo de exclusão como -KeysFilter.
  2. Selecione a identidade gerenciada atribuída pelo usuário (e a ID do cliente federada se estiver configurando o acesso entre locatários).
  3. Use Restore-AzSqlDatabase com o parâmetro -FromDeletedDatabaseBackup e forneça a lista preenchida de chaves obtidas nas etapas acima e a identidade acima (e a ID do cliente federada para configurar o acesso entre locatários) na chamada à API usando os parâmetros -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (e, se necessário, -FederatedClientId).

Restauração geográfica

As seguintes etapas são necessárias para uma restauração geográfica de um banco de dados configurado com chaves gerenciadas pelo cliente no nível do banco de dados:

  • Preencha a lista de chaves usadas pelo banco de dados primário usando o comando Get-AzSqlDatabaseGeoBackup e o -ExpandKeyList para recuperar todas as chaves.
  • Selecione a identidade gerenciada atribuída pelo usuário (e a ID do cliente federada se estiver configurando o acesso entre locatários).
  • Use Restore-AzSqlDatabase com o parâmetro -FromGeoBackup e forneça a lista preenchida de chaves obtidas nas etapas acima e a identidade acima (e a ID do cliente federada para configurar o acesso entre locatários) na chamada à API usando os parâmetros -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (e, se necessário, -FederatedClientId).

Importante

É recomendável que todas as chaves usadas pelo banco de dados sejam preservadas para restaurar o banco de dados. Também é recomendável passar todas essas chaves para o destino de restauração.

Observação

Os backups LTR (retenção de backup de longo prazo) não fornecem a lista de chaves usadas pelo backup. Para restaurar um backup LTR, todas as chaves usadas pelo banco de dados de origem precisam ser passadas para o destino de restauração LTR.

Para saber mais sobre a recuperação de backup do Banco de Dados SQL com a CMK no nível do banco de dados com exemplos usando o PowerShell, a CLI do Azure e as APIs REST, confira Configurar a replicação geográfica e a restauração de backup para Transparent Data Encryption com chaves gerenciadas pelo cliente no nível do banco de dados.

Limitações

O recurso de chaves gerenciadas pelo cliente no nível do banco de dados não dá suporte a rotações de chave quando os arquivos de log virtual do banco de dados são criptografados com uma chave antiga diferente do protetor primário atual do banco de dados. O erro gerado nesse caso é:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: a rotação de chave do protetor de TDE no nível do banco de dados é bloqueada quando transações ativas estão mantendo o log criptografado com chaves antigas.

Para entender melhor esse cenário, vamos considerar a seguinte linha do tempo:

Um exemplo de linha do tempo de rotações de chave em um banco de dados configurado com chaves gerenciadas pelo cliente no nível do banco de dados.

  • Time t0 = Um banco de dados é criado sem criptografia
  • Time t1 = Esse banco de dados está protegido por Thumbprint A, que é uma chave gerenciada pelo cliente no nível do banco de dados.
  • Time t2 = O protetor de banco de dados obteve uma rotação para uma nova chave gerenciada pelo cliente no nível do banco de dados, Thumbprint B.
  • Time t3 = Uma alteração de protetor para Thumbprint C foi solicitada.
  • Se os VLFs ativos estiverem usando Thumbprint A, a rotação não será permitida.
  • Se os VLFs ativos não estiverem usando Thumbprint A, a rotação será permitida.

Você pode usar a exibição sys.dm_db_log_info (Transact-SQL) – SQL Server do banco de dados e procurar arquivos de log virtuais ativos. Você verá um VLF ativo criptografado com a primeira chave (por exemplo, Thumbprint A). Depois que um log suficiente for gerado pela inserção de dados, esse VLF antigo será liberado e você poderá executar outra rotação de chave.

Se você acha que algo está segurando o log por mais tempo do que o esperado, confira a seguinte documentação para obter mais solução de problemas:

Próximas etapas

Verifique a seguinte documentação em várias operações de CMK no nível do banco de dados: