Compartilhar via

Criptografia de dados transparente do Azure SQL 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 TDE (Transparent Data Encryption) — uma chave assimétrica gerenciada pelo cliente usada para proteger a DEK (Chave de Criptografia de Banco de Dados)— é armazenado no Azure Key Vault ou no HSM Gerenciado do Azure Key Vault. Esses são serviços de gerenciamento de chaves seguros e baseados em nuvem projetados para alta disponibilidade e escalabilidade. Azure Key Vault oferece suporte a chaves RSA e pode ser suportado por HSMs validados pelo FIPS 140-2, nível 2. Para clientes que exigem maior garantia, o HSM Gerenciado do Azure Key Vault oferece hardware validado FIPS 140-2 Nível 3. A chave pode ser gerada no serviço, importada ou transferida com segurança de HSMs locais. O acesso direto às chaves é restrito— os serviços autorizados executam operações criptográficas sem expor o material de 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 SQL Managed Instance 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 de 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 exclusiva 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.

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 de 2.048 bits e 3.072 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 uma chave existente para o cofre de chaves, verifique se ela é fornecida em um dos formatos de arquivo com suporte: .pfx, .byokou .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 ao configurar o TDE gerenciado pelo cliente

  • Para garantir o desempenho e a confiabilidade ideais, é altamente recomendável usar um Azure Key Vault dedicado para SQL do Azure. Esse cofre de chaves não deve ser compartilhado com outros serviços. Se o cofre de chaves estiver sob carga pesada, devido ao uso compartilhado ou a operações de chave excessivas, ele poderá 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. Isso é fundamental durante failovers de servidor, que disparam operações importantes para cada banco de dados no servidor.

    Para obter mais informações sobre o comportamento de limitação, consulte as 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 web 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ágina exceder 500, use um Azure Key Vault dedicado para cada banco de dados de Hiperescala que não seja compartilhado com outros recursos do Azure SQL.

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

  • 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 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 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 as versões anteriores da chave no cofre de chaves ou HSM Gerenciado ao rotacionar chaves, para que os backups de banco de dados mais antigos 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 com o qual foi criptografado no momento da criação. As rotações de chave podem ser executadas seguindo as instruções no artigo Rotacionar o protetor de Criptografia Transparente de Dados (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.

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. A rotação automatizada está desabilitada por padrão. Quando habilitado, o servidor verifica continuamente o cofre de chaves ou o HSM Gerenciado para qualquer nova versão da chave usada como protetor do 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.

  • 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 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. Todos os cenários em que o cofre de chaves ou o ponto de extremidade HSM gerenciado podem ser alcançados, mas a conexão é negada, há ausência de permissões, entre outros, fazem com que os bancos de dados alterem 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.

TDE gerenciado pelo cliente e DR geográfica

Em cenários de grupos de failover e replicação geográfica ativa, os servidores primários e secundários envolvidos podem ser vinculados ao Azure Key Vault ou ao HSM Gerenciado do Azure localizado em qualquer região. O servidor e o cofre de chaves ou o HSM gerenciado não precisam ser colocados na mesma região. Por isso, para simplificar, os servidores primário e secundário podem ser conectados ao mesmo cofre de chaves ou HSM gerenciado (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 ou HSM gerenciados separados forem usados em ambos os servidores.

O Azure Key Vault e o HSM Gerenciado do Azure têm várias camadas de redundância implementadas para garantir que as chaves e os cofres de chaves permaneçam disponíveis em caso de falhas de serviço ou falhas de região. A redundância é suportada pelas regiões não emparelhadas e emparelhadas. Para obter mais informações, confira Disponibilidade e redundância do Azure Key Vault.

Há várias opções para armazenar a chave protetora de TDE, com base nos requisitos dos clientes:

  • Utilize o Azure Key Vault e a resiliência nativa de região emparelhada ou a resiliência de região não emparelhada.

  • Use o HSM do cliente e as chaves de carga no Azure Key Vault em cofres de chaves do Azure separados em várias regiões.

  • Use o HSM Gerenciado do Azure e a opção de replicação entre regiões.

    • Essa opção permite que o cliente selecione a região desejada em que as chaves são replicadas.

O diagrama a seguir representa uma configuração para regiões emparelhadas (primária e secundária) para um failover cruzado do Azure Key Vault com a configuração do Azure SQL para replicação geográfica usando um grupo de failover.

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

Comentários do Azure Key Vault para Geo-DR

  • Servidores primários e secundários no SQL do Azure acessam o Azure Key Vault na região primária.

  • O failover do Azure Key Vault é iniciado pelo serviço do Azure Key Vault e não pelo cliente.

  • Se o Azure Key Vault fizer failover para a região secundária, o servidor no SQL do Azure ainda poderá acessar o mesmo Azure Key Vault. Embora internamente, a conexão do Azure Key Vault é redirecionada para o Azure Key Vault na região secundária.

  • Novas criações de chave, importações e rotações de chave só são possíveis enquanto o Azure Key Vault no primário está disponível.

  • Depois que o failover ocorrer, a rotação de chaves não será permitida até que o Azure Key Vault na região primária da região emparelhada esteja acessível novamente.

  • O cliente não pode se conectar manualmente à região secundária.

  • O Azure Key Vault está em modo somente leitura enquanto o Azure Key Vault na região primária está indisponível.

  • O cliente não pode escolher ou verificar em qual região o Azure Key Vault está atualmente.

  • Para a região não pareada, ambos os servidores SQL do Azure acessam o Azure Key Vault na primeira região (conforme indicado no gráfico) e o Azure Key Vault usa armazenamento com redundância de zona para replicar os dados dentro da região, através de zonas de disponibilidade independentes dentro da mesma região.

Para obter mais informações, consulte disponibilidade e redundância do Azure Key Vault, pares de regiões do Azure e regiões não emparelhadas, e acordos de nível de serviço para o Azure Key Vault.

Comentários do Azure SQL para Geo-DR

  • Use a opção redundante por zona da Instância Gerenciada de SQL do Azure e do Banco de Dados SQL do Azure para melhorar a resiliência. Para obter mais informações, consulte O que são zonas de disponibilidade do Azure?.

  • Use grupos de failover para a Instância Gerenciada de SQL do Azure e o Banco de Dados SQL do Azure para recuperação de desastre para uma região secundária. Para obter mais informações, consulte visão geral dos grupos de failover & práticas recomendadas.

  • Quando um banco de dados faz parte de grupos de failover ou replicação geográfica ativa e se torna inacessível, o plano de controle SQL quebra o link e converte o banco de dados em um banco de dados autônomo. Depois de corrigir as permissões de chave, o banco de dados primário normalmente pode ser colocado online novamente. O banco de dados secundário não pode ser colocado online novamente porque o SQL do Azure não aceita backups completos para bancos de dados secundários por design. A recomendação é remover os bancos de dados secundários e restabelecer o link.

  • A configuração pode exigir uma zona DNS mais complexa se pontos de extremidade privados forem usados no SQL do Azure (por exemplo, ele não pode criar dois pontos de extremidade privados para o mesmo recurso na mesma zona DNS).

  • Verifique se os aplicativos usam lógica de repetição.

Há vários cenários em que os clientes podem querer escolher a solução de HSM Gerenciado do Azure em vez do Azure Key Vault:

  • Necessidade de conexão manual ao cofre secundário.

  • Leia o requisito de acesso ao cofre mesmo se ocorrer uma falha.

  • Flexibilidade para escolher para qual região seu material criptográfico é replicado

    • Requer habilitar a replicação entre regiões, que cria o segundo pool de HSM Gerenciado do Azure na segunda região.

  • O uso do HSM Gerenciado do Azure permite que os clientes criem uma réplica exata para HSM se o original estiver perdido ou indisponível.

  • Uso do HSM Gerenciado do Azure para requisitos regulatórios ou de segurança.

  • Ter a capacidade de fazer backup de todo o cofre em vez de fazer backup de chaves individuais.

Para obter mais informações, consulte Habilitar a replicação de várias regiões no HSM Gerenciado do Azure e recuperação de desastre do HSM Gerenciado.

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 Política do Azure para TDE gerenciado pelo cliente for definida como Negar, a criação do servidor lógico SQL do Azure ou da instância gerenciada 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