Partilhar via

Criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para MySQL - Servidor Flexível

  • Artigo

Com a criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para o Servidor Flexível MySQL, você pode colocar sua própria chave (BYOK) para proteção de dados em repouso e implementar a separação de tarefas para gerenciar chaves e dados. Com as chaves gerenciadas pelo cliente (CMKs), o cliente é responsável e, em última análise, controla o gerenciamento do ciclo de vida das chaves (criação, upload, rotação, exclusão de chaves), permissões de uso de chaves e operações de auditoria em chaves.

Nota

O Azure Key Vault Managed HSM (Hardware Security Module) tem atualmente suporte para chaves gerenciadas pelo cliente para o Banco de Dados do Azure para o Servidor Flexível MySQL.

Benefícios

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

  • Você controla totalmente o acesso aos dados 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 o alinhamento com as políticas corporativas
  • Gerenciamento central e organização de chaves no Cofre de Chaves do Azure ou no HSM gerenciado
  • Capacidade de implementar a separação de funções entre agentes de segurança, DBA e administradores de sistema

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

As identidades gerenciadas no Microsoft Entra ID fornecem aos serviços do Azure uma alternativa ao armazenamento de credenciais no código, provisionando uma identidade atribuída automaticamente que pode ser usada para autenticar qualquer serviço que ofereça suporte à autenticação do Microsoft Entra, como o Azure Key Vault (AKV). Atualmente, o Banco de Dados do Azure para Servidor Flexível MySQL dá suporte apenas à UMI (Identidade Gerenciada Atribuída pelo Usuário). Para obter mais informações, consulte Tipos de identidade gerenciados no Azure.

Para configurar a CMK para um Banco de Dados do Azure para Servidor Flexível MySQL, você precisa vincular o UMI ao servidor e especificar o cofre da Chave do Azure e a chave a ser usada.

O UMI deve ter o seguinte acesso ao cofre de chaves:

  • Get: Para recuperar a parte pública e as propriedades da chave no cofre de chaves.
  • Lista: Liste as versões da chave armazenadas em um Cofre de Chaves.
  • Chave de encapsulamento: Para ser capaz de criptografar a DEK. A DEK criptografada é armazenada no Banco de Dados do Azure para a instância do Servidor Flexível MySQL.
  • Unwrap Key: Para ser capaz de desencriptar o DEK. O Banco de Dados do Azure para Servidor Flexível MySQL precisa da DEK descriptografada para criptografar/descriptografar os dados.

Se o RBAC estiver habilitado, o UMI também deverá receber a seguinte função:

  • Key Vault Crypto Service Encryption User 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 like "Usuário de criptografia do Key Vault Crypto Service"
  • Para HSM gerenciado, atribua a função Usuário de criptografia do serviço de criptografia HSM gerenciado

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 criptografa e descriptografa 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 através da 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 no resto da criptografia.

Como funciona

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

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

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

Depois que o log for habilitado, os auditores poderão usar o Azure Monitor para revisar os logs de eventos de auditoria do Cofre de Chaves. Para habilitar o registro de eventos de auditoria do Cofre da Chave, consulte Monitorando o serviço do Cofre da Chave com informações do Cofre da Chave.

Nota

As alterações de permissão podem levar até 10 minutos para afetar o 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 criptografia de dados para o Banco de Dados do Azure para o Servidor Flexível MySQL

Antes de tentar configurar o Cofre da Chave ou o HSM Gerenciado, certifique-se de atender aos seguintes requisitos.

  • A instância do Cofre da Chave e do Banco de Dados do Azure para Servidor Flexível MySQL deve pertencer ao mesmo locatário do Microsoft Entra. O Cofre da Chave entre locatários e as interações flexíveis do servidor precisam ser suportados. Você precisará reconfigurar a criptografia de dados se mover os recursos do Cofre da Chave depois de executar a configuração.
  • A instância do Cofre da Chave e do Banco de Dados do Azure para Servidor Flexível MySQL deve residir na mesma região.
  • Habilite o recurso de exclusão suave no cofre de chaves com um período de retenção definido para 90 dias para proteger contra perda de dados caso ocorra uma exclusão acidental de chave (ou cofre de chaves). As ações de recuperação e limpeza têm suas próprias permissões 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 portal do Azure ou usando o PowerShell ou a CLI do Azure.
  • Habilite o recurso Proteção contra limpeza no cofre de chaves e defina o período de retenção para 90 dias. 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. Você pode habilitar esse recurso usando o PowerShell ou a CLI do Azure e somente depois de habilitar a exclusão suave.

Antes de tentar configurar a CMK, certifique-se de atender aos seguintes requisitos.

  • A chave gerenciada pelo cliente para criptografar a DEK pode ser apenas assimétrica, RSA\RSA-HSM(Vaults with Premium SKU) 2048,3072 ou 4096.
  • 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".
  • 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).

Nota

Para obter instruções detalhadas e passo a passo sobre como configurar a criptografia de data para o Banco de Dados do Azure para o Servidor Flexível MySQL por meio do portal do Azure, consulte Criptografia de dados para o Banco de Dados do Azure para MySQL - Servidor Flexível usando o portal do Azure.

Recomendações para configurar a criptografia de dados

Ao configurar o Cofre da Chave ou o HSM gerenciado para usar a criptografia de dados usando uma chave gerenciada pelo cliente, lembre-se das seguintes recomendações.

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

Nota

  • É aconselhável usar um cofre de chaves da mesma região, mas, se necessário, você pode usar um cofre de chaves de outra região, especificando as informações de "inserir identificador de chave". O HSM gerenciado pelo cofre de chaves deve estar na mesma região do servidor flexível do MySQL.

Condição chave gerenciada pelo cliente inacessível

Quando você configura a criptografia de dados com uma CMK no Cofre da Chave, 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 Cofre de Chaves, o servidor começará a negar todas as conexões em 10 minutos. O servidor flexível emite uma mensagem de erro correspondente e altera o estado do servidor para Inacessível. O servidor pode atingir esse estado por vários motivos.

  • Se você excluir o cofre de chaves, a instância do Banco de Dados do Azure para Servidor Flexível MySQL não poderá acessar a chave e passará para o estado Inacessível . Recupere o cofre de chaves e revalide a criptografia de dados para disponibilizar a instância do Servidor Flexível do Banco de Dados do Azure para MySQL.
  • 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 passará para o estado Inacessível . Recupere a chave e revalide a criptografia de dados para disponibilizar a instância do Servidor Flexível do Banco de Dados do Azure para MySQL.
  • Se a chave armazenada no Cofre de Chaves do Azure expirar, a chave se tornará inválida e a instância do Banco de Dados do Azure para Servidor Flexível 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 disponibilizar a instância do Servidor Flexível do Banco de Dados do Azure para MySQL.

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

  • Revogando as permissões get, list, wrap key e unwrap key do servidor
  • Eliminar a chave
  • Eliminar o cofre das chaves
  • Alterar as regras de firewall do cofre de chaves
  • Excluindo a identidade gerenciada pelo usuário usada para criptografia no servidor flexível com uma chave gerenciada pelo cliente no ID do Microsoft Entra

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:

  • Registo de atividades: Quando o acesso à Chave do Cliente no Cofre de Chaves gerido pelo cliente falha, são adicionadas entradas ao registo 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.

Réplica com uma chave gerenciada pelo cliente no Cofre da Chave

Depois que uma instância do Banco de Dados do Azure para Servidor Flexível MySQL é criptografada com a chave gerenciada de um cliente armazenada no Cofre da Chave, qualquer cópia recém-criada do servidor também é criptografada. Ao tentar criptografar uma instância do Banco de Dados do Azure para Servidor Flexível MySQL com uma chave gerenciada pelo cliente que já tenha uma réplica(s), recomendamos configurar a(s) réplica(s) adicionando a identidade gerenciada e a chave. Suponha que a instância do Banco de Dados do Azure para Servidor Flexível MySQL esteja configurada com backup de redundância geográfica. Nesse caso, a réplica deve ser configurada com a identidade gerenciada e a chave à qual a identidade tem acesso e que reside na região emparelhada geograficamente do servidor.

Restaurar com uma chave gerenciada pelo cliente no Cofre da Chave

Ao tentar restaurar uma instância do Banco de Dados do Azure para o Servidor Flexível MySQL, você pode selecionar a identidade e a chave gerenciadas pelo usuário para criptografar o servidor de restauração. Suponha que a instância do Banco de Dados do Azure para Servidor Flexível MySQL 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 à qual a identidade tem acesso e que reside na região emparelhada geograficamente do servidor.

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, é essencial seguir estas etapas nos servidores de origem e restaurados/réplica:

  • Inicie o processo de criação de réplica de restauração ou leitura a partir da instância de origem do Banco de Dados do Azure para o Servidor Flexível MySQL.
  • No servidor restaurado/de réplica, revalide a chave gerenciada pelo cliente nas configurações de criptografia de dados para garantir que a identidade gerenciada pelo usuário receba as permissões Get, List, Wrap key e Unwrap key para a chave armazenada no Key Vault.

Nota

O uso da mesma identidade e chave do servidor de origem não é obrigatório ao executar uma restauração.

Conteúdos relacionados