Criptografia de dados com uma chave gerenciada pelo cliente no Banco de Dados do Azure para PostgreSQL com Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Flexível

O Banco de Dados do Azure para PostgreSQL com Servidor Flexível usa a criptografia do Armazenamento do Microsoft Azure para criptografar dados inativos por padrão usando chaves gerenciadas pela Microsoft. Para usuários do Banco de Dados do Azure para PostgreSQL com Servidor Flexível, o processo é semelhante à criptografia de dados transparente de outros bancos de dados, como o SQL Server.

Muitas organizações requerem um controle total sobre o acesso aos dados usando uma chave gerenciada pelo cliente (CMK). A criptografia de dados com CMKs do Banco de Dados do Azure para PostgreSQL com Servidor Flexível permite que você traga a sua chave (BYOK) para a proteção de dados em repouso. Ela também permite que as organizações implementem a separação de tarefas no gerenciamento de chaves e dados. Com a criptografia por CMK, você é responsável e tem controle total do ciclo de vida de uma chave, das permissões de uso de chave e da auditoria de operações em chaves.

A criptografia de dados com CMKs do Banco de Dados do Azure para PostgreSQL com Servidor Flexível é definida no nível do servidor. Para um determinado servidor, um tipo de CMK conhecido como chave de criptografia de chave (KEK) é usado para criptografar a chave de criptografia de dados (DEK) do serviço. A KEK é uma chave assimétrica armazenada em uma instância do Azure Key Vault gerenciada pelo cliente e de propriedade dele. A KEK e a DEK são descritas em mais detalhes mais adiante nesse artigo.

O Key Vault é um sistema de gerenciamento de chaves externas baseado em nuvem. Ele é altamente disponível e fornece armazenamento escalonável e seguro para chaves criptográficas RSA, opcionalmente apoiado por módulos de segurança de hardware (HSMs) validados pelo FIPS 140. Ele não permite acesso direto a uma chave armazenada, mas fornece serviços de criptografia e descriptografia para as entidades autorizadas. O Key Vault pode gerar a chave, importá-la ou transferi-la de um dispositivo HSM local.

Benefícios

A criptografia de dados com CMKs do Banco de Dados do Azure para PostgreSQL com Servidor Flexível proporciona os seguintes benefícios:

  • Você controla totalmente o acesso a dados. Você pode remover uma chave para tornar um banco de dados inacessível.

  • Você controla totalmente o ciclo de vida de uma chave, incluindo a rotação da chave para se alinhar às políticas corporativas.

  • Você pode gerenciar e organizar as chaves centralmente no Key Vault.

  • Ativar a criptografia não afeta o desempenho com ou sem CMKs porque o PostgreSQL depende da camada de Armazenamento do Azure para a criptografia de dados em ambos os cenários. A única diferença é que, quando você usa uma CMK, a chave de criptografia do Armazenamento do Azure (que executa a criptografia de dados real) é criptografada.

  • Você pode implementar a separação de funções entre os diretores de segurança, os administradores de banco de dados e os administradores do sistema.

Terminologia

Chave de Criptografia de Dados (DEK): uma chave AES 256 simétrica que é usada para criptografar uma partição ou bloco de dados. Criptografar cada bloco de dados com uma chave diferente dificulta os ataques de criptoanálise. O provedor de recursos ou instância de aplicativo que criptografam e descriptografam um bloco específico precisam de acesso às DEKs. Quando você substitui uma DEK por uma nova chave, apenas os dados no respectivo bloco associado precisam ser criptografados novamente com a nova chave.

Chave de Criptografia de Chave (KEK): uma chave de criptografia que é 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 DEKs. Como a KEK é necessária para descriptografar as DEKs, a KEK é efetivamente um ponto único por meio do qual você pode excluir DEKs (ao excluir a KEK).

As DEKs, criptografadas com uma KEK, são armazenadas separadamente. Somente uma entidade que tenha acesso à KEK pode descriptografar essas DEKs. Para obter mais informações, confira Segurança na criptografia em repouso.

Como funciona a criptografia de dados com uma CMK

Diagrama mostrando uma visão geral do recurso

Uma identidade gerenciada atribuída pelo usuário do Microsoft Entra é usada para conectar e recuperar uma CMK. Para criar uma identidade, siga esse tutorial.

Para que um servidor PostgreSQL use CMKs armazenadas no Key Vault para criptografar a DEK, um administrador do Key Vault deve fornecer os seguintes direitos de acesso à identidade gerenciada que você criou:

  • get: para recuperar a parte pública e as propriedades da chave no Key Vault.

  • list: para listar e iterar por meio das chaves no Key Vault.

  • wrapKey: para criptografar a DEK. A DEK criptografada é armazenada no Banco de Dados do Azure para PostgreSQL.

  • unwrapKey: para descriptografar a DEK. O Banco de Dados do Azure para PostgreSQL precisa da DEK descriptografada para criptografar e descriptografar os dados.

O administrador do Key Vault também pode habilitar o registro em log de eventos de auditoria do Key Vault, para que possam ser auditados mais tarde.

Importante

Não fornecer os direitos de acesso mencionados a uma identidade gerenciada para acesso ao Key Vault pode resultar em falha ao buscar uma chave de criptografia e ao configurar o recurso CMK.

Quando você configura o servidor para usar a CMK armazenada no Key Vault, o servidor envia a DEK para o Key Vault para a criptografia. O Key Vault retorna a DEK criptografada armazenada no banco de dados do usuário. Quando necessário, o servidor envia a DEK protegida para o Key Vault para descriptografar. Os auditores podem usar o Azure Monitor para revisar os logs de eventos de auditoria do Key Vault se o registro em logs estiver ativado.

Requisitos para configurar a encriptação de dados para a Base de Dados Azure para servidor flexível PostgreSQL

Confira abaixo os requisitos para configurar o Key Vault:

  • O Key Vault e o servidor flexível do Banco de Dados do Azure para PostgreSQL devem pertencer ao mesmo locatário do Microsoft Entra. Não há suporte para interações do servidor e do Key Vault entre locatários. A movimentação de recursos do Key Vault posteriormente exige que você reconfigure a criptografia de dados.

  • A configuração do número de Dias para reter os cofres excluídos para o Key Vault deve ser 90. Se tiver configurado a instância existente do Key Vault com um número menor, você precisará criar uma nova instância do Key Vault, porque não é possível modificar uma instância após a criação.

  • Habilite o recurso de exclusão temporária no Key Vault para ajudar a proteger contra perda de dados se uma chave ou instância do Key Vault forem excluídas acidentalmente. O Key Vault retém os recursos excluídos temporariamente por 90 dias, a menos que o usuário os recupere ou os limpe nesse meio tempo. As ações de recuperação e limpeza têm as próprias permissões associadas em uma política de acesso do Key Vault.

    O recurso de exclusão temporária está desativado por padrão, mas você pode ativá-lo por meio do PowerShell ou da CLI do Azure. Você não pode ativá-lo por meio do portal do Azure.

  • Habilite a proteção contra limpeza para implementar um período de retenção obrigatório para os cofres e objetos de cofre excluídos.

  • Conceda à instância do Banco de Dados do Azure para PostgreSQL com Servidor Flexível acesso ao Key Vault com as permissões get, list, wrapKey e unwrapKey usando sua identidade gerenciada exclusiva.

Confira abaixo os requisitos para configurar a CMK no Banco de Dados do Azure para PostgreSQL com Servidor Flexível:

  • A CMK a ser usada para criptografar a DEK somente pode ser dos tipos assimétrica, RSA ou RSA-HSM. Os tamanhos de chave que têm suporte são 2.048, 3.072 e 4.096.

  • A data e hora da ativação da chave (se definida) deve estar no passado. A data e hora da expiração (se definida) deve estar no futuro.

  • A chave precisa estar no estado *Enabled-.

  • Se estiver importando uma chave existente para o Key Vault, certifique-se de fornecê-la nos formatos de arquivo com suporte (.pfx, .byok ou .backup).

Recomendações

Quando estiver usando uma CMK para criptografar dados, essas são as recomendações para você configurar o Key Vault:

  • 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 SIEM (gerenciamento de eventos e informações de segurança). Os Logs do Azure Monitor são um exemplo de um serviço que já está integrado.

  • Certifique-se de que o Key Vault e o Banco de Dados do Azure para PostgreSQL com Servidor Flexível residam na mesma região para garantir um acesso mais rápido para as operações de encapsulamento e desencapsulamento da DEK.

  • Bloqueie o Key Vault selecionando Desabilitar o acesso público e Permitir que serviços confiáveis da Microsoft ignorem esse firewall.

    Captura de tela das opções de rede para desabilitar o acesso público e permitir apenas serviços confiáveis da Microsoft.

Observação

Após selecionar Desabilitar o acesso público e Permitir que serviços confiáveis da Microsoft ignorem esse firewall, você poderá receber um erro semelhante ao seguinte quando tentar usar o acesso público para administrar o Key Vault por meio do portal: "Você habilitou o controle de acesso à rede. Somente as redes permitidas terão acesso a esse Key Vault." Esse erro não exclui a capacidade de fornecer chaves durante a configuração da CMK ou de buscar chaves no Azure Key Vault durante as operações do servidor.

Confira abaixo as recomendações para configurar uma CMK:

  • Mantenha uma cópia da CMK em um local seguro ou a resguarde no serviço de caução.

  • Se o Key Vault gerar a chave, crie um backup da chave antes de usá-la pela primeira vez. Você só pode restaurar o backup para o Key Vault.

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

Uma pessoa com direitos de acesso suficientes ao Key Vault poderá desabilitar acidentalmente o acesso do servidor à chave se:

  • Revogar as permissões list, get, wrapKey e unwrapKey do Key Vault da identidade que é usada para recuperar a chave no Key Vault.

  • Excluir a chave.

  • Excluir a instância do Key Vault.

  • Alterar as regras de firewall do Key Vault.

  • Excluir a identidade gerenciada do servidor no Microsoft Entra ID.

Como monitorar a CMK no Key Vault

Para monitorar o estado do banco de dados e ativar alertas para a perda de acesso ao protetor da criptografia de dados transparente, configure os seguintes recursos do Azure:

  • Integridade do recurso: um banco de dados que perdeu acesso à CMK aparece como Inacessível após a primeira conexão com o banco de dados ser negada.
  • Log de atividades: quando o acesso à CMK falhar na instância do Key Vault gerenciada pelo cliente, serão adicionadas entradas 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 receber notificações e alertas com base em suas preferências.

Como restaurar com a chave gerenciada de um cliente no Key Vault

Depois de a Base de Dados Azure para o servidor flexível PostgreSQL ser encriptada com a chave gerida de um cliente armazenada no Key Vault, qualquer cópia do servidor recém-criada também é encriptada. Você pode fazer essa nova cópia por meio de uma operação de restauração pontual (PITR) ou de réplicas de leitura.

Quando estiver configurando a criptografia de dados gerenciada pelo cliente durante a restauração ou criação de uma réplica de leitura, você pode evitar problemas seguindo essas etapas nos servidores primários e restaurados/de réplica:

  • Inicie o processo de restauração ou o processo de criação de uma réplica de leitura da instância do Banco de Dados do Azure para PostgreSQL com Servidor Flexível.

  • Tanto no servidor restaurado quanto na réplica do servidor você pode alterar a CMK e/ou a identidade do Microsoft Entra que são usadas para acessar o Key Vault nas configurações de criptografia de dados. Certifique-se de que o servidor recém-criado tenha as permissões list, wrap e unwrap para a chave armazenada no Key Vault.

  • Não revogue a chave original após a restauração. No momento, não damos suporte à revogação da chave após você ter restaurado um servidor habilitado por CMK para outro servidor.

HSMs gerenciados

Módulos de segurança de hardware (HSMs) são dispositivos de hardware resistentes a adulterações que ajudam a proteger os processos criptográficos gerando, protegendo e gerenciando as chaves usadas para criptografar dados, descriptografar dados, criar assinaturas e criar certificados digitais. Os HSMs são testados, validados e certificados de acordo com os mais altos padrões de segurança, incluindo FIPS 140 e Critérios Comuns.

O HSM Gerenciado do Azure Key Vault é um serviço de nuvem totalmente gerenciado, altamente disponível, de locatário único, em conformidade com padrões. Você pode usá-lo para proteger chaves criptográficas para seus aplicativos de nuvem por meio de HSMs validados pelo FIPS 140-3.

Ao criar novas instâncias do Banco de Dados do Azure para PostgreSQL com Servidor Flexível no portal do Azure com o recurso CMK, você pode escolher o HSM Gerenciado do Azure Key Vault como um repositório de chaves e uma alternativa ao Azure Key Vault. Em termos de identidade e permissões definidas pelo usuário, os pré-requisitos são os mesmos do Azure Key Vault (conforme listados anteriormente neste artigo). Para obter mais informações sobre como criar uma instância de HSM Gerenciado, suas vantagens e diferenças com relação a um repositório de certificados baseado em Key Vault compartilhado e como importar chaves para o HSM Gerenciado, confira O que é o HSM gerenciado do Azure Key Vault?.

Condição de CMK 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 perder o acesso à CMK no Key Vault, o servidor começará a negar todas as conexões após 10 minutos. O servidor emite uma mensagem de erro correspondente e altera o estado do servidor para Inacessível.

Algumas das razões pelas quais o estado do servidor se torna Inacessível são as seguintes:

  • Se você excluir a instância do Key Vault, a instância do Banco de Dados do Azure para PostgreSQL com Servidor Flexível não poderá acessar a chave e passará para um estado Inacessível. Para tornar o servidor Disponível, recupere a instância do Key Vault e revalide a criptografia de dados.
  • Se você excluir a chave do Key Vault, a instância do Banco de Dados do Azure para PostgreSQL com Servidor Flexível não poderá acessar a chave e passará para um estado Inacessível. Para tornar o servidor Disponível, recupere a chave e revalide a criptografia de dados.
  • Se você excluir do Microsoft Entra ID uma identidade gerenciada que é usada para recuperar uma chave do Key Vault, a instância do Banco de Dados do Azure para PostgreSQL com Servidor Flexível não poderá acessar a chave e passará para um estado Inacessível. Para tornar o servidor Disponível, recupere a identidade e revalide a criptografia de dados.
  • Se você revogar as políticas de acesso list, get, wrapKey e unwrapKey do Key Vault da identidade gerenciada que é usada para recuperar uma chave do Key Vault, a instância do Banco de Dados do Azure para PostgreSQL com Servidor Flexível não conseguirá acessar a chave e passará para um estado Inacessível. Adicione as políticas de acesso necessárias à identidade no Key Vault.
  • Se você configurar regras de firewall do Key Vault com excesso de restrições, o Banco de Dados do Azure para PostgreSQL com Servidor Flexível não poderá se comunicar com o Key Vault para recuperar as chaves. Ao configurar um firewall do Key Vault, certifique-se de selecionar a opção para permitir que os serviços confiáveis da Microsoft ignorem o firewall.

Observação

Quando uma chave for desabilitada ou excluída, expirar ou se tornar não acessível, um servidor que tiver dados criptografados por meio dessa chave se tornará Inacessível, conforme indicado anteriormente. O servidor não ficará disponível até que você habilite a chave novamente ou lhe atribua uma nova chave.

De modo geral, um servidor se torna Inacessível no prazo de 60 minutos após uma chave ser desabilitada ou excluída, expirar ou se tornar não acessível. Após a chave se tornar disponível, o servidor poderá levar até 60 minutos para ficar Acessível novamente.

Como usar a criptografia de dados com CMKs e recursos de continuidade de negócios com redundância geográfica

O Banco de Dados do Azure para PostgreSQL com Servidor Flexível dá suporte a recursos avançados de recuperação de dados, como réplicas e backup com redundância geográfica. A seguir, temos os requisitos para configurar a criptografia de dados com CMKs e esses recursos, além dos requisitos básicos para a criptografia de dados com CMKs:

  • A chave de criptografia de backup com redundância geográfica precisa ser criada em uma instância do Azure Key Vault na região em que o backup com redundância geográfica está armazenado.
  • A versão da API REST do Azure Resource Manager (ARM) para dar suporte aos servidores com CMK habilitados para backup com redundância geográfica é 2022-11-01-preview. Se quiser usar modelos do Azure Resource Manager para automatizar a criação de servidores que usam tanto criptografia com CMKs quanto recursos de backup com redundância geográfica, você deve usar essa versão da API.
  • Você não pode usar a mesma identidade gerenciada pelo usuário para se autenticar na instância do Key Vault do banco de dados primário e na instância do Key Vault que contém a chave de criptografia para o backup com redundância geográfica. Para manter a resiliência regional, recomendamos que você crie a identidade gerenciada pelo usuário na mesma região dos backups com redundância geográfica.
  • Se você configurar um banco de dados de réplica de leitura para ser criptografado com CMKs durante a criação, sua chave de criptografia precisará estar em uma instância do Key Vault na região em que o banco de dados de réplica de leitura reside. A identidade atribuída pelo usuário para se autenticar nessa instância do Azure Key Vault precisa ser criada na mesma região.

Limitações

Confira abaixo as limitações atuais para configurar a CMK no Banco de Dados do Azure para PostgreSQL com Servidor Flexível:

Próximas etapas