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

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

A Transparent Data Encryption (TDE) no SQL do Azure com chave gerenciada pelo cliente (CMK) habilita 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, o protetor Transparent Data Encryption (TDE) é uma chave gerenciada pelo cliente que protege a Chave de Criptografia do Banco de Dados (DEK). Você armazena o protetor TDE no Azure Key Vault ou no Azure Key Vault Managed HSM, que são serviços seguros de gerenciamento de chaves baseados em nuvem, projetados para alta disponibilidade e escalabilidade. Ambos os serviços suportam chaves criptográficas protegidas por hardware validado FIPS 140-2: o Azure Key Vault suporta o FIPS 140-2 Nível 2, e o Azure Key Vault Managed HSM suporta o FIPS 140-2 Nível 3. Ambos os serviços também suportam tipos de chave assimétricas e simétricas, e os algoritmos suportados e o uso dependem do modelo de implantação do TDE. Você pode gerar a chave no serviço, importá-la ou transferi-la com segurança de HSMs locais. O acesso direto às chaves é restrito, então serviços autorizados realizam operações criptográficas sem expor o material da chave.

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 refere-se tanto a um servidor no Banco de Dados SQL e Azure Synapse quanto a uma instância gerenciada no Instância Gerenciada de SQL ao longo deste artigo, a menos que indicado de outra forma.

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 mais informações sobre a criptografia de dados transparente para pools de SQL dedicados dentro de workspaces do Synapse, consulte a criptografia do Azure Synapse Analytics.

Observação

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

CMK (Chave Gerenciada pelo Cliente) e BYOK (Bring Your Own Key)

Neste artigo, os termos CMK (Chave Gerenciada pelo Cliente) e BYOK (Bring Your Own Key) são usados de forma intercambiável, mas representam algumas diferenças.

  • cmk (chave gerenciada pelo cliente) – o cliente gerencia o ciclo de vida de chave, incluindo criação, rotação e exclusão de chaves. A chave é armazenada no Azure Key Vault ou no HSM Gerenciado do Azure e usada para criptografia da DEK (Chave de Criptografia de Banco de Dados) no SQL do Azure, no SQL Server na VM do Azure e no SQL Server local.

  • Traga sua própria chave (BYOK) – O cliente traz ou importa com segurança sua própria chave de um HSM (módulo de segurança de hardware) local para o Azure Key Vault ou O HSM Gerenciado do Azure. Essas chaves importadas podem ser usadas como qualquer outra chave no Azure Key Vault, inclusive como uma Chave Gerenciada pelo Cliente para criptografia do DEK. Para obter mais informações, confira importar chaves protegidas por HSM para HSM gerenciado (BYOK).

Benefícios do TDE gerenciado pelo cliente

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

  • Controle total 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 dentro da organização.

  • O administrador do Azure Key Vault pode revogar permissões de acesso a chaves para tornar o banco de dados criptografado inacessível.

  • Gerenciamento central de chaves no Azure Key Vault.

  • Maior confiança de seus clientes finais, já que o Azure Key Vault foi projetado para que a Microsoft não possa ver nem extrair chaves de criptografia.

Importante

Para aqueles que usam o TDE gerenciado pelo serviço que gostaria de começar a usar o TDE gerenciado pelo cliente, os dados permanecem criptografados durante o processo de alternância e não há 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.

Permissões para configurar o TDE gerenciado pelo cliente

Diagrama mostrando a configuração e o funcionamento de TDE gerenciada pelo cliente.

Selecione o tipo de Azure Key Vault que você deseja usar.

Para que o servidor lógico no Azure use o protetor TDE armazenado no Azure Key Vault para criptografia do DEK, o Administrador do Key Vault precisa conceder direitos de acesso ao servidor usando sua identidade única 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. Há dois modelos de acesso para conceder ao servidor acesso ao cofre de chaves:

  • Controle de acesso baseado em função (RBAC) do Azure - Use o RBAC do Azure para conceder acesso ao cofre de chaves a um usuário, grupo ou aplicativo. Este método é recomendado por sua flexibilidade e granularidade. A função de Usuário de Criptografia do Serviço de Criptografia do Cofre de Chaves é necessária pela identidade do servidor para poder usar a chave para operações de criptografia e descriptografia.

  • Política de acesso ao cofre de chaves - Use a política de acesso ao cofre de chaves para conceder ao servidor acesso ao cofre de chaves. Este método é mais simples e direto, mas menos flexível. A identidade do servidor precisa ter as seguintes permissões no cofre de chaves:

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

No menu Configuração de acesso do portal do Azure, você tem a opção de selecionar controle de acesso baseado em função do Azure ou política de acesso ao cofre. Para obter instruções passo a passo sobre como configurar uma configuração de acesso do Azure Key Vault para TDE, consulte Configurar o Gerenciamento Extensível de Chaves TDE do SQL Server usando o Azure Key Vault. Para obter mais informações sobre os modelos de acesso, confira Segurança do Azure Key Vault.

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 um servidor é configurado para usar um protetor de TDE do Azure Key Vault, o servidor envia o DEK de cada banco de dados habilitado para 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

  • Os recursos de exclusão reversível (soft-delete) e proteção contra limpeza devem ser habilitados no Azure Key Vault. 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.

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

Principais requisitos para configurar o protetor de TDE

A Transparent Data Encryption com chaves gerenciadas pelo cliente utiliza uma chave externa, chamada de protetor TDE, armazenada no Azure Key Vault ou no Azure Managed HSM para proteger a chave de criptografia do banco de dados (DEK).

Os requisitos a seguir se aplicam.

Tipos e tamanhos de chave com suporte

Dependendo da oferta de SQL do Azure e da configuração de TDE, o protetor de TDE pode ser apoiado por chaves assimétricas ou simétricas armazenadas em Azure Key Vault ou Azure Key Vault HSM Gerenciado.

  • Chaves assimétricas (RSA ou RSA HSM)

    • Com suporte no Azure Key Vault e no HSM Gerenciado do Azure Key Vault
    • Tamanhos de chave suportados: 2.048 bits e 3.072 bits
    • Suportado para Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure e Azure Synapse Analytics

  • Chaves simétricas (AES)

    • Suportado no Azure Key Vault Premium (prévia) e no Azure Key Vault Managed HSM
    • Tamanhos de chave suportados: 128 bits, 192 bits e 256 bits
    • Suportado apenas para Banco de Dados SQL do Azure, atualmente em pré-visualização pública

Observação

Transparent Data Encryption with Symmetric Keys (AES) está atualmente em prévia. Os recursos de pré-visualização são lançados com capacidades limitadas, mas a Microsoft os disponibiliza em formato de pré-visualização para que os clientes possam obter acesso antecipado e fornecer feedback. Os recursos de pré-visualização estão sujeitos a termos complementares de pré-visualização, e não estão sujeitos a SLAs. O suporte é fornecido da melhor forma possível em determinados casos. No entanto, o Suporte da Microsoft quer muito seus comentários sobre a funcionalidade de versão prévia e pode fornecer o melhor suporte em determinados casos. Os recursos da preview podem ter funcionalidades limitadas ou restritas e podem estar disponíveis apenas em áreas geográficas selecionadas.

Comportamento de gerenciamento de chaves para chaves simétricas (AES)

Você pode usar chaves simétricas (AES) armazenadas no Azure Key Vault Premium (prévia) ou no Azure Key Vault Managed HSM como protetor de TDE. Para começar com uma chave de um módulo de segurança de hardware local (HSM), importe a chave para qualquer um dos serviços. Após a importação inicial, todas as operações do ciclo de vida das chaves em andamento ocorrem no Azure Key Vault Premium (prévia) ou no Azure Key Vault Managed HSM. A recuperação pontual, a recuperação de desastres geográficos e a revalidação de chaves dependem da disponibilidade da chave no local. Manter backups locais das chaves importadas para apoiar cenários de recuperação e revalidação. Esse comportamento se aplica apenas a chaves simétricas (AES), não a chaves assimétricas (RSA).

Requisitos principais de estado e validade

  • Se uma data de ativação de chave for especificada, ela deverá ser definida como uma data e hora no passado.
  • Se uma data de expiração de uma chave for especificada, ela deverá ser definida para uma data e hora futuras.
  • A chave precisa estar no estado Habilitado.

Principais requisitos de importação

Se você importar uma chave existente no Azure Key Vault, forneça a chave em um dos seguintes formatos suportados:

  • .pfx
  • .byok
  • .backup

Para importar chaves protegidas por HSM para o HSM Gerenciado do Azure, consulte Importar chaves protegidas por HSM para O HSM Gerenciado (BYOK).

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 para cenários de TDE gerenciados pelo cliente. Para obter mais detalhes sobre esse problema, consulte as notas de versão do CipherTrust Cloud Key Manager. Para esses casos, aguarde 24 horas depois de importar a chave para o Azure Key Vault para começar a usá-la como protetor de TDE para o servidor ou instância gerenciada. Esse problema é resolvido no Thales CipherTrust Manager v2.8.0.

Recomendações para configurar o TDE gerenciado pelo cliente

  • Para garantir desempenho e confiabilidade ideais, utilize um Azure Key Vault dedicado para SQL do Azure. Não compartilhe esse cofre de chaves com outros serviços. Se o cofre de chaves estiver sob grande carga devido ao uso compartilhado ou operações excessivas de chaves, isso pode afetar negativamente o desempenho do banco de dados, especialmente durante o acesso à chave de criptografia. O Azure Key Vault impõe limites de limitação. Quando esses limites são excedidos, as operações podem ser atrasadas ou falhar. Esse risco é maior durante failovers de servidores, que acionam operações de chave para todos os bancos de dados do servidor.

    Para obter mais informações sobre comportamento de limitação, confira Diretrizes de limitação do Azure Key Vault.

    Para manter a alta disponibilidade e evitar problemas de limitação, siga estas diretrizes por assinatura:

    • Use um Azure Key Vault dedicado para recursos SQL do Azure.

    • Associe não mais de 500 bancos de dados de Uso Geral a um único Azure Key Vault.

    • Associe não mais de 200 bancos de dados Comercialmente Críticos a um único Azure Key Vault.

    • O número de bancos de dados de Hiperescala que podem ser associados a um único Azure Key Vault é determinado pelo número de servidores de página. Cada servidor de página é vinculado a um arquivo de dados lógico. Para localizar o número de servidores de página, execute a consulta a seguir.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Não associe mais de 500 servidores de página a um único Azure Key Vault. À medida que o banco de dados aumenta, o número de servidores de página aumenta automaticamente, portanto, é importante monitorar o tamanho do banco de dados regularmente. Se o número de servidores de páginas ultrapassar 500, use um Azure Key Vault dedicado para cada banco de dados Hyperscale e não compartilhe esse cofre de chaves com outros recursos SQL do Azure.

    • Monitore e configure alertas do Azure Key Vault. Para obter mais informações sobre monitoramento e alertas, consulte Monitorar o Azure Key Vault e configurar alertas do Azure Key Vault.

  • Para alinhar com o planejamento de resiliência criptográfica de longo prazo, considere usar chaves simétricas AES-256 como protetores TDE.

    Espera-se que a computação quântica em grande escala quebre algoritmos criptográficos de chave pública como o RSA. A criptografia simétrica, incluindo AES, é considerada resiliente quântica em tamanhos de chave suficientemente grandes.

    A estratégia mais ampla de segurança quântica segura da Microsoft enfatiza a agilidade em criptomoedas. Adote algoritmos simétricos mais fortes onde eles são suportados e planeje futuras transições criptográficas à medida que as orientações e padrões evoluem.

    Importante

    Transparent Data Encryption com chaves simétricas (AES) tem suporte apenas para Banco de Dados SQL do Azure e está em versão prévia pública.

  • 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.

  • Habilitar auditoria e relatórios em todas as chaves de criptografia: o Azure Key Vault fornece logs fáceis de injetar 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.

  • Use um cofre de chaves de uma região do Azure que possa replicar seu conteúdo para uma região emparelhada, garantindo a máxima disponibilidade. Para obter mais informações, consulte Práticas recomendadas para usar o Azure Key Vault e disponibilidade e redundância do Azure Key Vault.

Observação

Para permitir maior flexibilidade na configuração do TDE gerenciado pelo cliente, o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure em uma região agora podem ser vinculados ao Azure Key Vault em qualquer outra região. O servidor e o cofre de chaves não precisam estar colocalizados na mesma região.

Recomendações para 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 de chave antes de usar a chave no Azure Key Vault pela primeira vez. O backup pode ser restaurado somente para um Azure Key Vault. Saiba mais sobre o comando Backup-AzKeyVaultKey. O HSM Gerenciado do Azure dá suporte à criação de um backup completo de todo o conteúdo do HSM, incluindo todas as chaves, versões, atributos, marcas e atribuições de função. Para obter mais informações, consulte Backup e restauração completos e restauração de chave seletiva.

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

  • Mantenha versões anteriores da chave no cofre de chaves ou no HSM Gerenciado ao fazer a rotação das chaves, para que você possa restaurar backups mais antigos do banco de dados. Quando o protetor TDE muda para um banco de dados, backups antigos do banco não são atualizados para usar o protetor TDE mais recente. No momento da restauração, cada backup precisa do protetor de TDE com o qual foi criptografado no momento da criação. Para rotacionar chaves, siga as instruções no artigo Rotacionar o protetor da Transparent Data Encryption (TDE).

  • Mantenha todas as chaves usadas anteriormente no Azure Key Vault ou no HSM Gerenciado do Azure mesmo depois de alternar para chaves gerenciadas pelo serviço. Ele garante que os backups de banco de dados possam ser restaurados com os protetores de TDE armazenados no Azure Key Vault ou no HSM Gerenciado do Azure. Os protetores de TDE criados com o Azure Key Vault ou o HSM Gerenciado do Azure devem ser mantidos até que todos os backups armazenados restantes tenham sido 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 no artigo Remover um protetor TDE (Transparent Data Encryption) usando o PowerShell. Sempre gire para um novo protetor de TDE e verifique se todos os bancos de dados estão usando a nova chave antes de excluir ou desabilitar a chave comprometida. Excluir ou desabilitar a chave sem antes rotacioná-la faz com que todos os bancos de dados criptografados se tornem inacessíveis e não invalida nenhuma cópia da chave que tenha sido anteriormente armazenada em backup e restaurada em outro cofre.

Dica

Usando chaves versionadas e sem versão do Azure Key Vault para TDE

Ao definir o protetor de TDE, você pode referenciar uma chave do Azure Key Vault usando uma versão de chave específica ou um identificador de chave sem versão.

Em ambos os casos, o Banco de Dados SQL do Azure sempre resolve e usa a versão mais recente habilitada da chave no Azure Key Vault ou no HSM Gerenciado do Azure Key Vault. Use identificadores de chave sem versão para evitar a inserção de uma versão de chave específica na configuração do protetor de TDE.

No momento, há suporte para identificadores de chave sem versão apenas para o Banco de Dados SQL do Azure.

Exemplos:

  • Identificador de chave que inclui uma versão específica

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Identificador de chave sem versão

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

Rotação do protetor de TDE

Girar o protetor de TDE permite que você substitua a chave usada para proteger a DEK (chave de criptografia de 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.

Você pode rotacionar o protetor do TDE alterando a configuração para usar uma nova chave armazenada no Azure Key Vault ou no Azure Key Vault Managed HSM. Dependendo da oferta SQL do Azure e da configuração com suporte, isso pode incluir:

  • Mudar para uma nova versão da mesma chave
  • Alternar para uma chave diferente
  • Alternar entre tipos de chave com suporte, como chaves assimétricas (RSA) e simétricas (AES)

Observação

Transparent Data Encryption com chaves simétricas (AES) tem suporte apenas para Banco de Dados SQL do Azure e está em versão prévia pública.

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. A rotação automatizada está desabilitada por padrão. Quando ativado, o servidor verifica continuamente o cofre de chaves ou o HSM gerenciado em busca de novas versões da chave que está sendo usada como protetor TDE. Se uma nova versão da chave for detectada, o protetor de TDE no servidor ou banco de dados será automaticamente girado para a versão mais recente da chave dentro de 24 horas.

Quando usado com a rotação de chaves automatizada do Azure Key Vault or rotação automática no HSM gerenciado do Azure, 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 do TDE com o CMK, usando a rotação manual ou automatizada de chaves, sempre utiliza a versão mais recente da chave que é suportada. A configuração não permite o uso de uma versão anterior ou inferior das chaves. Usar sempre a versão de chave mais recente é conforme com a política de segurança do SQL do Azure que não permite versões de chave anteriores que poderiam estar comprometidas. As versões anteriores da chave podem ser necessárias para fins de backup ou restauração do banco de dados, especialmente para backups de retenção de longo prazo, quando 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 ou HSM gerenciado que está sendo usado com o servidor primário (e não outra chave com o mesmo material de chave). Alternativamente, antes de iniciar a replicação geográfica, 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 ou no HSM gerenciado, e se o sistema tenta 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 protetor de TDE no servidor primário ao servidor secundário. O servidor secundário exige acesso à chave no mesmo cofre de chaves ou HSM gerenciado 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) exigiu permissões no cofre de chaves do servidor primário e o sistema tenta adicionar a chave ao servidor secundário.

  • Cenários de geo-replicação usando chaves gerenciadas pelo cliente (CMK) para TDE são suportados. 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 Azure Key Vault ou no HSM Gerenciado do Azure, em até 10 minutos um banco de dados começará a negar todas as conexões com a mensagem de erro correspondente e alterar seu estado para Inacessível. A única ação permitida em um banco de dados no estado Inacessível é a exclusão.

Estado inacessível

Se o banco de dados estiver inacessível devido a uma interrupção de rede intermitente (como um erro 5XX), nenhuma ação será necessária, pois os bancos de dados voltarão a ficar online automaticamente. Para reduzir o efeito de erros de rede ou interrupções ao acessar o protetor de TDE no Azure Key Vault ou no HSM Gerenciado do Azure, um buffer de 24 horas é introduzido antes que o serviço tente mover o banco de dados para um estado inacessível. Se ocorrer um failover antes de atingir o estado inacessível, o banco de dados ficará indisponível devido à perda do cache de criptografia.

Se o servidor perder o acesso ao protetor de TDE gerenciado pelo cliente no Azure Key Vault ou no HSM Gerenciado do Azure devido a qualquer erro do Azure Key Vault (como um erro 4XX), o banco de dados será movido para um estado inacessível após 30 minutos.

Restaurar o acesso ao banco de dados após um erro do Azure Key Vault ou do HSM Gerenciado do Azure

Depois que o acesso à chave é restaurado, colocar o banco de dados online novamente requer tempo e etapas adicionais, que podem variar de acordo com a duração da indisponibilidade da chave e o tamanho dos dados dentro do banco de dados.

Se o acesso à chave for restaurado dentro de 30 minutos, o banco de dados será recuperado automaticamente na hora seguinte. No entanto, se o acesso à chave for restaurado após mais de 30 minutos, a recuperação automática do banco de dados não será possível. Nesses casos, restaurar o banco de dados envolve procedimentos extras por meio do portal do Azure e pode ser demorado, dependendo do tamanho do banco de dados.

Depois que o banco de dados estiver online novamente, configurações de nível de servidor previamente definidas, incluindo configurações de grupo de failover, marcas e configurações no nível do banco de dados, como configurações de pool elástico, escala de leitura, pausa automática, histórico de restauração pontual, política de retenção de longo prazo e outras, são perdidas. Portanto, é recomendável que os clientes implementem um sistema de notificação para detectar a perda de acesso à chave de criptografia dentro de 30 minutos. Depois que a janela de 30 minutos tiver expirado, aconselhamos validar todas as configurações de nível de servidor e banco de dados no banco de dados recuperado.

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

Captura de tela de um banco de dados inacessível TDE BYOK.

Revogação acidental do acesso do protetor de TDE

Isso pode acontecer de alguém com direitos de acesso suficientes ao cofre de chaves ou ao HSM gerenciado desabilitar acidentalmente o acesso do servidor à chave ao:

  • revogar as permissões get, wrapKey, unwrapKey do cofre de chaves ou do HSM gerenciado do servidor

  • excluir a chave

  • excluindo o Key Vault ou o HSM gerenciado

  • alterar as regras de firewall do cofre de chaves ou do HSM gerenciado

  • 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 a Instância Gerenciada de SQL e o Azure Key Vault ou o HSM Gerenciado do Azure

O bloco de conectividade de rede entre a Instância Gerenciada de SQL e o cofre de chaves ou o HSM gerenciado ocorre principalmente quando o cofre de chaves ou o recurso HSM gerenciado existe, mas seu ponto de extremidade não pode ser acessado da instância gerenciada. Em todos os cenários em que o cofre de chaves ou o ponto de extremidade HSM gerenciado pode ser acessado, mas a conexão é negada, faltam permissões, etc., os bancos de dados mudam seu estado para Inacessível.

As causas mais comuns para a falta de conectividade de rede com o Azure Key Vault ou o HSM Gerenciado do Azure são:

  • O Azure Key Vault ou o HSM gerenciado do Azure é acessado via um ponto de extremidade privado e o endereço IP privado do Azure Key Vault ou do serviço HSM Gerenciado do Azure 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 ou do HSM gerenciado não é resolvido ou é resolvido para um endereço IP inválido.

Teste a conectividade da Instância Gerenciada de SQL com o Azure Key Vault ou o HSM Gerenciado do Azure que hospeda o protetor de 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 ou do HSM gerenciado.

    • Verifique outras configurações de rede, como tabela de rotas, existência de dispositivo virtual e a configuração dele etc.

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 é mostrado como "Indisponível" depois que a primeira conexão com o banco de dados é negada.

  • Entradas são adicionadas ao log de atividades quando o acesso ao protetor de TDE no cofre de chaves gerenciado pelo cliente falha. 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, Logic App, Webhook, ITSM ou Runbook de Automação.

Banco de dados backup e restore com TDE gerenciado pelo cliente

Depois que um banco de dados é criptografado com TDE usando uma chave do Azure Key Vault ou do HSM Gerenciado do Azure, todos os backups recém-gerados também sã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 TDE do Azure Key Vault ou do HSM Gerenciado do Azure, verifique se o material da chave está disponível para o servidor de destino. Portanto, recomendamos que você mantenha todas as versões antigas do protetor de TDE no cofre de chaves ou no módulo HSM gerenciado, para que os backups de banco de dados possam ser restaurados.

Importante

Não pode haver mais de um conjunto de protetores de TDE para um servidor a qualquer momento. A chave marcada com Tornar a chave o protetor de TDE padrão no painel do portal do Azure é o protetor de TDE. No entanto, várias chaves podem ser vinculadas a um servidor sem marcá-las como um protetor de TDE. Essas chaves não são usadas para proteger o DEK, mas podem 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 Restaurar um banco de dados de um backup no Banco de Dados SQL do Azure. 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 nativa do SQL Server com a Instância Gerenciada de SQL, consulte Início Rápido: Restaurar um banco de dados para a Instância Gerenciada de SQL do Azure com O SSMS.

Consideração adicional para arquivos de log: Os arquivos de log de backup permanecem criptografados com o protetor original do TDE, mesmo que este tenha sido alterado e o banco de dados esteja agora usando um novo protetor do TDE. No momento da restauração, ambas as chaves sã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 ou no HSM Gerenciado do Azure, essa chave será necessária no momento da restauração, mesmo que o banco de dados tenha sido alterado para usar o TDE gerenciado pelo serviço enquanto isso.

Alta disponibilidade com o TDE gerenciado pelo cliente

Com o Azure Key Vault ou o HSM Gerenciado do Azure fornecendo várias camadas de redundância, os TDEs que usam uma chave gerenciada pelo cliente podem aproveitar a disponibilidade e a resiliência do Azure Key Vault ou do HSM Gerenciado do Azure e depender totalmente do Azure Key Vault ou da solução de redundância de HSM Gerenciado do Azure.

As várias camadas de redundância do Azure Key Vault garantem o acesso à chave mesmo se os componentes de serviço individuais falharem ou as regiões do Azure ou zonas de disponibilidade estiverem inoperantes. Para obter mais informações, confira Disponibilidade e redundância do Azure Key Vault.

O Azure Key Vault oferece os seguintes componentes de disponibilidade e resiliência fornecidos automaticamente sem intervenção do usuário:

Observação

Para todas as regiões em par, as chaves do Azure Key Vault são replicadas para ambas as regiões, e existem Módulos de Segurança de Hardware (HSM) em ambas as regiões que podem operar nessas chaves. Para obter mais informações, confira Replicação de dados. Isso se aplica tanto às camadas de serviço Standard quanto Premium do Azure Key Vault e às chaves de software ou hardware.

A replicação de várias regiões do HSM Gerenciado do Azure permite estender um pool de HSM Gerenciado do Azure de uma região do Azure (chamada de região primária) para outra região do Azure (chamada de região estendida). Uma vez configuradas, ambas as regiões estão ativas, podem atender a solicitações e, com a replicação automatizada, compartilham o mesmo material-chave, funções e permissões. Para obter mais informações, consulte Habilitar a replicação de várias regiões no HSM Gerenciado do Azure.

Recuperação de desastre geográfico com TDE gerenciado pelo cliente

Geo-replicação ativa e grupos de failover dão suporte a TDE gerenciado pelo cliente. Os servidores primário e secundário podem usar um Azure Key Vault ou um HSM gerenciado Azure em qualquer região suportada. Os servidores e o repositório de chaves não precisam estar na mesma região.

Para um failover bem-sucedido, ambos os servidores devem ter acesso a todos os Azure Key Vault ou Azure Managed HSM que contenham uma chave necessária.

Considerações de configuração

As seguintes considerações se aplicam ao configurar a geo-replicação ativa ou um grupo de failover no portal do Azure:

  • Localização do protetor TDE: Os servidores primário e secundário podem usar o mesmo Azure Key Vault ou Azure Managed HSM. Usar o mesmo repositório de chaves reduz o risco de o material de chave ficar dessincronizado. Se você usar cofres de chaves separados em várias regiões, é necessário manter sincronizado o material de chave exigido. Para informações sobre resiliência de armazenamento de chaves, veja disponibilidade e redundância do Azure Key Vault e replicação multi-região no HSM gerenciado.

  • Redundância de zonas: Quando disponível, a redundância de zonas para Banco de Dados SQL do Azure ou Instância Gerenciada de SQL do Azure oferece resiliência extra dentro de uma região. Para obter mais informações, consulte O que são zonas de disponibilidade do Azure?.

  • Permissões de chave: Tanto o servidor primário quanto o secundário devem ter as permissões necessárias em todo Azure Key Vault ou Azure Managed HSM que contenha um protetor TDE obrigatório.

  • Disponibilidade de chaves: Certifique-se de que as chaves necessárias estejam disponíveis tanto no servidor principal quanto no secundário. Os servidores não precisam usar protetores TDE idênticos, mas cada servidor deve ter o mesmo material de chave. Você pode adicionar chaves a um servidor usando o portal Azure, PowerShell, CLI do Azure ou a API SQL do Azure REST. Se as chaves necessárias não estiverem disponíveis no momento do failover, o banco de dados pode se tornar inacessível.

  • Endpoints privados: A configuração pode exigir uma zona DNS mais complexa se você usar endpoints privados no SQL do Azure (por exemplo, não é possível criar dois endpoints privados para o mesmo recurso na mesma zona DNS).

  • Conectividade de aplicativos: Os aplicativos devem usar lógica de repetição para lidar com falhas transitórias durante o failover.

Para obter informações sobre como configurar o recurso de recuperação de desastre geográfico do SQL do Azure, consulte Replicação geográfica ativa ou Visão geral dos grupos de failover e práticas recomendadas.

Importante

Quando você cria um link de geo-replicação ou grupo de failover, o SQL do Azure valida que ambos os servidores podem acessar todas as chaves gerenciadas pelo cliente necessárias. Se qualquer um dos servidores não conseguir acessar uma chave necessária, a operação de criação falha. Por exemplo, se os servidores primário e secundário usarem a Chave A e a Chave B, respectivamente, adicione ambas as chaves a ambos os servidores antes de criar o link de geo-replicação ou o grupo de failover.

O diagrama a seguir mostra a geo-replicação do SQL do Azure com um grupo de failover e o failover entre regiões do Azure Key Vault em configuração de região pareada:

Diagrama mostrando o suporte a failover entre regiões do Azure Key Vault para uma região emparelhada.

Comportamento do Azure Key Vault durante o failover

  • O Azure Key Vault inicia o failover, não você.
  • Enquanto o cofre de chaves na região principal estiver indisponível, o cofre de chaves será somente para leitura.
  • Você pode criar, importar e rotacionar chaves apenas enquanto o cofre de chaves na região principal estiver disponível. Após um failover, a rotação de chaves permanece bloqueada até que a região primária esteja novamente acessível.
  • Você não pode escolher ou verificar em qual região o cofre de chaves está atualmente, e não pode se conectar manualmente à região secundária.

Recuperação de um protetor TDE inacessível

Se um banco de dados em uma relação de georreplicação ativa ou em um grupo de failover se tornar inacessível, o plano de controle do SQL do Azure interrompe o vínculo e converte o banco em um banco de dados autônomo.

Depois de restaurar as permissões chave, normalmente você pode reativar o banco de dados principal. Você não pode reativar o banco de dados secundário porque o SQL do Azure não aceita backups completos dos bancos de dados secundários. Exclua o banco de dados secundário e, em seguida, restabeleça o link de geo-replicação ou o grupo de failover.

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 vigor, todas as tentativas de criar ou atualizar um servidor lógico no Azure ou na instância gerenciada falharão se ela não estiver configurada com uma 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, consulte 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 em repouso
  • As instâncias gerenciadas devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso.

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 captura 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 – Desabilita a política e não impede que os usuários criem ou atualizem um servidor lógico ou uma instância gerenciada sem o TDE gerenciado pelo cliente habilitado

Se a Azure Policy 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 são registrados no log de atividades do grupo de recursos.

Importante

Versões anteriores de políticas integradas para TDE gerenciado pelo cliente que contêm o efeito AuditIfNotExists estão obsoletas. As atribuições de política existentes usando as políticas preteridas não são afetadas e continuam funcionando como antes.

Conteúdo relacionado

  • Last updated on