Partilhar via

Criptografia de dados transparente do SQL do Azure com chave gerenciada pelo cliente

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

A criptografia de dados transparente (TDE) no SQL do Azure com chave gerida pelo cliente (CMK) habilita o cenário de "Traga Sua Própria Chave" (BYOK) para proteção de dados em repouso e permite que as organizações implementem a separação de responsabilidades no gerenciamento de chaves e dados. Com o TDE gerenciado pelo cliente, o cliente é responsável pelo gerenciamento do ciclo de vida de uma chave (criação, upload, rotação, exclusão de chaves), permissões de uso de chaves e auditoria de operações em chaves.

Nesse cenário, o protetor TDE (Criptografia de Dados Transparente) — 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 Azure Key Vault Managed HSM. Estes são serviços de gerenciamento de chaves seguros e baseados em nuvem, projetados para alta disponibilidade e escalabilidade. O Azure Key Vault suporta chaves RSA e pode ser apoiado por HSMs validados pelo FIPS 140-2 Nível 2. Para clientes que necessitam de maior garantia, o Azure Key Vault Managed HSM 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 da chave.

Para o Banco de Dados SQL do Azure e o Azure Synapse Analytics, o protetor 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 SQL do Azure, o protetor TDE é definido no nível da instância e é herdado por todos os bancos de dados criptografados nessa instância. O termo servidor refere-se a um servidor no Banco de Dados SQL e no Azure Synapse e a uma instância gerenciada na Instância Gerenciada do SQL ao longo deste artigo, a menos que indicado de forma diferente.

O gerenciamento do protetor TDE no nível do banco de dados no Banco de Dados SQL do Azure está disponível. Para obter mais informações, consulte Criptografia de dados transparente (TDE) com chaves gerenciadas pelo cliente no nível do banco de dados.

Observação

Este artigo aplica-se à Base de Dados SQL do Azure, à Instância Gerida SQL do Azure e ao Azure Synapse Analytics (pools SQL dedicados (anteriormente SQL DW)). Para obter mais informações sobre criptografia de dados transparente para pools SQL dedicados dentro de espaços de trabalho Synapse, consulte Criptografia do Azure Synapse Analytics.

Observação

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

Chave gerenciada pelo cliente (CMK) e traga sua própria chave (BYOK)

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

  • Chave gerenciada pelo cliente (CMK) - O cliente gerencia o ciclo de vida da chave, incluindo a criação, rotação e exclusão de chaves. A chave é armazenada no Cofre da Chave do Azure ou no HSM Gerenciado do Azure e usada para criptografia da Chave de Criptografia de Banco de Dados (DEK) 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 módulo de segurança de hardware (HSM) local para o Azure Key Vault ou o Azure Managed HSM. Essas chaves importadas podem ser usadas como qualquer outra chave no Cofre de Chaves do Azure, inclusive como uma Chave Gerenciada pelo Cliente para criptografia da DEK. Para obter mais informações, consulte Importar chaves protegidas por HSM para HSM gerenciado (BYOK).

Benefícios do TDE gerenciado pelo cliente

A TDE gerenciada pelo cliente oferece os seguintes benefícios ao cliente:

  • Controle total e granular sobre o uso e gerenciamento do protetor TDE.

  • Transparência do uso do protetor TDE.

  • Capacidade de implementar separação de funções na gestão de chaves e dados dentro da organização.

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

  • Gerenciamento central de chaves no Cofre de Chaves do Azure.

  • Maior confiança dos seus clientes finais, uma vez que o Azure Key Vault foi concebido de forma a que a Microsoft não consiga ver nem extrair chaves de encriptação.

Importante

Para aqueles que usam TDE gerenciado por serviço 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á tempo de inatividade nem recriptografia 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 recriptografia da DEK, que é uma operação rápida e online.

Permissões para configurar TDE gerenciada pelo cliente

Diagrama mostrando a configuração e o funcionamento do TDE gerenciado pelo cliente.

Selecione o tipo de Cofre da Chave do Azure que você deseja usar.

Para que o servidor lógico no Azure use o protetor TDE armazenado no Cofre da Chave do Azure para criptografia da DEK, o Administrador do Cofre da Chave 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 a um usuário, grupo ou aplicativo acesso ao cofre de chaves. Este método é recomendado pela sua flexibilidade e granularidade. A identidade do servidor precisa da função de Utilizador de Criptografia () do Key Vault Crypto Service () para poder usar a chave em operações de criptografia e descriptografia.

  • Política de acesso ao cofre - 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 Cofre da Chave do Azure
    • wrapKey - para poder proteger (encriptar) DEK
    • unwrapKey - para poder desproteger (desencriptar) DEK

No menu Configuração do Access portal do Azure do cofre da chave, você tem a opção de selecionar de controle de acesso baseado em função do Azure ou política de acesso do Vault. Para obter instruções passo a passo sobre como configurar uma configuração de acesso ao Cofre de Chaves do Azure 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, consulte a segurança do Azure Key Vault .

Um Administrador do Cofre de Chaves do também pode habilitar o registro de eventos de auditoria do cofre de chaves, para que eles possam ser auditados posteriormente.

Quando um servidor é configurado para usar um protetor TDE do Cofre de Chaves do Azure, o servidor envia a 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 DEK protegido para o cofre de chaves para desencriptação.

Os auditores podem usar o Azure Monitor para revisar os logs de AuditEvent do cofre de chaves, se o registo estiver ativado.

Observação

Pode levar cerca de 10 minutos para que qualquer alteração de permissão entre em vigor no cofre de chaves. Isso inclui revogar as permissões de acesso ao protetor TDE no AKV, e os utilizadores dentro desse período de tempo ainda poderão ter permissões de acesso.

Requisitos para configurar o TDE gerenciado pelo cliente

  • Os recursos de proteção de exclusão suave e limpeza devem ser habilitados no Cofre da Chave do Azure. Isso ajuda a evitar o cenário de cofre de chaves acidental ou mal-intencionado ou exclusão de chave que pode levar o banco de dados a entrar estado de Inacessível. Ao configurar o protetor 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 proteção de exclusão suave e limpeza ativada. Se a proteção de exclusão suave e limpeza não estiver ativada no cofre de chaves, a configuração do protetor TDE falhará com um erro. Nesse caso, a proteção soft-delete e purge deve primeiro ser ativada no cofre de chaves e, em seguida, a configuração do protetor TDE deve ser executada.

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

Requisitos para configurar o protetor TDE

  • O protetor TDE só pode ser uma chave assimétrica, RSA ou RSA HSM. Os comprimentos de chave suportados são de 2.048 bits e 3.072 bits.

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

  • A chave deve estar no estado Enabled.

  • Se estiver a importar uma chave existente para o cofre de chaves, certifique-se de que é fornecida num dos formatos de ficheiro suportados: .pfx, .byokou .backup. Para importar chaves protegidas por HSM para o Azure Managed HSM, consulte Importar chaves protegidas por HSM para o Managed HSM (BYOK).

Observação

Um problema com as versões do Thales CipherTrust Manager anteriores à v2.8.0 impede que chaves recém-importadas para o Cofre de Chaves do Azure sejam usadas com o Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure para cenários TDE gerenciados pelo cliente. Para mais detalhes sobre esta questão, consulte as notas de atualização do CipherTrust Cloud Key Manager. Para esses casos, aguarde 24 horas após importar a chave para o Cofre de Chaves do Azure para começar a usá-la como protetor TDE para o servidor ou instância gerenciada. Este 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 Cofre da Chave do Azure dedicado para o Azure SQL. Este cofre de chaves não deve ser partilhado com outros serviços. Se o cofre de chaves estiver sob carga pesada, devido ao uso compartilhado ou operações de chave excessivas, 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. Isso é crítico durante failovers de servidor, que acionam operações de chave para cada banco de dados no servidor.

    Para obter mais informações sobre o comportamento de limitação, consulte Orientações de limitação do Cofre de Chaves do Azure.

    Para manter uma alta disponibilidade e evitar problemas de restrição, siga estas diretrizes para cada assinatura:

    • Use um Cofre da Chave do Azure dedicado para recursos SQL do Azure.

    • Associe não mais de 500 bancos de dados de uso geral a um único Cofre de Chaves do Azure.

    • Associe no máximo 200 bancos de dados Críticos para os Negócios a um único Cofre de Chaves do Azure.

    • O número de bancos de dados Hyperscale que podem ser associados a um único Cofre de Chaves do Azure é determinado pelo número de servidores de página. Cada servidor de página está vinculado a um arquivo de dados lógico. Para localizar o número de servidores de página, execute a seguinte consulta.

      -- # 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 Cofre da Chave do Azure. À medida que o banco de dados cresce, o número de servidores de página aumenta automaticamente, por isso é importante monitorar o tamanho do banco de dados regularmente. Se o número de servidores de página exceder 500, use um Cofre de Chaves do Azure dedicado para cada banco de dados Hyperscale que não é compartilhado com outros recursos SQL do Azure.

    • Monitorize e configure alertas no 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 recursos 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 a auditoria e a geração de relatórios sobre todas as chaves de criptografia: o Cofre de Chaves do Azure fornece logs que são fáceis de injetar em outras informações de segurança e ferramentas de gerenciamento de eventos. O Operations Management Suite o Log Analytics é um exemplo de um serviço já integrado.

  • Utilize um cofre de chaves de uma região do Azure que possa replicar o seu conteúdo para uma região emparelhada para 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 SQL do Azure em uma região agora podem ser vinculados ao Cofre da Chave do Azure em qualquer outra região. O servidor e o cofre de chaves não precisam estar localizados na mesma região.

Recomendações ao configurar o protetor TDE

  • Mantenha uma cópia do protetor TDE em um local seguro ou deposite-a no serviço de depósito.

  • Se a chave for gerada no cofre de chaves, crie um backup de chave antes de usá-la no Cofre de Chaves do Azure pela primeira vez. O backup pode ser restaurado apenas para um Cofre de Chaves do Azure. 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, tags e atribuições de função. Para obter mais informações, consulte Backup e restauração completos e Restauração seletiva de chaves.

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

  • Mantenha as versões anteriores da chave no cofre de chaves ou no HSM gerenciado durante a rotação de chaves, para que backups de bancos de dados mais antigos possam ser restaurados. Quando o protetor TDE é alterado para um banco de dados, backups antigos do banco de dados não são atualizados usar o protetor TDE mais recente. No momento da restauração, cada backup precisa do protetor TDE com o qual foi criptografado no momento da criação. As rotações de chave podem ser realizadas seguindo as instruções no artigo Girar o protetor de criptografia de dados transparente (TDE).

  • Mantenha todas as chaves usadas anteriormente no Azure Key Vault ou no Azure Managed HSM mesmo depois de mudar para chaves gerenciadas por serviço. Ele garante que os backups de banco de dados possam ser restaurados com os protetores TDE armazenados no Azure Key Vault ou no Azure Managed HSM. Os protetores TDE criados com o Azure Key Vault ou o Azure Managed HSM 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 TDE

Girar o protetor TDE para um servidor significa alternar para uma nova chave assimétrica que protege os bancos de dados no servidor. A rotação de chaves é uma operação on-line e deve levar apenas alguns segundos para ser concluída. A operação apenas descriptografa e criptografa novamente a chave de criptografia do banco de dados, não todo o banco de dados.

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

A rotação automatizada do protetor TDE pode ser ativada ao configurar o protetor TDE para o servidor. A rotação automatizada está desativada 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 detetada, o protetor 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 rotação automatizada de chaves no Cofre de Chaves do Azure ou rotação automática no HSM Gerenciado do Azure, esse recurso permite a rotação de toque zero de ponta a ponta para o protetor TDE no Banco de Dados SQL do Azure e na Instância Gerenciada SQL do Azure.

Observação

Configurar TDE com CMK, usando rotação manual ou automatizada de chaves, utiliza sempre 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 está em conformidade com a política de segurança SQL do Azure que não permite versões de chave anteriores que possam ser comprometidas. As versões anteriores da chave podem ser necessárias para fins de backup ou restauração de banco de dados , especialmente para backups de retenção de longo prazo , onde as versões de chave mais antigas 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 TDE

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

  • Os servidores primário e secundário devem ter Get, wrapKey e unwrapKey permissões no cofre de chaves do servidor primário (cofre de chaves que armazena a chave protetora TDE do servidor primário).

  • Para um servidor com rotação automatizada de chaves habilitada, antes de iniciar a replicação geográfica, adicione a chave de criptografia que está sendo usada como protetor TDE no servidor primário ao servidor secundário. O servidor secundário requer acesso à chave no mesmo cofre de chaves ou módulo de segurança de hardware (HSM) gerido que está a ser utilizado com o servidor primário (e não a 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 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 TDE no servidor primário ao servidor secundário. O servidor secundário requer acesso à chave no mesmo cofre de chaves ou módulo de segurança de hardware (HSM) gerido que está a ser utilizado com o servidor primário (e não a 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 se o sistema tenta adicionar a chave ao servidor secundário.

  • Há suporte para cenários de replicação geográfica usando chaves gerenciadas pelo cliente (CMK) para TDE. A TDE com rotação automática de chaves deve 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 TDE, consulte Rotação automática de chaves para configurações de replicação geográfica.

Protetor TDE inacessível

Quando a TDE é configurada para usar uma chave gerenciada pelo cliente, o acesso contínuo ao protetor TDE é necessário para que o banco de dados permaneça online. Se o servidor perder o acesso ao protetor TDE gerenciado pelo cliente no Cofre da Chave do Azure 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 é excluí-lo.

Estado inacessível

Se o banco de dados estiver inacessível devido a uma interrupção intermitente da rede (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 TDE no Cofre da Chave do Azure 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 TDE gerenciado pelo cliente no Azure Key Vault ou no Azure Managed HSM 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 Azure Managed HSM

Depois que o acesso à chave é restaurado, colocar o banco de dados on-line novamente requer tempo e etapas adicionais, que podem variar com base na duração da indisponibilidade da chave e no tamanho dos dados dentro do banco de dados.

Se o acesso à chave for restaurado dentro de 30 minutos, o banco de dados autorrecupera-se automaticamente durante a 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, a restauração do banco de dados envolve procedimentos extras por meio do portal do Azure e pode ser demorada, dependendo do tamanho do banco de dados.

Quando a base de dados voltar a estar online, as definições previamente configuradas ao nível do servidor, tais como as configurações de grupo de tolerância a falhas, etiquetas, e as definições ao nível da base de dados, tais como configurações de pool elástico, escala de leitura, pausa automática, histórico de restauração a partir de um ponto no tempo, política de retenção a longo prazo, e outras, serão perdidas. Por isso, recomenda-se que os clientes implementem um sistema de notificação para detetar a perda de acesso à chave de criptografia em 30 minutos. Depois que a janela de 30 minutos expirar, recomendamos validar todas as configurações de nível de servidor e banco de dados no banco de dados recuperado.

Segue-se uma vista dos passos adicionais necessários no portal para colocar uma base de dados inacessível novamente online.

Captura de ecrã de uma base de dados TDE BYOK inacessível.

Revogação acidental do acesso do protetor TDE

Pode acontecer que alguém com direitos de acesso suficientes ao cofre de chaves ou ao HSM gerido desative acidentalmente o acesso do servidor à chave por:

  • Revogar as permissões obter, wrapKey e unwrapKey do cofre de chaves ou do HSM gerenciado no servidor.

  • apagar a chave

  • eliminar o cofre de chaves ou o HSM gerenciado

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

  • excluindo 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 do SQL e o Cofre da Chave do Azure ou o HSM Gerenciado do Azure

O bloco de conectividade de rede entre a Instância Gerenciada SQL e o cofre de chaves ou HSM gerenciado acontece principalmente quando o cofre de chaves ou o recurso HSM gerenciado existe, mas seu ponto de extremidade não pode ser acessado a partir 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, permissões ausentes, etc., 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 Azure Managed HSM são:

  • O Azure Key Vault ou o Azure Managed HSM é exposto através de um ponto de extremidade privado e o endereço IP privado do Azure Key Vault ou do serviço Azure Managed HSM não é permitido nas regras de saída do Network Security Group (NSG) associado à sub-rede da instância gerida.

  • Resolução DNS incorreta, como quando o cofre de chaves ou o FQDN HSM gerenciado não é resolvido ou é resolvido para um endereço IP inválido.

Teste a conectividade da Instância Gerenciada do SQL com o Cofre da Chave do Azure ou o HSM Gerenciado do Azure que hospeda o protetor TDE.

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

Caso o teste retorne TcpTestSucceeded: False, revise a configuração de rede:

  • Verifique o endereço IP resolvido, confirme se é válido. Um valor ausente significa que há problemas com a resolução de 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 sua configuração, etc.

Monitore o TDE gerenciado pelo cliente

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

  • Azure Resource Health. Um banco de dados inacessível que perdeu o acesso ao protetor TDE aparece como "Indisponível" depois que a primeira conexão com o banco de dados é negada.

  • Registro de atividades quando falhar o acesso ao protetor TDE no cofre de chaves gerido pelo cliente, as entradas serão adicionadas ao log de atividades. A criação de alertas para esses eventos permite que você restabeleça o acesso o mais rápido possível.

  • Grupos de Ação podem ser definidos para enviar notificações e alertas com base em suas preferências, por exemplo, Email/SMS/Push/Voice, Logic App, Webhook, ITSM ou Automation Runbook.

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 Azure Managed HSM, todos os backups recém-gerados também são criptografados com o mesmo protetor TDE. Quando o protetor TDE é alterado, backups antigos do banco de dados não são atualizados usar o protetor TDE mais recente.

Para restaurar um backup criptografado com um protetor TDE do Azure Key Vault ou do Azure Managed HSM, 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 TDE no cofre de chaves ou no HSM gerenciado, para que os backups do banco de dados possam ser restaurados.

Importante

Não pode haver mais de um protetor TDE definido para um servidor a qualquer momento. A chave marcada com Tornar a chave o protetor TDE padrão no painel do portal do Azure é o protetor TDE. No entanto, várias chaves podem ser vinculadas a um servidor sem marcá-las como um protetor TDE. Essas chaves não são usadas para proteger a DEK, mas podem ser usadas durante a restauração a partir de um backup, se o arquivo de backup for criptografado com a chave com a impressão digital correspondente.

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 <Servername> do servidor de destino não tem acesso a todos os URIs AKV criados entre <> de carimbo de data/hora #1 e <>de carimbo de data/hora #2. Repita a operação depois de restaurar todos os URIs 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 ausentes. Para garantir que todos os backups possam ser restaurados, certifique-se de que o servidor de destino para a restauração tenha acesso a todas as chaves necessárias. Essas chaves não precisam ser marcadas como proteção TDE.

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

Outra consideração para os arquivos de log: Os arquivos de log de backup permanecem criptografados com o protetor TDE original, mesmo que ele tenha sido girado e o banco de dados agora esteja usando um novo protetor 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 TDE armazenado no Cofre de Chaves do Azure 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 por serviço nesse meio tempo.

Alta disponibilidade com TDE gerenciada pelo cliente

Com o Azure Key Vault ou o Azure Managed HSM 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 Azure Managed HSM e confiar totalmente na solução de redundância do Azure Key Vault ou do Azure Managed HSM.

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 ou zonas de disponibilidade do Azure estiverem inativas. Para obter mais informações, consulte Disponibilidade e redundância do Azure Key Vault.

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

Observação

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

A replicação multirregional do Azure Managed HSM permite estender um pool do Azure Managed HSM 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 ficam ativas, capazes de atender solicitações e, com a replicação automatizada, compartilham o mesmo material, funções e permissões de chave. Para obter mais informações, consulte Habilitar replicação de várias regiões no Azure Managed HSM.

Geo-DR e TDE gerido pelo cliente

Em cenários de replicação geográfica ativa e grupos de failover , os servidores primário e secundário envolvidos podem ser vinculados ao Cofre da Chave do Azure ou ao HSM Gerenciado do Azure localizados em qualquer região. O servidor e o cofre de chaves ou o HSM gerenciado não precisam ser colocados na mesma região. Com 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 criptografia pode estar desfasado, se forem usados cofres de chaves separados ou HSMs geridos para os dois servidores.

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

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

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

  • Use o HSM do cliente e carregue chaves no Cofre de Chaves do Azure em Cofres de Chaves do Azure separados em várias regiões.

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

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

O diagrama a seguir representa uma configuração para regiões emparelhadas (primária e secundária) de 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.

Azure Key Vault observações para Geo-DR

  • Os servidores primários e secundários no SQL do Azure acessam o Cofre da Chave do Azure na região primária.

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

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

  • Novas criações, importações e rotações de chaves só são possíveis enquanto o Cofre de Chaves do Azure no primário estiver disponível.

  • Uma vez que o failover ocorra, a rotação de chaves não é permitida até que o Cofre de Chaves do Azure na região primária do par de regiões esteja acessível novamente.

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

  • O Azure Key Vault está num estado só de leitura quando o Azure Key Vault na região primária não está operacional.

  • O cliente não pode escolher ou verificar em que região o Cofre da Chave do Azure está atualmente.

  • Para região não emparelhada, os servidores SQL do Azure acessam o Cofre da Chave do Azure na primeira região (conforme indicado no gráfico) e o Cofre da Chave do Azure usa armazenamento com redundância de zona para replicar os dados dentro da região, em zonas de disponibilidade independentes 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 emparelhadase Acordos de nível de serviço para o Azure Key Vault.

Observações SQL do Azure para Geo-DR

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

  • Utilize grupos de failover para a Instância Gerida do SQL do Azure e a Base de Dados SQL do Azure para recuperação de desastres numa região secundária. Para obter mais informações, consulte a visão geral dos grupos de failover , práticas recomendadas &.

  • Quando um banco de dados faz parte de grupos ativos de replicação geográfica ou failover 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 usa backups completos para bancos de dados secundários por design. A recomendação é abandonar os bancos de dados secundários e restabelecer o vínculo.

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

  • Certifique-se de que os aplicativos usem a lógica de repetição.

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

  • Requisito de conexão manual com o cofre secundário.

  • Mesmo em caso de falha, há um requisito de acesso de leitura ao cofre.

  • Flexibilidade para escolher para qual região seu material-chave será replicado

    • Requer a habilitação da 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 o HSM se o original for perdido ou indisponível.

  • Uso do Azure Managed HSM para requisitos de segurança ou regulamentares.

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

Para obter mais informações, consulte Habilitar replicação de várias regiões no Azure Managed HSM e Managed HSM disaster recovery.

Política do Azure para TDE gerenciado pelo cliente

A Política do Azure pode ser usada para impor TDE gerenciada pelo cliente durante a criação ou atualização de um servidor do Banco de Dados SQL do Azure ou da Instância Gerenciada SQL do Azure. Com essa política em vigor, todas as tentativas de criar ou atualizar um servidor lógico no Azure ou uma instância gerenciada falham se ele não estiver configurado com uma chave gerenciada pelo cliente. A Política do Azure pode ser aplicada a toda a assinatura do Azure ou apenas dentro de um grupo de recursos.

Para obter mais informações sobre a Política do Azure, consulte O que é a Política do Azure e Estrutura de definição da Política do Azure.

As duas políticas internas a seguir são suportadas para TDE gerenciada pelo cliente na Política do Azure:

  • Os servidores SQL 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ítica de TDE gerenciada pelo cliente pode ser gerenciada acessando o portal do Azuree pesquisando o serviço Política de. Em Definições, procure a chave gerenciada pelo cliente.

Estas políticas têm três efeitos:

  • Auditoria - A configuração padrão e captura apenas um relatório de auditoria nos logs de atividade da Política do Azure

  • Negar - Impede a criação ou atualização do servidor lógico ou da instância gerenciada sem que uma chave gerida pelo cliente esteja configurada

  • Desativado - Desativa a política e não restringe os usuários a criar ou atualizar um servidor lógico ou instância gerida sem TDE gerida pelo cliente ativada

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

Importante

As versões anteriores das políticas predefinidas para TDE geridas pelo cliente que contêm o efeito AuditIfNotExists foram descontinuadas. As atribuições de política existentes que usam as políticas preteridas não são afetadas e continuam a funcionar como antes.

Conteúdo relacionado

  • Last updated on