Compartilhar via

Criptografia de dados

  • Artigo

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

Todos os dados gerenciados por uma instância do Banco de Dados do Azure para PostgreSQL flexível 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.

Para obter a criptografia de seus dados, o Banco de Dados do Azure para PostgreSQL – Servidor flexível usa a Criptografia de Armazenamento do Microsoft Azure para dados inativos, fornecendo chaves para criptografar e descriptografar dados no Armazenamento de Blobs e nos serviços de 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.

O Banco de Dados do Azure para PostgreSQL – Servidor flexível dá suporte à configuração de criptografia de dados em dois modos diferentes: chave gerenciada por serviço e chave gerenciada pelo cliente. 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.

Com a chave de criptografia gerenciada de serviço, o Banco de Dados do Azure para PostgreSQL – Servidor flexível cuida do provisionamento do Azure Key Vault no qual as chaves são mantidas e assume toda a responsabilidade de fornecer a chave com a qual os dados são criptografados e descriptografados. O serviço também cuida do armazenamento, proteção, auditoria de acesso, configuração de rede e rotação automática da chave.

Com a chave de criptografia gerenciada pelo cliente, você assume toda a responsabilidade. Portanto, você deve implantar o seu próprio Azure Key Vault ou HSM do Azure Key Vault. 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.

Benefícios fornecidos por cada modo

A criptografia de dados com chaves gerenciadas de 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 de serviço não afeta negativamente o desempenho de suas cargas de trabalho.
  • Simplifica o gerenciamento de

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

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 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.
  • É recomendável 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 ajudar com a proteção 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 associadas a um Key Vault, uma função RBAC ou 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 da expiração (se 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).

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 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.
  • Bloqueie o Key Vault selecionando Desabilitar o acesso público e Permitir que serviços confiáveis da Microsoft ignorem esse firewall.

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." 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 gerenciada pelo cliente em um local seguro ou use caução de chave 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.

Considerações especiais

Revogação acidental de acesso à chave do 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 de Criptografia do Key Vault ou revogar as permissões da identidade 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.

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 Banco de Dados do Azure para PostgreSQL no portal do Azure com a chave gerenciada pelo cliente, você pode escolher o HSM Gerenciado do Azure Key Vault como um repositório de chaves, como 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 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 o servidor perder o acesso à chave mantida no Key Vault, o servidor começará a negar todas as conexões dentro de 10 minutos. O servidor emite uma mensagem de erro correspondente e altera o estado do servidor para Inacessível.

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

  • Se você girar a chave e esquecer de atualizar a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL de modo que ele aponte para a nova versão da chave. A chave antiga, para a qual a instância estava apontando, eventualmente expira e transforma o estado do servidor em Inacessível. Para evitar isso, toda vez que você girar a chave, 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." Como alternativa, você pode invocar a API REST Servidores - Atualizar do serviço.
  • 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.
  • Caso exclua, do Microsoft Entra ID, uma identidade gerenciada usada para recuperar uma chave do Key Vault ou exclua a atribuição de função RBAC do Azure com a função de Usuário do Serviço de Criptografia 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 fica disponível até que você habilite novamente a chave ou 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. Depois que a chave ficar disponível, o servidor poderá levar até 60 minutos para se tornar Acessível 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.

Rotação de chaves gerenciadas pelo cliente e chaves sem versão (versão prévia)

Como medida de precaução, recomendamos que você gire a chave periodicamente ou sempre que a chave estiver comprometida.

Observação

A maioria das empresas tem requisitos externos ou internos para girar suas chaves periodicamente – por exemplo, a cada 90 dias. Para chaves geradas pelo Key Vault, você pode configurar a autorrotação de chave de criptografia no Azure Key Vault. Se você habilitar a autorrotação, você deverá usar um CMK sem versão (versão prévia) para criptografia de dados no servidor flexível do Banco de Dados do Azure para PostgreSQL para aproveitar este recurso.

Girar manualmente a chave ajuda a proteger os seus dados caso a chave esteja comprometida. Para girar a chave, crie ou importe uma nova geração de chave para a chave comprometida.

  • Se você estiver usando chaves gerenciadas pelo cliente sem versão (versão prévia), o servidor obterá a nova chave automaticamente.
  • Se você estiver usando chaves com versão, será necessário atualizar a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL para usar a nova versão da chave. Somente então o servidor começa a usar a nova chave para criptografar e descriptografar dados.

Chaves gerenciadas pelo cliente sem versão (versão prévia)

Chaves sem versão são recomendadas para criptografia de dados no servidor flexível do Banco de Dados do Azure para PostgreSQL. Ele abrange corretamente qualquer um dos principais cenários de rotação descritos anteriormente. Depois que uma nova versão de chave estiver disponível, o servidor usará automaticamente a nova versão da versão da chave para criptografar e descriptografar dados.

A API não é alterada para chaves sem versão. Em vez de fornecer o URI do identificador de chave inteiro, omita a parte da versão do identificador de chave. Isso se aplica à API, à CLI do Azure, aos modelos do ARM e aos modelos do Bicep. O portal do Azure tem uma caixa de seleção para habilitar sem versão, que você pode usar para selecionar apenas o identificador de chave sem versão.

Limitações

Aqui estão as limitações atuais para configurar a chave gerenciada pelo cliente no servidor flexível do Banco de Dados do Azure para PostgreSQL:

Conteúdo relacionado