Criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para MySQL

Ao usar a criptografia de dados com chaves gerenciadas pelo cliente no Banco de Dados do Azure para MySQL, você pode usar sua própria chave (BYOK) para proteger os dados em repouso e implementar a separação de funções entre o gerenciamento de chaves e o gerenciamento de dados. Ao usar CMKs (chaves gerenciadas pelo cliente), você controla:

  • Gerenciamento de ciclo de vida de chave, incluindo criação de chave, upload, rotação e exclusão
  • Permissões de uso de chave
  • Auditoria de operações em chaves

Benefícios das CMK (chaves gerenciadas pelo cliente)

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

  • Você controla totalmente o acesso a dados removendo a chave e tornando o banco de dados inacessível.
  • Você tem controle total sobre o ciclo de vida da chave, incluindo a rotação da chave para atender às políticas corporativas.
  • Você pode gerenciar e organizar centralmente chaves em Azure Key Vault ou HSM Gerenciado.
  • Você pode implementar a separação de tarefas entre agentes de segurança, DBA e administradores do sistema.

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

As identidades gerenciadas na ID do Microsoft Entra fornecem uma maneira mais segura de autenticar clientes nos serviços. A criptografia CMK usa a identidade gerenciada do servidor do Banco de Dados do Azure para MySQL para se conectar ao Azure Key Vault que armazena o arquivo CMK. Banco de Dados do Azure para MySQL atualmente dá suporte apenas à UAMI (identidade gerenciada) atribuída pelo usuário para acesso ao Key Vault. Para saber mais, confira Tipos de identidade gerenciada.

Para configurar a CMK para um Banco de Dados do Azure para MySQL, vincule a UAMI ao servidor e especifique o Azure Key Vault e a chave a serem usados.

A UAMI precisa do seguinte acesso ao cofre de chaves:

  • Get: para recuperar a parte pública e as propriedades da chave no cofre de chaves.
  • Lista: Para listar as versões da chave armazenada em um Key Vault.
  • Chave de encapsulamento: para criptografar o DEK. A DEK criptografada é armazenada em uma instância do Banco de Dados do Azure para MySQL – Servidor Flexível.
  • Descriptografar chave: para descriptografar a DEK. Banco de Dados do Azure para MySQL precisa do DEK descriptografado para criptografar ou descriptografar os dados.

Se o Azure RBAC estiver habilitado, atribua funções à UAMI em vez de conceder acesso direto.

  • Usuário de Criptografia do Serviço de Criptografia do Key Vault ou a função com as permissões:
    • Microsoft.KeyVault/vaults/keys/wrap/action
    • Microsoft.KeyVault/vaults/keys/unwrap/action
    • Microsoft.KeyVault/vaults/keys/read como "Usuário de Criptografia do Serviço de Criptografia do Key Vault"
  • Para o HSM gerenciado, atribua a função Usuário de Criptografia do Serviço de Criptografia do HSM Gerenciado

Defina a criptografia de dados com CMKs no nível do servidor. Para um determinado servidor, use uma CMK, chamada de chave de criptografia de chave (KEK), para criptografar a chave de criptografia de dados (DEK) do serviço. A KEK é uma chave assimétrica armazenada em uma instância do Azure Key Vault gerenciada pelo cliente e de propriedade dele. O Key Vault é um armazenamento seguro escalonável e altamente disponível para chaves de criptografia RSA, opcionalmente apoiado por HSMs (módulos de segurança de hardware) validados pelo FIPS 140. Key Vault não permite acesso direto a uma chave armazenada, mas fornece serviços de criptografia e descriptografia usando a chave para entidades autorizadas. O cofre de chaves pode gerar a chave ou transferi-la para o cofre de chaves de um dispositivo HSM local.

Quando você configura um servidor flexível para usar uma CMK armazenada no cofre de chaves, o servidor envia a DEK para o cofre de chaves para criptografia. O Key Vault retorna a DEK criptografada armazenada no banco de dados do usuário. Da mesma forma, o servidor flexível envia a DEK protegida para o cofre de chaves para descriptografia quando necessário.

Diagrama de como a criptografia de dados com uma chave gerenciada pelo cliente funciona.

Depois de habilitar o registro em log, os auditores podem usar o Azure Monitor para revisar os logs de eventos de auditoria do Key Vault. Para habilitar o registro em log de eventos de auditoria do Key Vault, confira Monitoramento do serviço do cofre de chaves com insights do Key Vault.

Note

As alterações de permissão podem levar até 10 minutos para afetar o cofre de chaves.

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

Antes de tentar configurar o Key Vault ou o HSM Gerenciado, certifique-se de atender aos seguintes requisitos.

  • O Key Vault e a instância do Banco de Dados do Azure para MySQL – servidor flexível precisam pertencer ao mesmo locatário do Microsoft Entra. É preciso ter suporte para interações do servidor flexível e de Key Vault entre locatários. Você precisará reconfigurar a criptografia de dados caso mova recursos do Key Vault após realizar a configuração.
  • O Key Vault e a instância do Banco de Dados do Azure para MySQL – servidor flexível precisam residir na mesma região.
  • Habilite o recurso Exclusão Reversível no cofre de chaves.
  • Ativar a Proteção contra Limpeza.
  • Defina o período de retenção como 90 dias.
    • As ações de recuperação e limpeza têm permissões próprias em uma política de acesso do Key Vault.
    • O recurso de exclusão reversível está desativado por padrão.

Antes de tentar configurar a CMK, verifique se atende aos requisitos a seguir.

  • A chave gerenciada pelo cliente para criptografar o DEK pode ser apenas assimétrica, RSA\RSA-HSM(Vaults com SKU Premium) 2048, 3072 ou 4096.
  • A data de ativação da chave (se definida) precisa ser uma data e uma hora no passado. A data de validade não está definida.
  • A chave precisa estar no estado Habilitado.
  • A chave deve ter exclusão reversível com o período de retenção definido como 90 dias. Essa configuração define implicitamente o atributo recoveryLevel de chave necessário como Recoverable.
  • 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).

Note

Para obter instruções detalhadas e passo a passo sobre como configurar a criptografia de dados, consulte Criptografia de dados para o Banco de Dados do Azure para MySQL com o portal do Azure ou criptografia de dados para o Banco de Dados do Azure para MySQL – Servidor Flexível com a CLI do Azure.

Recomendações para configurar a criptografia de dados

Ao configurar Key Vault ou HSM Gerenciado para usar a criptografia de dados com uma chave gerenciada pelo cliente, tenha em mente as seguintes recomendações:

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

Note

O cofre de chaves usado deve ser da mesma região que o servidor de banco de dados.

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

Quando você configura a criptografia de dados com um CMK em Key Vault, o servidor requer acesso contínuo a essa chave para permanecer online. Se o servidor flexível 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 flexível emite uma mensagem de erro correspondente e altera o estado do servidor para inacessível. O servidor pode alcançar esse estado por vários motivos.

Se você excluir o cofre de chaves, a instância do servidor flexível do Banco de Dados do Azure para MySQL não poderá acessar a chave e entrará no estado Inaccessible. Para criar a instância do servidor Available:

Se você excluir a chave do cofre de chaves, a instância do servidor flexível do Banco de Dados do Azure para MySQL não poderá acessar a chave e entrará no estado Inaccessible. Para criar a instância do servidor Available:

  • Recupere a chave.
  • Revalidar a criptografia de dados.

Note

Mesmo que a chave expire, o servidor permanecerá acessível pelo design para evitar o tempo de inatividade.

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

Alguém com direitos de acesso suficientes para Key Vault pode desabilitar acidentalmente o acesso flexível do servidor à chave:

  • Revogando as permissões do cofre de chaves get, list, wrap key e unwrap key do servidor
  • Excluir a chave
  • Excluir o cofre de chaves
  • Alterar as regras de firewall do cofre de chaves
  • Excluir a identidade gerenciada do usuário usada para criptografia no servidor flexível com uma chave gerenciada pelo cliente 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 a perda de acesso transparente do protetor de criptografia de dados, configure os seguintes recursos de Azure:

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

Réplica com uma chave gerenciada pelo cliente no Key Vault

Quando você criptografa uma instância de servidor Banco de Dados do Azure para MySQL flexível com a chave gerenciada de um cliente armazenada em Key Vault, qualquer cópia recém-criada do servidor também é criptografada. Quando você tenta criptografar uma instância de servidor Banco de Dados do Azure para MySQL flexível com uma chave gerenciada pelo cliente que já tem uma réplica, configure uma ou mais réplicas adicionando a identidade gerenciada e a chave. Se você configurar a instância de servidor flexível do Banco de Dados do Azure para MySQL com backup de redundância geográfica, deverá configurar a réplica com a identidade gerenciada e a chave à qual a identidade tem acesso e que reside na região geograficamente correspondente do servidor.

Restaurar com uma chave gerenciada pelo cliente no Key Vault

Ao restaurar uma instância de servidor Banco de Dados do Azure para MySQL flexível, selecione a identidade gerenciada pelo usuário e a chave para criptografar o servidor de restauração. Se a instância de servidor flexível do Banco de Dados do Azure para MySQL estiver configurada com backup de redundância geográfica, você deverá configurar o servidor de restauração com a identidade gerenciada e a chave à qual a identidade tem acesso e que reside na região geograficamente correspondente do servidor.

Durante a restauração ou a criação de uma réplica de leitura, siga estes passos nos servidores de origem e restaurados ou de réplica:

  • Inicie o processo de restauração ou criação de réplica de leitura da instância do Banco de Dados do Azure para MySQL – servidor flexível de origem.
  • No servidor restaurado ou de réplica, revalide a CMK nas configurações de criptografia de dados para verificar as permissões da UAMI na chave.

Note

Você não precisa usar a mesma identidade (UAMI) e a chave que no servidor de origem ao executar uma restauração.

Conteúdo relacionado

  • Last updated on