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 todas as bases de dados de sistema e de utilizador, registos do servidor, segmentos de registo write-ahead e cópias de segurança. A criptografia é efetuada pelo armazenamento subjacente através de encriptação do lado do servidor do Armazenamento de Discos 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 encriptação gerida pelo cliente , assumes 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:

• Para configurações CMK de inquilino único, o Key Vault e a sua instância de servidor flexível do 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 Cofre da Chave depois requer que você reconfigure a criptografia de dados.
• Recomendamos que defina a configuração Dias para manter cofres eliminados do Key Vault 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 tiveres algum Key Vault, que foi implementado há muito tempo, pode ainda ter o soft-delete desativado. Nesse caso, você pode ativá-lo usando a 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.
• 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: 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. 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 manual de chaves e atualizações, ou com atualizações automáticas da versão da chave 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.

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 continua a usar a versão antiga da chave até a atualizares. 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 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 na tua 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 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 na sua instância PostgreSQL após uma rotação de chave. O PostgreSQL identifica automaticamente a nova versão da chave e volta a encriptar a chave de encriptação dos dados. Isto simplifica significativamente a gestão do ciclo de vida das chaves, especialmente quando combinado com a autorrotação do Key Vault.

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

No portal, selecione a caixa de seleção para guiar a interface a suprimir os 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.

• 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 permissões de acesso suficientes ao Key Vault pode, acidentalmente, desativar 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.

Monitorizar as chaves guardadas 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.

Restaurar backups de um servidor configurado com uma chave gerida 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 restauro ou o processo de criação de uma réplica de leitura a partir da instância principal do servidor flexível 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. 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 de chave gerida 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:

Recuperar da eliminação de identidade gerida

Se a identidade gerida atribuída pelo utilizador usada para aceder à chave de encriptação armazenada no Key Vault for eliminada no Microsoft Entra ID, deverá seguir estes passos para recuperar o acesso:

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.

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. 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 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. A identidade atribuída pelo usuário para autenticação nessa instância do Cofre da Chave precisa ser criada 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 num Key Vault ou numa instância de HSM Gerido que pertence a um Microsoft Entra ID diferente do da sua instância do servidor flexível do Base de Dados do Azure para PostgreSQL. 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 uma instância do Base de Dados do Azure para PostgreSQL no tenant do fornecedor de serviços e configurar chaves geridas pelo cliente com a chave do tenant do cliente.

Ao criar uma instância do Base de Dados do Azure para PostgreSQL com chaves geridas pelo cliente, deve garantir que a instância tem acesso às chaves que o cliente utilizou. Em cenários de locatário único, concede acesso direto ao cofre de chaves à identidade gerida atribuída pelo utilizador da instância do 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 entre inquilinos, é o que se usa ao criar a CMK entre inquilinos para a instância Base de Dados do Azure para PostgreSQL.

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

Utilize o portal do Azure

Para configurar chaves geridas pelo cliente entre tenants para uma nova instância 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

• Esta funcionalidade ainda não é suportada no Azure PowerShell ou no CLI do Azure.
• 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 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 a encriptação de dados na Base de Dados do Azure para PostgreSQL