Criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para MySQL – Servidor Flexível
APLICA-SE A:
Banco de Dados do Azure para MySQL - Servidor flexível
Com a criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para MySQL – Servidor Flexível, você poderá usar BYOK (Bring Your Own Key) para a proteção de dados inativos e implementar a separação de direitos para gerenciamento de chaves e dados. Com CMKs (chaves gerenciadas pelo cliente), o cliente tem a responsabilidade e controla o gerenciamento de ciclo de vida da chave (criação, carregamento, rotação e exclusão de chave), as permissões de uso da chave e as operações de auditoria em chaves.
Benefícios
A criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para MySQL – Servidor Flexível oferece os seguintes benefícios:
- 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
- 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 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 fazer autenticação em qualquer serviço que dê suporte à autenticação do Azure AD, como o AKV (Azure Key Vault). O Banco de Dados do Azure para MySQL – Servidor Flexível atualmente dá suporte somente à UMI (identidade gerenciada atribuída pelo usuário). Para saber mais, confira Tipos de identidade gerenciada.
Para configurar a CMK para um servidor flexível do Banco de Dados do Azure para MySQL, você precisa vincular a UMI ao servidor e especificar o cofre de chaves do Azure e a chave a serem usados.
A 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.
- 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 – Servidor Flexível precisa da DEK descriptografada para criptografar/descriptografar os dados.
Descrição e terminologia
DEK (chave de criptografia de dados) : uma chave simétrica AES256 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 pelo 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, apenas os dados no respectivo bloco associado precisam ser criptografados novamente com a nova chave.
KEK (chave de criptografia de chave) : uma chave de criptografia usada para criptografar as DEKs. Uma KEK que nunca deixa o Key Vault permite que as DEKs sejam criptografadas e controladas. A entidade que tem acesso à KEK pode ser diferente da entidade que requer a DEK. Uma vez que a KEK é necessária para descriptografar das DEKs, a KEK é efetivamente um ponto único pelo qual os DEKs podem ser efetivamente excluídos com a exclusão da KEK. As DEKs, criptografadas com as KEKs, são armazenadas separadamente. Somente uma entidade com acesso à KEK pode descriptografar essas DEKs. Para obter mais informações, confira Segurança na criptografia em repouso.
Como ele funciona
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. De modo semelhante, o servidor flexível enviará a DEK protegida para o cofre de chaves para descriptografia, conforme 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.
Observação
As alterações de permissão podem levar até 10 minutos para afetar o cofre de chaves. Isso inclui a revogação de permissões de acesso ao protetor TDE no AKV. Além disso, os usuários dentro desse período ainda podem ter permissões de acesso.
Requisitos para configurar a criptografia de dados para o Banco de Dados do Azure para MySQL – servidor flexível
Antes de tentar configurar Key Vault, verifique se atende aos requisitos a seguir.
- 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.
- Habilite a funcionalidade de exclusão reversível no cofre de chaves com um período de retenção definido como 90 dias para proteger contra a perda de dados em caso de exclusão acidental de chave (ou do cofre de chaves). As ações de recuperação e limpeza têm permissões próprias em uma política de acesso do Key Vault. A funcionalidade de exclusão reversível está desativada por padrão, mas você pode habilitá-la por meio do portal do Azure ou usando o PowerShell ou a CLI do Azure.
- Habilite a funcionalidade Proteção de Limpeza no cofre de chaves com o período de retenção definido como 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 tenha passado o período de retenção. Você pode habilitar esse recurso usando o PowerShell ou a CLI do Azure e somente depois de habilitar a exclusão reversível.
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. Isso define implicitamente o atributo de chave necessário recoveryLevel: "Recuperável".
- A chave deve ter a proteção de limpeza habilitada.
- Se você estiver importando uma chave existente para o cofre de chaves, forneça-a nos formatos de arquivo com suporte (.pfx, .byok, .backup).
Observação
Para obter instruções detalhadas e passo a passo sobre como configurar a criptografia de dados para o Banco de Dados do Azure para MySQL – servidor flexível por meio do portal do Azure, confira Configurar a criptografia de dados para o Banco de Dados do Azure para MySQL – servidor flexível.
Recomendações para configurar a criptografia de dados
Ao configurar o Key Vault 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. O Log Analytics do Azure Monitor é um exemplo de um serviço que já está integrado.
- 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.
Observação
- É recomendável usar um cofre de chaves da mesma região, mas, se necessário, poderá usar um cofre de chaves de outra região especificando as informações para "inserir um identificador de chave".
- Atualmente, não há suporte para a chave RSA armazenada no HSM Gerenciado do Azure Key Vault.
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 conseguirá acessar a chave e passará para o estado Inacessível. Recupere o cofre de chaves e revalide a criptografia de dados para tornar o a instância do Banco de Dados do Azure para MySQL – servidor flexível Disponível.
- 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 conseguirá acessar a chave e passará para o estado Inacessível. Recupere a chave e revalide a criptografia de dados para tornar o a instância do Banco de Dados do Azure para MySQL – servidor flexível Disponível.
- Se a chave armazenada no Azure Key Vault expirar, ela se tornará inválida, e a instância do Banco de Dados do Azure para MySQL – Servidor Flexível passará para o estado Inacessível. Estenda a data de expiração da chave usando a CLI e revalide a criptografia de dados para tornar a instância do Banco de Dados do Azure para MySQL – servidor flexível Disponível.
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:
- Revogar as permissões get, list, wrap key e unwrap key do cofre de chaves 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 do Banco de Dados do Azure para MySQL – servidor flexível com uma chave gerenciada pelo cliente que já tenha réplicas, é recomendável configurar as réplicas, adicionando a identidade e a chave gerenciadas. 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.
Para evitar problemas durante a configuração da criptografia de dados gerenciados pelo cliente durante a restauração ou a criação de réplica de leitura, é essencial seguir estas etapas nos servidores fonte e restaurado/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/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.
Observação
O uso da mesma identidade e chave que as do servidor de origem não é obrigatório ao executar uma restauração.