Criptografia de dados do Banco de Dados do Azure para 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 da desativação. É altamente recomendável que você atualize para o servidor flexível do Banco de Dados do Azure para MySQL. Para obter mais informações sobre a migração para o servidor flexível do Banco de Dados do Azure para MySQL, confira O que está acontecendo com o Servidor Único do Banco de Dados do Azure para MySQL?

A criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para MySQL permite que você traga sua própria chave (BYOK) para proteção de dados em repouso. Ela também permite que as organizações implementem a separação de tarefas no gerenciamento de chaves e dados. Com a criptografia gerenciada pelo cliente, você é responsável por (com controle total): ciclo de vida de uma chave, permissões de uso de chave e auditoria de operações em 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 determinado servidor, uma chave gerenciada pelo cliente, chamada KEK (chave de criptografia de chave), é usada para criptografar a DEK (chave de criptografia de dados) usada pelo serviço. A KEK é uma chave assimétrica armazenada em uma instância do Azure Key Vault gerenciada pelo cliente e de propriedade dele. A KEK (chave de criptografia de chave) e a DEK (chave de criptografia de dados) são descritas em mais detalhes posteriormente neste artigo.

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

Observação

Esse recurso tem suporte apenas no armazenamento "Armazenamento de uso geral v2 (suporte até 16TB)" disponível em tipos de preço de Uso Geral e Otimizado para Memória. Consulte Conceitos de armazenamento para obter mais detalhes. Para obter outras limitações, veja a seção Limitação.

Benefícios

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

  • O acesso a 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 se alinhar com as políticas corporativas
  • Gerenciamento central e organização de chaves no Azure Key Vault
  • Capacidade de implementar a separação de tarefas entre os gerentes de segurança, DBA e administradores do sistema

Descrição e terminologia

DEK (chave de criptografia de dados) : uma chave simétrica AES256 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 pelo provedor de recursos ou instância do aplicativo que criptografa e descriptografa um bloco específico. Quando você substitui uma DEK por uma nova chave, apenas os dados no respectivo bloco associado precisam ser criptografados novamente com a nova chave.

KEK (chave de criptografia de chave) : uma chave de criptografia usada para criptografar as DEKs. Uma KEK que nunca deixa o Key Vault permite que as DEKs sejam criptografadas e controladas. A entidade que tem acesso à KEK pode ser diferente da entidade que requer a DEK. Uma vez que o KEK é necessário para descriptografar os DEKs, o KEK é efetivamente um ponto único pelo qual os DEKs podem ser efetivamente excluídos pela exclusão do KEK.

As DEKs, criptografadas com as KEKs, são armazenadas separadamente. Somente uma entidade com acesso à KEK pode descriptografar essas DEKs. Para obter mais informações, confira Segurança na criptografia em repouso.

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

Diagram that shows an overview of Bring Your Own Key

Para que um servidor MySQL use chaves gerenciadas pelo cliente armazenadas no Key Vault para criptografia da DEK, um administrador do Key Vault fornece os seguintes direitos de acesso ao servidor:

  • obter: para recuperar a parte pública e as propriedades da chave no Key Vault.
  • wrapKey: para poder criptografar a DEK. O DEK criptografado é armazenado no Banco de Dados do Azure para MySQL.
  • unwrapKey: para poder descriptografar a DEK. O Banco de Dados do Azure para MySQL precisa do DEK descriptografado para criptografar/descriptografar os dados

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

Quando o servidor é configurado para usar a chave gerenciada pelo cliente armazenada no cofre de chaves, o servidor envia a DEK para o cofre de chaves para criptografias. O Key Vault retorna a DEK criptografada, que é armazenada no banco de dados do usuário. De modo semelhante, 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 eventos do Key Vault se o registro em log estiver habilitado.

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

Veja a seguir os requisitos para configurar o Key Vault:

  • O Key Vault e o Banco de Dados do Azure para MySQL precisam pertencer ao mesmo locatário do Microsoft Entra. Não há suporte para interações do servidor e do Key Vault entre locatários. A movimentação de recursos do Key Vault posteriormente exige que você reconfigure a criptografia de dados.
  • Habilite o recurso de exclusão reversível no cofre de chaves com período de retenção definino como 90 dias para proteger contra perda de dados em caso de exclusão acidental da chave (ou do cofre de chaves). Os recursos com exclusão reversível são retidos por 90 dias por padrão, a menos que o período de retenção seja definido explicitamente 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 do Key Vault. O recurso de exclusão reversível 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).
  • Habilita o recurso Proteção de Limpeza no cofre de chaves com o período de retenção definido como 90 dias. A proteção contra limpeza só poderá ser habilitada quando a exclusão reversível estiver habilitada. Ela pode ser ativado via CLI do Azure ou 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 tenha passado o período de retenção. Os cofres e objetos excluídos de maneira reversível ainda podem ser recuperados, garantindo que a política de retenção será seguida.
  • Conceda o acesso do Banco de Dados do Azure para MySQL ao cofre de chaves com as permissões get, wrapKey e unwrapKey usando a identidade gerenciada exclusiva. No portal do Azure, a identidade de 'Serviço' exclusiva é criada automaticamente quando a criptografia de dados é habilitada no MySQL. ConfiraConfigurar a criptografia de dados para MySQL para obter instruções passo a passo quando estiver usando o portal do Azure.

Veja a seguir os requisitos para configurar a chave gerenciada pelo cliente:

  • A chave gerenciada pelo cliente a ser usada para criptografar a DEK só pode ser assimétrica, RSA 2048.
  • A data de ativação da chave (se definida) precisa ser uma data e uma hora no passado. A data de validade não definida.
  • A chave precisa estar no estado Habilitado.
  • A chave deve ter exclusão suave com período de retenção definido como 90 dias. Isso define implicitamente o atributo de chave necessário recoveryLevel: "Recuperável". Se a retenção for definida como < 90 dias, o recoveryLevel: "CustomizedRecoverable", que não é o requisito, portanto, defina o período de retenção como 90 dias.
  • A chave deve ter a proteção de limpeza habilitada.
  • Se você estiver importando uma chave existente no cofre de chaves, certifique-se de fornecê-la nos formatos de arquivo com suporte (.pfx, .byok, .backup).

Recomendações

Quando você estiver usando a criptografia de dados usando uma chave gerenciada pelo cliente, veja as recomendações para configurar o Key Vault:

  • Defina um bloqueio de recurso no Key Vault para controlar quem pode excluir esse recurso crítico e evitar a exclusão acidental ou não autorizada.

  • Habilite a auditoria e relatórios em todas as chaves de criptografia. O Key Vault fornece logs que são fáceis de serem injetados em outras ferramentas de gerenciamento de eventos e informações de segurança. O Log Analytics do Azure Monitor é um exemplo de um serviço que já está integrado.

  • Verifique se o Key Vault e o Banco de Dados do Azure para MySQL residem na mesma região, para garantir um acesso mais rápido para as operações de encapsulamento e desencapsulamento da DEK.

  • Bloqueie o Azure Key Vault para apenas ponto de extremidade privado e redes selecionadas e permita somente serviços confiáveis da Microsoft para proteger os recursos.

    trusted-service-with-AKV

Veja recomendações para configurar uma chave gerenciada pelo cliente:

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

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

Condição de chave gerenciada pelo cliente inacessível

Quando você configura a criptografia de dados com uma chave gerenciada pelo cliente no Key Vault, 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 Key Vault, o servidor começará a negar todas as conexões em dez 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 alcançar esse estado são:

  • Se criarmos um servidor de restauração pontual para o Banco de Dados do Azure para MySQL, que tem criptografia de dados habilitada, o servidor recém-criado estará no estado Inacessível. Você pode corrigir isso por meio do portal do Azure ou da CLI.
  • Se criarmos uma réplica de leitura para o Banco de Dados do Azure para MySQL, que tem criptografia de dados habilitada, o servidor de réplica estará no estado Inacessível. Você pode corrigir isso por meio do portal do Azure ou da CLI.
  • Se você excluir o Key Vault, o Banco de Dados do Azure para MySQL não poderá acessar a chave e será movido para o estado Inacessível. Recupere o Key Vault e revalide a criptografia de dados para tornar o servidor Disponível.
  • Se você excluir a chave do KeyVault, o Banco de Dados do Azure para MySQL não poderá acessar a chave e será movido para o estado Inacessível. Recupere a Chave e revalide a criptografia de dados para tornar o servidor Disponível.
  • Se a chave armazenada no Azure Key Vault expirar, ela se tornará inválida e o Banco de Dados do Azure para MySQL passará para o estado Inacessível. Estenda a data de expiração da chave usando a CLI e revalide a criptografia de dados para tornar o servidor Disponível.

Revogação acidental de acesso à chave do Key Vault

Pode acontecer de alguém com direitos de acesso suficientes ao Key Vault desabilitar acidentalmente o acesso do servidor à chave ao:

  • Revogue as permissões get, wrapKey e unwrapKey do cofre de chaves do servidor.
  • Excluir a chave.
  • Excluir o cofre de chaves.
  • Alterar as regras de firewall do cofre de chaves.
  • Excluir a identidade gerenciada do servidor no Microsoft Entra ID.

Monitorar a chave gerenciada pelo cliente no Key Vault

Para monitorar o estado do banco de dados e habilitar o alerta para perda de acesso ao protetor do Transparent Data Encryption, configure os seguintes recursos do Azure:

  • Azure Resource Health: um banco de dados inacessível que perdeu o acesso à chave do cliente aparecerá como "Inacessível" após a negação da primeira conexão com o banco de dados.

  • Log de atividades: quando o acesso à chave do cliente falha no Key Vault gerenciado pelo cliente, as entradas são adicionadas ao log de atividades. Você poderá restabelecer o acesso assim que 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 gerenciada do cliente no Key Vault

Depois que o Banco de Dados do Azure para MySQL é criptografado com uma chave gerenciada pelo cliente armazenada no Key Vault, qualquer cópia recém-criada do servidor também é criptografada. Você pode fazer essa nova cópia por meio de uma operação de restauração local ou geográfica, ou por meio de réplicas de leitura. No entanto, a cópia pode ser alterada para refletir a nova chave gerenciada pelo 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 durante a configuração da criptografia de dados gerenciados pelo cliente durante a restauração ou a criação de réplica de leitura, é importante seguir estas etapas nos servidores fonte e restaurado/de réplica:

  • Inicie o processo de restauração ou criação de réplica de leitura fonte do Banco de Dados do Azure para MySQL.
  • Mantenha o servidor recém-criado (restaurado/de réplica) em um estado inacessível, porque sua identidade exclusiva ainda não recebeu permissões para o Key Vault.
  • 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 desencapsulamento para a chave armazenada no Key Vault.

Limitações

No Banco de Dados do Azure para MySQL, o suporte para criptografia de dados inativos usando a CMK (chave gerenciada do cliente) tem poucas limitações -

  • O suporte para essa funcionalidade é limitado para os tipos de preço Uso Geral e Otimizado para Memória.

  • Esse recurso só tem suporte em regiões e servidores que dão suporte ao armazenamento de uso geral v2 (até 16 TB). Para obter a lista de regiões do Azure que dão suporte ao armazenamento de até 16 TB, veja a seção de armazenamento na documentação aqui

    Observação

    • Para todos os novos servidores MySQL criados nas regiões do Azure com suporte para armazenamento de uso geral v2, o suporte para criptografia com as chaves do gerenciador de clientes está disponível. O servidor PITR (restauração pontual) ou a réplica de leitura não está qualificada, embora teoricamente seja 'nova'.
    • Para validar se você provisionou o armazenamento de uso geral de servidor v2, você pode ir para a folha de tipo de preço no portal e ver o tamanho máximo de armazenamento compatível com o servidor provisionado. Caso você possa mover o controle deslizante até 4 TB, o servidor está no armazenamento de uso geral v1 e não dá suporte à criptografia com chaves gerenciadas pelo cliente. No entanto, os dados são criptografados usando chaves de serviço gerenciadas em todos os momentos. Se você tiver dúvidas, entre em contato com AskAzureDBforMySQL@service.microsoft.com.

  • A criptografia só tem suporte com a chave de criptografia RSA 2048.

Próximas etapas