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

Com a utilização de chaves geridas pelo cliente para encriptação de dados no Azure Database for MySQL, pode trazer a sua própria chave (BYOK) para proteger os dados quando em repouso e implementar a separação de papéis na gestão de chaves e dados. Com chaves geridas pelo cliente (CMKs), o cliente controla:

• Gestão do ciclo de vida das chaves (criação de chaves, carregamento, rotação, eliminação)
• Permissões de utilização de chaves
• Operações de auditoria em chaves

Benefícios das Chaves Geridas pelo Cliente (CMK)

A criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para 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 geridas no Microsoft Entra ID fornecem uma forma mais segura de autenticar clientes em serviços. A encriptação CMK utiliza a identidade gerida do servidor Azure Database for MySQL para se ligar ao Azure Key Vault que armazena o CMK. Atualmente, a Azure Database for MySQL suporta apenas a Identidade Gerida atribuída pelo Utilizador (UAMI) para acesso ao Key Vault. Para obter mais informações, consulte Tipos de identidade gerenciados no Azure.

Para configurar o CMK para uma base de dados Azure para MySQL, precisas de ligar o UAMI ao servidor e especificar o Azure Key Vault e a chave a usar.

A UAMI necessita do 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 flexível do servidor MySQL.
• Unwrap Key: Para ser capaz de desencriptar o DEK. O Banco de Dados do Azure para MySQL precisa da DEK descriptografada para criptografar/descriptografar os dados.

Se o Azure RBAC estiver ativado, o UAMI deve receber funções atribuídas em vez de acesso individual.

• Key Vault Crypto Service Encryption User ou a função com as permissões:
  • Microsoft.KeyVault/vaults/keys/wrap/action
  • Microsoft.KeyVault/vaults/keys/desencriptar/ação
  • 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

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 envia a DEK protegida para o cofre de chaves para desencriptação quando necessário.

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.

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

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

• O Cofre da Chave e o Banco de Dados do Azure para instância de servidor flexível do MySQL devem 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.
• O Cofre da Chave e a instância de servidor flexível do Banco de Dados do Azure para MySQL devem residir na mesma região.
• Ativar a funcionalidade Eliminação Suave no cofre de chaves
• Ativa a proteção contra purga.
• Defina o período de retenção para 90 dias.
  • 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.
  • A funcionalidade de eliminação suave está desligada por defeito.

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 Enabled.
• A chave deve ter exclusão suave com período de retenção definido para 90 dias. Esta definição define implicitamente o atributo recoveryLevel da chave requerida como Recoverable.
• 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

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.
• 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 no Cofre de Chaves. 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 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 apagares o cofre de chaves, a instância do servidor flexível do Azure Database for MySQL não consegue aceder à chave e passa para o estado Inaccessible. Para criar a instância Availabledo servidor:

• Recupera o cofre de chaves.
• Revalide a encriptação dos dados.

Se eliminar a chave do cofre de chaves, a instância de servidor flexível do Azure Database for MySQL não consegue aceder à chave e passa para Inaccessible estado. Para criar a instância Availabledo servidor:

• Recupera a chave.
• Revalide a encriptação dos dados.

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 do cofre de chaves obter, listar, encapsular chave e desembrulhar chave 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

Monitorizar a chave gerida pelo cliente no Cofre de Chaves

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 de servidor flexível do Banco de Dados do Azure para 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 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 de servidor flexível do Banco de Dados do Azure para 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 de servidor flexível do Banco de Dados do Azure para MySQL, você pode selecionar a identidade gerenciada pelo usuário e a chave para criptografar o servidor de restauração. Suponha que a instância de servidor flexível do Banco de Dados do Azure para 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.

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

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

Conteúdo relacionado

• Criptografia de dados para o Banco de Dados do Azure para MySQL - Servidor flexível com CLI do Azure
• Encriptação de dados para Azure Database for MySQL com o Portal do Azure
• Segurança em repouso de criptografia
• Autenticação do Microsoft Entra para o Banco de Dados do Azure para MySQL - Flexible Server