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

Ao usar encriptação de dados com chaves geridas pelo cliente para o Base de Dados do Azure para MySQL, pode trazer a sua própria chave (BYOK) para proteção de dados em repouso, implementando a separação de funções na gestão de chaves e dados. Quando utiliza chaves geridas pelo cliente (CMKs), controla:

• Gestão do ciclo de vida das chaves, incluindo criação, upload, rotação e eliminação de chaves
• 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:

• Controla totalmente o acesso aos dados removendo a chave e tornando a base de dados inacessível.
• Tem controlo total sobre o ciclo de vida da chave, incluindo a rotação da chave para alinhar com as políticas da empresa.
• Podes gerir e organizar chaves centralmente no Azure Key Vault ou no Managed HSM.
• Pode implementar a separação de funções entre oficiais de segurança, DBA e administradores de sistemas.

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 Base de Dados do Azure para MySQL para se ligar ao Azure Key Vault que armazena o CMK. O Base de Dados do Azure para MySQL atualmente suporta apenas 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 Base de Dados do Azure para MySQL, ligue o UAMI ao servidor e especifique o Azure Key Vault e a chave a usar.

A UAMI necessita do seguinte acesso ao cofre da chave:

• Get: Para recuperar a parte pública e as propriedades da chave no cofre de chaves.
• Lista: Para listar as versões da chave armazenadas num Key Vault.
• Chave de Wrap: Para encriptar o DEK. A DEK criptografada é armazenada no Banco de Dados do Azure para a instância flexível do servidor MySQL.
• Chave de desembrulho: Para desencriptar o DEK. O Base de Dados do Azure para MySQL precisa do DEK desencriptado para encriptar ou desencriptar os dados.

Se o Azure RBAC estiver ativado, atribui funções ao UAMI em vez de acesso individual.

• Key Vault Crypto Service Encryption User ou a função que tenha as permissões:
  • Microsoft.KeyVault/vaults/keys/wrap/action
  • Microsoft.KeyVault/vaults/keys/desencriptar/ação
  • Microsoft.KeyVault/vaults/keys/read como "Utilizador da encriptação do serviço de criptografia do Key Vault"
• Para o Managed HSM, atribua a função Utilizador de Encriptação do Serviço de Criptografia do Managed HSM

Defina a encriptação dos dados com CMKs ao nível do servidor. Para um servidor específico, é utilizada uma CMK, designada por chave de encriptação de chaves (KEK), para encriptar a chave de encriptação 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 Key Vault não permite acesso direto a uma chave armazenada, mas fornece serviços de encriptação e desencriptação ao utilizar a chave para entidades autorizadas. O cofre de chaves pode gerar a chave ou transferi-la 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 Key Vault devolve a DEK encriptada armazenada na base de dados do utilizador. Da mesma forma, o servidor flexível envia a DEK protegida para o cofre de chaves para desencriptação quando necessário.

Depois de ativar o registo, os auditores podem usar o Azure Monitor para rever os registos de eventos de auditoria do Key Vault. Para ativar o registo de eventos de auditoria do Key Vault, consulte Monitorizar o serviço Key Vault com informações do Key Vault.

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 Key Vault e a instância de servidor flexível do Base de Dados do Azure para MySQL têm de pertencer ao mesmo inquilino do Microsoft Entra. O Cofre da Chave entre locatários e as interações flexíveis do servidor precisam ser suportados. Tem de reconfigurar a encriptação de dados se mover recursos do Key Vault após efetuar 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.
• Ativa a funcionalidade de Apagar 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 eliminação definitiva têm as suas próprias permissões numa política de acesso ao Key Vault.
  • 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 gerida pelo cliente para encriptar o DEK só pode ser 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 purga ativada.
• Se estiver a importar uma chave existente para o cofre de chaves, certifique-se de a fornecer num dos formatos de ficheiro suportados (.pfx, .byok, .backup).

Recomendações para configurar a criptografia de dados

Quando configurar o Key Vault ou o HSM gerido para usar encriptação de dados com uma chave gerida pelo cliente, tenha em mente as 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 configura encriptação de dados com uma CMK no Key Vault, o servidor requer acesso contínuo a esta chave para se manter 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 eliminar o cofre de chaves, a instância do servidor flexível do Base de Dados do Azure para 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 Key Vault, a instância do servidor flexível do Base de Dados do Azure para MySQL não consegue aceder à chave e passa para o estado Inaccessible. Para criar a instância Availabledo servidor:

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

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

Alguém com direitos de acesso suficientes ao Key Vault pode desativar acidentalmente o acesso flexível ao servidor da chave através de:

• Revogando as permissões do cofre de chaves obter, listar, encapsular chave e desembrulhar chave do servidor
• Eliminar a chave
• Eliminar o cofre de chaves
• Alterar as regras de firewall do cofre de chaves
• Eliminar a identidade gerida pelo utilizador utilizada para encriptação no servidor flexível com uma chave gerida pelo cliente no Microsoft Entra ID

Monitorizar a chave gerida pelo cliente no Cofre de Chaves

Para monitorizar o estado da base de dados e permitir alertas para a perda de acesso transparente ao protetor de encriptação de dados, configure as seguintes funcionalidades 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 gerida pelo cliente no Key Vault

Quando encripta uma instância de servidor flexível do Base de Dados do Azure para MySQL com a chave gerida de um cliente armazenada no Key Vault, qualquer cópia recém-criada do servidor também é encriptada. Quando tentar encriptar uma instância de servidor flexível do Base de Dados do Azure para MySQL com uma chave gerida pelo cliente que já tenha uma réplica, configure uma ou mais réplicas adicionando a identidade e a chave geridas. Se configurar a instância de servidor flexível Base de Dados do Azure para MySQL com backup de geo-redundância, deve configurar a réplica com a identidade gerida e a chave à qual a identidade tem acesso e que reside na região geo-pareada do servidor.

Restaurar com uma chave gerida pelo cliente no Key Vault

Quando restaurar uma instância de servidor flexível Base de Dados do Azure para MySQL, selecione a identidade gerida pelo utilizador e a chave para encriptar o servidor de restauro. Se a instância do servidor flexível do Base de Dados do Azure para MySQL estiver configurada com cópia de segurança com georredundância, tem de configurar o servidor de restauro com a identidade gerida e a chave a que a identidade tem acesso e que se encontra na região emparelhada geograficamente do servidor.

Durante o restauro ou a criação de uma réplica de leitura, siga estes passos nos servidores de origem e no servidor restaurado ou de réplica:

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

Conteúdo relacionado

• Encriptação de dados para o Base de Dados do Azure para MySQL – servidor flexível com a CLI do Azure
• Encriptação de dados para o Base de Dados do Azure para MySQL – servidor flexível 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