Criptografia de dados em repouso no Banco de Dados do Azure para PostgreSQL

Todos os dados gerenciados por uma instância de 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, logs do servidor, segmentos de log write-ahead e backups. A criptografia é tratada pelo armazenamento subjacente por meio da criptografia do lado do servidor do Armazenamento em Disco do Azure.

Criptografia em repouso com serviço (SMK) ou chaves gerenciadas pelo cliente (CMK)

O Banco de Dados do Azure para PostgreSQL dá suporte a dois modos de criptografia de dados em repouso: chaves gerenciadas de serviço (SMK) e chaves gerenciadas pelo cliente (CMK). A criptografia de dados com chaves gerenciadas de serviço é o modo padrão para o Banco de Dados do Azure para servidor flexível 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. Este modo dá-lhe mais controlo sobre o processo de encriptação, mas também requer que faça a gestão das chaves de encriptação por conta própria. Você deve implantar seu próprio Azure Key Vault ou Azure Key Vault Managed Hardware Security Module (HSM) e configurá-lo para armazenar as chaves de criptografia usadas pelo seu Banco de Dados do Azure para instância de servidor flexível PostgreSQL.

O modo 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 Banco de Dados do Azure para PostgreSQL usa a criptografia do Armazenamento do Azure para dados em repouso. Ao usar a CMK, o cliente é responsável por fornecer chaves para criptografar e descriptografar dados nos serviços de Armazenamento de Blob e Arquivos do Azure. Essas chaves devem ser armazenadas no Azure Key Vault ou no Azure Key Vault Managed Hardware Security Module (HSM). Para obter mais informações, consulte chaves gerenciadas pelo cliente para criptografia de Armazenamento do Azure.

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

A criptografia de dados com chaves gerenciadas de serviço para o Banco de Dados do Azure para PostgreSQL fornece os seguintes benefícios:

• O serviço controla automática e totalmente o acesso aos dados.
• O serviço controla automática e totalmente o ciclo de vida da sua chave, incluindo a rotação da mesma.
• Você não precisa se preocupar com o gerenciamento de chaves de criptografia de dados.
• A criptografia de dados baseada em chaves gerenciadas pelo serviço não afeta negativamente o desempenho de suas cargas de trabalho.
• Simplifica a gestão das chaves de encriptação (incluindo a sua rotação regular) e a gestão das identidades utilizadas para aceder a essas chaves.

A criptografia de dados com chaves gerenciadas pelo cliente para o Banco de Dados do Azure para PostgreSQL oferece os seguintes benefícios:

• Você controla totalmente o acesso aos 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 alinhá-la com as políticas corporativas.
• Você pode gerenciar e organizar centralmente todas as suas chaves de criptografia em suas próprias instâncias do Cofre de Chaves do Azure.
• A criptografia de dados com base 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 de sistema.

Requisitos 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 sua própria chave. Você deve conceder as permissões necessárias no Cofre da Chave, para que sua instância de 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 aspetos de rede do Cofre da Chave do Azure no qual a chave é mantida, para que sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL possa acessar a chave. Auditar o acesso à chave também é sua responsabilidade. Finalmente, você é responsável por girar a chave e, quando necessário, atualizar a configuração do seu Banco de Dados do Azure para a instância flexível do servidor PostgreSQL para que ela faça referência à versão girada da chave.

Quando você configura chaves gerenciadas pelo cliente para uma conta de armazenamento, o Armazenamento do Azure encapsula a chave de criptografia de dados raiz (DEK) da conta com a chave gerenciada pelo cliente no cofre de chaves associado ou no HSM gerenciado. A proteção da chave de criptografia raiz muda, mas os dados em sua conta de Armazenamento do Azure permanecem sempre criptografados. Não é necessária nenhuma ação extra da sua parte para garantir que os seus dados permaneçam encriptados. 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. É altamente disponível e fornece armazenamento escalável e seguro para chaves criptográficas RSA, opcionalmente apoiado por módulos de segurança de hardware (HSMs) validados FIPS 140 . Não permite o acesso direto a uma chave armazenada, mas fornece serviços de encriptação e desencriptação a entidades autorizadas. O Cofre de Chaves pode gerar a chave, importá-la ou recebê-la transferida de um dispositivo HSM local.

A seguir está a lista de requisitos para configurar a criptografia de dados para o Banco de Dados do Azure para PostgreSQL:

• O Key Vault e a sua instância de servidor flexível do Azure Database para PostgreSQL devem pertencer ao mesmo locatário do Microsoft Entra. Não há suporte para o Cofre da Chave entre locatários e interações de servidor. Mover o recurso Cofre da Chave depois requer que você reconfigure a criptografia de dados.
• Recomendamos que você defina a configuração Dias para manter cofres excluídos para o Cofre de Chaves para 90 dias. Se você configurou uma instância existente do Cofre da Chave com um número menor, ela ainda deverá ser válida. No entanto, se você deseja modificar essa configuração e aumentar o valor, é necessário criar uma nova instância do Cofre da Chave. Depois que uma instância é criada, não é possível modificar essa configuração.
• Habilite o recurso de exclusão suave no Cofre de Chaves para ajudá-lo a se proteger contra perda de dados, se uma chave ou uma instância do Cofre de Chaves for excluída acidentalmente. O Key Vault retém recursos excluídos por 90 dias, a menos que o usuário os recupere ou limpe enquanto isso. As ações de recuperação e limpeza têm suas próprias permissões associadas a um Cofre de Chaves, uma função RBAC ou uma permissão de política de acesso. O recurso de exclusão suave está ativado por padrão. Se você tiver algum Cofre de Chaves que foi implantado há muito tempo, ele ainda pode ter a exclusão suave desabilitada. Nesse caso, você pode ativá-lo usando a CLI do Azure.
• Habilite a proteção contra limpeza para impor um período de retenção obrigatório para cofres e objetos do cofre excluídos.
• Conceda ao Banco de Dados do Azure para PostgreSQL acesso de identidade gerenciada atribuída pelo usuário à chave da instância do servidor flexível por:
• Preferido: o Cofre de Chaves do Azure deve ser configurado com o modelo de permissão RBAC e a identidade gerida deve receber a função Utilizador de Encriptação do Serviço de Cripto do Cofre de Chaves.
• Legado: Se o Cofre da Chave do Azure estiver configurado com o modelo de permissão de política de acesso, conceda as seguintes permissões à identidade gerenciada:
• get: Para recuperar as propriedades e a parte pública da chave no Cofre da Chave.
• list: Para listar e iterar através das chaves armazenadas no Cofre de Chaves.
• wrapKey: Para criptografar a chave de criptografia de dados.
• unwrapKey: Para desencriptar a chave de encriptação de dados.
• A chave usada para criptografar a chave de criptografia de dados pode ser apenas assimétrica, RSA ou RSA-HSM. São suportados tamanhos de chave de 2.048, 3.072 e 4.096. Recomendamos o uso de uma chave de 4.096 bits para melhor segurança.
• A data e a hora para a ativação da chave (se definidas) devem estar no passado. A data e a hora de expiração (se definidas) devem ser no futuro.
• A chave deve estar no estado Habilitado .
• Se estiver a importar uma chave existente para o Cofre da Chave, forneça-a nos formatos de ficheiro suportados (.pfx, .byokou .backup).

Atualizações da versão da chave CMK

A CMK pode ser configurada com rotação e atualizações manuais de chaves ou com atualizações automáticas de versão de chaves após uma rotação manual ou automática de chaves no Cofre de Chaves.

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

Importante

Ao girar a chave para uma nova versão, você deve manter a chave antiga disponível para que a recriptografia seja bem-sucedida. Embora a maioria das reencriptações deva acontecer dentro de 30 minutos, recomendamos que aguarde pelo menos 2 horas antes de desativar o acesso à versão antiga da chave.

Rotação manual de chaves e atualizações

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

Sempre que você gira manualmente a chave ou AKV gira automaticamente a chave com base em sua política de rotação, você tem que atualizar a propriedade CMK em sua instância 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 da versão da chave

Para habilitar as 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 version da 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 criptografará novamente a chave de criptografia de dados. Esta é uma grande simplificação no gerenciamento do ciclo de vida da sua chave, especialmente quando combinada com a rotação automática do Key Vault.

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

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

Recommendations

Quando estiver a utilizar uma chave gerida pelo cliente para encriptação de dados, siga estas recomendações para configurar o Cofre de Chaves:

• Para evitar a exclusão acidental ou não autorizada desse recurso crítico, defina um bloqueio de recurso no Cofre da Chave.
• 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 ferramentas de gerenciamento de eventos e informações de segurança (SIEM). O Azure Monitor Logs é um exemplo de um serviço que já está integrado.
• Bloqueie o Cofre da Chave selecionando Desativar acesso público e Permitir que serviços confiáveis da Microsoft ignorem esse firewall.
• Habilite as atualizações automáticas da versão da chave.

Observação

Depois de selecionar Desativar acesso público e Permitir que serviços fidedignos da Microsoft ignorem esta firewall, poderá receber um erro semelhante ao seguinte quando tentar utilizar o acesso público para administrar o Cofre da Chave através do portal: "Ativou o controlo de acesso à rede. Apenas as redes permitidas têm acesso a este cofre de chaves." Este erro não impede a capacidade de fornecer chaves durante a configuração de chaves gerenciadas pelo cliente ou buscar chaves do Cofre de Chaves durante as operações do servidor.

• 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.

Considerações especiais

Revogação acidental do acesso a chaves no Cofre de Chaves do Azure

Alguém com direitos de acesso suficientes ao Cofre da Chave pode desativar acidentalmente o acesso do servidor à chave ao:

• Cancelar a atribuição da função RBAC Key Vault Crypto Service Encryption User ou revogar as permissões da identidade usada para recuperar a chave no Key Vault.
• Eliminando a chave.
• Eliminando a instância do Cofre de Chaves.
• Alterar as regras de firewall do Cofre da Chave.
• Excluindo a identidade gerenciada do servidor no Microsoft Entra ID.

Monitorando as chaves mantidas no Azure Key Vault

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

• Integridade do recurso: um banco de dados que perdeu o acesso à CMK aparece como Inacessível depois que a primeira conexão com o banco de dados é negada.
• Registro de atividades: quando o acesso à CMK na instância do Cofre de Chaves gerenciada pelo cliente falha, as entradas são adicionadas ao registro de atividades. Você pode restabelecer o acesso se criar alertas para esses eventos o mais rápido possível.
• Grupos de ação: defina esses grupos para receber notificações e alertas com base em suas preferências.

Restaurando backups de um servidor configurado com uma chave gerenciada pelo cliente

Depois que sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL for criptografada com uma chave gerenciada pelo cliente armazenada no Cofre da Chave, qualquer cópia de servidor recém-criada também será criptografada. Você pode fazer essa nova cópia por meio de uma operação de restauração point-in-time (PITR) ou ler réplicas.

Ao configurar a criptografia de dados com chave gerenciada pelo cliente, durante operações como restauração de um backup ou criação de uma réplica de leitura, você pode evitar problemas seguindo estas etapas nos servidores primário e restaurado 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 de servidor flexível principal do Banco de Dados do Azure para PostgreSQL.
• No servidor restaurado ou de réplica, você pode alterar a chave gerenciada pelo cliente e a identidade gerenciada atribuída ao usuário usada para acessar o Cofre da Chave. Verifique se a identidade atribuída no servidor recém-criado tem as permissões necessárias no Cofre da Chave.
• Não revogue a chave original após a restauração. No momento, não oferecemos suporte à revogação de chaves depois que você restaura um servidor com chave gerenciada pelo cliente para outro servidor.

HSMs gerenciados

Os módulos de segurança de hardware (HSMs) são dispositivos de hardware invioláveis que ajudam a proteger processos criptográficos gerando, protegendo e gerenciando chaves usadas para criptografar dados, descriptografar dados, criar assinaturas digitais 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 Common Criteria.

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

Ao criar novas instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL no portal do Azure com a chave gerenciada pelo cliente, você pode escolher o Azure Key Vault Managed HSM como um armazenamento de chaves, como uma alternativa ao Azure Key Vault. Os pré-requisitos, em termos de identidade e permissões definidas pelo usuário, são os mesmos do Cofre da Chave do Azure (conforme listado anteriormente neste artigo). Para obter mais informações sobre como criar uma instância do HSM gerenciado, suas vantagens e diferenças de um armazenamento de certificados compartilhado baseado no Cofre de Chaves e como importar chaves para o HSM gerenciado, consulte O que é o HSM gerenciado do Azure Key Vault?.

Condição chave gerenciada pelo cliente inacessível

Quando você configura a criptografia de dados com uma chave gerenciada pelo cliente armazenada no Cofre da Chave, 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 muda seu estado para Inacessível e começa a negar todas as conexões.

Algumas das possíveis razões pelas quais o estado do servidor pode se tornar Inacessível são:

Motivo	Resoluçã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.	Tem de prolongar a data de validade da chave. Em seguida, você deve aguardar que o serviço revalide a chave e faça a transição automática do estado do servidor para Pronto. Somente quando o servidor estiver de volta ao estado Pronto , você poderá girar a chave para uma versão mais recente ou criar uma nova chave e atualizar o servidor para que ele se refira a essa nova versão da mesma chave ou à nova chave.
Você gira a chave e esquece de atualizar a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL para que ela aponte 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 essa situação, 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 apenas atualizará a chave/identidade.". Se preferir atualizá-lo usando a API, você pode invocar o ponto de extremidade Servidores - Atualização do serviço.
Você exclui a instância do Cofre da Chave, a instância flexível do servidor do Banco de Dados do Azure para PostgreSQL não pode acessar a chave e se move para um estado Inacessível .	Recupere a instância do Cofre da Chave 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, do Microsoft Entra ID, uma identidade gerenciada que é usada para recuperar qualquer uma das chaves de criptografia armazenadas no Cofre da Chave.	Recupere a identidade e aguarde 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.
Seu modelo de permissão do Cofre da Chave está configurado para usar o controle de acesso baseado em função. Você remove a atribuição da função RBAC do Usuário do Serviço de Criptografia do Key Vault das identidades geridas que estão configuradas para obter 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 Cofre da Chave 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 Cofre da Chave está configurado para usar políticas de acesso. Você revoga as políticas de acesso list, get, wrapKey ou 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 Cofre da Chave 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 Cofre de Chaves excessivamente restritivas, para que sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL não possa se comunicar com o Cofre de Chaves para recuperar suas chaves.	Ao configurar um firewall do Cofre da Chave, certifique-se de selecionar a opção para permitir serviços confiáveis da Microsoft para que sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL possa ignorar o firewall.

Observação

Quando uma chave é desativada, excluída, expirada ou inacessível, um servidor que tem dados criptografados com essa chave torna-se Inacessível, como dito anteriormente. O estado do servidor não muda para Pronto novamente até que possa revalidar as chaves de criptografia.

Geralmente, um servidor torna-se Inacessível dentro de 60 minutos depois que uma chave é desativada, excluída, expirada ou inacessível. Depois que a chave ficar disponível, o servidor pode levar até 60 minutos para ficar pronto novamente.

Recuperando-se da exclusão de identidade gerenciada

Se o usuário atribuído identidade gerenciada usada para acessar a chave de criptografia armazenada no Cofre da Chave for excluído no ID do Microsoft Entra, você deverá seguir estas etapas para recuperar:

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 o Banco de Dados do Azure para propriedades flexíveis da instância do servidor 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 Cofre de Chaves do Azure (AKV).
4. Aguarde cerca de uma hora até que o servidor revalide a chave.

Importante

A criação simples de uma nova identidade de ID do Entra com o mesmo nome da identidade apagada não restaura a identidade gerida eliminada.

Usando 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 dá suporte a recursos avançados de recuperação de dados , como réplicas e backup com redundância geográfica. A seguir estão os requisitos para configurar a criptografia de dados com CMKs e esses recursos, além dos requisitos básicos para criptografia de dados com CMKs:

• A chave de criptografia de backup com redundância geográfica precisa ser criada em uma instância do Cofre de Chaves que deve existir na região onde o backup com redundância geográfica está armazenado.
• A versão da API REST do Azure Resource Manager para dar suporte a servidores CMK habilitados para backup com redundância geográfica é 2022-11-01-preview. Se você quiser usar modelos do Azure Resource Manager para automatizar a criação de servidores que usam criptografia com CMKs e recursos de backup com redundância geográfica, use esta versão da API.
• Não é possível usar a mesma identidade gerenciada pelo usuário para autenticar a instância do Cofre da Chave do banco de dados primário e a instância do Cofre da Chave que contém a chave de criptografia para 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 Cofre da Chave na região onde reside o banco de dados de réplica de leitura. A identidade atribuída pelo usuário para autenticação nessa instância do Cofre da Chave precisa ser criada na mesma região.

Limitações

Estas são as limitações atuais para configurar a chave gerenciada pelo cliente em uma instância de 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 de servidor flexível existente do Banco de Dados do Azure para PostgreSQL. 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, não é possível reverter para a chave gerenciada pelo sistema. Se você quiser reverter, você deve restaurar o servidor para um novo com criptografia de dados configurada com chave gerenciada pelo sistema.
• A instância do Azure Key Vault Managed HSM ou a instância do Azure Key Vault na qual você planeja armazenar a chave de criptografia deve existir na mesma região na qual a instância do Banco de Dados do Azure para servidor flexível está sendo criada.

Conteúdo relacionado

• Configurar criptografia de dados