Compartilhar via

Criptografia de dados no Banco de Dados do Azure para PostgreSQL

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

Todos os dados gerenciados por um servidor flexível do Banco de Dados do Azure para PostgreSQL são sempre criptografados em repouso. Esses dados incluem todos os bancos de dados do sistema e do usuário, arquivos temporários, logs de servidor, segmentos de log write-ahead e backups.

Criptografia em repouso com SMK (Serviço) ou CMK (Chaves Gerenciadas pelo Cliente)

O servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a dois modos de criptografia de dados em repouso: SMK (chaves gerenciadas por serviço) e CMK (chaves gerenciadas pelo cliente). A criptografia de dados com chaves gerenciadas de serviço é o modo padrão para o servidor flexível do Banco de Dados do Azure para PostgreSQL. Nesse modo, o serviço gerencia automaticamente as chaves de criptografia usadas para criptografar seus dados. Você não precisa executar nenhuma ação para habilitar ou gerenciar a criptografia nesse modo.

No modo de chaves gerenciadas pelo cliente , você pode trazer sua própria chave de criptografia para criptografar seus dados. Esse modo oferece mais controle sobre o processo de criptografia, mas também exige que você gerencie as chaves de criptografia por conta própria. Você deve implantar seu próprio Azure Key Vault ou HSM (Managed Hardware Security Module) do Azure Key Vault e configurá-lo para armazenar as chaves de criptografia usadas pelo servidor flexível do Banco de Dados do Azure para PostgreSQL.

O modo de configuração só pode ser selecionado no momento da criação do servidor. Ele não pode ser alterado de um modo para outro durante o tempo de vida do servidor.

Para obter a criptografia de seus dados, o servidor flexível do Banco de Dados do Azure para PostgreSQL usa a criptografia de Armazenamento do Azure para dados em repouso. Ao usar o CMK, o cliente é responsável por fornecer chaves para criptografar e descriptografar dados nos serviços de Armazenamento de Blobs e Arquivos do Azure. Essas chaves devem ser armazenadas no Azure Key Vault ou no Módulo de Segurança de Hardware Gerenciado (HSM) do Azure Key Vault. Para obter mais informações, confira chaves gerenciadas pelo cliente para criptografia do Armazenamento do Microsoft Azure.

Benefícios fornecidos por cada modo (SMK ou CMK)

A criptografia de dados com chaves gerenciadas pelo serviço para o servidor flexível do Banco de Dados do Azure para PostgreSQL oferece os seguintes benefícios:

  • O serviço controla automaticamente e totalmente o acesso a dados.
  • O serviço controla automaticamente e totalmente o ciclo de vida da chave, incluindo a rotação da chave.
  • Você não precisa se preocupar com o gerenciamento de chaves de criptografia de dados.
  • A criptografia de dados com base em chaves gerenciadas pelo serviço não afeta negativamente o desempenho de suas cargas de trabalho.
  • Ela simplifica o gerenciamento de chaves de criptografia (incluindo sua rotação regular) e o gerenciamento das identidades usadas para acessar essas chaves.

A criptografia de dados com chaves gerenciadas pelo cliente para o servidor flexível do Banco de Dados do Azure para PostgreSQL oferece 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 centralmente todas as suas chaves de criptografia em suas próprias instâncias do Azure Key Vault.
  • A criptografia de dados baseada em chaves gerenciadas pelo cliente não afeta negativamente o desempenho de suas cargas de trabalho.
  • Você pode implementar a separação de tarefas entre agentes de segurança, administradores de banco de dados e administradores do sistema.

Requisitos do CMK

Com a chave de criptografia gerenciada pelo cliente, você assume toda a responsabilidade. Portanto, você deve implantar seu próprio Azure Key Vault ou Azure Key Vault HSM. Você deve gerar ou importar a sua própria chave. Você deve conceder as permissões necessárias no Key Vault para que o servidor flexível do Banco de Dados do Azure para PostgreSQL possa executar as ações necessárias na chave. Você precisa cuidar da configuração de todos os aspectos de rede do Azure Key Vault no qual a chave é mantida, para que o servidor flexível do Banco de Dados do Azure para PostgreSQL possa acessar a chave. Auditar o acesso à chave também é sua responsabilidade. Por fim, você é responsável por girar a chave e, quando necessário, atualizar a configuração do servidor flexível do Banco de Dados do Azure para PostgreSQL para que ele faça referência à versão girada da chave.

Quando você configura chaves gerenciadas pelo cliente para uma conta de armazenamento, o Armazenamento do Microsoft Azure encapsula a chave de criptografia de dados (DEK) raiz para a conta com a chave gerenciada pelo cliente no cofre de chaves associado ou HSM gerenciado. A proteção da chave de criptografia raiz muda, mas os dados em sua conta de Armazenamento do Microsoft Azure permanecem sempre criptografados. Não há nenhuma ação adicional necessária de sua parte para garantir que os seus dados permaneçam criptografados. A proteção por chaves gerenciadas pelo cliente entra em vigor imediatamente.

O Azure Key Vault é um sistema de gerenciamento de chaves externo 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 entidades autorizadas. O Key Vault pode gerar a chave, importá-la ou recebê-la transferida de um dispositivo HSM local.

Veja a seguir a lista de requisitos para configurar a criptografia de dados para o servidor flexível do Banco de Dados do Azure para PostgreSQL:

  • O Key Vault e o Servidor Flexível do Banco de Dados do Azure para PostgreSQL precisam 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.
  • Recomendamos definir a configuração Dias para manter os cofres excluídos para o Key Vault como 90 dias. Se você configurou uma instância existente do Key Vault com um número menor, ela ainda deverá ser válida. No entanto, se você quiser modificar essa configuração e aumentar o valor, será necessário criar uma nova instância do Key Vault. Depois que uma instância é criada, não é possível modificar essa configuração.
  • Habilite o recurso de exclusão reversível no Key Vault para ajudá-lo a proteger contra perda de dados, se uma chave ou uma instância do Key Vault for excluída 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 suas próprias permissões, que podem estar associadas a um Key Vault, a uma função RBAC ou a uma permissão de política de acesso. O recurso de exclusão reversível está ativado por padrão. Se você tiver algum Key Vault implantado há muito tempo, ele ainda poderá ter a exclusão reversível desabilitada. Nesse caso, você pode ativá-lo usando a CLI 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 à identidade gerenciada atribuída pelo usuário do Servidor Flexível do Banco de Dados do Azure para PostgreSQL acesso à chave por meio de:
  • A chave usada para criptografar a chave de criptografia de dados pode ser apenas assimétrica, RSA ou RSA-HSM. Os tamanhos de chave que têm suporte são 2.048, 3.072 e 4.096. É recomendável usar uma chave de 4.096 bits para melhorar a segurança.
  • A data e hora da ativação da chave (se definida) deve estar no passado. A data e hora de expiração (se estiver definida) deve estar no futuro.
  • A chave deve estar no estado Habilitado.
  • 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).

Atualizações de versão de chave do CMK

O CMK pode ser configurado com rotação manual de chaves e atualizações ou com atualizações automáticas de versão de chave após uma rotação manual ou automática de chaves no Key Vault.

Para obter detalhes, consulte Configurar a criptografia de dados com a chave gerenciada pelo cliente durante o provisionamento do servidor

Rotação e atualizações manuais de chave

Ao configurar o CMK com atualizações manuais de chave, você deve atualizar manualmente a versão da chave no servidor flexível do Banco de Dados do Azure para PostgreSQL após uma rotação manual ou automática de chaves no Key Vault. O servidor continuará a usar a versão da chave antiga até que você a atualize. Você provisiona esse modo especificando um URI de chave, incluindo o GUID de versão no URI. Por exemplo, https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Até recentemente, essa era a única opção disponível.

Sempre que você girar manualmente a chave ou o AKV girar automaticamente a chave com base em sua política de rotação, você precisará atualizar a propriedade CMK na instância do PostgreSQL. Essa abordagem provou ser um trabalho propenso a erros para os operadores ou exigiu um script personalizado para lidar com a rotação, especialmente ao usar o recurso de rotação automática do Key Vault.

Atualizações automáticas de versão da chave

Para habilitar atualizações automáticas de versão de chave, use um URI de chave sem versão. Isso elimina a necessidade de atualizar a propriedade de versão do CMK em sua instância do PostgreSQL após uma rotação de chave. O PostgreSQL pegará automaticamente a nova versão da chave e reenscriptografará a chave de criptografia de dados. Essa é uma enorme simplificação no gerenciamento do ciclo de vida de chaves, especialmente quando combinado com a rotação automática do Key Vault.

Para implementar usando ARM, Bicep, Terraform, Azure PowerShell ou CLI do Azure, basta omitir o GUID de versão do seu URI de chave.

No Portal, selecione a caixa de seleção para orientar a interface do usuário para suprimir GUIDs de versão durante a seleção interativa e ao validar o URI.

Recomendações

Quando você estiver usando uma chave gerenciada pelo cliente para criptografia de dados, siga estas recomendações para configurar o Key Vault:

  • Defina um bloqueio de recursos no Key Vault para evitar a exclusão acidental ou não autorizada deste recurso crítico.
  • Habilite a auditoria e o relatório sobre 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.
  • Bloqueie o Key Vault selecionando Desabilitar o acesso público e Permitir que serviços confiáveis da Microsoft ignorem esse firewall.
  • Habilitar atualizações automáticas de versão da chave.

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 cofre de chaves". Este erro não impede a capacidade de fornecer chaves durante a configuração da chave gerenciada pelo cliente ou buscar chaves do Key Vault durante as operações do servidor.

  • Mantenha uma cópia da chave administrada pelo cliente em um local seguro ou deposite-a em um serviço de custódia.
  • 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.

Considerações especiais

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

Alguém com direitos de acesso suficientes ao Key Vault pode desabilitar acidentalmente o acesso do servidor à chave:

  • Cancelar a atribuição da função RBAC Usuário de Criptografia do Serviço Key Vault ou revogar as permissões da identidade utilizada 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.

Monitoramento das chaves mantidas no Azure Key Vault

Para monitorar o estado do banco de dados e ativar alertas para a perda de acesso ao protetor de criptografia de dados, 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.

Restauração de backups de um servidor configurado com uma chave gerenciada pelo cliente

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

Ao configurar a criptografia de dados com a chave gerenciada pelo cliente, durante a operação, como a restauração de um backup ou a criação de uma réplica de leitura, você pode evitar problemas seguindo estas etapas nos servidores primários e restaurados ou 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.
  • No servidor restaurado ou de réplica, você pode alterar a chave gerenciada pelo cliente e a identidade gerenciada atribuída pelo usuário usada para acessar o Key Vault. Certifique-se de que a identidade atribuída no servidor recém-criado tenha as permissões necessárias no Key Vault.
  • Não revogue a chave original após a restauração. No momento, não há suporte para revogação de chave depois que você restaura um servidor com chave gerenciada pelo cliente 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 de servidor flexível do Azure Database para PostgreSQL no portal do Azure utilizando uma chave gerida pelo cliente, você pode optar por utilizar o HSM Gerenciado do Azure Key Vault como repositório de chaves, em 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 chave gerenciada do cliente inacessível

Quando você configura a criptografia de dados com uma chave gerenciada pelo cliente armazenada no Key Vault, o acesso contínuo a essa chave é necessário para que o servidor permaneça online. Se esse não for o caso, o servidor alterará seu estado para Inacessível e começará a negar todas as conexões.

Alguns dos possíveis motivos pelos quais o estado do servidor pode se tornar Inacessível são:

Causa Solução
Qualquer uma das chaves de criptografia apontadas pelo servidor tinha uma data e hora de expiração configuradas e essa data e hora são atingidas. Você deve estender a data de expiração da chave. Em seguida, você deve aguardar o serviço revalidar a chave e fazer a transição automática do estado do servidor para Pronto. Somente quando o servidor estiver de volta ao estado Pronto, você poderá fazer a rotação de chaves para uma versão mais recente ou criar uma nova chave e atualizar o servidor para que ele se refira à nova versão da mesma chave ou à nova chave.
Você faz a rotação de chaves e esquece de atualizar a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL de modo que ele aponta para a nova versão da chave. A chave antiga, para a qual o servidor está apontando, expira e transforma o estado do servidor em Inacessível. Para evitar isso, toda vez que você fizer a rotação de chaves, certifique-se de também atualizar a instância do seu servidor para apontar para a nova versão. Para fazer isso, você pode usar o az postgres flexible-server update, seguindo o exemplo que descreve "Alterar chave/identidade para criptografia de dados. A criptografia de dados não pode ser habilitada após a criação do servidor; isso só atualizará a chave/identidade". Se preferir atualizá-la usando a API, você poderá invocar o endpoint Servidores – Atualização do serviço.
Você exclui a instância do Key Vault e a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL não pode acessar chave e passa para um estado Inacessível. Recupere a instância do Key Vault e aguarde até que o serviço execute a revalidação periódica da chave e faça a transição automática do estado do servidor para Pronto.
Você exclui uma identidade gerenciada do Microsoft Entra ID que é usada para recuperar qualquer uma das chaves de criptografia armazenadas no Key Vault. Recupere a identidade e aguarde até que o serviço execute a revalidação periódica da chave e faça a transição automática do estado do servidor para Pronto.
O modelo de permissão do Key Vault está configurado para usar o controle de acesso baseado em função. Você remove a atribuição de função RBAC do Usuário de Criptografia do Serviço de Criptografia do Key Vault dasidentidades gerenciadas configuradas para recuperar qualquer uma das chaves. Conceda a função RBAC novamente à identidade gerenciada e aguarde até que o serviço execute a revalidação periódica da chave e faça a transição automática do estado do servidor para Pronto. Uma abordagem alternativa consiste em conceder a função no Key Vault a uma identidade gerenciada diferente e atualizar o servidor para que ele use essa outra identidade gerenciada para acessar a chave.
Seu modelo de permissão do Key Vault está configurado para usar políticas de acesso. Você revoga as políticas de acesso list, get, wrapKeyou unwrapKey das identidades gerenciadas configuradas para recuperar qualquer uma das chaves. Conceda a função RBAC novamente à identidade gerenciada e aguarde até que o serviço execute a revalidação periódica da chave e faça a transição automática do estado do servidor para Pronto. Uma abordagem alternativa consiste em conceder as políticas de acesso necessárias no Key Vault a uma identidade gerenciada diferente e atualizar o servidor para que ele use essa outra identidade gerenciada para acessar a chave.
Você configura regras de firewall do Key Vault excessivamente restritivas de modo que o servidor flexível do Banco de Dados do Azure para PostgreSQL não pode se comunicar com o Key Vault para recuperar as chaves. Ao configurar um firewall do Key Vault, certifique-se de selecionar a opção que conceda permissões a serviços confiáveis da Microsoft para que o servidor flexível do Banco de Dados do Azure para PostgreSQL possa ignorar o firewall.

Observação

Quando uma chave for desabilitada ou excluída, expirar ou se tornar inacessível, um servidor que tiver dados criptografados por meio dessa chave se tornará Inacessível, conforme indicado anteriormente. O estado do servidor não será alterado para Pronto novamente até que ele possa revalidar as chaves de criptografia.

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. Depois que a chave ficar disponível, o servidor poderá levar até 60 minutos para se tornarPronto novamente.

Recuperar-se da exclusão de identidade gerenciada

Se a identidade gerenciada atribuída pelo usuário usada para acessar a chave de criptografia armazenada no Key Vault for excluída no Microsoft Entra ID, você deverá seguir estas etapas para recuperá-la:

  1. Recupere a identidade ou crie uma nova identidade gerenciada do Entra ID.
  2. Se você criou uma nova identidade, mesmo que ela tenha exatamente o mesmo nome que tinha antes de ser excluída, atualize as propriedades do servidor flexível do Banco de Dados do Azure para que ele saiba que precisa usar essa nova identidade para acessar a chave de criptografia.
  3. Verifique se essa identidade tem permissões adequadas para operações na chave no AKV (Azure Key Vault).
  4. Aguarde cerca de uma hora até que o servidor revalide a chave.

Importante

Simplesmente criar uma nova identidade do Entra ID com o mesmo nome que a identidade excluída não recupera da exclusão de identidade gerenciada.

Uso de criptografia de dados com chaves gerenciadas pelo cliente 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 Key Vault que deve existir na região em que o backup com redundância geográfica é 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

Essas são as limitações atuais para configurar a chave gerenciada pelo cliente em um servidor flexível do Banco de Dados do Azure para PostgreSQL:

  • Você pode configurar a criptografia de chave gerenciada pelo cliente somente durante a criação de um novo servidor, não como uma atualização para uma instância do servidor flexível do Banco de Dados do Azure para PostgreSQL existente. Em vez disso, você pode restaurar um backup PITR para um novo servidor com criptografia CMK.
  • Depois de configurar a criptografia de chave gerenciada pelo cliente, você não poderá reverter para a chave gerenciada do sistema. Se quiser reverter, será necessário restaurar o servidor para um novo com criptografia de dados configurada com chave gerenciada pelo sistema.
  • A instância do HSM Gerenciado do Azure Key Vault ou a instância do Azure Key Vault na qual você planeja armazenar a chave de criptografia deve existir na mesma região onde a instância do Banco de dados do Azure para o servidor flexível está sendo criada.

Conteúdo relacionado