Criptografia de dados em repouso no servidor flexível do Azure Database para PostgreSQL

O Servidor Flexível do Banco de Dados do Azure para PostgreSQL sempre criptografa todos os dados em repouso. Esses dados incluem todos os bancos de dados do sistema e do usuário, logs de servidor, segmentos de log de gravação antecipada e backups. O armazenamento subjacente faz o gerenciamento da criptografia por meio de criptografia no servidor do Armazenamento em Disco do Azure.

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

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

Você pode selecionar o modo somente no momento da criação do servidor. Você não pode alterar o modo de um para outro durante o tempo de vida do servidor.

Para obter a criptografia de seus dados, Banco de Dados do Azure para PostgreSQL usa a criptografia Armazenamento do Azure para dados em repouso. Ao usar o CMK, você é responsável por fornecer chaves para criptografar e descriptografar dados em serviços de Armazenamento de Blobs e Arquivos do Azure. Você deve armazenar essas chaves em Azure Key Vault ou Azure Key Vault HSM (Managed Hardware Security Module). 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 de serviço para o 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.
• Ele 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 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

Ao usar a chave de criptografia gerenciada pelo cliente, você assume a responsabilidade. Você deve implantar sua própria Azure Key Vault ou Azure Key Vault HSM. Você deve gerar ou importar a sua própria chave. Você deve conceder 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ê deve configurar todos os aspectos de rede do Azure Key Vault em que a chave é mantida, para que seu servidor Banco de Dados do Azure para PostgreSQL flexível 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 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 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.

A lista a seguir descreve os requisitos para configurar a criptografia de dados para Banco de Dados do Azure para PostgreSQL:

• Para configurações de CMK de locatário único, o Key Vault e o seu servidor flexível do Banco de Dados do Azure para PostgreSQL devem pertencer ao mesmo locatário do Microsoft Entra. Para cenários entre locatários, consulte Chaves gerenciadas pelo cliente entre locatários. Mover o recurso Key Vault depois requer a reconfiguração da criptografia de dados.
• Defina a configuração Dias de retenção de cofres excluídos do Key Vault para 90 dias. Se você configurou uma instância de Key Vault existente com um número menor, ela permanecerá válida. No entanto, se você quiser modificar essa configuração e aumentar o valor, deverá criar uma nova instância Key Vault. Depois que uma instância é criada, você não pode modificar essa configuração.
• Habilite o recurso de exclusão reversível em Key Vault para ajudar a proteger contra perda de dados se uma chave ou uma instância de 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 temporária desabilitada. Nesse caso, você pode ativá-lo usando 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 fazendo o seguinte:
• Preferencialmente: configure o Azure Key Vault com o modelo de permissões RBAC e atribua à identidade gerenciada a função Key Vault Crypto Service Encryption User.
• Herdado: se o Azure Key Vault 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 Key Vault.
• list: para listar e iterar por meio das chaves armazenadas no Key Vault.
• wrapKey: para criptografar a chave de criptografia de dados.
• unwrapKey: para descriptografar a chave de criptografia de dados.
• 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. Use 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

Você pode configurar o CMK para rotação manual de chaves e atualizações ou para 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 mais informações, 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 da 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 da chave no Key Vault. O servidor continua a usar a versão da chave antiga até que você a atualize. Você provisiona esse modo especificando um URI de chave que inclui a versão GUID no URI. Por exemplo, https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Até recentemente, essa opção era a única opção disponível.

Sempre que você girava manualmente a chave ou o AKV fazia a rotação automática da chave com base em sua política de rotação, era necessário atualizar a propriedade CMK no seu servidor 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. Essa abordagem elimina a necessidade de atualizar a propriedade de versão do CMK no servidor PostgreSQL após uma rotação de chave. O PostgreSQL automaticamente pega a nova versão da chave e reenscriptografa a chave de criptografia de dados. Essa abordagem simplifica significativamente o gerenciamento do ciclo de vida das chaves, especialmente quando combinada com a rotação automática do Key Vault.

Para implementar essa abordagem usando Azure Resource Manager, Bicep, Terraform, Azure PowerShell ou CLI do Azure, omita a versão GUID do seu URI de chave.

No portal, marque a caixa de seleção para fazer com que a interface do usuário suprima os GUIDs de versão durante a seleção interativa e ao validar o URI.

Recommendations

Ao usar uma chave gerenciada pelo cliente para criptografia de dados, siga estas recomendações para configurar Key Vault:

• Defina um bloqueio de recurso em Key Vault para evitar a exclusão acidental ou não autorizada desse 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.
• Habilitar atualizações automáticas de versão da chave.

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

Monitorar as 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 de 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.

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

Depois de criptografar o servidor Banco de Dados do Azure para PostgreSQL flexível com uma chave gerenciada pelo cliente armazenada em Key Vault, 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 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 de criação de uma réplica de leitura a partir do servidor flexível primário 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 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 um novo servidor flexível do Banco de Dados do Azure para PostgreSQL no portal do Azure com chave gerenciada pelo cliente, você pode escolher Azure Key Vault Managed HSM como armazenamento de chaves, como 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 em Key Vault, o servidor requer acesso contínuo a essa chave para permanecer online. Se o servidor perder o acesso, ele alterará seu estado para Inacessível e começará a negar todas as conexões.

Alguns possíveis motivos para o estado do servidor se tornar Inacessível incluem:

Recuperar-se da exclusão de identidade gerenciada

Se você excluir a identidade gerenciada atribuída pelo usuário que acessa a chave de criptografia armazenada em Key Vault no Microsoft Entra ID, siga estas etapas para recuperar:

1. Recupere a identidade ou crie uma identidade gerenciada do Entra ID.
2. Se você criou uma nova identidade, mesmo que ela tenha exatamente o mesmo nome que a identidade excluída, atualize o Banco de Dados Azure para propriedades de servidor flexíveis 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.

Usar a 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. Os requisitos a seguir se aplicam à configuração da criptografia de dados com CMKs e esses recursos, além dos requisitos básicos de criptografia de dados com CMKs:

• Você precisa criar a chave de criptografia de backup com redundância geográfica em uma instância de 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, crie a identidade gerenciada pelo usuário na mesma região que os 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. Você precisa criar a identidade atribuída pelo usuário para se autenticar nessa instância Key Vault na mesma região.

Chaves gerenciadas pelo cliente entre locatários (CMK) (versão preliminar)

As chaves gerenciadas pelo cliente entre locatários permitem que você use chaves de criptografia armazenadas em um Key Vault ou em uma instância de HSM Gerenciado que pertence a um Microsoft Entra ID diferente do servidor flexível do Banco de Dados do Azure para PostgreSQL. A configuração de CMK entre locatários requer configuração adicional e coordenação entre os locatários. No cenário entre locatários, o recurso Banco de Dados do Azure para PostgreSQL reside em um locatário gerenciado por um ISV (Fornecedor Independente de Software) conhecido como o provedor de serviços. A chave usada para criptografia do recurso Banco de Dados do Azure para PostgreSQL reside em um cofre de chaves em um locatário diferente que o cliente gerencia.

Visão geral da configuração

No locatário ISV

• Criar um aplicativo multitenant

  • Configure a identidade gerenciada atribuída pelo usuário como uma credencial federada no aplicativo

No locatário do cliente

1. Instalar o aplicativo multilocatário

2. Crie ou use o cofre de chaves ou o HSM gerenciado existente e conceda permissões de chave ao aplicativo multilocatário

   1. Crie uma chave ou use uma chave existente

   2. Recupere a chave do Azure Key Vault ou do HSM Gerenciado do Azure e registre o Identificador de Chave

No locatário ISV

Até este ponto, você configurou o aplicativo multilocatário no locatário do provedor de serviços. Você também instalou o aplicativo no locatário do cliente e configurou o cofre de chaves e a chave no locatário do cliente. Em seguida, você pode criar um servidor Banco de Dados do Azure para PostgreSQL no locatário do provedor de serviços e configurar chaves gerenciadas pelo cliente com a chave do locatário do cliente.

Ao criar um servidor Banco de Dados do Azure para PostgreSQL com chaves gerenciadas pelo cliente, você deve garantir que ele tenha acesso às chaves usadas pelo cliente. Em cenários de tenant único, você concede acesso direto ao cofre de chaves à identidade gerenciada atribuída pelo usuário do servidor do Banco de Dados do Azure para PostgreSQL. Em um cenário entre locatários, você não pode mais depender do acesso direto ao cofre de chaves porque ele está em outro locatário gerenciado pelo cliente. Essa restrição explica por que você criou um aplicativo multilocatário e registrou uma identidade gerenciada no aplicativo para conceder acesso ao cofre de chaves do cliente nas seções anteriores. Essa identidade gerenciada, juntamente com a ID do aplicativo entre locatários, é o que você usa ao criar o CMK entre locatários para o servidor Banco de Dados do Azure para PostgreSQL.

Sempre que uma nova versão da chave estiver disponível no cofre de chaves, o servidor Banco de Dados do Azure para PostgreSQL automaticamente pegará a nova versão.

Usar o portal do Azure

Para configurar chaves gerenciadas pelo cliente entre locatários para um novo servidor Banco de Dados do Azure para PostgreSQL no portal Azure, siga estas etapas:

1. Na criação do recurso no Banco de Dados do Azure para PostgreSQL, selecione a guia Segurança no portal do Azure e, em seguida, selecione Chave gerenciada pelo cliente.

2. Atribua a identidade gerenciada atribuída ao usuário criada como Identidade gerenciada atribuída ao usuário.

3. Atribua o aplicativo multilocatário usando o nome do aplicativo.

4. Insira um identificador de chave no método Seleção de Chave usando o Identificador de Chave do cliente obtido do locatário do cliente.

Use modelos JSON do Azure Resource Manager e a API REST

Implante um modelo do ARM com os seguintes parâmetros específicos:

Aqui está um exemplo de uma API REST com os três parâmetros configurados:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Exemplo do corpo da solicitação:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Aqui está um exemplo de uma API REST para rotação de chaves. O exemplo patch atualiza apenas o URI da chave CMK para girar a chave de criptografia sem recriar o servidor.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Corpo da solicitação (exemplo de chave girada):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Limitações da versão preliminar de chaves gerenciadas pelo cliente (CMK) entre locatários

• Azure PowerShell e CLI do Azure ainda não dão suporte a esse recurso.
• Atualmente, não há suporte para a criação de um servidor com backups geograficamente redundantes nem para a habilitação de operações de backup com retenção de longo prazo.
• No momento, há suporte para a versão prévia apenas nessas regiões:
  • Leste dos EUA 2
  • Oeste dos EUA 2
  • Centro dos EUA
  • Sudeste da Austrália
  • Leste da Austrália
  • Europa Setentrional

Limitações de CMK (chaves gerenciadas pelo cliente)

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 um servidor flexível 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 em que você planeja armazenar a chave de criptografia deve existir na mesma região em que você está criando o Servidor Flexível do Banco de Dados do Azure.

Conteúdo relacionado

• Configurar a criptografia de dados no Banco de Dados do Azure para PostgreSQL