Criptografia de dados transparente (TDE) com chaves gerenciadas pelo cliente no nível do banco de dados

Aplica-se a:Banco de Dados SQL do Azure

Este artigo descreve a criptografia de dados transparente (TDE) com chaves gerenciadas pelo cliente no nível do banco de dados para o Banco de Dados SQL do Azure.

Nota

O TDE CMK de nível de banco de dados está disponível para o Banco de Dados SQL do Azure (todas as edições do Banco de Dados SQL). Ele não está disponível para Instância Gerenciada SQL do Azure, SQL Server local, VMs do Azure e Azure Synapse Analytics (pools SQL dedicados (anteriormente SQL DW)).

Nota

Microsoft Entra ID é o novo nome para o Azure Ative Directory (Azure AD). Estamos atualizando a documentação neste momento.

Descrição geral

O Azure SQL oferece capacidade de criptografia em repouso aos clientes por meio da criptografia de dados transparente (TDE). A extensão da TDE com chave gerenciada pelo cliente (CMK) permite a proteção de dados em repouso onde o protetor TDE (a chave de criptografia) é armazenado em um Cofre de Chaves do Azure que criptografa as chaves de criptografia do banco de dados. Atualmente, o TDE com CMK é definido no nível do servidor e é herdado por todos os bancos de dados criptografados associados a esse servidor. Este novo recurso permite definir o protetor TDE como uma chave gerenciada pelo cliente individualmente para cada banco de dados dentro do servidor. Qualquer Microsoft.Sql/servers/databases recurso com uma propriedade válida e não vazia encryptionProtector é configurado com chaves gerenciadas pelo cliente no nível do banco de dados.

Nesse cenário, uma chave assimétrica armazenada em um Cofre de Chaves do Azure (AKV) de propriedade e gerenciado pelo cliente pode ser usada individualmente para cada banco de dados dentro de um servidor para criptografar a chave de criptografia de banco de dados (DEK), chamada protetor TDE. Há uma opção para adicionar chaves, remover chaves e alterar a identidade gerenciada atribuída pelo usuário (UMI) para cada banco de dados. Para obter mais informações sobre identidades, consulte Tipos de identidade gerenciados no Azure.

A seguinte funcionalidade está disponível:

• Identidade gerenciada atribuída pelo usuário: você pode atribuir uma única identidade gerenciada atribuída pelo usuário ao banco de dados. Essa identidade pode ser usada para acessar o Cofre de Chaves do Azure e gerenciar 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 TDE. As chaves de criptografia que estão sendo adicionadas usam a identidade gerenciada atribuída pelo usuário já atribuída ao banco de dados para acessar o Cofre de Chaves do Azure.
• Identidade de cliente federado: você também pode habilitar uma chave gerenciada pelo cliente (CMK) do Cofre de Chaves do Azure em um locatário diferente do Microsoft Entra para ser definida como protetor TDE no nível do banco de dados, utilizando o conjunto de identidades de cliente federado no Banco de Dados SQL do Azure. Isso permite que você gerencie o TDE com chaves armazenadas no Cofre de Chaves do Azure de um locatário diferente.

Nota

A identidade gerenciada atribuída pelo sistema não é suportada no nível do banco de dados.

Benefícios do TDE gerenciado 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 seus serviços, muitos estão se voltando para pools elásticos como uma maneira de distribuir recursos de computação de forma eficiente em vários bancos de dados. Ao ter cada um dos bancos de dados de seus 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 para essa abordagem. Quando vários bancos de dados são hospedados no mesmo servidor lógico SQL do Azure, eles compartilham o protetor TDE no nível do servidor. Os ISVs não conseguem oferecer verdadeiros recursos de chaves gerenciadas pelo cliente (CMK) para seus clientes. Sem a capacidade de gerenciar suas próprias chaves de criptografia, os clientes podem hesitar em confiar dados confidenciais ao serviço do ISV, especialmente se as regulamentações de conformidade exigirem que mantenham controle total sobre suas chaves de criptografia.

Com o TDE CMK no nível do banco de dados, os ISVs podem oferecer a capacidade de CMK aos seus clientes e alcançar o isolamento de segurança, já que o protetor TDE de cada banco de dados pode potencialmente ser de propriedade do respetivo cliente ISV em um cofre de chaves de sua propriedade. O isolamento de segurança alcançado para os clientes do ISV é tanto em termos da chave quanto da identidade usada para acessar a chave.

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

Para obter mais informações sobre a configuração de identidade entre locatários, consulte o documento de nível de servidor Chaves gerenciadas pelo cliente entre locatários com criptografia de dados transparente.

Principais cenários de gerenciamento suportados

Para a seção a seguir, vamos supor que haja um servidor que consiste em três bancos de dados (por exemplo Database1, , Database2e Database3).

Cenário existente

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

• Servidor – Key1 definido como CMK
• Database1 – Key1 utilizado como CMK
• Database2 – Key1 utilizado como CMK
• Database3 – Key1 utilizado como CMK

Novo cenário suportado: 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 definido como CMK
• Database1 – Key2 utilizado como CMK
• Database2 – Key1 utilizado como CMK
• Database3 – Key1 utilizado como CMK

Nota

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á ser aceito para usar a chave gerenciada pelo serviço para criptografia de dados transparente.

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

O servidor lógico é configurado com chave gerenciada pelo serviço (SMK) 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 protetor TDE
• Database1 – Key2 definido como CMK
• Database2 – Conjunto de chaves gerenciadas pelo serviço como protetor TDE
• Database3 – Conjunto de chaves gerenciadas pelo serviço como protetor TDE

Revertendo para a criptografia no nível do servidor

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

Nota

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 a operação de reversão só seja suportada se o servidor lógico estiver configurado com chave gerenciada por serviço ao usar TDE, um banco de dados configurado com CMK no nível de banco de dados pode ser restaurado para um servidor configurado com CMK, desde que o servidor tenha acesso a todas as chaves que estão sendo 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 Azure Key Vault (AKV) e identidades gerenciadas, incluindo configurações de chave e permissões concedidas à identidade que se aplicam ao recurso de chave gerenciada pelo cliente (CMK) no nível do servidor, também se aplicam à CMK no nível do banco de dados. Para obter mais informações, consulte Criptografia de dados transparente (TDE) com CMK e Identidades gerenciadas com CMK.

Gestão de chaves

Girar o protetor TDE para um banco de dados significa alternar para uma nova chave assimétrica que protege o banco de dados. A rotação de chaves é uma operação on-line e deve levar apenas alguns segundos para ser concluída. A operação apenas 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 tiver sido atribuída a um banco de dados, girar a chave no nível do banco de dados é uma operação CRUD do banco de dados que envolve a atualização da propriedade do protetor de criptografia do banco de dados. Set-AzSqlDatabase e a propriedade -EncryptionProtector podem ser usados para girar chaves. Para criar um novo banco de dados configurado com CMK no nível de banco de dados, New-AzSqlDatabase pode ser usado com os -EncryptionProtectorparâmetros , -AssignIdentitye -UserAssignedIdentityId .

Novas chaves podem ser adicionadas e as chaves existentes podem ser removidas do banco de dados usando solicitações semelhantes e modificando a propriedade keys para o recurso de banco de dados. Set-AzSqlDatabase com o parâmetro -KeyList e -KeysToRemove pode ser usado para essas operações. Para recuperar o protetor de criptografia, a identidade e a configuração de chaves, Get-AzSqlDatabase pode ser usado. O recurso Microsoft.Sql/servers/databases do Azure Resource Manager por padrão mostra apenas o protetor 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, e um valor point-in-time (por exemplo, -KeysFilter "current"2023-01-01) pode ser usado para recuperar as chaves atuais usadas e as chaves usadas no passado em um ponto específico no tempo.

Rotação automática de chaves

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

Permissão para gerenciamento de chaves

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 RBAC do Azure.

Modelo de permissão de política de acesso

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

• get - para recuperar a parte pública e as propriedades da chave no Cofre da Chave do Azure.
• wrapKey - para ser capaz de proteger (encriptar) DEK.
• unwrapKey - para poder desproteger (desencriptar) DEK.

Modelo de permissões do RBAC do Azure

Para que o banco de dados use o protetor TDE armazenado no AKV para criptografia do DEK, uma nova atribuição de função 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 criptografia de dados transparente descreve como configurar um ID de cliente federado para CMK no nível do servidor. Configuração semelhante precisa ser feita para CMK no nível de banco de dados e o ID do cliente federado deve ser adicionado como parte das solicitações de API Set-AzSqlDatabase ou New-AzSqlDatabase .

Nota

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

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

No caso de um protetor TDE inacessível, conforme descrito em Criptografia de dados transparente (TDE) com CMK, uma vez que o acesso à chave tenha sido corrigido, Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation pode ser usado para tornar o banco de dados acessível.

Nota

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 chaves para CMK no nível do banco de dados em detalhes, juntamente com o Powershell, a CLI do Azure e exemplos da API REST.

Considerações adicionais

• Se a TDE com CMK já estiver habilitada no nível do servidor, a configuração da CMK para um banco de dados específico substituirá a configuração da CMK no nível do servidor (a DEK do banco de dados será criptografada novamente com o protetor TDE no nível do banco de dados).
• Quaisquer 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 sua própria configuração de CMK.
• A CMK no nível de banco de dados não é suportada pelo Transact-SQL (T-SQL).
• A identidade gerenciada atribuída pelo usuário (UMI) 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 de nível de banco de dados.
• As configurações de CMK entre locatários no nível do servidor não afetam bancos de dados individuais configurados com CMK no nível de banco de dados e eles continuam a usar sua própria configuração de locatário único ou locatário cruzado.
• Somente uma única identidade gerenciada atribuída pelo usuário pode ser definida no nível do banco de dados.

Nota

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

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

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

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

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

Importante

A identidade usada na solicitação de atualização do banco de dados deve ter acesso a todas as chaves que estão sendo 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 de API de banco de dados de atualização para o banco de dados primário e secundário que você deseja migrar, juntamente com a identidade e as chaves acima como chaves de nível de banco de dados usando Set-AzSqlDatabase e o -KeyList parâmetro. Ainda não defina o protetor de criptografia.
3. A chave de nível de banco de dados que você deseja usar como protetor primário nos bancos de dados deve ser adicionada primeiro ao banco de dados secundário. Use Set-AzSqlDatabase com -KeyList para adicionar essa chave no banco de dados secundário.
4. Depois que a chave do protetor de criptografia for adicionada ao banco de dados secundário, use o Set-AzSqlDatabase para defini-lo como o protetor de criptografia no banco de dados primário usando o -EncryptionProtector parâmetro.
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 por serviço no nível do servidor e 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 bancos de dados 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 os cofres de chaves separados estiverem ligados aos servidores primários e secundários, o cliente é responsável por manter o material da chave nos cofres de chaves consistente, para que a georreplicação secundária esteja sincronizada e possa assumir o controlo com a mesma chave do cofre de chaves ligado se o principal ficar inacessível devido a uma falha na região e for acionada uma ativação pós-falha. Até quatro secundários podem ser configurados e o encadeamento (secundários de secundários) não é suportado.

Para estabelecer a replicação geográfica ativa para um banco de dados que foi configurado com CMK no nível de banco de dados, uma réplica secundária deve 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. Pré-preencha a lista de chaves usadas pelo banco de dados primário usando o comando Get-AzSqlDatabase e os -ExpandKeyList parâmetros and -KeysFilter "current" . Exclua -KeysFilter se desejar recuperar todas as chaves.
2. Selecione a identidade gerenciada atribuída pelo usuário (e a ID do cliente federado se estiver configurando o acesso entre locatários).
3. Crie um novo banco de dados como secundário usando New-AzSqlDatabaseSecondary e forneça a lista pré-preenchida de chaves obtidas do banco de dados de origem e a identidade acima (e DI do cliente federado se configurar o acesso entre locatários) na chamada de API usando os -KeyListparâmetros , , , -EncryptionProtector (e se necessário, -AssignIdentity-UserAssignedIdentityId-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 CMK no nível de banco de dados deve ter uma réplica (ou cópia) configurada com CMK no nível de banco de dados. A réplica não pode usar configurações de criptografia no nível do servidor.

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

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

Para obter mais informações, Configurar replicação geográfica e restauração de backup para criptografia de dados transparente 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, PowerShell e a CLI do Azure.

Nota

Todas as práticas recomendadas em relação à replicação geográfica e alta disponibilidade destacadas na criptografia de dados transparente (TDE) com CMK para CMK no nível do servidor aplicam-se à CMK no nível do banco de dados.

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

Depois que um banco de dados é criptografado com TDE usando uma chave do Cofre de Chaves do Azure, todos os backups recém-gerados também são criptografados com o mesmo protetor TDE. Quando o protetor TDE é alterado, os backups antigos do banco de dados não são atualizados para usar o protetor TDE mais recente. Para restaurar um backup criptografado com um protetor TDE do Cofre de Chaves do Azure configurado no nível do banco de dados, verifique se o material da chave é fornecido ao banco de dados de destino. Recomendamos que você mantenha todas as versões antigas do protetor TDE em um cofre de chaves, para que os backups do banco de dados possam ser restaurados.

Importante

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

Restauro para um ponto anterior no tempo

As etapas a seguir são necessárias para uma restauração point-in-time de um banco de dados configurado com chaves gerenciadas pelo cliente no nível do banco de dados:

1. Pré-preencha a lista de chaves usadas pelo banco de dados primário usando o comando Get-AzSqlDatabase e os -ExpandKeyList parâmetros and -KeysFilter "2023-01-01" . 2023-01-01 é um exemplo do momento em que você deseja restaurar o banco de dados. Exclua -KeysFilter se desejar recuperar todas as chaves.
2. Selecione a identidade gerenciada atribuída pelo usuário (e a ID do cliente federado se estiver configurando o acesso entre locatários).
3. Use Restore-AzSqlDatabase com o parâmetro e forneça a lista pré-preenchida de chaves obtidas a partir das etapas acima, e a identidade acima (e ID de cliente federado se configurar o -FromPointInTimeBackup acesso entre locatários) na chamada de API usando os -KeyListparâmetros , , , -EncryptionProtector (e se necessário, -AssignIdentity-UserAssignedIdentityId-FederatedClientId).

Nota

Restaurar um banco de dados sem a -EncryptionProtector propriedade com todas as chaves válidas irá redefini-lo para usar 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 descartada

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

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

Restauração geográfica

As etapas a seguir 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:

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

Importante

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

Nota

Os backups LTR (long-term backup retention - 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 devem ser passadas para o destino de restauração LTR.

Para saber mais sobre a recuperação de backup para o Banco de Dados SQL com CMK no nível do banco de dados com exemplos usando o Powershell, a CLI do Azure e as APIs REST, consulte Configurar a replicação geográfica e a restauração de backup para criptografia de dados transparente 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 oferece suporte a rotações de chaves quando os arquivos de log virtuais do banco de dados são criptografados com uma chave antiga diferente do protetor primário atual do banco de dados. O erro lançado neste caso é:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: A rotação de chaves para o TDE Protetor no nível do banco de dados é bloqueada quando as transações ativas estão segurando o log criptografado com chaves antigas.

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

• Tempo t0 = Um banco de dados é criado sem criptografia
• Tempo t1 = Este banco de dados é protegido pelo , que é uma chave gerenciada pelo Thumbprint Acliente no nível do banco de dados.
• Tempo t2 = O protetor de banco de dados é girado para uma nova chave gerenciada pelo cliente no nível do banco de dados, Thumbprint B.
• Tempo t3 = É solicitada uma alteração do protetor para Thumbprint C .
• Se os VLF ativos estiverem usando Thumbprint A, a rotação não é permitida.
• Se os VLFs ativos não estiverem usando Thumbprint A, a rotação é permitida.

Você pode usar o modo de exibição sys.dm_db_log_info (Transact-SQL) - SQL Server para seu banco de dados e procurar arquivos de log virtuais que estejam ativos. Você deve ver um VLF ativo criptografado com a primeira chave (por exemplo, Thumbprint A). Uma vez que o log suficiente tenha sido gerado pela inserção de dados, este VLF antigo é liberado e você deve ser capaz de executar outra rotação de chave.

Se você acredita que algo está atrasando seu log por mais tempo do que o esperado, consulte a seguinte documentação para obter mais solução de problemas:

• sys.dm_db_log_stats (Transact-SQL) para valores possíveis log_truncation_holdup_reason .
• Solucione o erro 9002 do log de transações completo.

Próximos passos

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

• Gerenciamento de identidades e chaves para TDE com chaves gerenciadas pelo cliente no nível do banco de dados

• Configure a replicação geográfica e a restauração de backup para criptografia de dados transparente com chaves gerenciadas pelo cliente no nível do banco de dados