Criptografia de dados transparente do SQL do Azure com chave gerenciada pelo cliente

Aplica-se a:Banco de Dados SQL do AzureInstância Gerenciada SQL do Azure(somente pools SQL dedicados) do Azure Synapse Analytics

A criptografia de dados transparente (TDE) no SQL do Azure com chave gerida pelo cliente (CMK) habilita o cenário de "Traga Sua Própria Chave" (BYOK) para proteção de dados em repouso e permite que as organizações implementem a separação de responsabilidades no gerenciamento de chaves e dados. Com o TDE gerenciado pelo cliente, o cliente é responsável pelo gerenciamento do ciclo de vida de uma chave (criação, upload, rotação, exclusão de chaves), permissões de uso de chaves e auditoria de operações em chaves.

Neste cenário, o protetor Encriptação de Dados Transparente (TDE) é uma chave gerida pelo cliente que protege a Chave de Encriptação da Base de Dados (DEK). Armazena o protetor TDE no Azure Key Vault ou no Azure Key Vault Managed HSM, que são serviços seguros de gestão de chaves baseados na cloud, concebidos para alta disponibilidade e escalabilidade. Ambos os serviços suportam chaves criptográficas protegidas por hardware validado pelo FIPS 140-2: o Azure Key Vault suporta FIPS 140-2 Nível 2, e o Azure Key Vault Managed HSM suporta FIPS 140-2 Nível 3. Ambos os serviços também suportam tipos de chaves assimétricas e simétricas, e os algoritmos suportados e a utilização dependem do modelo de implementação TDE. Pode gerar a chave no serviço, importá-la ou transferi-la de forma segura a partir de HSMs locais. O acesso direto às chaves é restrito, pelo que serviços autorizados realizam operações criptográficas sem expor o material da chave.

Para o Banco de Dados SQL do Azure e o Azure Synapse Analytics, o protetor TDE é definido no nível do servidor e é herdado por todos os bancos de dados criptografados associados a esse servidor. Para a Instância Gerenciada SQL do Azure, o protetor TDE é definido no nível da instância e é herdado por todos os bancos de dados criptografados nessa instância. O termo servidor refere-se a um servidor no Banco de Dados SQL e no Azure Synapse e a uma instância gerenciada na Instância Gerenciada do SQL ao longo deste artigo, a menos que indicado de forma diferente.

O gerenciamento do protetor TDE no nível do banco de dados no Banco de Dados SQL do Azure está disponível. Para obter mais informações, consulte Criptografia de dados transparente (TDE) com chaves gerenciadas pelo cliente no nível do banco de dados.

Observação

Este artigo aplica-se à Base de Dados SQL do Azure, à Instância Gerida SQL do Azure e ao Azure Synapse Analytics (pools SQL dedicados (anteriormente SQL DW)). Para obter mais informações sobre criptografia de dados transparente para pools SQL dedicados dentro de espaços de trabalho Synapse, consulte Criptografia do Azure Synapse Analytics.

Observação

Microsoft Entra ID era anteriormente conhecido como Azure Ative Directory (Azure AD).

Chave gerenciada pelo cliente (CMK) e traga sua própria chave (BYOK)

Neste artigo, os termos Customer Managed Key (CMK) e Bring Your Own Key (BYOK) são usados de forma intercambiável, mas representam algumas diferenças.

  • Chave gerenciada pelo cliente (CMK) - O cliente gerencia o ciclo de vida da chave, incluindo a criação, rotação e exclusão de chaves. A chave é armazenada no Cofre da Chave do Azure ou no HSM Gerenciado do Azure e usada para criptografia da Chave de Criptografia de Banco de Dados (DEK) no SQL do Azure, no SQL Server na VM do Azure e no SQL Server local.

  • Traga sua própria chave (BYOK) - O cliente traz ou importa com segurança sua própria chave de um módulo de segurança de hardware (HSM) local para o Azure Key Vault ou o Azure Managed HSM. Essas chaves importadas podem ser usadas como qualquer outra chave no Cofre de Chaves do Azure, inclusive como uma Chave Gerenciada pelo Cliente para criptografia da DEK. Para obter mais informações, consulte Importar chaves protegidas por HSM para HSM gerenciado (BYOK).

Benefícios do TDE gerenciado pelo cliente

A TDE gerenciada pelo cliente oferece os seguintes benefícios ao cliente:

  • Controle total e granular sobre o uso e gerenciamento do protetor TDE.

  • Transparência do uso do protetor TDE.

  • Capacidade de implementar separação de funções na gestão de chaves e dados dentro da organização.

  • O administrador do Azure Key Vault pode revogar as permissões de acesso à chave para tornar o banco de dados criptografado inacessível.

  • Gerenciamento central de chaves no Cofre de Chaves do Azure.

  • Maior confiança dos seus clientes finais, uma vez que o Azure Key Vault foi concebido de forma a que a Microsoft não consiga ver nem extrair chaves de encriptação.

Importante

Para aqueles que usam TDE gerenciado por serviço que gostariam de começar a usar o TDE gerenciado pelo cliente, os dados permanecem criptografados durante o processo de troca e não há tempo de inatividade nem recriptografia dos arquivos de banco de dados. A mudança de uma chave gerenciada pelo serviço para uma chave gerenciada pelo cliente requer apenas a recriptografia da DEK, que é uma operação rápida e online.

Permissões para configurar TDE gerenciada pelo cliente

Diagrama mostrando a configuração e o funcionamento do TDE gerenciado pelo cliente.

Selecione o tipo de Cofre da Chave do Azure que você deseja usar.

Para que o servidor lógico no Azure utilize o protetor TDE armazenado no Azure Key Vault para encriptação do DEK, o Administrador do Key Vault precisa de conceder direitos de acesso ao servidor usando a sua identidade única Microsoft Entra. A identidade do servidor pode ser uma identidade gerenciada atribuída pelo sistema ou uma identidade gerenciada atribuída pelo usuário atribuída ao servidor. Há dois modelos de acesso para conceder ao servidor acesso ao cofre de chaves:

  • Controle de acesso baseado em função (RBAC) do Azure - Use o RBAC do Azure para conceder a um usuário, grupo ou aplicativo acesso ao cofre de chaves. Este método é recomendado pela sua flexibilidade e granularidade. A identidade do servidor precisa da função de Utilizador de Criptografia () do Key Vault Crypto Service () para poder usar a chave em operações de criptografia e descriptografia.

  • Política de acesso ao cofre - Use a política de acesso ao cofre de chaves para conceder ao servidor acesso ao cofre de chaves. Este método é mais simples e direto, mas menos flexível. A identidade do servidor precisa ter as seguintes permissões no cofre de chaves:

    • get - para recuperar a parte pública e as propriedades da chave no Cofre da Chave do Azure
    • wrapKey - para poder proteger (encriptar) DEK
    • unwrapKey - para poder desproteger (desencriptar) DEK

No menu Configuração do Access portal do Azure do cofre da chave, você tem a opção de selecionar de controle de acesso baseado em função do Azure ou política de acesso do Vault. Para obter instruções passo a passo sobre como configurar uma configuração de acesso ao Cofre de Chaves do Azure para TDE, consulte Configurar o Gerenciamento Extensível de Chaves TDE do SQL Server usando o Azure Key Vault. Para obter mais informações sobre os modelos de acesso, consulte a segurança do Azure Key Vault .

Um Administrador do Cofre de Chaves do também pode habilitar o registro de eventos de auditoria do cofre de chaves, para que eles possam ser auditados posteriormente.

Quando um servidor é configurado para usar um protetor TDE do Cofre de Chaves do Azure, o servidor envia a DEK de cada banco de dados habilitado para TDE para o cofre de chaves para criptografia. O cofre de chaves retorna a DEK criptografada, que é armazenada no banco de dados do usuário.

Quando necessário, o servidor envia DEK protegido para o cofre de chaves para desencriptação.

Os auditores podem usar o Azure Monitor para revisar os logs de AuditEvent do cofre de chaves, se o registo estiver ativado.

Observação

Pode levar cerca de 10 minutos para que qualquer alteração de permissão entre em vigor no cofre de chaves. Isso inclui revogar as permissões de acesso ao protetor TDE no AKV, e os utilizadores dentro desse período de tempo ainda poderão ter permissões de acesso.

Requisitos para configurar o TDE gerenciado pelo cliente

  • Os recursos de proteção de exclusão suave e limpeza devem ser habilitados no Cofre da Chave do Azure. Isso ajuda a evitar o cenário de cofre de chaves acidental ou mal-intencionado ou exclusão de chave que pode levar o banco de dados a entrar estado de Inacessível. Ao configurar o protetor TDE em um servidor existente ou durante a criação do servidor, o SQL do Azure valida se o cofre de chaves que está sendo usado tem a proteção de exclusão suave e limpeza ativada. Se a proteção de exclusão suave e limpeza não estiver ativada no cofre de chaves, a configuração do protetor TDE falhará com um erro. Nesse caso, a proteção soft-delete e purge deve primeiro ser ativada no cofre de chaves e, em seguida, a configuração do protetor TDE deve ser executada.

  • Ao usar um firewall com o Cofre de Chaves do Azure, você deve habilitar a opção Permitir que serviços confiáveis da Microsoft ignorem o firewall, a menos que esteja usando pontos de extremidade privados para o Cofre de Chaves do Azure. Para obter mais informações, consulte Configurar firewalls e redes virtuais do Azure Key Vault.

Requisitos chave para configurar o protetor TDE

A Encriptação de Dados Transparente com chaves geridas pelo cliente utiliza uma chave externa, referida como protetor TDE, armazenada no Azure Key Vault ou no Azure Managed HSM para proteger a chave de encriptação da base de dados (DEK).

Aplicam-se os seguintes requisitos.

Tipos e tamanhos de chave suportados

Dependendo da oferta SQL do Azure e da configuração TDE, o protetor TDE pode ser suportado por chaves assimétricas ou simétricas armazenadas no Azure Key Vault ou no Azure Key Vault Managed HSM.

  • Chaves assimétricas (RSA ou RSA HSM)

    • Suportado no Azure Key Vault e no Azure Key Vault Managed HSM
    • Tamanhos de chave suportados: 2.048 bits e 3.072 bits
    • Suportado para Base de Dados SQL do Azure, Azure SQL Managed Instance e Azure Synapse Analytics

  • Chaves simétricas (AES)

    • Suportado no Azure Key Vault Premium (pré-visualização) e no Azure Key Vault Managed HSM
    • Tamanhos de chave suportados: 128 bits, 192 bits e 256 bits
    • Suportado apenas para Base de Dados SQL do Azure, atualmente em pré-visualização pública

Observação

Encriptação de Dados Transparente with Symmetric Keys (AES) está atualmente em pré-visualização. As funcionalidades de pré-visualização são lançadas com capacidades limitadas, mas a Microsoft disponibiliza-as em regime de pré-visualização para que os clientes possam obter acesso antecipado e fornecer feedback. As funcionalidades de pré-visualização estão sujeitas a termos suplementares de pré-visualização independentes e não estão sujeitas a SLAs. O apoio é prestado com o máximo de empenho em certos casos. No entanto, o Suporte da Microsoft está ansioso para obter os seus comentários sobre a funcionalidade de visualização e pode fornecer o melhor suporte possível em certos casos. Os recursos de visualização podem ter funcionalidade limitada ou restrita e podem estar disponíveis apenas em áreas geográficas selecionadas.

Comportamento de gestão de chaves para chaves simétricas (AES)

Pode usar chaves simétricas (AES) armazenadas no Azure Key Vault Premium (pré-visualização) ou no Azure Key Vault Managed HSM como protetor TDE. Para começar com uma chave de um módulo de segurança de hardware local (HSM), importe a chave para qualquer um dos serviços. Após a importação inicial, todas as operações do ciclo de vida das chaves em curso ocorrem no Azure Key Vault Premium (pré-visualização) ou no Azure Key Vault Managed HSM. A recuperação para um ponto no tempo, a recuperação de desastre geográfico e a revalidação da chave dependem todas de a chave continuar disponível nesse local. Manter backups locais das chaves importadas para suportar cenários de recuperação e revalidação. Este comportamento aplica-se apenas a chaves simétricas (AES), não a chaves assimétricas (RSA).

Estado chave e requisitos de validade

  • Se for especificada uma data de ativação da chave, esta deve ser definida para uma data e hora no passado.
  • Se for especificada uma data de expiração da chave, esta deve ser definida para uma data e hora futuras.
  • A chave deve estar no estado Enabled.

Requisitos chave de importação

Se importar uma chave existente para o Azure Key Vault, forneça a chave num dos seguintes formatos suportados:

  • .pfx
  • .byok
  • .backup

Para importar chaves protegidas por HSM para o Azure Managed HSM, consulte Importar chaves protegidas por HSM para o Managed HSM (BYOK).

Observação

Um problema com as versões do Thales CipherTrust Manager anteriores à v2.8.0 impede que chaves recém-importadas para o Cofre de Chaves do Azure sejam usadas com o Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure para cenários TDE gerenciados pelo cliente. Para mais detalhes sobre esta questão, consulte as notas de atualização do CipherTrust Cloud Key Manager. Para esses casos, aguarde 24 horas após importar a chave para o Cofre de Chaves do Azure para começar a usá-la como protetor TDE para o servidor ou instância gerenciada. Este problema é resolvido no Thales CipherTrust Manager v2.8.0.

Recomendações para configurar o TDE gerido pelo cliente

  • Para garantir desempenho e fiabilidade ótimos, utilize um Azure Key Vault dedicado para SQL do Azure. Não partilhe este cofre de chaves com outros serviços. Se o cofre de chaves estiver sob grande carga devido ao uso partilhado ou operações excessivas de chaves, pode afetar negativamente o desempenho da base de dados, especialmente durante o acesso à chave de encriptação. O Azure Key Vault impõe limites de limitação. Quando esses limites são excedidos, as operações podem ser atrasadas ou falhar. Este risco é maior durante failovers de servidores, que desencadeiam operações de chave para todas as bases de dados no servidor.

    Para obter mais informações sobre o comportamento de limitação, consulte Orientações de limitação do Cofre de Chaves do Azure.

    Para manter uma alta disponibilidade e evitar problemas de restrição, siga estas diretrizes para cada assinatura:

    • Use um Cofre da Chave do Azure dedicado para recursos SQL do Azure.

    • Associe não mais de 500 bancos de dados de uso geral a um único Cofre de Chaves do Azure.

    • Associe no máximo 200 bancos de dados Críticos para os Negócios a um único Cofre de Chaves do Azure.

    • O número de bancos de dados Hyperscale que podem ser associados a um único Cofre de Chaves do Azure é determinado pelo número de servidores de página. Cada servidor de página está vinculado a um arquivo de dados lógico. Para localizar o número de servidores de página, execute a seguinte consulta.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Não associe mais de 500 servidores de páginas a um único Azure Key Vault. À medida que o banco de dados cresce, o número de servidores de página aumenta automaticamente, por isso é importante monitorar o tamanho do banco de dados regularmente. Se o número de servidores de páginas ultrapassar 500, use um Azure Key Vault dedicado para cada base de dados Hyperscale e não partilhe esse cofre de chaves com outros recursos SQL do Azure.

    • Monitorize e configure alertas no Azure Key Vault. Para obter mais informações sobre monitoramento e alertas, consulte Monitorar o Azure Key Vault e Configurar alertas do Azure Key Vault.

  • Para alinhar com o planeamento de resiliência criptográfica a longo prazo, considere usar chaves simétricas AES-256 como protetor TDE.

    Espera-se que a computação quântica em grande escala quebre algoritmos criptográficos de chave pública como o RSA. A criptografia simétrica, incluindo o AES, é considerada resiliente quântica em tamanhos de chave suficientemente grandes.

    A estratégia mais ampla de segurança quântica da Microsoft enfatiza a criptoagilidade. Adote algoritmos simétricos mais fortes onde forem suportados e planeia futuras transições criptográficas à medida que as orientações e os padrões evoluem.

    Importante

    O Encriptação de Dados Transparente with Symmetric Keys (AES) é atualmente suportado apenas para Base de Dados SQL do Azure e está em pré-visualização pública.

  • Defina um bloqueio de recursos no cofre de chaves para controlar quem pode excluir esse recurso crítico e evitar a exclusão acidental ou não autorizada. Saiba mais sobre bloqueios de recursos.

  • Habilite a auditoria e a geração de relatórios sobre todas as chaves de criptografia: o Cofre de Chaves do Azure fornece logs que são fáceis de injetar em outras informações de segurança e ferramentas de gerenciamento de eventos. O Operations Management Suite o Log Analytics é um exemplo de um serviço já integrado.

  • Utilize um cofre de chaves de uma região do Azure que possa replicar o seu conteúdo para uma região emparelhada para máxima disponibilidade. Para obter mais informações, consulte Práticas recomendadas para usar o Azure Key Vault e disponibilidade e redundância do Azure Key Vault.

Observação

Para permitir maior flexibilidade na configuração do TDE gerenciado pelo cliente, o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure em uma região agora podem ser vinculados ao Cofre da Chave do Azure em qualquer outra região. O servidor e o cofre de chaves não precisam estar localizados na mesma região.

Recomendações para configurar o protetor TDE

  • Mantenha uma cópia do protetor TDE em um local seguro ou deposite-a no serviço de depósito.

  • Se a chave for gerada no cofre de chaves, crie um backup de chave antes de usá-la no Cofre de Chaves do Azure pela primeira vez. O backup pode ser restaurado apenas para um Cofre de Chaves do Azure. Saiba mais sobre o comando Backup-AzKeyVaultKey. O HSM Gerenciado do Azure dá suporte à criação de um backup completo de todo o conteúdo do HSM, incluindo todas as chaves, versões, atributos, tags e atribuições de função. Para obter mais informações, consulte Backup e restauração completos e Restauração seletiva de chaves.

  • Crie um novo backup sempre que forem feitas alterações na chave (por exemplo, atributos de chave, tags, ACLs).

  • Mantenha versões anteriores da chave no cofre de chaves ou no HSM Gerido ao efetuar a rotação das chaves, para poder restaurar cópias de segurança antigas da base de dados. Quando o protetor TDE muda para uma base de dados, backups antigos da base de dados não são atualizados para usar o protetor TDE mais recente. No momento da restauração, cada backup precisa do protetor TDE com o qual foi criptografado no momento da criação. Para efetuar a rotação das chaves, siga as instruções no artigo Efetuar a rotação do protetor da Encriptação de Dados Transparentes (TDE).

  • Mantenha todas as chaves usadas anteriormente no Azure Key Vault ou no Azure Managed HSM mesmo depois de mudar para chaves gerenciadas por serviço. Ele garante que os backups de banco de dados possam ser restaurados com os protetores TDE armazenados no Azure Key Vault ou no Azure Managed HSM. Os protetores TDE criados com o Azure Key Vault ou o Azure Managed HSM devem ser mantidos até que todos os backups armazenados restantes tenham sido criados com chaves gerenciadas pelo serviço. Faça cópias de backup recuperáveis dessas chaves usando Backup-AzKeyVaultKey.

  • Para remover uma chave potencialmente comprometida durante um incidente de segurança sem o risco de perda de dados, siga as etapas no artigo Remover um protetor TDE (Encriptação de Dados Transparente) usando o PowerShell. Roda sempre para um novo protetor TDE e verifica se todas as bases de dados estão a usar a nova chave antes de apagar ou desativar a chave comprometida. Apagar ou desativar a chave sem fazer primeiro a sua rotação faz todas as bases de dados encriptadas tornarem-se inacessíveis e não invalida quaisquer cópias da chave que tenham sido anteriormente guardadas em cópia de segurança e restauradas noutro cofre.

Sugestão

Utilização de chaves Azure Key Vault versionadas e sem versão para TDE

Quando defines o protetor TDE, podes referenciar uma chave Azure Key Vault usando uma versão específica da chave ou um identificador de chave sem versão.

Em ambos os casos, o Base de Dados SQL do Azure utiliza e resolve sempre a versão mais recente habilitada da chave no Azure Key Vault ou no Azure Key Vault Managed HSM. Use identificadores de chave sem versão para evitar incorporar uma versão específica de chave na configuração do protetor TDE.

Identificadores de chave sem versão são atualmente suportados apenas para Base de Dados SQL do Azure.

Exemplos:

  • Identificador de chave que inclui uma versão específica

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Identificador de chave sem versão

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

Rotação do protetor TDE

Rodar o protetor TDE permite-lhe substituir a chave usada para proteger a chave de encriptação da base de dados (DEK). A rotação de chaves é uma operação on-line e deve levar apenas alguns segundos para ser concluída. A operação apenas descriptografa e criptografa novamente a chave de criptografia do banco de dados, não todo o banco de dados.

Pode fazer a rotação do protetor TDE alterando a configuração para utilizar uma nova chave armazenada no Azure Key Vault ou no Azure Key Vault Managed HSM. Dependendo da oferta SQL do Azure e da configuração suportada, isto pode incluir:

  • Mudar para uma nova versão da mesma tecla
  • Mudar para uma chave diferente
  • Alternar entre tipos de chaves suportados, como chaves assimétricas (RSA) e chaves simétricas (AES)

Observação

O Encriptação de Dados Transparente with Symmetric Keys (AES) é atualmente suportado apenas para Base de Dados SQL do Azure e está em pré-visualização pública.

Rotação do protetor TDE pode ser feita manualmente ou usando o recurso de rotação automatizada.

A rotação automatizada do protetor TDE pode ser ativada ao configurar o protetor TDE para o servidor. A rotação automatizada está desativada por padrão. Quando ativado, o servidor verifica continuamente o cofre de chaves ou o HSM gerenciado em busca de novas versões da chave que está sendo usada como protetor TDE. Se uma nova versão da chave for detetada, o protetor TDE no servidor ou banco de dados será automaticamente girado para a versão mais recente da chave dentro de 24 horas.

Quando usado com rotação automatizada de chaves no Cofre de Chaves do Azure ou rotação automática no HSM Gerenciado do Azure, esse recurso permite a rotação de toque zero de ponta a ponta para o protetor TDE no Banco de Dados SQL do Azure e na Instância Gerenciada SQL do Azure.

Observação

Configurar TDE com CMK, usando rotação manual ou automatizada de chaves, utiliza sempre a versão mais recente da chave que é suportada. A configuração não permite o uso de uma versão anterior ou inferior das chaves. Usar sempre a versão de chave mais recente está em conformidade com a política de segurança SQL do Azure que não permite versões de chave anteriores que possam ser comprometidas. As versões anteriores da chave podem ser necessárias para fins de backup ou restauração de banco de dados , especialmente para backups de retenção de longo prazo , onde as versões de chave mais antigas devem ser preservadas. Para configurações de replicação geográfica, todas as chaves exigidas pelo servidor de origem precisam estar presentes no servidor de destino.

Considerações sobre replicação geográfica ao configurar a rotação automatizada do protetor TDE

Para evitar problemas durante o estabelecimento ou durante a replicação geográfica, quando a rotação automática do protetor TDE estiver habilitada no servidor primário ou secundário, é importante seguir estas regras ao configurar a replicação geográfica:

  • Os servidores primário e secundário devem ter Get, wrapKey e unwrapKey permissões no cofre de chaves do servidor primário (cofre de chaves que armazena a chave protetora TDE do servidor primário).

  • Para um servidor com rotação automatizada de chaves habilitada, antes de iniciar a replicação geográfica, adicione a chave de criptografia que está sendo usada como protetor TDE no servidor primário ao servidor secundário. O servidor secundário requer acesso à chave no mesmo cofre de chaves ou módulo de segurança de hardware (HSM) gerido que está a ser utilizado com o servidor primário (e não a outra chave com o mesmo material de chave). Como alternativa, antes de iniciar a replicação geográfica, verifique se a identidade gerenciada do servidor secundário (atribuída pelo usuário ou atribuída pelo sistema) tem as permissões necessárias no cofre de chaves do servidor primário ou no HSM gerenciado e se o sistema tenta adicionar a chave ao servidor secundário.

  • Para uma configuração de replicação geográfica existente, antes de habilitar a rotação automatizada de chaves no servidor primário, adicione a chave de criptografia que está sendo usada como protetor TDE no servidor primário ao servidor secundário. O servidor secundário requer acesso à chave no mesmo cofre de chaves ou módulo de segurança de hardware (HSM) gerido que está a ser utilizado com o servidor primário (e não a outra chave com o mesmo material de chave). Como alternativa, antes de habilitar a chave automatizada, verifique se a identidade gerenciada do servidor secundário (atribuída pelo usuário ou atribuída pelo sistema) tem as permissões necessárias no cofre de chaves do servidor primário e se o sistema tenta adicionar a chave ao servidor secundário.

  • São suportados cenários de geo-replicação utilizando chaves geridas pelo cliente (CMK) para TDE. A TDE com rotação automática de chaves deve ser configurada em todos os servidores se você estiver configurando a TDE no portal do Azure. Para obter mais informações sobre como configurar a rotação automática de chaves para configurações de replicação geográfica com TDE, consulte Rotação automática de chaves para configurações de replicação geográfica.

Protetor TDE inacessível

Quando a TDE é configurada para usar uma chave gerenciada pelo cliente, o acesso contínuo ao protetor TDE é necessário para que o banco de dados permaneça online. Se o servidor perder o acesso ao protetor TDE gerenciado pelo cliente no Cofre da Chave do Azure ou no HSM Gerenciado do Azure, em até 10 minutos um banco de dados começará a negar todas as conexões com a mensagem de erro correspondente e alterará seu estado para Inacessível. A única ação permitida em um banco de dados no estado Inacessível é excluí-lo.

Estado inacessível

Se o banco de dados estiver inacessível devido a uma interrupção intermitente da rede (como um erro 5XX), nenhuma ação será necessária, pois os bancos de dados voltarão a ficar online automaticamente. Para reduzir o efeito de erros de rede ou interrupções ao acessar o protetor TDE no Cofre da Chave do Azure ou no HSM Gerenciado do Azure, um buffer de 24 horas é introduzido antes que o serviço tente mover o banco de dados para um estado inacessível. Se ocorrer um failover antes de atingir o estado inacessível, o banco de dados ficará indisponível devido à perda do cache de criptografia.

Se o servidor perder o acesso ao protetor TDE gerenciado pelo cliente no Azure Key Vault ou no Azure Managed HSM devido a qualquer erro do Azure Key Vault (como um erro 4XX), o banco de dados será movido para um estado inacessível após 30 minutos.

Restaurar o acesso ao banco de dados após um erro do Azure Key Vault ou do Azure Managed HSM

Depois que o acesso à chave é restaurado, colocar o banco de dados on-line novamente requer tempo e etapas adicionais, que podem variar com base na duração da indisponibilidade da chave e no tamanho dos dados dentro do banco de dados.

Se o acesso à chave for restaurado dentro de 30 minutos, o banco de dados autorrecupera-se automaticamente durante a hora seguinte. No entanto, se o acesso à chave for restaurado após mais de 30 minutos, a recuperação automática do banco de dados não será possível. Nesses casos, a restauração do banco de dados envolve procedimentos extras por meio do portal do Azure e pode ser demorada, dependendo do tamanho do banco de dados.

Quando a base de dados voltar a estar online, as definições previamente configuradas ao nível do servidor, tais como as configurações de grupo de tolerância a falhas, etiquetas, e as definições ao nível da base de dados, tais como configurações de pool elástico, escala de leitura, pausa automática, histórico de restauração a partir de um ponto no tempo, política de retenção a longo prazo, e outras, serão perdidas. Por isso, recomenda-se que os clientes implementem um sistema de notificação para detetar a perda de acesso à chave de criptografia em 30 minutos. Depois que a janela de 30 minutos expirar, recomendamos validar todas as configurações de nível de servidor e banco de dados no banco de dados recuperado.

Segue-se uma vista dos passos adicionais necessários no portal para colocar uma base de dados inacessível novamente online.

Captura de ecrã de uma base de dados TDE BYOK inacessível.

Revogação acidental do acesso do protetor TDE

Pode acontecer que alguém com direitos de acesso suficientes ao cofre de chaves ou ao HSM gerido desative acidentalmente o acesso do servidor à chave por:

  • Revogar as permissões obter, wrapKey e unwrapKey do cofre de chaves ou do HSM gerenciado no servidor.

  • apagar a chave

  • eliminar o cofre de chaves ou o HSM gerenciado

  • alterar as regras de firewall do cofre de chaves ou do HSM gerenciado

  • excluindo a identidade gerenciada do servidor no Microsoft Entra ID

Saiba mais sobre as causas comuns para o banco de dados se tornar inacessível.

Conectividade bloqueada entre a Instância Gerenciada do SQL e o Cofre da Chave do Azure ou o HSM Gerenciado do Azure

O bloco de conectividade de rede entre a Instância Gerenciada SQL e o cofre de chaves ou HSM gerenciado acontece principalmente quando o cofre de chaves ou o recurso HSM gerenciado existe, mas seu ponto de extremidade não pode ser acessado a partir da instância gerenciada. Todos os cenários em que o cofre de chaves ou o ponto de extremidade HSM gerenciado podem ser alcançados, mas a conexão é negada, permissões ausentes, etc., fazem com que os bancos de dados alterem seu estado para Inacessível.

As causas mais comuns para a falta de conectividade de rede com o Azure Key Vault ou o Azure Managed HSM são:

  • O Azure Key Vault ou o Azure Managed HSM é exposto através de um ponto de extremidade privado e o endereço IP privado do Azure Key Vault ou do serviço Azure Managed HSM não é permitido nas regras de saída do Network Security Group (NSG) associado à sub-rede da instância gerida.

  • Resolução DNS incorreta, como quando o cofre de chaves ou o FQDN HSM gerenciado não é resolvido ou é resolvido para um endereço IP inválido.

Teste a conectividade da Instância Gerenciada do SQL com o Cofre da Chave do Azure ou o HSM Gerenciado do Azure que hospeda o protetor TDE.

  • O endpoint é o FQDN do cofre-forte, como <vault_name>.vault.azure.net (sem o https://).
  • A porta a ser testada é 443.
  • O resultado para RemoteAddress deve existir e ser o endereço IP correto
  • O resultado para o teste TCP deve ser TcpTestSucceeded: True.

Caso o teste retorne TcpTestSucceeded: False, revise a configuração de rede:

  • Verifique o endereço IP resolvido, confirme se é válido. Um valor ausente significa que há problemas com a resolução de DNS.

    • Confirme se o grupo de segurança de rede na instância gerenciada tem uma regra de saída que abrange o endereço IP resolvido na porta 443, especialmente quando o endereço resolvido pertence ao ponto de extremidade privado do cofre de chaves ou do HSM gerenciado.

    • Verifique outras configurações de rede, como tabela de rotas, existência de dispositivo virtual e sua configuração, etc.

Monitore o TDE gerenciado pelo cliente

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

  • Azure Resource Health. Um banco de dados inacessível que perdeu o acesso ao protetor TDE aparece como "Indisponível" depois que a primeira conexão com o banco de dados é negada.

  • Registro de atividades quando falhar o acesso ao protetor TDE no cofre de chaves gerido pelo cliente, as entradas serão adicionadas ao log de atividades. A criação de alertas para esses eventos permite que você restabeleça o acesso o mais rápido possível.

  • Grupos de Ação podem ser definidos para enviar notificações e alertas com base em suas preferências, por exemplo, Email/SMS/Push/Voice, Logic App, Webhook, ITSM ou Automation Runbook.

Banco de dados backup e restore com TDE gerenciado pelo cliente

Depois que um banco de dados é criptografado com TDE usando uma chave do Azure Key Vault ou do Azure Managed HSM, todos os backups recém-gerados também são criptografados com o mesmo protetor TDE. Quando o protetor TDE é alterado, os backups antigos do banco de dados não são atualizados para usar o protetor TDE mais recente.

Para restaurar um backup criptografado com um protetor TDE do Azure Key Vault ou do Azure Managed HSM, verifique se o material da chave está disponível para o servidor de destino. Portanto, recomendamos que você mantenha todas as versões antigas do protetor TDE no cofre de chaves ou no HSM gerenciado, para que os backups do banco de dados possam ser restaurados.

Importante

Não pode haver mais de um protetor TDE definido para um servidor a qualquer momento. A chave marcada com Tornar a chave o protetor TDE padrão no painel do portal do Azure é o protetor TDE. No entanto, várias chaves podem ser vinculadas a um servidor sem marcá-las como um protetor TDE. Essas chaves não são usadas para proteger a DEK, mas podem ser usadas durante a restauração a partir de um backup, se o arquivo de backup for criptografado com a chave com a impressão digital correspondente.

Se a chave necessária para restaurar um backup não estiver mais disponível para o servidor de destino, a seguinte mensagem de erro será retornada na tentativa de restauração: "O <Servername> do servidor de destino não tem acesso a todos os URIs AKV criados entre <> de carimbo de data/hora #1 e <>de carimbo de data/hora #2. Repita a operação depois de restaurar todos os URIs AKV."

Para atenuá-lo, execute o cmdlet Get-AzSqlServerKeyVaultKey para o servidor de destino ou Get-AzSqlInstanceKeyVaultKey para a instância gerenciada de destino para retornar a lista de chaves disponíveis e identificar as ausentes. Para garantir que todos os backups possam ser restaurados, certifique-se de que o servidor de destino para a restauração tenha acesso a todas as chaves necessárias. Essas chaves não precisam ser marcadas como proteção TDE.

Para saber mais sobre a recuperação de backup para o Banco de Dados SQL, consulte Restaurar um banco de dados a partir de um backup no Banco de Dados SQL do Azure. Para saber mais sobre a recuperação de backup para pools SQL dedicados no Azure Synapse Analytics, consulte Recuperar um pool SQL dedicado. Para backup/restauração nativo do SQL Server com Instância Gerida SQL, consulte Início Rápido: restaurar um banco de dados para Instância Gerida SQL do Azure com SSMS.

Outra consideração para os arquivos de log: Os arquivos de log de backup permanecem criptografados com o protetor TDE original, mesmo que ele tenha sido girado e o banco de dados agora esteja usando um novo protetor TDE. No momento da restauração, ambas as chaves são necessárias para restaurar o banco de dados. Se o arquivo de log estiver usando um protetor TDE armazenado no Cofre de Chaves do Azure ou no HSM Gerenciado do Azure, essa chave será necessária no momento da restauração, mesmo que o banco de dados tenha sido alterado para usar o TDE gerenciado por serviço nesse meio tempo.

Alta disponibilidade com TDE gerenciada pelo cliente

Com o Azure Key Vault ou o Azure Managed HSM fornecendo várias camadas de redundância, os TDEs que usam uma chave gerenciada pelo cliente podem aproveitar a disponibilidade e a resiliência do Azure Key Vault ou do Azure Managed HSM e confiar totalmente na solução de redundância do Azure Key Vault ou do Azure Managed HSM.

Várias camadas de redundância do Azure Key Vault garantem o acesso à chave mesmo se os componentes de serviço individuais falharem ou as regiões ou zonas de disponibilidade do Azure estiverem inativas. Para obter mais informações, consulte Disponibilidade e redundância do Azure Key Vault.

O Azure Key Vault oferece os seguintes componentes de disponibilidade e resiliência que são fornecidos automaticamente sem intervenção do usuário:

Observação

Para todas as regiões pares, as chaves do Azure Key Vault são replicadas para ambas as regiões e há Módulos de Segurança de Hardware (HSM) em ambas as regiões que podem operar nessas chaves. Para obter mais informações, consulte Replicação de dados. Isso se aplica às camadas de serviço do Cofre de Chaves do Azure Standard e Premium e às chaves de software ou hardware.

A replicação multirregional do Azure Managed HSM permite estender um pool do Azure Managed HSM de uma região do Azure (chamada de região primária) para outra região do Azure (chamada de região estendida). Uma vez configuradas, ambas as regiões ficam ativas, capazes de atender solicitações e, com a replicação automatizada, compartilham o mesmo material, funções e permissões de chave. Para obter mais informações, consulte Habilitar replicação de várias regiões no Azure Managed HSM.

Recuperação de desastre geográfico com TDE gerido pelo cliente

Grupos ativos de geo-replicação e failover suportam TDE gerido pelo cliente. Os servidores primário e secundário podem usar um Azure Key Vault ou um Azure Managed HSM em qualquer região suportada. Os servidores e a loja de chaves não têm de estar na mesma região.

Para um failover bem-sucedido, ambos os servidores devem ter acesso a todos os Azure Key Vault ou Azure Managed HSM que contenham uma chave necessária.

Questões de configuração

As seguintes considerações aplicam-se ao configurar a geo-replicação ativa ou um grupo de failover no portal do Azure:

  • Localização do protetor TDE: Os servidores primário e secundário podem usar o mesmo Azure Key Vault ou Azure Managed HSM. Usar o mesmo repositório de chaves reduz o risco de o material de chaves ficar dessincronizado. Se utilizar cofres de chaves separados em várias regiões, tem de manter sincronizado o material de chaves necessário. Para informações sobre a resiliência do key-store, consulte disponibilidade e redundância do Azure Key Vault e replicação multi-região no HSM Gerido.

  • Redundância de zonas: Quando disponível, a redundância de zonas para Base de Dados SQL do Azure ou Azure SQL Managed Instance proporciona resiliência extra dentro de uma região. Para obter mais informações, consulte O que são zonas de disponibilidade do Azure?.

  • Permissões de chave: Tanto o servidor primário como o secundário devem ter as permissões necessárias em cada Azure Key Vault ou Azure Managed HSM que contenha um protetor TDE obrigatório.

  • Disponibilidade de chaves: Garantir que as chaves necessárias estão disponíveis tanto no servidor principal como no secundário. Os servidores não precisam de usar protetores TDE idênticos, mas cada servidor deve ter o mesmo material de chave. Pode adicionar chaves a um servidor usando o portal Azure, PowerShell, CLI do Azure ou a API SQL do Azure REST. Se as chaves necessárias não estiverem disponíveis no momento do failover, a base de dados pode tornar-se inacessível.

  • Endpoints privados: A configuração pode exigir uma zona DNS mais complexa se usar endpoints privados no SQL do Azure (por exemplo, não pode criar dois endpoints privados para o mesmo recurso na mesma zona DNS).

  • Conectividade da aplicação: As aplicações devem usar um mecanismo de repetição para lidar com falhas transitórias durante o failover.

Para obter informações sobre como configurar o recurso de recuperação após desastre geográfica do SQL do Azure, consulte Geo-replicação ativa ou Descrição geral e melhores práticas dos grupos de ativação pós-falha.

Importante

Quando cria um link de geo-replicação ou um grupo de failover, o SQL do Azure valida que ambos os servidores podem aceder a todas as chaves geridas pelo cliente necessárias. Se qualquer um dos servidores não conseguir aceder a uma chave necessária, a operação de criação falha. Por exemplo, se os servidores primário e secundário usarem a Chave A e a Chave B, respetivamente, adicione ambas as chaves a ambos os servidores antes de criar o link de geo-replicação ou o grupo de failover.

O diagrama seguinte mostra a georreplicação do SQL do Azure com um grupo de ativação pós-falha e a ativação pós-falha entre regiões do Azure Key Vault numa configuração de regiões emparelhadas:

Diagrama mostrando o suporte a failover entre regiões do Azure Key Vault para uma região emparelhada.

Comportamento do Azure Key Vault durante o failover

  • O Azure Key Vault inicia o failover, não tu.
  • Embora o cofre de chaves na região primária não esteja disponível, o cofre de chaves está em modo só de leitura.
  • Pode criar, importar e alternar chaves apenas enquanto o cofre de chaves na região principal estiver disponível. Após um failover, a rotação de chaves permanece bloqueada até que a região primária volte a ser acessível.
  • Não podes escolher ou verificar em que região está atualmente o cofre de chaves, nem podes ligar-te manualmente à região secundária.

Recuperar de um protetor TDE inacessível

Se uma base de dados numa relação ativa de geo-replicação ou grupo de failover se tornar inacessível, o plano de controlo do SQL do Azure interrompe a ligação e converte a base de dados numa base de dados autónoma.

Depois de restaurar permissões chave, normalmente consegues voltar a pôr a base de dados principal online. Não podes voltar a pôr a base de dados secundária online porque o SQL do Azure não aceita backups completos das bases de dados secundárias. Elimine a base de dados secundária e, em seguida, restabeleça a ligação de georreplicação ou o grupo de failover.

Política do Azure para TDE gerenciado pelo cliente

A Política do Azure pode ser usada para impor TDE gerenciada pelo cliente durante a criação ou atualização de um servidor do Banco de Dados SQL do Azure ou da Instância Gerenciada SQL do Azure. Com essa política em vigor, todas as tentativas de criar ou atualizar um servidor lógico no Azure ou uma instância gerenciada falham se ele não estiver configurado com uma chave gerenciada pelo cliente. A Política do Azure pode ser aplicada a toda a assinatura do Azure ou apenas dentro de um grupo de recursos.

Para obter mais informações sobre a Política do Azure, consulte O que é a Política do Azure e Estrutura de definição da Política do Azure.

As duas políticas internas a seguir são suportadas para TDE gerenciada pelo cliente na Política do Azure:

  • Os servidores SQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso
  • As instâncias gerenciadas devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso

A política de TDE gerenciada pelo cliente pode ser gerenciada acessando o portal do Azuree pesquisando o serviço Política de. Em Definições, procure a chave gerenciada pelo cliente.

Estas políticas têm três efeitos:

  • Auditoria - A configuração padrão e captura apenas um relatório de auditoria nos logs de atividade da Política do Azure

  • Negar - Impede a criação ou atualização do servidor lógico ou da instância gerenciada sem que uma chave gerida pelo cliente esteja configurada

  • Desativado - Desativa a política e não restringe os usuários a criar ou atualizar um servidor lógico ou instância gerida sem TDE gerida pelo cliente ativada

Se a Política do Azure para TDE gerenciada pelo cliente estiver definida como Negar, o servidor lógico SQL do Azure ou a criação de instância gerenciada falhará. Os detalhes dessa falha são registrados no log de atividades do grupo de recursos.

Importante

As versões anteriores das políticas predefinidas para TDE geridas pelo cliente que contêm o efeito AuditIfNotExists foram descontinuadas. As atribuições de política existentes que usam as políticas preteridas não são afetadas e continuam a funcionar como antes.

Conteúdo relacionado

  • Last updated on