Criptografia de dados transparente do Azure SQL com chaves gerenciadas pelo cliente

  • Artigo

Aplica-se a:Banco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse Analytics (somente pools de SQL dedicados)

A TDE (Transparent Data Encryption) do SQL do Azure com a CMK (chave gerenciada pelo cliente) permite cenários de BYOK (Bring Your Own Key) para proteção de dados inativos e permite que as organizações implementem separação de tarefas no gerenciamento de chaves e dados. Com a TDE gerenciada pelo cliente, o cliente é responsável e tem controle total do gerenciamento de ciclo de vida da chave (criação, carregamento, rotação e exclusão de chave), das permissões de uso de chave e da auditoria de operações nas chaves.

Nesse cenário, a chave usada para criptografia da DEK (Database Encryption Key), chamada de protetor de TDE, é uma chave assimétrica gerenciada pelo cliente, armazenada em um AKV (Azure Key Vault) de propriedade do cliente e gerenciado por ele, um sistema de gerenciamento de chave externa baseado em nuvem. O Key Vault é um armazenamento seguro escalonável e altamente disponível para chaves de criptografia RSA, opcionalmente apoiado por HSMs (módulos de segurança de hardware) validados pelo FIPS 140-2 Nível 2. Ele não permite acesso direto a uma chave armazenada, mas fornece serviços de criptografia/descriptografia usando a chave para as entidades autorizadas. A chave pode ser gerada pelo cofre de chaves, importada ou transferida para o cofre de chaves de um dispositivo HSM local.

Para o Banco de Dados SQL do Azure e o Azure Synapse Analytics, o protetor de TDE é definido no nível do servidor e é herdado por todos os bancos de dados criptografados associados a esse servidor. Para a Instância Gerenciada de SQL do Azure, o protetor de TDE é definido no nível de instância e é herdado por todos os bancos de dados criptografados nessa instância. O termo servidor se refere a um servidor no banco de dados SQL e ao Azure Synapse e a uma instância gerenciada no SQL instância gerenciada em todo este documento, a menos que indicado de forma diferente.

O gerenciamento do protetor de TDE no nível do banco de dados no banco de dados SQL do Azure está disponível. Para obter mais informações, confira TDE (Transparent Data Encryption) com chaves gerenciadas pelo cliente no nível do banco de dados.

Observação

  • Este artigo se aplica ao Banco de Dados SQL do Azure, à Instância Gerenciada de SQL do Azure e ao Azure Synapse Analytics (pools de SQL dedicados, anteriormente conhecido como SQL DW). Para obter a documentação sobre a criptografia de dados transparente para pools de SQL dedicados nos workspaces do Azure Synapse, confira Criptografia do Azure Synapse Analytics.
  • Para fornecer aos clientes do Azure SQL com duas camadas de criptografia de dados em repouso, a criptografia de infraestrutura (usando o algoritmo de criptografia AES-256) com chaves gerenciadas pela plataforma está sendo distribuída. Isso fornece uma camada de adição de criptografia em repouso junto com TDE com chaves gerenciadas pelo cliente, que já está disponível. Para o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure, todos os bancos de dados, incluindo o banco de dados master e outros bancos de dados do sistema, serão criptografados quando a criptografia de infraestrutura estiver ativada. No momento, os clientes devem solicitar acesso para esta capacidade. Se você estiver interessado nessa funcionalidade, entre em contato com AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Observação

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

Benefícios do TDE gerenciado pelo cliente

O TDE gerenciado pelo cliente fornece os seguintes benefícios para o cliente:

  • Controle completo e granular sobre o uso e o gerenciamento do protetor de TDE;

  • Transparência do uso do protetor de TDE;

  • Capacidade de implementar a separação de tarefas no gerenciamento de chaves e dados na organização;

  • O administrador do Key Vault pode revogar as permissões de acesso à chave para tornar o banco de dados criptografado inacessível;

  • Gerenciamento central de chaves no AKV;

  • Maior confiança dos clientes finais, já que o AKV foi projetado de modo que a Microsoft não possa ver nem extrair as chaves de criptografia;

Importante

Para aqueles que usam TDE gerenciado pelo serviço e que gostariam de começar a usar o TDE gerenciado pelo cliente, os dados permanecem criptografados durante o processo de troca e não há nenhum tempo de inatividade nem nova criptografia dos arquivos de banco de dados. A mudança de uma chave gerenciada pelo serviço para uma chave gerenciada pelo cliente requer apenas a nova criptografia da DEK, que é uma operação rápida e online.

Como funciona o TDE gerenciado pelo cliente

Configuração e funcionamento do TDE gerenciado pelo cliente

Para que o servidor lógico no Azure possa usar o protetor de TDE armazenado no AKV para criptografia de DEK, o administrador do cofre de chaves precisa conceder os seguintes direitos de acesso ao servidor usando sua identidade exclusiva do Microsoft Entra:

  • get – para recuperar a parte pública e as propriedades da chave no Key Vault

  • wrapKey – para poder proteger (criptografar) a DEK

  • unwrapKey – para poder desproteger (descriptografar) a DEK

O administrador do cofre de chaves também pode habilitar o registro em log de eventos de auditoria do cofre de chaves, para que eles possam ser auditados posteriormente.

Quando o servidor é configurado para usar um protetor de TDE do AKV, o servidor envia a DEK de cada banco de dados habilitado por TDE para o cofre de chaves para criptografia. O cofre de chaves retorna a DEK criptografada, que é armazenada no banco de dados do usuário.

Quando necessário, o servidor envia a DEK protegida para o cofre de chaves para descriptografia.

Os auditores poderão usar o Azure Monitor para examinar os logs de AuditEvent do cofre de chaves se o registro em log estiver habilitado.

Observação

As alterações de permissão podem levar cerca de dez minutos para entrar em vigor no cofre de chaves. Isso inclui a revogação de permissões de acesso ao protetor TDE no AKV. Além disso, os usuários dentro desse período ainda podem ter permissões de acesso.

Requisitos para configurar o TDE gerenciado pelo cliente

Requisitos para configurar o AKV

  • Os recursos exclusão temporária e proteção contra limpeza precisam estar habilitados no cofre de chaves para proteção contra a perda de dados em caso de exclusão acidental da chave (ou do cofre de chaves).

  • Conceda ao servidor ou à instância gerenciada acesso ao cofre de chaves (obter, wrapKey, unwrapKey) usando a identidade do Microsoft Entra. A identidade do servidor pode ser uma identidade gerenciada atribuída pelo sistema ou uma identidade gerenciada atribuída pelo usuário atribuída ao servidor. Ao usar o portal do Azure, a identidade do Microsoft Entra é criada automaticamente quando o servidor é criado. Ao usar o PowerShell ou a CLI do Azure, a identidade do Microsoft Entra deve ser explicitamente criada e verificada. Consulte Configurar a TDE com BYOK e Configurar a TDE com BYOK para a Instância Gerenciada do SQL para obter instruções passo a passo detalhadas ao usar o PowerShell.

    • 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 com a função Usuário de criptografia do serviço de criptografia do Key Vault.

  • Ao usar um firewall com o AKV, você deve habilitar a opção Permitir que os serviços confiáveis da Microsoft ignorem o firewall. Para obter mais informações, consulte Configurar redes virtuais e firewalls do Azure Key Vault.

Habilitar a exclusão temporária e a proteção contra limpeza no AKV

Importante

A exclusão temporária e a proteção contra limpeza precisam estar habilitadas no cofre de chaves durante a configuração da TDE gerenciada pelo cliente em uma instância gerenciada ou um servidor novo ou existente.

A exclusão temporária e a proteção contra limpeza são recursos importantes do Azure Key Vault que permitem a recuperação de cofres excluídos e objetos excluídos do cofre de chave, reduzindo o risco de um usuário excluir uma chave ou um cofre de chaves de maneira acidental ou mal-intencionada.

  • Os recursos excluídos com a exclusão reversível são retidos por 90 dias, a menos que sejam recuperados ou limpos pelo cliente. As ações de recuperação e limpeza têm suas próprias permissões associadas em uma política de acesso do cofre de chaves. O recurso de exclusão temporária está ativado por padrão nos novos cofres de chaves e pode ser habilitado por meio do portal do Azure, do PowerShell ou da CLI do Azure.

  • A Proteção contra limpeza pode ser ativada na CLI do Azure e no PowerShell. Quando a Proteção contra limpeza está ativada, não é possível limpar cofres e objetos no estado excluído durante o período de retenção. O período de retenção padrão é de 90 dias, mas é configurável de 7 a 90 dias no portal do Azure.

  • O SQL do Azure exige a habilitação da exclusão temporária e da proteção contra limpeza no cofre de chaves que contém a chave de criptografia que está sendo usada como o protetor de TDE para o servidor ou a instância gerenciada. Isso ajuda a evitar o cenário de exclusão acidental ou mal-intencionada de uma chave ou um cofre de chaves que pode levar o banco de dados a entrar no estado Inacessível.

  • Durante a configuração do protetor de TDE em um servidor existente ou durante a criação do servidor, o SQL do Azure valida se o cofre de chaves que está sendo usado tem a exclusão temporária e a proteção contra limpeza ativadas. Se a exclusão temporária e a proteção contra limpeza não estiverem habilitadas no cofre de chaves, a configuração do protetor de TDE falhará com um erro. Nesse caso, a exclusão temporária e a proteção contra limpeza precisam ser habilitadas primeiro no cofre de chaves, e a configuração do protetor de TDE deve ser realizada.

Requisitos para configurar o protetor de TDE

  • O protetor de TDE só pode ser uma chave assimétrica, RSA ou HSM RSA. Os comprimentos de chave com suporte são 2048 e 3072 bits.

  • A data de ativação da chave (se definida) precisa ser uma data e uma hora no passado. A data de validade (se definida) deve ser uma data e hora no futuro.

  • A chave precisa estar no estado Habilitado.

  • Se você estiver importando a chave existente para o cofre de chaves, certifique-se de fornecê-la nos formatos de arquivo com suporte (.pfx, .byok ou .backup).

Observação

O SQL do Azure já dá suporte ao uso de uma chave RSA armazenada em um HSM gerenciado como um protetor de TDE. O HSM Gerenciado do Azure Key Vault é um serviço de nuvem em conformidade com os padrões de um único locatário, altamente disponível e totalmente gerenciado que permite proteger chaves criptográficas para seus aplicativos de nuvem usando HSMs validados FIPS 140-2 Nível 3. Saiba mais sobre o HSMs Gerenciado.

Observação

Um problema com as versões do Thales CipherTrust Manager antes da v2.8.0 impede que as chaves recém-importadas para o Azure Key Vault sejam usadas com o Banco de Dados SQL do Azure ou a Instância Gerenciada de SQL do Azure em cenários de TDE gerenciados pelo cliente. Você pode encontrar mais detalhes sobre esse problema aqui. Nesses casos, aguarde 24 horas depois de importar a chave no cofre de chaves para começar a usá-la como o protetor de TDE para o servidor ou a instância gerenciada. Esse problema foi resolvido no Thales CipherTrust Manager v2.8.0.

Recomendações ao configurar o TDE gerenciado pelo cliente

Recomendações ao configurar o AKV

  • Associe, no máximo, 500 bancos de dados de Uso Geral ou 200 bancos de dados Comercialmente Críticos a um cofre de chaves em uma assinatura única para garantir alta disponibilidade quando o servidor acessar o protetor de TDE no cofre de chaves. Esses números são baseados na experiência e documentados nos limites de serviço do cofre de chaves. A intenção aqui é evitar problemas após o failover do servidor, pois ele vai disparar a mesma quantidade de operações de chave no cofre que nos bancos de dados nesse servidor.

  • Defina um bloqueio de recurso no cofre de chaves para controlar quem pode excluir esse recurso crítico e evitar a exclusão acidental ou não autorizada. Saiba mais sobre bloqueios de recursos.

  • Habilite auditoria e relatórios em todas as chaves de criptografia: o Key Vault fornece logs que são fáceis de serem injetados em outras ferramentas de gerenciamento de eventos e informações de segurança. O Operations Management Suite Log Analytics é um exemplo de um serviço que já está integrado.

  • Vincule cada servidor com dois cofres de chaves que residem em regiões diferentes e mantenha o mesmo material de chave para garantir a alta disponibilidade dos bancos de dados criptografados. Marque a chave de um dos cofres de chaves como o protetor TDE. O sistema alterna automaticamente para o cofre de chaves na segunda região com o mesmo material de chave, se houver uma paralisação afetando o cofre de chaves na primeira região.

Observação

Para aumentar a maior flexibilidade da configuração da TDE gerenciada pelo cliente, agora é possível vincular o Banco de Dados SQL do Microsoft Azure e a Instância Gerenciada de SQL do Azure de uma região ao cofre de chaves de outras regiões. O servidor e o cofre de chaves não precisam estar localizados na mesma região.

Recomendações ao configurar o protetor de TDE

  • Mantenha uma cópia do protetor de TDE em um local seguro ou coloque-o no serviço de caução.

  • Se a chave for gerada no cofre de chaves, crie um backup da chave antes de usar a chave no AKV pela primeira vez. O backup pode ser restaurado somente para um Azure Key Vault. Saiba mais sobre o comando Backup-AzKeyVaultKey.

  • Crie um backup sempre que forem feitas alterações na chave (por exemplo, ACLs, marcas e atributos de chave).

  • Mantenha as versões anteriores da chave no cofre de chaves ao fazer rotação de chaves para que os backups mais antigos do banco de dados possam ser restaurados. Quando o protetor de TDE é alterado para um banco de dados, os backups antigos do banco de dados não são atualizados para usar o protetor de TDE mais recente. No momento da restauração, cada backup precisa do protetor de TDE em que foi criptografado na hora da criação. As rotações de chave podem ser executadas seguindo as instruções descritas em Girar o protetor da Transparent Data Encryption usando o PowerShell.

  • Mantenha todas as chaves usadas anteriormente no AKV mesmo depois de mudar para chaves gerenciadas pelo serviço. Isso garante que os backups do banco de dados possam ser restaurados com os protetores de TDE armazenados no AKV. Os protetores de TDE criados com o Azure Key Vault devem ser mantidos até que todos os backups armazenados restantes sejam criados com chaves gerenciadas pelo serviço. Faça cópias de backup recuperáveis dessas chaves usando Backup-AzKeyVaultKey.

  • Para remover uma chave potencialmente comprometida durante um incidente de segurança sem o risco de perda de dados, siga as etapas em Remover uma chave potencialmente comprometida.

Rotação do protetor de TDE

Girar o protetor de TDE para um servidor significa alternar para uma nova chave assimétrica que protege os bancos de dados no servidor. 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.

A rotação do protetor de TDE pode ser feita manualmente ou usando o recurso de rotação automatizada.

A rotação automatizada do protetor de TDE pode ser habilitada quando o protetor de TDE é configurado para o servidor. O backup automatizado está desabilitado por padrão. Quando habilitado, o servidor verificará continuamente o cofre de chaves em busca de novas versões da chave que está sendo usada como o protetor de TDE. Se uma nova versão da chave for detectada, o protetor de TDE no servidor ou no banco de dados será girado automaticamente para a versão mais recente da chave no período de até 24 horas.

Quando usado com a rotação de chaves automatizada do Azure Key Vault, esse recurso permite a rotação de ponta a ponta com toque zero para o protetor de TDE no Banco de Dados SQL do Azure e na Instância Gerenciada de SQL do Azure.

Observação

A configuração de TDE com CMK usando a rotação manual ou automatizada das chaves sempre usará a última versão da chave com suporte. A configuração não permite o uso de uma versão anterior ou inferior das chaves. Sempre usar a versão de chave mais recente está em conformidade com a política de segurança do SQL do Azure que não permite versões de chave anteriores que possam estar comprometidas. As versões anteriores da chave podem ser necessárias para fins de backup ou restauração do banco de dados, especialmente no caso de backups de retenção de longo prazo, em que as versões mais antigas da chave devem ser preservadas. Para configurações de replicação geográfica, todas as chaves exigidas pelo servidor de origem precisam estar presentes no servidor de destino.

Considerações sobre replicação geográfica ao configurar a rotação automatizada do protetor de TDE

Para evitar problemas no estabelecimento da replicação geográfica ou durante a replicação geográfica, quando a rotação automática do protetor de TDE está habilitada no servidor primário ou secundário, é importante seguir estas regras ao configurar a replicação geográfica:

  • Os servidores primários e secundários precisam ter permissões Get, wrapKey e unwrapKey no cofre de chaves do servidor primário (o cofre de chaves que contém a chave do protetor de TDE do servidor primário).

  • Para um servidor com a rotação de chave automatizada habilitada, antes de iniciar a replicação geográfica, adicione a chave de criptografia que está sendo usada como o protetor de TDE no servidor primário ao servidor secundário. O servidor secundário exige acesso à chave no mesmo cofre de chaves que está sendo usado com o servidor primário (e não outra chave com o mesmo material de chave). Como alternativa, antes de iniciar a replicação geográfica, verifique se a identidade gerenciada do servidor secundário (atribuída pelo usuário ou pelo sistema) tem as permissões necessárias no cofre de chaves do servidor primário, e o sistema tentará adicionar a chave ao servidor secundário.

  • Para uma configuração de replicação geográfica existente, antes de habilitar a rotação automatizada de chaves no servidor primário, adicione a chave de criptografia que está sendo usada como o protetor de TDE no servidor primário ao servidor secundário. O servidor secundário exige acesso à chave no mesmo cofre de chaves que está sendo usado com o servidor primário (e não outra chave com o mesmo material de chave). Como alternativa, antes de habilitar a chave automatizada, verifique se a identidade gerenciada do servidor secundário (atribuída pelo usuário ou atribuída pelo sistema) tem as permissões necessárias no cofre de chaves do servidor primário, e o sistema tentará adicionar a chave ao servidor secundário.

  • Há suporte para cenários de replicação geográfica que usam a CMK (chaves gerenciadas pelo cliente) para TDE. A TDE com a rotação automática de chaves precisará ser configurada em todos os servidores se você estiver configurando a TDE no portal do Azure. Para obter mais informações sobre como configurar a rotação automática de chaves para configurações de replicação geográfica com a TDE, confira Rotação automática de chaves para configurações de replicação geográfica.

Protetor de TDE inacessível

Quando a TDE é configurada para usar uma chave gerenciada pelo cliente, é necessário o acesso contínuo ao protetor de TDE, para que o banco de dados permaneça online. Se o servidor perder o acesso ao protetor de TDE gerenciado pelo cliente no AKV, um banco de dados vai começar, em até dez minutos, a negar todas as conexões com a mensagem de erro correspondente e alterar o estado para Inacessível. A única ação permitida em um banco de dados no estado Inacessível é a exclusão.

Observação

Se o banco de dados estiver inacessível devido a uma interrupção intermitente da rede, não haverá ação necessária e os bancos de dados voltarão a ficar online automaticamente.

Depois que o acesso à chave for restaurado, colocar novamente o banco de dados online exigirá tempo e etapas extras, o que pode variar de acordo com o tempo decorrido sem acesso à chave e o tamanho dos dados no banco de dados:

Observação

  • Se o acesso à chave for restaurado em 30 minutos, o banco de dados será recuperado automaticamente na próxima hora.
  • Se o acesso à chave for restaurado em mais de 30 minutos, a recuperação automática do banco de dados não será possível. A recuperação do banco de dados exige etapas adicionais no portal do Azure e pode demorar dependendo do tamanho do banco de dados.
  • Quando o banco de dados ficar online novamente, serão perdidas as configurações no nível do servidor previamente definidas, que podem incluir configuração de grupo de failover, marcas e configurações no nível do banco de dados, como configuração de pools elásticos, expansão de leitura, pausa automática, histórico de restauração pontual, política de retenção de longo prazo e outras. Portanto, é recomendável que os clientes implementem um sistema de notificação que identifique a perda de acesso à chave de criptografia em 30 minutos. Depois que o período de 30 minutos expirar, recomendamos validar todas as configurações no nível do servidor e do banco de dados no banco de dados recuperado.

Veja abaixo uma exibição das etapas extras necessárias no portal para colocar um banco de dados inacessível online novamente.

Banco de dados byok inacessível do TDE

Revogação acidental do acesso do protetor de TDE

Pode acontecer de alguém com direitos de acesso suficientes ao cofre de chaves desabilitar acidentalmente o acesso do servidor à chave ao:

  • Revogar as permissões get, wrapKey, unwrapKey do cofre de chaves do servidor

  • excluir a chave

  • excluir o cofre de chaves

  • alterar as regras de firewall do cofre de chaves

  • excluir a identidade gerenciada do servidor no Microsoft Entra ID

Saiba mais sobre as causas comuns para o banco de dados se tornar inacessível.

Conectividade bloqueada entre Instância Gerenciada de SQL e Key Vault

Na Instância Gerenciada de SQL, erros de rede ao tentar acessar o protetor de TDE no Azure Key Vault podem não fazer com que os bancos de dados alterem o estado deles para Inacessível, mas tornarão a instância indisponível posteriormente. Isso acontece principalmente quando o recurso do cofre de chaves existe, mas o ponto de extremidade dele não pode ser acessado da instância gerenciada. Todos os cenários em que o ponto de extremidade do cofre de chaves pode ser alcançado, mas a conexão é negada, permissões estão ausentes etc., farão com que os bancos de dados alterem o estado deles para Inacessível.

As causas mais comuns para a falta de conectividade de rede para o Key Vault são:

  • O Key Vault é exposto por meio de ponto de extremidade privado e o endereço IP privado do serviço AKV não é permitido nas regras de saída do NSG (Grupo de Segurança de Rede) associado à sub-rede da instância gerenciada.
  • Resolução DNS incorreta, como quando o FQDN do cofre de chaves não é resolvido ou é resolvido para um endereço IP inválido.

Teste a conectividade de Instância Gerenciada de SQL para o Key Vault que hospeda o protetor TDE.

  • O ponto de extremidade é o FQDN do seu cofre, como <nome_do_cofre>.vault.azure.net (sem https://).
  • A porta a ser testada é a 443.
  • O resultado de RemoteAddress deve existir e ser o endereço IP correto
  • O resultado do teste TCP deve ser TcpTestSucceeded: True.

Caso o teste retorne TcpTestSucceededed: False, examine a configuração de rede:

  • Verifique o endereço IP resolvido e confirme se ele tem valor. Um valor ausente significa que há problemas com a resolução DNS.
    • Confirme se o grupo de segurança de rede na instância gerenciada tem uma regra de saída que abrange o endereço IP resolvido na porta 443, especialmente quando o endereço resolvido pertence ao ponto de extremidade privado do cofre de chaves.
    • Verifique outras configurações de rede, como tabela de rotas, existência de dispositivo virtual e a configuração dele etc.

Como monitorar o TDE gerenciado pelo cliente

Para monitorar o estado do banco de dados e habilitar o alerta para perda de acesso ao protetor do TDE, configure os seguintes recursos do Azure:

  • Azure Resource Health. Um banco de dados inacessível que perdeu o acesso ao protetor de TDE aparecerá como "Não disponível" após a negação da primeira conexão com o banco de dados.
  • Quando o log de atividades falha ao acessar o protetor de TDE no cofre de chaves gerenciado pelo cliente, as entradas são adicionadas ao log de atividades. A criação de alertas para esses eventos permite que você reinstale o acesso assim que possível.
  • Os Grupos de Ações podem ser definidos para enviar a você notificações e alertas com base em suas preferências, por exemplo, email/SMS/push/voz, aplicativo lógico, webhook, ITSM ou runbook de automação.

Backup e restauração de banco de dados com TDE gerenciado pelo cliente

Depois que um banco de dados for criptografado com TDE usando uma chave do 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 Key Vault, verifique se o material da chave está disponível no servidor de destino. Portanto, é recomendável manter todas as versões antigas do protetor de TDE no cofre de chaves para que os backups do banco de dados possam ser restaurados.

Importante

Não pode haver mais de um conjunto de protetor de TDE para um servidor. É a chave marcada com "Tornar a chave o protetor de TDE padrão" no painel do portal do Azure. No entanto, várias chaves adicionais podem ser vinculadas a um servidor sem serem marcadas como um 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 for criptografado com a chave com a impressão digital correspondente.

Se a chave necessária para restaurar um backup não estiver mais disponível para o servidor de destino, a seguinte mensagem de erro será retornada na tentativa de restauração: "O servidor de destino <Servername> não tem acesso a todos os URIs do AKV criados entre <Timestamp #1> e <Timestamp #2>. Tente realizar a operação novamente depois de restaurar todos os URIs do AKV".

Para atenuá-lo, execute o cmdlet Get-AzSqlServerKeyVaultKey para o servidor de destino ou Get-AzSqlInstanceKeyVaultKey para a instância gerenciada de destino para retornar a lista de chaves disponíveis e identificar as que estão ausentes. Para garantir que todos os backups possam ser restaurados, verifique se o servidor de destino para a restauração tem acesso a todas essas chaves necessárias. Essas chaves não precisam ser marcadas como protetor de TDE.

Para saber mais sobre a recuperação de backup do Banco de Dados SQL, consulte Recuperar um banco de dados SQL . Para saber mais sobre a recuperação de backup para pools de SQL dedicados no Azure Synapse Analytics, confira Recuperar um pool de SQL dedicado. Para backup/restauração nativos do SQL Server com a Instância Gerenciada de SQL, confira Guia de Início Rápido: Restaurar um banco de dados na Instância Gerenciada de SQL.

Consideração adicional para arquivos de log de backup: os arquivos de log permanecem criptografados com o protetor de TDE original, mesmo que tenha sido girado e o banco de dados agora esteja usando um novo protetor de TDE. No momento da restauração, ambas as chaves serão necessárias para restaurar o banco de dados. Se o arquivo de log estiver usando um protetor de TDE armazenado no Azure Key Vault, essa chave será necessária na hora da restauração, mesmo que o banco de dados tenha sido alterado para usar o TDE gerenciado pelo serviço.

Alta disponibilidade com o TDE gerenciado pelo cliente

Mesmo em casos em que não há configuração de redundância geográfica, é altamente recomendável configurar o servidor para usar dois cofres de chaves diferentes em duas regiões diferentes com o mesmo material da chave. A chave no cofre de chaves secundário em outra região não deve ser marcada como um protetor de TDE e isto nem é permitido. Se houver uma interrupção afetando o cofre de chaves primário, o sistema mudará automaticamente para a outra chave vinculada com a mesma impressão digital no cofre de chaves secundário, se existir. Observe que essa mudança não ocorrerá se o protetor de TDE estiver inacessível devido a direitos de acesso revogados ou porque a chave ou o cofre de chaves foi excluído, pois isso pode indicar que o cliente quis restringir intencionalmente o acesso do servidor à chave. Fornecer o mesmo material de chave para dois cofres de chaves em regiões diferentes pode ser feito criando a chave fora do cofre de chaves e importando-os para os dois cofres de chaves.

Como alternativa, ela pode ser realizada gerando uma chave usando o cofre de chaves primárias em uma região e clonando a chave em um cofre de chaves em uma região diferente do Azure. Use o cmdlet Backup-AzKeyVaultKey para recuperar a chave no formato criptografado do cofre de chaves primário e, em seguida, use o cmdlet Restore-AzKeyVaultKey e especifique um cofre de chaves na segunda região para clonar a chave. Como alternativa, use o portal do Azure para fazer backup e restaurar a chave. A operação de backup/restauração de chave só é permitida entre cofres de chaves na mesma assinatura do Azure e Geografia do Azure.

HA de servidor único

TDE gerenciado pelo cliente e DR geográfica

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 os cofres de chaves separados estão vinculados aos servidores primários e secundários, o cliente é responsável por manter a consistência do material de chave nos cofres de chaves, de modo que o geo-secundário esteja em sincronia e possa assumir o uso da mesma chave do cofre de chaves vinculado, se o servidor primário ficar inacessível devido a uma falha na região e um failover for disparado. Até quatro servidores secundários podem ser configurados, e não há suporte para o encadeamento (secundários de secundários).

Para evitar problemas ao estabelecer ou durante a replicação geográfica devido ao material de chave incompleto, é importante seguir estas regras ao configurar o TDE gerenciado pelo cliente (caso utilize-se cofres de chaves diferentes para os servidores primário e secundário):

  • Todos os cofres de chaves envolvidos devem ter as mesmas propriedades e os mesmos direitos de acesso para os respectivos servidores.

  • Todos os cofres de chaves envolvidos devem conter material de chave idêntico. Isso se aplica não apenas ao protetor de TDE atual, mas a todos os protetores de TDE anteriores que podem ser usados nos arquivos de backup.

  • Tanto a configuração inicial quanto a rotação do protetor de TDE devem ser feitas primeiro no secundário e, em seguida, no primário.

Grupos de failover e Geo-DR

Para testar um failover, siga as etapas em Visão geral da replicação geográfica ativa. O failover de teste deve ser feito regularmente para validar se o Banco de Dados SQL manteve a permissão de acesso a ambos os cofres de chaves.

Agora é possível vincular o servidor do Banco de Dados SQL do Microsoft Azure e a Instância Gerenciada de SQL de uma região ao cofre de chaves de outras regiões. O servidor e o cofre de chaves não precisam estar colocalizados na mesma região. Por isso, para simplificar, os servidores primário e secundário podem ser conectados ao mesmo cofre de chaves (em qualquer região). Isso ajuda a evitar cenários em que o material de chave pode ficar fora de sincronia se cofres de chaves separados são usados nos dois servidores. O Azure Key Vault tem várias camadas de redundância em vigor para garantir que as chaves e os cofres de chaves permaneçam disponíveis em caso de falhas de serviço ou região. Redundância e disponibilidade de Cofre de Chaves do Azure

Política do Azure para TDE gerenciado pelo cliente

A Política do Azure pode ser usada para impor o TDE gerenciado pelo cliente durante a criação ou atualização de um servidor Banco de Dados SQL do Azure ou uma Instância Gerenciada de SQL do Azure. Com essa política em uso, qualquer tentativa de criar ou atualizar um servidor lógico no Azure ou na instância gerenciada falhará se ela não for criada com a chave gerenciada pelo cliente. O Azure Policy pode ser aplicado a toda a assinatura do Azure ou apenas dentro de um grupo de recursos.

Para obter mais informações sobre o Azure Policy, confira O que é o Azure Policy? e Estrutura de definição do Azure Policy.

As duas políticas internas a seguir têm suporte para o TDE gerenciado pelo cliente na Política do Azure:

  • Os SQL Servers devem usar chaves gerenciadas pelo cliente para criptografar dados inativos
  • As instâncias gerenciadas devem usar chaves gerenciadas pelo cliente para criptografar dados inativos

A políticas de TDE gerenciada pelo cliente pode ser gerenciada no portal do Azure e procurando o serviço de Políticas. Em Definições,procure por chave gerenciada pelo cliente.

Há três efeitos para essas políticas:

  • Auditoria – a configuração padrão e capturará apenas um relatório de auditoria nos logs de atividades do Azure Policy
  • Negar - Impede a criação ou atualização de instâncias gerenciadas ou do servidor lógico sem a configuração de uma chave gerenciada pelo cliente
  • Desabilitado - Desabilitará a política e não restringirá os usuários de criarem ou atualizarem um servidor lógico ou uma instância gerenciada sem a TDE gerenciada pelo cliente habilitada

Se a Política do Azure para TDE gerenciada pelo cliente estiver definida como Negar, a criação do servidor lógico ou instância gerenciada do SQL do Azure falhará. Os detalhes dessa falha serão registrados no Log de atividades do grupo de recursos.

Importante

Versões anteriores de políticas internas para TDE gerenciada pelo cliente contendo o efeito AuditIfNotExist foram preteridas. As atribuições de política existentes usando as políticas preteridas não são impactadas e continuarão a funcionar como antes.

Próximas etapas

Você também pode querer verificar os seguintes scripts de exemplo do PowerShell para as operações comuns com o TDE gerenciado pelo cliente:

Além disso, habilite o Microsoft Defender para SQL para proteger seus bancos de dados e os dados neles. Ele tem funcionalidades para descobrir e mitigar possíveis vulnerabilidades no banco de dados e detecta atividades anômalas que podem indicar uma ameaça aos seus bancos de dados.