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

Com a criptografia de dados usando chaves gerenciadas pelo cliente no Azure Database para MySQL, você pode trazer sua própria chave (BYOK) para a proteção de dados em repouso, permitindo a implementação da separação de responsabilidades no gerenciamento de chaves e dados. Com as CMKs (chaves gerenciadas pelo cliente), o cliente controla:

• Gerenciamento de ciclo de vida de chave (criação de chave, upload, rotação, 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 com a 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 ou HSM Gerenciado
• Capacidade de implementar a separação de tarefas entre os responsáveis pela segurança, DBAs 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. Atualmente, o Banco de Dados do Azure para MySQL 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 o CMK para um Banco de Dados do Azure para MySQL, você precisa vincular a UAMI ao servidor e especificar o Azure Key Vault e a chave a ser usada.

A UAMI deve possuir o seguinte acesso ao Key Vault:

• Get: para recuperar a parte pública e as propriedades da chave no cofre de chaves.
• List: listar as versões da chave armazenada em um cofre de chaves.
• Wrap Key: para poder criptografar a DEK. A DEK criptografada é armazenada em uma instância do Banco de Dados do Azure para MySQL – Servidor Flexível.
• Unwrap Key: para poder descriptografar a DEK. O Banco de Dados do Azure para MySQL precisa do DEK descriptografado para criptografar/descriptografar os dados.

Se o Azure RBAC estiver habilitado, a UAMI deverá ter funções atribuídas em vez de acesso individual.

• 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

A criptografia de dados com CMKs é definida no nível do servidor. Para um determinado servidor, uma CMK, chamada KEK (chave de criptografia de chave), é usada para criptografar a DEK (chave de criptografia de dados de 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. O Key Vault não permite acesso direto a uma chave armazenada, mas fornece serviços de criptografia/descriptografia usando a chave para as entidades autorizadas. O cofre de chaves importado pode gerar a chave ou ser transferido 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.

Após fazer logon, os auditores poderão usar o Azure Monitor para examinar 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.

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. Além disso, se você mover recursos do Key Vault depois de executar a configuração, será necessário reconfigurar a criptografia de dados.
• O Key Vault e a instância do Banco de Dados do Azure para MySQL – servidor flexível precisam residir na mesma região.
• Habilitar o recurso Soft Delete 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 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).

Recomendações para configurar a criptografia de dados

Ao configurar o Key Vault ou o HSM Gerenciado para usar a criptografia de dados usando uma chave gerenciada pelo cliente, lembre-se das recomendações a seguir.

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

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

Quando você configura a criptografia de dados com uma CMK no Key Vault, o acesso contínuo a essa chave é necessário para que o servidor permaneça 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 muda para o estado Inaccessible. Para criar a instância do servidor Available:

• Recupere o cofre de chaves.
• Revalidar a criptografia de dados.

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 muda para o estado Inaccessible. Para criar a instância do servidor Available:

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

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 flexível à chave ao:

• 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 perda de acesso ao protetor do Transparent Data Encryption, configure os seguintes recursos do 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

Depois que a instância do Banco de Dados do Azure para MySQL – servidor flexível for criptografada com uma chave gerenciada pelo cliente armazenada no Key Vault, toda cópia recém-criada do servidor também será criptografada. Ao tentar criptografar uma instância de servidor flexível do Banco de Dados do Azure para MySQL com uma chave gerenciada pelo cliente que já tenha uma réplica, recomendamos configurar uma ou mais réplicas adicionando a identidade gerenciada e a chave. Suponha que a instância do Banco de Dados do Azure para MySQL – servidor flexível esteja configurada com backup de redundância geográfica. Nesse caso, a réplica deve ser configurada com a identidade gerenciada e a chave para a qual a identidade tem acesso e que reside na região emparelhada geográfica do servidor.

Restaurar com uma chave gerenciada pelo cliente no Key Vault

Ao tentar restaurar uma instância do Banco de Dados do Azure para MySQL – servidor flexível, você pode selecionar a identidade gerenciada pelo usuário e a chave para criptografar o servidor de restauração. Suponha que a instância do Banco de Dados do Azure para MySQL – servidor flexível esteja configurada com backup de redundância geográfica. Nesse caso, você deve configurar o servidor de restauração com a identidade gerenciada e a chave para a qual a identidade tem acesso e que reside na região emparelhada geográfica do servidor.

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

• 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/réplica, revalide a CMK nas configurações de criptografia de dados para validar as permissões UAMI da chave.

Conteúdo relacionado

• Criptografia de dados para o Banco de Dados do Azure para MySQL — Servidor Flexível com a CLI do Azure
• Criptografia de dados para o Banco de Dados do Azure para MySQL com o portal do Azure
• Segurança em repouso de criptografia
• Autenticação do Microsoft Entra para Banco de Dados do Azure para MySQL - Servidor Flexível