Encriptação de dados em repouso no Base de Dados do Azure para PostgreSQL flexible server

O servidor flexível Base de Dados do Azure para PostgreSQL encripta sempre todos os dados em repouso. Estes dados incluem todas as bases de dados do sistema e dos utilizadores, registos de servidores, segmentos de registo de escrita antecipada e backups. O armazenamento subjacente gere a encriptação através da encriptação do lado do servidor do Armazenamento de Discos do Azure.

Encriptação em repouso com chaves geridas de serviço (SMK) ou chaves geridas 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 o servidor flexível PostgreSQL.

Só pode selecionar o modo apenas no momento da criação do servidor. Não podes mudar o modo de um para outro durante toda a vida útil do servidor.

Para conseguir encriptação dos seus dados, o Base de Dados do Azure para PostgreSQL utiliza encriptação do Armazenamento do Azure para dados em repouso. Quando usa o CMK, é responsável por fornecer chaves para encriptar e desencriptar dados nos serviços Armazenamento de Blobs e Ficheiros do Azure. Deve armazenar estas chaves 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 usadas 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

Quando usa a chave de encriptação gerida pelo cliente, assume a responsabilidade. Deve implementar o 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 seu servidor flexível do Banco de Dados do Azure para PostgreSQL possa executar as ações necessárias na chave. Deve configurar todos os aspetos de rede do Azure Key Vault onde a chave está guardada, para que o seu servidor flexível Base de Dados do Azure para PostgreSQL possa aceder à 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 o servidor flexível 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 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 lista seguinte descreve os requisitos para configurar a encriptação de dados para o Base de Dados do Azure para PostgreSQL:

• Para configurações CMK de inquilino único, o Key Vault e o seu servidor flexível Base de Dados do Azure para PostgreSQL devem pertencer ao mesmo inquilino Microsoft Entra. Para cenários entre tenants, consulte Chaves geridas pelo cliente entre tenants. Mover o recurso Key Vault depois requer reconfigurar a encriptação dos dados.
• Defina a configuração Dias para reter cofres eliminados do Key Vault para 90 dias. Se configurou uma instância existente do Key Vault com um número mais baixo, ela continua válida. No entanto, se quiser modificar esta definição e aumentar o valor, deve criar uma nova instância do Key Vault. Depois de criada uma instância, não podes modificar essa definição.
• Ative a funcionalidade de eliminação suave no Key Vault para ajudar a proteger contra perda de dados caso uma chave ou uma instância do Key Vault seja eliminada 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 tiveres algum Key Vault, que foi implementado há muito tempo, pode ainda ter o soft-delete desativado. Nesse caso, podes ativá-lo usando CLI do Azure.
• Ative a proteção contra remoção para impor um período de retenção obrigatório para cofres e objetos de cofres eliminados.
• Atribua à identidade gerida atribuída pelo utilizador do servidor flexível do Base de Dados do Azure para PostgreSQL acesso à chave da seguinte forma:
• Preferencial: Configurar o Azure Key Vault com o modelo de permissões RBAC e atribuir à identidade gerida o papel de utilizador do Key Vault Crypto Service Encryption.
• 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: Recuperar as propriedades e a parte pública da chave no Key Vault.
• list: Para listar e percorrer as chaves armazenadas no Key Vault.
• 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. Use uma chave de 4.096 bits para maior 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

Pode configurar o CMK para a rotação manual de chaves e atualizações, ou para atualizações automáticas das versões da chave após uma rotação manual ou automática da chave no Key Vault.

Para mais informações, consulte Configurar encriptação de dados com chave gerida pelo cliente durante o provisionamento do servidor.

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

Quando configura o CMK com atualizações manuais de chaves, deve atualizar manualmente a versão da chave no Base de Dados do Azure para PostgreSQL flexible server após uma rotação manual ou automática de chaves no Key Vault. O servidor continua a usar a versão antiga da chave até a atualizares. Provisiona-se este modo especificando um URI-chave que inclui a versão GUID no URI. Por exemplo, https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Até há pouco tempo, esta opção era a única disponível.

Sempre que rotas manualmente a chave ou o AKV autorrota a chave com base na sua política de rotação, tinhas de atualizar a propriedade CMK no teu 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 da versão da chave

Para ativar atualizações automáticas de versões de chaves, utilize um URI de chave sem versão. Esta abordagem elimina a necessidade de atualizar a propriedade de versão do CMK no seu servidor PostgreSQL após uma rotação de chaves. O PostgreSQL identifica automaticamente a nova versão da chave e volta a encriptar a chave de encriptação dos dados. Esta abordagem simplifica significativamente a gestão do ciclo de vida das chaves, especialmente quando combinada com a rotação automática do Key Vault.

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

No portal, selecione a caixa de seleção para orientar a interface a suprimir os GUIDs de versão durante a seleção interativa e ao validar o URI.

Recommendations

Quando usar uma chave gerida pelo cliente para encriptação de dados, siga estas recomendações para configurar o Key Vault:

• Defina um bloqueio de recurso no Key Vault para evitar a eliminação acidental ou não autorizada deste recurso crítico.
• 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.

• 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 Key Vault pode desativar acidentalmente o acesso ao servidor da chave através de:

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

Monitorizar as chaves guardadas no Azure Key Vault

Para monitorizar o estado da base de dados e ativar alertas para a perda de acesso ao protetor de encriptação de dados, configure as seguintes funcionalidades 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.

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

Depois de encriptar o seu servidor flexível Base de Dados do Azure para PostgreSQL com uma chave gerida pelo cliente armazenada no Key Vault, qualquer cópia do servidor recém-criada também é encriptada. Você pode fazer essa nova cópia por meio de uma operação de restauração 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 restauro ou o processo de criação de uma réplica de leitura a partir do servidor flexível principal da base de dados Base 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. Neste momento, a revogação de chaves não é suportada depois de restaurar um servidor com chave gerida 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.

Quando estiver a criar um novo servidor flexível Base de Dados do Azure para PostgreSQL no portal Azure com a chave gerida pelo cliente, pode escolher o Azure Key Vault Managed HSM como armazenamento de chaves, como 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 de chave gerida pelo cliente inacessível

Quando configura a encriptação de dados com uma chave gerida pelo cliente armazenada no Key Vault, o servidor requer acesso contínuo a essa chave para se manter online. Se o servidor perder o acesso, muda o seu estado para Inacessível e começa a negar todas as ligações.

Algumas possíveis razões para o estado do servidor se tornar Inacessível incluem:

Recuperar da eliminação de identidade gerida

Se eliminar a identidade gerida atribuída pelo utilizador que acede à chave de encriptação armazenada no Key Vault no Microsoft Entra ID, siga estes passos para recuperar:

1. Recupere a identidade ou crie uma nova identidade gerenciada do Entra ID.
2. Se criaste uma nova identidade, mesmo que tenha exatamente o mesmo nome da identificação eliminada, atualiza a base de dados do Azure para obter propriedades flexíveis do servidor, para que saiba que tem de usar essa nova identidade para aceder à chave de encriptação.
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.

Use encriptação de dados com chaves geridas pelo cliente e funcionalidades de continuidade de negócio geo-redundantes

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. Aplicam-se os seguintes requisitos para a configuração da encriptação de dados com CMKs e estas funcionalidades, além dos requisitos básicos para encriptação de dados com CMKs:

• Tens de criar a chave de encriptação de backup geo-redundante numa instância do Key Vault que deve existir na região onde o backup geo-redundante 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, crie a identidade gerida pelo utilizador na mesma região das cópias de segurança geo-redundantes.
• Se configurar uma base de dados de réplica de leitura para ser encriptada com CMKs aquando da criação, a respetiva chave de encriptação tem de estar numa instância do Key Vault na região onde se encontra a base de dados de réplica de leitura. Tem de criar a identidade atribuída pelo utilizador para se autenticar nesta instância do Key Vault na mesma região.

Chaves geridas pelo cliente entre inquilinos (CMK) (pré-visualização)

As chaves geridas pelo cliente entre tenants permitem utilizar chaves de encriptação armazenadas no Azure Key Vault ou numa instância de HSM Gerido que pertence a um Microsoft Entra ID diferente do Base de Dados do Azure para PostgreSQL – Servidor Flexível. A configuração de CMK entre locatários requer uma configuração adicional e coordenação entre os locatários. No cenário entre tenants, o recurso Base de Dados do Azure para PostgreSQL está localizado num tenant gerido por um Fornecedor Independente de Software (ISV), referido como prestador de serviços. A chave usada para a encriptação do recurso Base de Dados do Azure para PostgreSQL reside num cofre de chaves num tenant diferente que o cliente gere.

Visão geral da configuração

No locatário ISV

• Criar um aplicativo multilocatário

  • Configurar a identidade gerida atribuída pelo utilizador como uma credencial federada na aplicação

No do locatário do cliente

1. Instalar o aplicativo multilocatário

2. Crie ou use o cofre de chaves existente ou HSM gerido e conceda permissões de chave à aplicação multitenant

   1. Criar uma chave nova ou usar uma chave existente

   2. Recupere a chave do Cofre de Chaves do Azure 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, pode criar um servidor do Base de Dados do Azure para PostgreSQL no tenant do fornecedor de serviços e configurar chaves geridas pelo cliente utilizando a chave do tenant do cliente.

Ao criar um servidor Base de Dados do Azure para PostgreSQL com chaves geridas pelo cliente, deve garantir que tem acesso às chaves que o cliente utilizou. Em cenários de inquilino único, dá acesso direto ao cofre de chaves à identidade gerida pelo utilizador do servidor Base de Dados do Azure para PostgreSQL. Num cenário entre tenants, deixa de poder contar com o acesso direto ao cofre de chaves, uma vez que este se encontra noutro tenant gerido pelo cliente. Esta restrição é a razão pela qual criou uma aplicação cross-tenant e registou uma identidade gerida dentro da aplicação para lhe dar acesso ao cofre de chaves do cliente nas secções anteriores. Esta identidade gerida, juntamente com o ID de aplicação cross-ten, é o que se usa ao criar a CMK cross-tenant para o servidor Base de Dados do Azure para PostgreSQL.

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

Utilize o portal do Azure

Para configurar chaves geridas pelo cliente entre inquilinos para um novo servidor do Base de Dados do Azure para PostgreSQL no portal do Azure, siga estes passos:

1. No Base de Dados do Azure para PostgreSQL criar recurso, selecione o separador Security no portal Azure, e depois selecione Chave gerida pelo cliente.

2. Atribua a identidade gerida atribuída pelo utilizador criada à Identidade gerida atribuída pelo utilizador.

3. Atribua a aplicação multitenant utilizando o nome da aplicação.

4. Introduza um identificador de chave no método de Seleção de Chaves usando o identificador de chave do cliente obtido junto do inquilino cliente.

Utilize modelos JSON do Azure Resource Manager e a API REST

Implante um modelo 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 do pedido:

{
"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 do PATCH atualiza apenas o URI da chave CMK para rodar a chave de encriptação 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 do pedido (exemplo de rotação da chave):

{
    "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 das chaves geridas pelo cliente (CMK) entre locatários

• O Azure PowerShell e o CLI do Azure ainda não suportam esta funcionalidade.
• A criação de um servidor com cópias de segurança com redundância geográfica e a ativação de operações de cópia de segurança com retenção de longo prazo não são atualmente suportados.
• A pré-visualização é atualmente suportada apenas nestas regiões:
  • E.U.A. Leste 2
  • E.U.A. Oeste 2
  • E.U.A. Central
  • Austrália Sudeste
  • Leste da Austrália
  • Europa do Norte

Limitações das chaves geridas pelo cliente (CMK)

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

• Pode configurar a encriptação de chaves geridas pelo cliente apenas durante a criação de um novo servidor, não como uma atualização de um servidor flexível existente no Base de Dados do Azure para PostgreSQL. Em vez disso, pode restaurar um backup PITR para um novo servidor com encriptação 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 onde planeia armazenar a chave de encriptação deve existir na mesma região onde está a criar a base de dados Azure para servidor flexível.

Conteúdo relacionado

• Configurar a encriptação de dados na Base de Dados do Azure para PostgreSQL