Customer-managed TDE for Azure Synapse Analytics

Aplica-se a: pools de SQL dedicados do Azure Synapse Analytics (antes conhecido como SQL DW)

Dica

Microsoft Fabric Data Warehouse é um armazém relacional de escala empresarial com base de data lake, arquitetura pronta para o futuro, IA integrada e novos recursos. Se você não estiver familiarizado com o data warehouse, comece com Fabric Data Warehouse. As cargas de trabalho existentes de pools de SQL dedicados podem ser atualizadas para Fabric para acessar novos recursos em ciência de dados, análise em tempo real e relatórios.

A criptografia de dados transparente (TDE) com chave gerenciada pelo cliente (CMK) possibilita o cenário Bring Your Own Key (BYOK) para proteção de dados em repouso e possibilita que as organizações implementem separação de funções no gerenciamento de chaves e dados. Ao usar TDE gerenciado pelo cliente, você assume a responsabilidade e tem controle total sobre o gerenciamento do ciclo de vida das chaves (criação, upload, rotação, exclusão), permissões de uso de chaves e auditoria das operações sobre chaves.

Nesse cenário, o protetor Transparent Data Encryption (TDE) é uma chave gerenciada pelo cliente que protege a Chave de Criptografia do Banco de Dados (DEK). Você armazena o protetor TDE no Azure Key Vault ou no Azure Key Vault Managed HSM, que são serviços seguros de gerenciamento de chaves baseados em nuvem, projetados para alta disponibilidade e escalabilidade. Ambos os serviços suportam chaves criptográficas protegidas por hardware validado FIPS 140-2: o Azure Key Vault suporta o FIPS 140-2 Nível 2, e o Azure Key Vault Managed HSM suporta o FIPS 140-2 Nível 3. Ambos os serviços também suportam tipos de chave assimétricas e simétricas, e os algoritmos suportados e o uso dependem do modelo de implantação do TDE. Você pode gerar a chave no serviço, importá-la ou transferi-la com segurança de HSMs locais. O acesso direto às chaves é restrito, então serviços autorizados realizam operações criptográficas sem expor o material da chave.

Note

Este artigo aborda pools SQL dedicados independentes (anteriormente SQL DW).

  • Para pools SQL dedicados do Azure Synapse Analytics (anteriormente SQL DW), defina o protetor TDE no nível do servidor. Todos os bancos de dados criptografados associados a esse servidor herdam o protetor TDE.
  • Criptografe os dados em pools SQL dedicados e pools SQL serverless em um workspace Synapse usando a chave gerenciada pelo cliente configurada no nível do workspace. Para obter mais informações sobre a criptografia de dados transparente para pools de SQL dedicados dentro de workspaces do Synapse, consulte a criptografia do Azure Synapse Analytics.

CMK (Chave Gerenciada pelo Cliente) e BYOK (Bring Your Own Key)

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

  • Chave Gerenciada pelo Cliente (CMK) - Você gerencia o ciclo de vida da chave, incluindo criação, rotação e exclusão de chaves. Armazene a chave no Azure Key Vault ou no Azure Managed HSM e use-a para criptografia da Chave de Criptografia do Banco de Dados (DEK).

  • Traga Sua Própria Chave (BYOK) - Você traz ou importa sua própria chave de forma segura de um módulo de segurança de hardware local (HSM) para o Azure Key Vault. Essas chaves importadas podem ser usadas como qualquer outra chave no Azure Key Vault, inclusive como uma Chave Gerenciada pelo Cliente para criptografia do DEK. Para obter mais informações, confira 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:

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

  • Transparência do uso do protetor de TDE.

  • Capacidade de implementar a separação de tarefas no gerenciamento de chaves e dados dentro da organização.

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

  • Gerenciamento central de chaves no Azure Key Vault.

  • Maior confiança de seus clientes finais, já que o Azure Key Vault foi projetado para que a Microsoft não possa ver nem extrair chaves de criptografia.

Importante

Para quem usa TDE gerenciado pelo serviço e quer passar a usar TDE gerenciado pelo cliente, os dados permanecem criptografados durante a transição, e não há indisponibilidade nem nova criptografia dos arquivos do banco de dados. A mudança de uma chave gerenciada pelo serviço para uma chave gerenciada pelo cliente requer apenas a nova criptografia da DEK, que é uma operação rápida e online.

Permissões para configurar TDE gerenciado pelo cliente no Azure Key Vault

Selecione o tipo de Azure Key Vault que você deseja usar.

Para que o servidor lógico SQL no Azure use o protetor TDE armazenado no Azure Key Vault para criptografia do DEK, o Administrador do Key Vault precisa conceder direitos de acesso ao servidor usando sua identidade única do 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 acesso ao cofre de chaves a um usuário, grupo ou aplicativo. Este método é recomendado por sua flexibilidade e granularidade. A identidade do servidor precisa da função Key Vault Crypto Service Encryption User para usar a chave em operações de criptografia e descriptografia.

  • Política de acesso ao cofre de chaves - 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 das seguintes permissões no cofre de chaves:

    • get – para recuperar a parte pública e as propriedades da chave no Azure Key Vault
    • wrapKey – para poder proteger (criptografar) a DEK
    • unwrapKey – para poder desproteger (descriptografar) a DEK

No menu Configuração de acesso do portal do Azure, você tem a opção de selecionar controle de acesso baseado em função do Azure ou política de acesso ao cofre. Para obter instruções passo a passo sobre como configurar o acesso ao Azure Key Vault para TDE, consulte Set up SQL Server TDE Extensible Key Management by using Azure Key Vault. Para obter mais informações sobre os modelos de acesso, confira Segurança do Azure Key Vault.

O administrador do cofre de chaves também pode habilitar o registro em log de eventos de auditoria do cofre de chaves, para que eles possam ser auditados posteriormente.

Quando você configura um servidor para usar um protetor TDE do Azure Key Vault, o servidor envia o DEK de cada banco de dados habilitado por TDE para o cofre de chaves para ser criptografado. O cofre de chaves retorna o DEK criptografado, que o servidor armazena no banco de dados de usuários.

Quando necessário, o servidor envia o DEK protegido para o cofre de chaves para descriptografá-lo.

Auditores podem usar o Azure Monitor para revisar os logs AuditEvent do Azure Key Vault se o log estiver ativado.

Note

Pode levar cerca de 10 minutos para que qualquer alteração de permissão entre em vigor no cofre de chaves. Esse período inclui revogar permissões de acesso ao protetor TDE no AKV, e os usuários ainda podem ter permissões de acesso.

Requisitos para configurar o TDE gerenciado pelo cliente no Azure Key Vault

  • Ative os recursos exclusão reversível e proteção contra purga no Azure Key Vault. Essa configuração ajuda a prevenir a exclusão acidental ou maliciosa do cofre de chaves ou das chaves, que pode levar o banco de dados a entrar no estado Inacessível. Quando você configura o protetor TDE em um servidor existente ou durante a criação do servidor, o SQL do Azure valida que o cofre de chaves que você está usando tem a exclusão reversível e a proteção contra purga habilitadas. Se a exclusão temporária e a proteção contra limpeza não estiverem habilitadas no cofre de chaves, a configuração do protetor de TDE falhará com um erro. Nesse caso, ative a exclusão reversível e a proteção contra limpeza definitiva no cofre de chaves e, em seguida, configure o protetor do TDE.

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

Principais requisitos para configurar o protetor de TDE

A Transparent Data Encryption com chaves gerenciadas pelo cliente utiliza uma chave externa, chamada de protetor TDE, armazenada no Azure Key Vault para proteger a chave de criptografia do banco de dados (DEK).

Os requisitos a seguir se aplicam.

Tipos e tamanhos de chave com suporte

O protetor do TDE pode ser protegido por chaves assimétricas armazenadas no Azure Key Vault. Os tamanhos de chave suportados são 2.048 bits e 3.072 bits.

Requisitos principais de estado e validade

  • Se você especificar uma data de ativação da chave, defina-a para uma data e hora no passado.
  • Se você especificar uma data de validade da chave, defina para uma data e hora futuras.
  • A chave precisa estar no estado Habilitado.

Principais requisitos de importação

Se você importar uma chave existente no Azure Key Vault, forneça a chave em um dos seguintes formatos suportados:

  • .pfx
  • .byok
  • .backup

Recomendações para configurar TDE gerenciado pelo cliente no Azure Key Vault

Para manter a alta disponibilidade e evitar problemas de limitação, siga estas diretrizes por assinatura:

  • Para garantir desempenho e confiabilidade ideais, utilize um Azure Key Vault dedicado para SQL do Azure. Não compartilhe esse cofre de chaves com outros serviços. Se o cofre de chaves estiver sob grande carga devido ao uso compartilhado ou operações excessivas de chaves, isso pode afetar negativamente o desempenho do banco de dados, especialmente durante o acesso à chave de criptografia. O Azure Key Vault impõe limites de limitação. Quando esses limites são excedidos, as operações podem ser atrasadas ou falhar. Esse risco é maior durante failovers de servidores, que acionam operações de chave para todos os bancos de dados do servidor.

    Para mais informações sobre comportamento de limitação, veja as orientações sobre limitação do Azure Key Vault.

    • O número de bancos de dados Hyperscale que você pode associar a um único Azure Key Vault depende do número de servidores de página. Cada servidor de página é vinculado a um arquivo de dados lógico. Para encontrar 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ágina a um único Azure Key Vault. À medida que o banco de dados aumenta, o número de servidores de página aumenta automaticamente, portanto, é 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 banco de dados Hyperscale e não compartilhe esse cofre de chaves com outros recursos SQL do Azure.

    • Monitore e configure alertas do Azure Key Vault. Para mais informações sobre monitoramento e alertas, veja Monitorar Azure Key Vault e Configurar alertas do Azure Key Vault.

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

  • Habilitar auditoria e relatórios em todas as chaves de criptografia: o Azure Key Vault fornece logs fáceis de injetar em outras ferramentas de gerenciamento de eventos e informações de segurança. O Operations Management Suite Log Analytics é um exemplo de um serviço que já está integrado.

  • Use um cofre de chaves de uma região do Azure que possa replicar seu conteúdo para uma região emparelhada, garantindo a 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.

Recomendações para configurar o protetor de TDE

  • Mantenha uma cópia do protetor TDE em um local seguro ou deposite-o em um serviço de custódia.

  • Se você gerar a chave no cofre de chaves, crie um backup de chave antes de usar a chave no Azure Key Vault pela primeira vez. Você só pode restaurar o backup para um Azure Key Vault. Para saber mais, veja o comando Backup-AzKeyVaultKey . O Azure Managed HSM suporta a 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ções. Para obter mais informações, consulte Backup e restauração completos e restauração de chave seletiva.

  • Crie um novo backup sempre que fizer qualquer alteração na chave (por exemplo, atributos da chave, tags, ACLs).

  • Mantenha versões anteriores da chave no cofre de chaves ou no HSM Gerenciado ao fazer a rotação das chaves, para que você possa restaurar backups mais antigos do banco de dados. Quando o protetor TDE muda para um banco de dados, backups antigos do banco não são atualizados para usar o protetor TDE mais recente. No momento da restauração, cada backup precisa do protetor de TDE com o qual foi criptografado no momento da criação. Para rotacionar chaves, siga as instruções no artigo Rotacionar o protetor da Transparent Data Encryption (TDE).

  • Mantenha todas as chaves usadas anteriormente no Azure Key Vault mesmo após mudar para chaves gerenciadas pelo serviço. Ele garante que backups do banco de dados possam ser restaurados com os protetores TDE armazenados no Azure Key Vault. Os protetores TDE criados com o Azure Key Vault precisam ser mantidos até que todos os backups armazenados restantes sejam criados com chaves gerenciadas pelo serviço. Faça cópias de backup recuperáveis dessas chaves usando o 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 (Transparent Data Encryption) usando o PowerShell. Sempre gire para um novo protetor de TDE e verifique se todos os bancos de dados estão usando a nova chave antes de excluir ou desabilitar a chave comprometida. Excluir ou desabilitar a chave sem antes rotacioná-la faz com que todos os bancos de dados criptografados se tornem inacessíveis e não invalida nenhuma cópia da chave que tenha sido anteriormente armazenada em backup e restaurada em outro cofre.

Rotação do protetor de TDE

Quando você gira o protetor TDE, você substitui a chave que protege a chave de criptografia do banco de dados (DEK). A rotação de chaves é uma operação online e leva apenas alguns segundos. Essa operação descriptografa e recriptografa apenas a chave de criptografia do banco de dados, não todo o banco de dados.

Você pode rotacionar o protetor TDE mudando a configuração para usar uma nova chave armazenada no Azure Key Vault. Dependendo da oferta e da configuração suportada, essa chave pode ser:

  • Mudar para uma nova versão da mesma chave
  • Alternar para uma chave diferente

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

Você pode ativar a rotação automática do protetor TDE ao configurar o protetor TDE para o servidor. A rotação automática é desativada por padrão. Quando ativado, o servidor verifica continuamente o cofre de chaves em busca de novas versões da chave usada como protetor TDE. Se o servidor detectar uma nova versão da chave, ele automaticamente rotaciona o protetor TDE no servidor ou banco de dados para a versão mais recente da chave em até 24 horas.

Note

Quando você configura o TDE com CMK usando rotação manual ou automatizada das chaves, sempre usa a versão mais recente da chave que o sistema suporta. 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 é conforme com a política de segurança do SQL do Azure que não permite versões de chave anteriores que poderiam estar comprometidas.

Protetor de TDE inacessível

Quando você configura o TDE para usar uma chave gerenciada pelo cliente, o banco de dados precisa de acesso contínuo ao protetor TDE para permanecer online. Se o servidor perder o acesso ao protetor TDE gerenciado pelo cliente no Azure Key Vault, o banco de dados começa a negar todas as conexões em até 10 minutos, exibe uma mensagem de erro e altera seu estado para Inacessível. A única ação permitida em um banco de dados no estado Inacessível é a exclusão.

Estado inacessível

Se o banco de dados estiver inacessível devido a uma interrupção de rede intermitente (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 Azure Key Vault, o serviço introduz um buffer de 24 horas antes de tentar 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 devido a qualquer erro do Azure Key Vault (como um erro 4XX), o banco de dados passa para um estado inacessível após 30 minutos.

Restaurar o acesso ao banco de dados após um erro no Azure Key Vault

Depois que o acesso à chave é restaurado, colocar o banco de dados online novamente requer tempo e etapas adicionais, que podem variar de acordo com a duração da indisponibilidade da chave e o tamanho dos dados dentro do banco de dados.

Se o acesso à chave for restaurado dentro de 30 minutos, o banco de dados será recuperado automaticamente na 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, restaurar o banco de dados envolve procedimentos extras por meio do portal do Azure e pode ser demorado, dependendo do tamanho do banco de dados.

Depois que o banco de dados estiver online novamente, configurações de nível de servidor previamente definidas, incluindo configurações de grupo de failover, marcas e configurações no nível do banco de dados, como configurações de pool elástico, escala de leitura, pausa automática, histórico de restauração pontual, política de retenção de longo prazo e outras, são perdidas. Portanto, é recomendável que os clientes implementem um sistema de notificação para detectar a perda de acesso à chave de criptografia dentro de 30 minutos. Depois que a janela de 30 minutos tiver expirado, aconselhamos validar todas as configurações de nível de servidor e banco de dados no banco de dados recuperado.

Veja a seguir uma exibição das etapas extras necessárias no portal para colocar um banco de dados inacessível novamente online.

Revogação acidental do acesso do protetor de TDE

Isso pode acontecer de alguém com direitos de acesso suficientes ao cofre de chaves ou ao HSM gerenciado desabilitar acidentalmente o acesso do servidor à chave ao:

  • revogar as permissões get, wrapKey, unwrapKey do cofre de chaves ou do HSM gerenciado do servidor

  • excluir a chave

  • excluindo o Key Vault ou o HSM gerenciado

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

  • excluir 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 Instância Gerenciada de SQL e Azure Key Vault

O bloco de conectividade de rede entre a Instância Gerenciada de SQL e o cofre de chaves ou o HSM gerenciado ocorre principalmente quando o cofre de chaves ou o recurso HSM gerenciado existe, mas seu ponto de extremidade não pode ser acessado 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, há ausência de permissões, entre outros, fazem com que os bancos de dados alterem seu estado para Inacessível.

As causas mais comuns para a falta de conectividade de rede ao Azure Key Vault são:

  • O Azure Key Vault é exposto via endpoint privado e o endereço IP privado do serviço Azure Key Vault não é permitido nas regras de saída do Network Security Group (NSG) associado à sub-rede de instâncias gerenciadas.

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

Teste a conectividade do Instância Gerenciada de SQL para o Azure Key Vault que hospeda o protetor TDE.

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

Caso o teste retorne TcpTestSucceededed: False, examine a configuração de rede:

  • Verifique o endereço IP resolvido e confirme se ele tem valor. Um valor ausente significa que há problemas com a resolução 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 a configuração dele etc.

Monitorar o TDE gerenciado pelo cliente

Para monitorar o estado do banco de dados e habilitar o alerta para perda de acesso ao protetor do 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" após a negação da primeira conexão ao banco de dados.

  • Entradas são adicionadas ao log de atividades quando o acesso ao protetor de TDE no cofre de chaves gerenciado pelo cliente falha. Ao criar alertas para esses eventos, você pode restabelecer 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, Voz, Logic App, Webhook, ITSM ou Automation Runbook.

Backup e restauração do banco de dados com TDE gerenciado pelo cliente

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

Para restaurar um backup criptografado com um protetor TDE do Azure Key Vault, certifique-se de que o material da chave esteja disponível para o servidor alvo. Portanto, mantenha todas as versões antigas do protetor TDE em key vault ou HSM gerenciado, para que backups do banco de dados possam ser restaurados.

Importante

Não pode haver mais de um conjunto de protetores de TDE para um servidor a qualquer momento. A chave marcada com Tornar a chave o protetor de TDE padrão no painel do portal do Azure é o protetor de TDE. No entanto, várias chaves podem ser vinculadas a um servidor sem marcá-las como um protetor de TDE. Essas chaves não são usadas para proteger o 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 servidor de destino <Servername> não tem acesso a todos os URIs do AKV criados entre <Timestamp #1> e <Timestamp #2>. Tente realizar a operação novamente depois de restaurar todos os URIs do 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 que estão ausentes. Para garantir que todos os backups possam ser restaurados, verifique se o servidor de destino para a restauração tem acesso a todas essas chaves necessárias. Essas chaves não precisam ser marcadas como protetor de TDE.

Para saber mais sobre a recuperação de backup para pools de SQL dedicados no Azure Synapse Analytics, confira Recuperar um pool de SQL dedicado.

Consideração adicional para arquivos de log: Os arquivos de log de backup permanecem criptografados com o protetor original do TDE, mesmo que este tenha sido alterado e o banco de dados esteja agora usando um novo protetor do 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 Azure Key Vault, essa chave é necessária no momento da restauração, mesmo que o banco de dados tenha sido alterado para usar TDE gerenciado pelo serviço nesse meio tempo.

Alta disponibilidade com o TDE gerenciado pelo cliente

Ao usar as múltiplas camadas de redundância do Azure Key Vault, os TDEs que utilizam uma chave gerenciada pelo cliente podem se beneficiar da disponibilidade e resiliência do Azure Key Vault. Eles podem confiar totalmente na solução de redundância do Azure Key Vault.

As múltiplas camadas de redundância do Azure Key Vault garantem acesso à chave mesmo que componentes individuais de serviço falhem ou regiões ou zonas de disponibilidade do Azure estejam fora do ar. Para obter mais informações, confira Disponibilidade e redundância do Azure Key Vault.

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

Conteúdo relacionado

  • Última atualização em