Partilhar via

Encriptação de dados transparente do SQL do Azure com chave gerida pelo cliente

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure Azure SQL Managed InstanceAzure Synapse Analytics (somente pools SQLdedicados)

A criptografia de dados transparente (TDE) do SQL do Azure com chave gerenciada pelo cliente (CMK) habilita o cenário Bring Your Own Key (BYOK) para proteção de dados em repouso e permite que as organizações implementem a separação de tarefas no gerenciamento de chaves e dados. Com a Encriptação de Dados Transparente gerida pelo cliente, o cliente é responsável e tem o controlo total da gestão do ciclo de vida da chave (criação, carregamento, rotação e eliminação da chave), das permissões de utilização da chave e da auditoria de operações nas chaves.

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

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 em todo este documento, 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.

Nota

  • 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 documentação sobre criptografia de dados transparente para pools SQL dedicados dentro de espaços de trabalho Synapse, consulte Criptografia do Azure Synapse Analytics.
  • Para fornecer aos clientes SQL do Azure duas camadas de criptografia de dados em repouso, a criptografia de infraestrutura (usando o algoritmo de criptografia AES-256) com chaves gerenciadas pela plataforma está sendo implantada. Isso fornece uma camada adicional de criptografia em repouso, juntamente com TDE com chaves gerenciadas pelo cliente, que já está disponível. Para o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure, todos os bancos de dados, incluindo o banco de dados e outros bancos de dados do sistema, serão criptografados quando a master criptografia de infraestrutura estiver ativada. Neste momento, os clientes devem solicitar acesso a esse recurso. Se você estiver interessado nesse recurso, entre em contato com AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Nota

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

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 Cofre de Chaves pode revogar as permissões de acesso à chave para tornar o banco de dados criptografado inacessível;

  • Gestão central de chaves em AKV;

  • Maior confiança dos seus clientes finais, uma vez que o AKV foi concebido de tal forma que a Microsoft não consegue ver nem extrair chaves de encriptação;

Importante

Para aqueles que utilizam a Encriptação de Dados Transparente gerida pelo serviço e que gostariam de começar a utilizar a Encriptação de Dados Transparente gerida pelo cliente, os dados permanecem encriptados durante o processo de alteração e não há um período de inatividade nem de reencriptação dos ficheiros da base de dados. A alteração de uma chave gerida pelo serviço para uma chave gerida pelo cliente só requer a reencriptação da chave de encriptação, uma operação rápida e online.

Como funciona a Encriptação de Dados Transparente gerida pelo cliente

Setup and functioning of the customer-managed TDE

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

  • get - para recuperar a parte pública e as propriedades da chave no Cofre da Chave

  • wrapKey - para poder proteger (encriptar) DEK

  • unwrapKey - para poder desproteger (desencriptar) DEK

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

Quando o servidor é configurado para usar um protetor TDE da AKV, 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 eventos do cofre de chaves, se o log estiver habilitado.

Nota

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 usuários dentro desse período de tempo ainda podem ter permissões de acesso.

Requisitos para configurar a TDE gerida pelo cliente

Requisitos para configurar o AKV

  • Os recursos de proteção de exclusão suave e limpeza devem ser habilitados no cofre de chaves para proteger contra perda de dados devido à exclusão acidental de chave (ou cofre de chaves).

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

    • Consoante o modelo de permissão do cofre de chaves (política de acesso ou RBAC do Azure), o acesso ao cofre de chaves pode ser concedido através da criação de uma política de acesso no cofre de chaves ou da criação de uma nova atribuição de função RBAC do Azure com a função Utilizador de Encriptação do Serviço de Criptografia do Key Vault.

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

Habilite a proteção de exclusão suave e limpeza para AKV

Importante

A proteção de exclusão suave e limpeza deve ser habilitada no cofre de chaves ao configurar o TDE gerenciado pelo cliente em um servidor ou instância gerenciada novo ou existente.

A proteção de exclusão suave e limpeza são recursos importantes do Azure Key Vault que permitem a recuperação de cofres excluídos e objetos excluídos do cofre de chaves, reduzindo o risco de um usuário excluir acidentalmente ou maliciosamente uma chave ou um cofre de chaves.

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

  • A proteção contra limpeza pode ser ativada usando a CLI do Azure ou o PowerShell. Quando a proteção contra remoção está ativada, não é possível remover um cofre ou objeto com o estado eliminado até o período de retenção ter passado. O período de retenção padrão é de 90 dias, mas é configurável de 7 a 90 dias por meio do portal do Azure.

  • O SQL do Azure requer que a proteção de exclusão suave e limpeza seja habilitada no cofre de chaves que contém a chave de criptografia que está sendo usada como o protetor TDE para o servidor ou instância gerenciada. 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 no estado 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.

Requisitos para configurar o protetor da Encriptação de Dados Transparente

  • O protetor da Encriptação de Dados Transparente só pode ser uma chave assimétrica, RSA ou RSA-HSM. Os comprimentos de chave suportados são 2048 bits e 3072 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 Habilitado .

  • Se estiver a importar uma chave existente para o cofre de chaves, certifique-se de que a fornece nos formatos de ficheiro suportados (.pfx, .byokou .backup).

Nota

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

Nota

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. Mais detalhes sobre esta questão podem ser encontrados aqui. Para esses casos, aguarde 24 horas após a importação da chave para o cofre de chaves para começar a usá-la como protetor TDE para o servidor ou instância gerenciada. Este problema foi resolvido no Thales CipherTrust Manager v2.8.0.

Recomendações ao configurar a TDE gerida pelo cliente

Recomendações ao configurar o AKV

  • Associe no máximo 500 bancos de dados de uso geral ou 200 bancos de dados críticos para os negócios no total a um cofre de chaves em uma única assinatura para garantir alta disponibilidade quando o servidor acessar o protetor TDE no cofre de chaves. Esses números são baseados na experiência e documentados nos limites do serviço do cofre de chaves. A intenção aqui é evitar problemas após o failover do servidor, pois ele acionará tantas operações importantes no vault quanto houver bancos de dados nesse servidor.

  • Defina um bloqueio de recursos no cofre de chaves para controlar quem pode eliminar este recurso crítico e evitar a eliminaçã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 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 Log Analytics é um exemplo de um serviço que já está integrado.

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

Nota

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 de chaves em qualquer outra região. O servidor e o cofre de chaves não têm de estar colocalizados 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 usar a chave no AKV pela primeira vez. O backup pode ser restaurado apenas para um Cofre de Chaves do Azure. Saiba mais sobre o comando Backup-AzKeyVaultKey .

  • 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 ao girar 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 para usar o protetor TDE mais recente. No momento do restauro, cada cópia de segurança precisa do protetor TDE com o qual foi encriptado aquando da criação. As rotações de chave podem ser executadas seguindo as instruções em Girar o protetor de criptografia de dados transparente usando o PowerShell.

  • Mantenha todas as chaves utilizadas anteriormente no AKV, mesmo depois de mudar para as chaves geridas pelo serviço. Garante, assim, que as cópias de segurança da base de dados podem ser restauradas com os protetores TDE armazenados no AKV. Os protetores TDE criados com o Azure Key Vault devem ser mantidos até que todos os backups armazenados restantes tenham sido criados com chaves gerenciadas pelo serviço. Faça cópias de segurança recuperáveis destas chaves com Backup-AzKeyVaultKey.

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

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.

A 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 verificará continuamente o cofre de chaves 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 será automaticamente girado para a versão mais recente da chave dentro de 60 minutos.

Quando usado com rotação automatizada de chaves no Cofre de Chaves 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.

Nota

Definir TDE com CMK usando rotação manual ou automatizada de chaves sempre usará 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 do banco de dados, especialmente no caso de 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:

Protetor de Encriptação de Dados Transparente Inacessível

Quando a Encriptação de Dados Transparente é configurada para utilizar uma chave gerida pelo :ente, o acesso contínuo ao protetor da Encriptação de Dados Transparente é necessário para que a base de dados permaneça online. Se o servidor perder o acesso ao protetor TDE gerenciado pelo cliente no AKV, 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.

Nota

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

Depois que o acesso à chave é restaurado, colocar o banco de dados on-line novamente requer tempo e etapas extras, que podem variar com base no tempo decorrido sem acesso à chave e no tamanho dos dados no banco de dados:

Nota

  • Se o acesso à chave for restaurado dentro de 30 minutos, o banco de dados será recuperado automaticamente na próxima hora.
  • 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. Trazer de volta o banco de dados requer etapas adicionais no portal do Azure e pode levar uma quantidade significativa de tempo, dependendo do tamanho do banco de dados.
  • Quando o banco de dados estiver online novamente, as configurações no nível do servidor previamente configuradas que podem incluir configuração de grupo de failover, tags e configurações no nível do banco de dados, como configuração de pools elásticos, escala de leitura, pausa automática, histórico de restauração point-in-time, política de retenção de longo prazo e outras serão perdidas. Portanto, é recomendável que os clientes implementem um sistema de notificação que identifique a perda de acesso à chave de criptografia em 30 minutos. Quando 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.

Abaixo está uma visão das etapas adicionais necessárias no portal para colocar um banco de dados inacessível on-line novamente.

TDE BYOK Inaccessible Database

Revogação acidental do acesso do protetor TDE

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

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

  • apagar a chave

  • Eliminar o Cofre da Chave

  • Alterar as regras de firewall do Cofre de Chaves

  • 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 SQL e o Cofre da Chave

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

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

  • O Key Vault é exposto através do ponto final privado e o endereço IP privado do serviço AKV não é permitido nas regras de saída do NSG (Network Security Group) associado à sub-rede da instância gerida.
  • Resolução DNS incorreta, como quando o FQDN do cofre de chaves não é resolvido ou é resolvido para um endereço IP inválido.

Teste a conectividade da Instância Gerenciada SQL com o Cofre de Chaves que hospeda o protetor TDE.

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

No caso de o teste devolver TcpTestSucceeded: False, reveja a configuração da rede:

  • Verifique o endereço IP resolvido, confirme se é válido. Um valor em falta significa que existem 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.
    • Verifique outras configurações de rede, como tabela de rotas, existência de dispositivo virtual e sua configuração, etc.

Monitorização da TDE gerida 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:

Cópia de segurança e restauro da base de dados com a Encriptação de Dados Transparente gerida pelo cliente

Uma vez que um banco de dados é criptografado com TDE usando uma chave do Cofre de Chaves, todos os backups recém-gerados também são criptografados com o mesmo protetor TDE. Quando o protetor TDE é alterado, os backups antigos do banco de dados não são atualizados para usar o protetor TDE mais recente.

Para restaurar um backup criptografado com um protetor TDE do Cofre de Chaves, certifique-se de que o material da chave esteja disponível para o servidor de destino. Por conseguinte, recomendamos que mantenha todas as versões antigas do protetor de Encriptação de Dados Transparente no cofre de chaves, para que possa restaurar as cópias de segurança da base de dados.

Importante

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

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 <Servername> de destino não tem acesso a todos os URIs AKV criados entre <o Timestamp #1> e <o Timestamp #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 protetor TDE.

Para saber mais sobre a recuperação de backup para o Banco de dados SQL, consulte Recuperar um banco de dados no Banco de dados SQL. Para saber mais sobre a recuperação de backup para pools SQL dedicados no Azure Synapse Analytics, consulte Recuperar um pool SQL dedicado. Para obter o backup/restauração nativo do SQL Server com a Instância Gerenciada do SQL, consulte Guia de início rápido: restaurar um banco de dados para a Instância Gerenciada do SQL.

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 serã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, 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 nesse meio tempo.

Alta disponibilidade com TDE gerenciada pelo cliente

Mesmo nos casos em que não há redundância geográfica configurada para o servidor, é altamente recomendável configurar o servidor para usar dois cofres de chaves diferentes em duas regiões diferentes com o mesmo material de chave. A chave no cofre de chaves secundárias na outra região não deve ser marcada como protetor TDE e nem sequer é permitida. Se houver uma interrupção que afete o cofre da chave primária, e somente então, o sistema alternará automaticamente para a outra chave vinculada com a mesma impressão digital no cofre da chave secundária, se ela existir. Observe que essa mudança não acontecerá se o protetor TDE estiver inacessível devido a direitos de acesso revogados ou porque a chave ou o cofre de chaves for excluído, pois isso pode indicar que o cliente queria intencionalmente restringir o acesso do servidor à chave. Fornecer o mesmo material de chave para dois cofres de chaves em regiões diferentes pode ser feito criando a chave fora do cofre de chaves e importando-os para ambos os cofres de chaves.

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

Single-Server HA

Geo-DR e Encriptação de Dados Transparente gerida 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 mesmo cofre de chaves (em qualquer região) ou a cofres de chaves separados. Se cofres de chaves separados estiverem vinculados aos servidores primário e secundário, o cliente será responsável por manter o material de chave nos cofres de chaves consistente, para que o geo-secundário esteja sincronizado e possa assumir o controle usando a mesma chave de seu cofre de chaves vinculado se o primário se tornar inacessível devido a uma interrupção na região e um failover for acionado. Até quatro secundários podem ser configurados e o encadeamento (secundários de secundários) não é suportado.

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

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

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

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

Failover groups and geo-dr

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

O servidor do Banco de Dados SQL do Azure e a Instância Gerenciada SQL em uma região agora podem ser vinculados ao cofre de chaves em qualquer outra região. O servidor e o cofre de chaves não precisam estar colocalizados na mesma região. Com isto, para simplificar, os servidores primários e secundários podem ser ligados ao mesmo cofre de chaves (em qualquer região). Isso ajuda a evitar cenários em que o material da chave pode estar fora de sincronia se cofres de chaves separados forem usados para ambos os servidores. O Azure Key Vault tem várias camadas de redundância no lugar para garantir que as chaves e os cofres de chaves permanecem disponíveis em caso de falha de serviço ou região. Disponibilidade e redundância do Azure Key Vault

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 na instância gerenciada falharão 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 a 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 Azure e procurando o serviço de Política. Em Definições, procure a chave gerenciada pelo cliente.

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

  • Auditoria - A configuração padrão e capturará 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 uma chave gerenciada pelo cliente configurada
  • Desabilitado - Desabilitará a política e não impedirá que os usuários criem ou atualizem um servidor lógico ou instância gerenciada sem o TDE gerenciado pelo cliente habilitado

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 serão registrados no log de atividades do grupo de recursos.

Importante

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

Próximos passos

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

Além disso, habilite o Microsoft Defender para SQL para proteger seus bancos de dados e seus dados, com funcionalidades para descobrir e mitigar possíveis vulnerabilidades do banco de dados e detetar atividades anômalas que possam indicar uma ameaça aos seus bancos de dados.