Partilhar via

Banco de Dados do Azure para criptografia de dados MySQL com uma chave gerenciada pelo cliente

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único

Importante

O servidor único do Banco de Dados do Azure para MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

A encriptação de dados com chaves geridas pelo cliente da Base de Dados do Azure para MySQL permite-lhe trazer a sua própria chave (BYOK) para a proteção de dados inativos. Também permite às organizações implementarem a separação de deveres na gestão das chaves e dos dados. Com a criptografia gerenciada pelo cliente, você é responsável e tem controle total do ciclo de vida de uma chave, das permissões de uso da chave e da auditoria das operações nas chaves.

A criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para MySQL é definida no nível do servidor. Para um determinado servidor, uma chave gerenciada pelo cliente, chamada chave de criptografia de chave (KEK), é usada para criptografar a chave de criptografia de dados (DEK) usada pelo serviço. O KEK é uma chave assimétrica armazenada em uma instância do Cofre de Chaves do Azure de propriedade e gerenciada pelo cliente. A chave de criptografia de chave (KEK) e a chave de criptografia de dados (DEK) são descritas com mais detalhes mais adiante neste artigo.

O Key Vault é um sistema de gerenciamento de chaves externo baseado em nuvem. É altamente disponível e fornece armazenamento escalável e seguro para chaves criptográficas RSA, opcionalmente apoiado por módulos de segurança de hardware (HSMs) validados FIPS 140. Não permite o acesso direto a uma chave armazenada, mas fornece serviços de encriptação e desencriptação a entidades autorizadas. O Cofre de Chaves pode gerar a chave, importá-la ou transferi-la de um dispositivo HSM local.

Nota

Este recurso é suportado apenas no armazenamento "General Purpose storage v2 (suporte até 16TB)" disponível nos níveis de preços de uso geral e memória otimizada. Consulte Conceitos de armazenamento para obter mais detalhes. Para outras limitações, consulte a seção de limitações .

Benefícios

A criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para MySQL oferece os seguintes benefícios:

  • O acesso aos dados é totalmente controlado por você pela capacidade de remover a chave e tornar o banco de dados inacessível
  • Controle total sobre o ciclo de vida da chave, incluindo a rotação da chave para alinhá-la com as políticas corporativas
  • Gerenciamento central e organização de chaves no Cofre de Chaves do Azure
  • Capacidade de implementar a separação de funções entre agentes de segurança e DBA e administradores de sistemas

Terminologia e descrição

Chave de criptografia de dados (DEK): uma chave AES256 simétrica usada para criptografar uma partição ou bloco de dados. Criptografar cada bloco de dados com uma chave diferente torna os ataques de análise de criptografia mais difíceis. O acesso a DEKs é necessário para o provedor de recursos ou instância do aplicativo que está criptografando e descriptografando um bloco específico. Quando você substitui uma DEK por uma nova chave, somente os dados em seu bloco associado devem ser criptografados novamente com a nova chave.

Chave de criptografia de chave (KEK): uma chave de criptografia usada para criptografar as DEKs. Um KEK que nunca sai do Key Vault permite que os próprios DEKs sejam criptografados e controlados. A entidade que tem acesso ao KEK pode ser diferente da entidade que requer o DEK. Uma vez que o KEK é necessário para desencriptar os DEKs, o KEK é efetivamente um único ponto pelo qual os DEKs podem ser efetivamente eliminados pela eliminação do KEK.

Os DEKs, criptografados com os KEKs, são armazenados separadamente. Apenas uma entidade com acesso ao KEK pode desencriptar estes DEKs. Para obter mais informações, consulte Segurança na criptografia em repouso.

Como funciona a criptografia de dados com uma chave gerenciada pelo cliente

Para que um servidor MySQL use chaves gerenciadas pelo cliente armazenadas no Cofre de Chaves para criptografia do DEK, um administrador do Cofre de Chaves concede os seguintes direitos de acesso ao servidor:

  • get: Para recuperar a parte pública e as propriedades da chave no cofre de chaves.
  • wrapKey: Para poder encriptar a DEK. A DEK criptografada é armazenada no Banco de Dados do Azure para MySQL.
  • unwrapKey: Para ser capaz de desencriptar o DEK. O Banco de Dados do Azure para MySQL precisa da DEK descriptografada para criptografar/descriptografar os dados

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 a chave gerenciada pelo cliente armazenada no cofre de chaves, o servidor envia o DEK para o cofre de chaves para criptografias. O Cofre da Chave retorna a DEK criptografada, que é armazenada no banco de dados do usuário. Da mesma forma, quando necessário, o servidor envia a DEK protegida para o cofre de chaves para desencriptação. Os auditores podem usar o Azure Monitor para revisar os logs de eventos de auditoria do Key Vault, se o log estiver habilitado.

Requisitos para configurar a criptografia de dados para o Banco de Dados do Azure para MySQL

A seguir estão os requisitos para configurar o Cofre da Chave:

  • O Cofre de Chaves e o Banco de Dados do Azure para MySQL devem pertencer ao mesmo locatário do Microsoft Entra. Não há suporte para o Cofre da Chave entre locatários e interações de servidor. Mover o recurso Key Vault posteriormente requer que você reconfigure a criptografia de dados.
  • Habilite o recurso de exclusão suave no cofre de chaves com o período de retenção definido para 90 dias, para proteger contra perda de dados se ocorrer uma exclusão acidental de chave (ou cofre de chaves). Os recursos excluídos por software são retidos por 90 dias por padrão, a menos que o período de retenção seja explicitamente definido como <=90 dias. 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á desativado por padrão, mas você pode habilitá-lo por meio do PowerShell ou da CLI do Azure (observe que não é possível habilitá-lo por meio do portal do Azure).
  • Habilite o recurso Proteção contra limpeza no cofre de chaves com o período de retenção definido para 90 dias. A proteção contra limpeza só pode ser ativada quando a exclusão suave estiver ativada. Ele pode ser ativado por meio da CLI do Azure ou do PowerShell. Quando a proteção contra limpeza está ativada, um cofre ou um objeto no estado excluído não pode ser limpo até que o período de retenção tenha passado. Cofres e objetos excluídos por software ainda podem ser recuperados, garantindo que a política de retenção seja seguida.
  • Conceda ao Banco de Dados do Azure para MySQL acesso ao cofre de chaves com as permissões get, wrapKey e unwrapKey usando sua identidade gerenciada exclusiva. No portal do Azure, a identidade 'Serviço' exclusiva é criada automaticamente quando a criptografia de dados é habilitada no MySQL. Consulte Configurar criptografia de dados para MySQL para obter instruções detalhadas e passo a passo quando você estiver usando o portal do Azure.

A seguir estão os requisitos para configurar a chave gerenciada pelo cliente:

  • A chave gerenciada pelo cliente a ser usada para criptografar o DEK pode ser apenas assimétrica, RSA 2048.
  • A data de ativação da chave (se definida) deve ser uma data e hora no passado. A data de validade não está definida.
  • A chave deve estar no estado Habilitado .
  • A chave deve ter exclusão suave com período de retenção definido para 90 dias. Isso define implicitamente o atributo chave necessário recoveryLevel: "Recuperável". Se a retenção estiver definida como < 90 dias, o recoveryLevel: "CustomizedRecoverable", que não é o requisito para definir o período de retenção, é definido como 90 dias.
  • A chave deve ter a proteção contra limpeza ativada.
  • Se estiver a importar uma chave existente para o cofre de chaves, certifique-se de que a fornece nos formatos de ficheiro suportados (.pfx, .byok, .backup).

Recomendações

Quando você estiver usando a criptografia de dados usando uma chave gerenciada pelo cliente, aqui estão recomendações para configurar o Cofre da Chave:

  • Defina um bloqueio de recursos no Cofre da Chave para controlar quem pode excluir esse recurso crítico e evitar a exclusão acidental ou não autorizada.
  • Habilite a auditoria e a geração de relatórios sobre todas as chaves de criptografia. O Key Vault fornece logs que são fáceis de injetar em outras informações de segurança e ferramentas de gerenciamento de eventos. O Azure Monitor Log Analytics é um exemplo de um serviço que já está integrado.
  • Certifique-se de que o Cofre de Chaves e o Banco de Dados do Azure para MySQL residam na mesma região, para garantir um acesso mais rápido para operações de encapsulamento e desempacotamento DEK.
  • Bloqueie o Azure KeyVault apenas para pontos de extremidade privados e redes selecionadas e permita que apenas serviços confiáveis da Microsoft protejam os recursos.

Aqui estão recomendações para configurar uma chave gerenciada pelo cliente:

  • Mantenha uma cópia da chave gerenciada pelo cliente em um local seguro ou deposite-a no serviço de depósito.

  • Se o Cofre da Chave gerar a chave, crie um backup de chave antes de usá-la pela primeira vez. Você só pode restaurar o backup para o Cofre da Chave. Para obter mais informações sobre o comando backup, consulte Backup-AzKeyVaultKey.

Condição chave gerenciada pelo cliente inacessível

Quando você configura a criptografia de dados com uma chave gerenciada pelo cliente no Cofre da Chave, o acesso contínuo a essa chave é necessário para que o servidor permaneça online. Se o servidor perder o acesso à chave gerenciada pelo cliente no Cofre de Chaves, o servidor começará a negar todas as conexões em 10 minutos. O servidor emite uma mensagem de erro correspondente e altera o estado do servidor para Inacessível. Algumas das razões pelas quais o servidor pode atingir esse estado são:

  • Se criarmos um servidor de Restauração Point In Time para seu Banco de Dados do Azure para MySQL, que tenha a criptografia de dados habilitada, o servidor recém-criado estará no estado Inacessível . Pode corrigir este problema através do portal do Azure ou da CLI.
  • Se criarmos uma réplica de leitura para seu Banco de Dados do Azure para MySQL, que tenha a criptografia de dados habilitada, o servidor de réplica estará no estado Inacessível . Pode corrigir este problema através do portal do Azure ou da CLI.
  • Se você excluir o KeyVault, o Banco de Dados do Azure para MySQL não poderá acessar a chave e passará para o estado Inacessível . Recupere o Cofre da Chave e revalide a criptografia de dados para disponibilizar o servidor.
  • Se excluirmos a chave do KeyVault, o Banco de Dados do Azure para MySQL não poderá acessar a chave e passará para o estado Inacessível . Recupere a chave e revalide a criptografia de dados para disponibilizar o servidor.
  • Se a chave armazenada no Azure KeyVault expirar, a chave se tornará inválida e o Banco de Dados do Azure para MySQL fará a transição para o estado Inacessível . Estenda a data de expiração da chave usando a CLI e, em seguida, revalide a criptografia de dados para tornar o servidor disponível.

Revogação acidental do acesso à chave do Cofre da Chave

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

  • Revogando o cofre de getchaves , wrapKeye unwrapKey permissões do servidor.
  • Excluindo a chave.
  • Eliminar o cofre de chaves.
  • Alterar as regras de firewall do cofre de chaves.
  • Excluindo a identidade gerenciada do servidor no Microsoft Entra ID.

Monitorar a chave gerenciada pelo cliente no Cofre da Chave

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

  • Azure Resource Health: um banco de dados inacessível que perdeu o acesso à chave do cliente é exibido como "Inacessível" após a primeira conexão com o banco de dados ter sido negada.

  • Registro de atividades: quando o acesso à chave do cliente no Cofre de Chaves gerenciado pelo cliente falha, as entradas são adicionadas ao registro de atividades. Você pode restabelecer o acesso o mais rápido possível, se criar alertas para esses eventos.

  • Grupos de ação: defina esses grupos para enviar notificações e alertas com base em suas preferências.

Restaurar e replicar com uma chave gerida pelo cliente no Key Vault

Depois que o Banco de Dados do Azure para MySQL é criptografado com a chave gerenciada de um cliente armazenada no Cofre da Chave, qualquer cópia recém-criada do servidor também é criptografada. Você pode fazer essa nova cópia por meio de uma operação local ou de restauração geográfica, ou por meio de réplicas de leitura. No entanto, a cópia pode ser alterada para refletir a chave gerenciada de um novo cliente para criptografia. Quando a chave gerenciada pelo cliente é alterada, os backups antigos do servidor começam a usar a chave mais recente.

Para evitar problemas ao configurar a criptografia de dados gerenciada pelo cliente durante a restauração ou a criação de réplicas de leitura, é importante seguir estas etapas nos servidores de origem e restaurados/de réplica:

  • Inicie o processo de criação de réplica de restauração ou leitura a partir do Banco de Dados do Azure de origem para MySQL.
  • Mantenha o servidor recém-criado (restaurado/réplica) em um estado inacessível, porque sua identidade exclusiva ainda não recebeu permissões para o Cofre de Chaves.
  • No servidor restaurado/de réplica, revalide a chave gerenciada pelo cliente nas configurações de criptografia de dados para garantir que o servidor recém-criado receba permissões de encapsulamento e desempacotamento para a chave armazenada no Cofre de Chaves.

Limitações

Para o Banco de Dados do Azure para MySQL, o suporte para criptografia de dados em repouso usando a chave gerenciada do cliente (CMK) tem algumas limitações -

  • O suporte para essa funcionalidade é limitado aos níveis de preços de uso geral e memória otimizada.

  • Este recurso só é suportado em regiões e servidores, que suportam armazenamento de uso geral v2 (até 16 TB). Para obter a lista de regiões do Azure que suportam armazenamento de até 16 TB, consulte a seção de armazenamento na documentação aqui

    Nota

    • Todos os novos servidores MySQL criados nas regiões do Azure com suporte ao armazenamento de uso geral v2, o suporte para criptografia com chaves do gerenciador do cliente está disponível. O servidor ou réplica de leitura Point In Time Restored (PITR) não se qualificará, embora, em teoria, sejam 'novos'.
    • Para validar se o armazenamento de uso geral do servidor provisionado v2, você pode ir para a folha da camada de preços no portal e ver o tamanho máximo de armazenamento suportado pelo servidor provisionado. Se você puder mover o controle deslizante até 4TB, seu servidor estará no armazenamento de uso geral v1 e não suportará criptografia com chaves gerenciadas pelo cliente. No entanto, os dados são criptografados usando chaves gerenciadas pelo serviço em todos os momentos.

  • A encriptação só é suportada com a chave criptográfica RSA 2048.

Próximos passos