Criptografia de dados com uma chave gerenciada pelo cliente no Banco de Dados do Azure para PostgreSQL - Servidor Flexível

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

O servidor flexível do Banco de Dados do Azure para PostgreSQL usa a criptografia do Armazenamento do Azure para criptografar dados em repouso por padrão, usando chaves gerenciadas pela Microsoft. Para usuários do Banco de Dados do Azure para servidor flexível PostgreSQL, é semelhante à criptografia de dados transparente em outros bancos de dados, como o SQL Server.

Muitas organizações exigem controle total de acesso aos dados usando uma chave gerenciada pelo cliente (CMK). A criptografia de dados com CMKs para o servidor flexível do Banco de Dados do Azure para PostgreSQL permite que você coloque sua chave (BYOK) para proteção de dados em repouso. Também permite às organizações implementarem a separação de deveres na gestão das chaves e dos dados. Com a criptografia CMK, você é responsável e tem controle total do ciclo de vida de uma chave, das permissões de uso da chave e da auditoria das operações nas chaves.

A criptografia de dados com CMKs para o servidor flexível do Banco de Dados do Azure para PostgreSQL é definida no nível do servidor. Para um servidor específico, um tipo de CMK chamado chave de criptografia de chave (KEK) é usado para criptografar a chave de criptografia de dados (DEK) do serviço. O KEK é uma chave assimétrica armazenada em uma instância do Cofre de Chaves do Azure de propriedade e gerenciada pelo cliente. O KEK e o DEK são descritos com mais detalhes mais adiante neste artigo.

O 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 transferi-la de um dispositivo HSM local.

Benefícios

A criptografia de dados com CMKs para o servidor flexível do 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 chaves centralmente no Cofre da Chave.

• Ativar a criptografia não afeta o desempenho com ou sem CMKs, porque o PostgreSQL depende da camada de Armazenamento do Azure para criptografia de dados em ambos os cenários. A única diferença é que, quando você usa uma CMK, a chave de criptografia do Armazenamento do Azure (que executa a criptografia de dados real) é criptografada.

• Você pode implementar uma separação de tarefas entre agentes de segurança, administradores de banco de dados e administradores de sistema.

Terminologia

Chave de criptografia de dados (DEK): uma chave simétrica AES 256 usada para criptografar uma partição ou bloco de dados. Criptografar cada bloco de dados com uma chave diferente torna os ataques de criptoanálise mais difíceis. O provedor de recursos ou instância de aplicativo que criptografa e descriptografa um bloco específico precisa de acesso a DEKs. Quando você substitui uma DEK por uma nova chave, somente os dados em seu bloco associado devem ser criptografados novamente com a nova chave.

Chave de criptografia de chave (KEK): uma chave de criptografia usada para criptografar as DEKs. Um KEK que nunca sai do Key Vault permite que os próprios DEKs sejam criptografados e controlados. A entidade que tem acesso ao KEK pode ser diferente da entidade que requer os DEKs. Como o KEK é necessário para descriptografar os DEKs, o KEK é efetivamente um único ponto pelo qual você pode excluir DEKs (excluindo o KEK).

Os DEKs, criptografados com um KEK, são armazenados separadamente. Apenas uma entidade que tenha acesso ao KEK pode desencriptar estes DEKs. Para obter mais informações, consulte Segurança na criptografia em repouso.

Como funciona a criptografia de dados com uma CMK

Uma identidade gerenciada atribuída pelo usuário do Microsoft Entra é usada para conectar e recuperar uma CMK. Para criar uma identidade, siga este tutorial.

Para que um servidor PostgreSQL use CMKs armazenadas no Cofre da Chave para criptografia da DEK, um administrador do Cofre da Chave concede os seguintes direitos de acesso à identidade gerenciada que você criou:

• get: Para recuperar a parte pública e as propriedades da chave no Cofre da Chave.

• list: Para listar e iterar através de chaves no Cofre da Chave.

• wrapKey: Para criptografar a DEK. A DEK criptografada é armazenada no Banco de Dados do Azure para PostgreSQL.

• unwrapKey: Para desencriptar a DEK. O Banco de Dados do Azure para PostgreSQL precisa da DEK descriptografada para criptografar e descriptografar os dados.

O administrador do Cofre da Chave também pode habilitar o registro de eventos de auditoria do Cofre da Chave, para que eles possam ser auditados posteriormente.

Como alternativa à atribuição de direitos de acesso, conforme explicado acima, você pode criar uma nova atribuição de função do Azure RBAC com a função Key Vault Crypto Service Encryption User.

Quando você configura o servidor para usar a CMK armazenada no Cofre da Chave, o servidor envia a DEK para o Cofre da Chave para criptografia. O Cofre da Chave retorna a DEK criptografada armazenada no banco de dados do usuário. Quando necessário, o servidor envia a DEK protegida para o Cofre da Chave para desencriptação. Os auditores podem usar o Azure Monitor para revisar os logs de eventos de auditoria do Key Vault, se o log estiver ativado.

Requisitos para configurar a criptografia de dados para o Banco de Dados do Azure para servidor flexível PostgreSQL

Aqui estão os requisitos para configurar o Cofre de Chaves:

• O Key Vault e o servidor flexível do Banco de Dados do Azure para PostgreSQL devem pertencer ao mesmo locatário do Microsoft Entra. Não há suporte para 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.

• A configuração Dias para manter cofres excluídos para o Cofre da Chave deve ser 90. Se você configurou a instância existente do Cofre da Chave com um número menor, precisará criar uma nova instância do Cofre da Chave porque não é possível modificar uma instância após a criação.

• Recomenda-se definir a configuração Dias para manter cofres excluídos para o Cofre de Chaves para 90 dias. Caso você tenha configurado 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 sua configuração.

• Habilite o recurso de exclusão suave no Cofre da Chave para ajudar a proteger contra a perda de dados se uma chave ou uma instância do Cofre da Chave 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 uma política de acesso ao Cofre de Chaves.

  O recurso de exclusão suave está desativado por padrão, mas você pode ativá-lo por meio do PowerShell ou da CLI do Azure. Não é possível ativá-lo por meio do portal 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 instância de servidor flexível do PostgreSQL acesso ao Cofre da Chave com as permissões get, list, wrapKey e unwrapKey , usando sua identidade gerenciada exclusiva. Como alternativa, crie uma nova atribuição de função RBAC do Azure com a função Key Vault Crypto Service Encryption User para a identidade gerenciada.

Aqui estão os requisitos para configurar a CMK no Banco de Dados do Azure para o servidor flexível PostgreSQL:

• A CMK a ser usada para criptografar a DEK pode ser apenas assimétrica, RSA ou RSA-HSM. São suportados tamanhos de chave de 2.048, 3.072 e 4.096.

• 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 *Enabled- Estado.

• Se estiver a importar uma chave existente para o Cofre da Chave, forneça-a nos formatos de ficheiro suportados (.pfx, .byokou .backup).

Recomendações

Quando você estiver usando uma CMK para criptografia de dados, aqui estão recomendações para configurar o Cofre de Chaves:

• Defina um bloqueio de recursos no Cofre da Chave para controlar quem pode excluir esse recurso crítico e evitar a exclusão acidental ou não autorizada.

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

  

Aqui estão as recomendações para configurar uma CMK:

• Mantenha uma cópia da CMK 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 para o Cofre da Chave.

Revogação acidental do acesso à chave do Cofre da Chave

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

• Revogar as permissões list, get, wrapKey e unwrapKey da identidade usada para recuperar a chave no Cofre da Chave.

• Excluindo a chave.

• Excluindo a instância do Cofre da Chave.

• Alterar as regras de firewall do Cofre da Chave.

• Excluindo a identidade gerenciada do servidor no Microsoft Entra ID.

Monitorando a CMK no Key Vault

Para monitorar o estado do banco de dados e ativar alertas para a perda de acesso ao protetor de criptografia de dados transparente, 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 com a chave gerenciada de um cliente no Cofre da Chave

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

Ao configurar a criptografia de dados gerenciada pelo cliente durante a restauração ou a criação de uma réplica de leitura, você pode evitar problemas seguindo estas etapas nos servidores primário e restaurado/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 CMK e/ou a identidade do Microsoft Entra usada para acessar o Cofre da Chave nas configurações de criptografia de dados. Verifique se o servidor recém-criado tem permissões de lista, encapsulamento e desempacotamento para a chave armazenada 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 de restaurar um servidor habilitado para CMK 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 o recurso CMK, 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 CMK inacessível

Quando você configura a criptografia de dados com uma CMK no Cofre da Chave, o acesso contínuo a essa chave é necessário para que o servidor permaneça online. Se o servidor perder o acesso à CMK no Cofre da Chave, o servidor começará a negar todas as conexões em 10 minutos. O servidor emite uma mensagem de erro correspondente e altera o estado do servidor para Inacessível.

Algumas das razões pelas quais o estado do servidor se torna Inacessível são:

• Se você excluir a instância do Cofre da Chave, a instância flexível do servidor do Banco de Dados do Azure para PostgreSQL não poderá acessar a chave e será movida para um estado Inacessível . Para disponibilizar o servidor, recupere a instância do Cofre da Chave e revalide a criptografia de dados.
• Se você excluir a chave do Cofre da Chave, a instância flexível do servidor do Banco de Dados do Azure para PostgreSQL não poderá acessar a chave e será movida para um estado Inacessível . Para tornar o servidor disponível, recupere a chave e revalide a criptografia de dados.
• Se você excluir, da ID do Microsoft Entra, uma identidade gerenciada usada para recuperar uma chave do Cofre da Chave, ou excluindo a atribuição de função RBAC do Azure com a função Usuário de Criptografia do Serviço de Criptografia 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 . Para tornar o servidor disponível, recupere a identidade e revalide a criptografia de dados.
• Se você revogar a lista Cofre da Chave, as políticas de acesso get, wrapKey e unwrapKey da identidade gerenciada usada para recuperar uma chave do Cofre da Chave, a instância flexível do servidor do Banco de Dados do Azure para PostgreSQL não poderá acessar a chave e passará para um estado Inacessível. Adicione as políticas de acesso necessárias à identidade no Cofre da Chave.
• Se você configurar regras de firewall do Cofre de Chaves excessivamente restritivas, o servidor flexível do Banco de Dados do Azure para PostgreSQL não poderá se comunicar com o Cofre de Chaves para recuperar chaves. Ao configurar um firewall do Cofre da Chave, certifique-se de selecionar a opção para permitir que serviços confiáveis da Microsoft ignorem o firewall.

Recuperando-se da exclusão de identidade gerenciada

Em casos raros, quando a identidade gerenciada do Entra ID, usada pela CMK para recuperar uma chave do Azure Key Vault (AKV), é excluída no Microsoft Entra ID, as etapas recomendadas para se recuperar, seguem-se as etapas recomendadas para recuperar:

1. Recupere a identidade ou crie uma nova identidade gerenciada do Entra ID
2. Verifique se essa identidade tem permissões adequadas para operações na chave no Cofre de Chaves do Azure (AKV). Dependendo do modelo de permissão do cofre de chaves (política de acesso ou RBAC do Azure), o acesso ao cofre de chaves pode ser concedido criando uma política de acesso no cofre de chaves (políticas de acesso list, get, wrapKey e unwrapKey ) ou criando uma nova atribuição de função do Azure RBAC com a função Key Vault Crypto Service Encryption User.
3. Revalide a criptografia de dados CMK com uma identidade nova ou recuperada na tela do portal do Azure Database for PostgreSQL - Flexible Server Data Encryption Azure.

Usando criptografia de dados com CMKs e recursos de continuidade de negócios com redundância geográfica

O servidor flexível do 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 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

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

• Você pode configurar a criptografia CMK 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 CMK, não é possível removê-la. Se você quiser remover esse recurso, a única maneira é restaurar o servidor para um servidor não-CMK.

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

Próximos passos

• Saiba mais sobre os Serviços de Domínio Microsoft Entra.