Customer-managed TDE for Azure Synapse Analytics

Aplica-se a: Pools SQL dedicados do Azure Synapse Analytics (anteriormente SQL DW)

Dica

Microsoft Fabric Data Warehouse é um armazém relacional de escala empresarial baseado numa base de data lake, com uma arquitetura pronta para o futuro, IA incorporada e novas funcionalidades. Se és novo no data warehousing, começa pelo Fabric Data Warehouse. As cargas de trabalho existentes de pool SQL dedicado podem atualizar para o Fabric para acessar novas capacidades em ciência de dados, análise em tempo real e relatórios.

A encriptação transparente de dados (TDE) com chave gerida pelo cliente (CMK) permite o cenário Bring Your Own Key (BYOK) para proteção de dados em repouso e permite às organizações implementar a separação de funções na gestão de chaves e dados. Ao usar TDE gerido pelo cliente, assume a responsabilidade por e tem controlo total sobre a gestão do ciclo de vida das chaves (criação, upload, rotação, eliminação), as permissões de utilização de chaves e a auditoria das operações nas 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.

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 ao nível do servidor. Todas as bases de dados encriptadas associadas a esse servidor herdam o protetor TDE.
  • Encripte os dados em pools SQL dedicados e pools SQL serverless num espaço de trabalho Synapse usando a chave gerida pelo cliente configurada ao nível do workspace. 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.

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 Gerida pelo Cliente (CMK) - Geres o ciclo de vida da chave, incluindo criação, rotação e eliminação de chaves. Armazene a chave no Azure Key Vault ou no Azure Managed HSM e utilize-a para encriptação da Chave de Encriptação da Base de Dados (DEK).

  • Traga a Sua Própria Chave (BYOK) - Pode trazer ou importar de forma segura a sua própria chave 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 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 gerida pelo cliente oferece os seguintes benefícios:

  • 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 quem usa TDE gerido por serviços e quer começar a usar TDE gerido pelo cliente, os dados permanecem encriptados durante o processo de transição, e não há tempo de inatividade ou reencriptação dos ficheiros da base 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 o TDE gerido pelo cliente no Azure Key Vault

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

Para que o servidor lógico SQL no Azure use 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 necessita do papel Key Vault Crypto Service Encryption User para usar a chave em operações de encriptação e desencriptação.

  • 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 necessita das 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 instruções passo a passo sobre como configurar uma configuração de acesso ao Azure Key Vault para TDE, consulte Configurar o SQL Server TDE Extensible Key Management 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 configuras um servidor para usar um protetor TDE do Azure Key Vault, o servidor envia o DEK de cada base de dados compatível com TDE para o cofre de chaves para encriptação. O cofre de chaves devolve o DEK encriptado, que o servidor armazena na base de dados do utilizador.

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

Os auditores podem usar o Azure Monitor para rever os registos AuditEvent do cofre de chaves se o registo estiver ativado.

Note

Pode demorar cerca de 10 minutos para que quaisquer alterações de permissão entrem em vigor para o cofre de chaves. Este período inclui revogar permissões de acesso ao protetor TDE no AKV, e os utilizadores podem ainda ter permissões de acesso.

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

  • Ative as funcionalidades de eliminação suave e proteção contra purga no Azure Key Vault. Esta configuração ajuda a prevenir a eliminação do cofre de chaves ou de chaves acidental ou maliciosa, que pode levar a base de dados a ficar no estado Inaccessible. Quando configuras o protetor TDE num servidor existente ou durante a criação do servidor, o SQL do Azure valida que o cofre de chaves que estás a usar tem a proteção contra eliminação suave e purga 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. Neste caso, ativa a proteção contra eliminação suave e purga no Key Vault e depois realiza a configuração do protetor TDE.

  • 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 para proteger a chave de encriptação da base de dados (DEK).

Aplicam-se os seguintes requisitos.

Tipos e tamanhos de chave suportados

O protetor TDE pode ser protegido por chaves assimétricas armazenadas no Azure Key Vault. Os comprimentos de chave suportados são de 2 048 bits e 3 072 bits.

Estado chave e requisitos de validade

  • Se especificar uma data de ativação da chave, defina-a para uma data e hora do passado.
  • Se especificar uma data de validade da chave, defina-a 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

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

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

  • 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 mais informações sobre comportamento de limitação, consulte as orientações de limitação do Azure Key Vault.

    • O número de bases de dados Hyperscale que pode associar a um único Azure Key Vault depende do número de servidores de páginas. Cada servidor de página está 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á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 mais informações sobre monitorização e alertas, consulte Monitorizar Azure Key Vault e Configurar alertas do Azure Key Vault.

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

Recomendações para configurar o protetor TDE

  • Guarde uma cópia do protetor TDE num local seguro ou envie-o em custódia para um serviço de escrow.

  • Se gerar a chave no cofre de chaves, crie um backup de chave antes de usar a chave no Azure Key Vault pela primeira vez. Só é possível restaurar a cópia de segurança para um Azure Key Vault. Para saber mais, consulte o comando Backup-AzKeyVaultKey. O Azure Managed HSM suporta a criação de uma cópia de segurança completa de todo o conteúdo do HSM, incluindo todas as chaves, versões, atributos, etiquetas e atribuições de funções. Para obter mais informações, consulte Backup e restauração completos e Restauração seletiva de chaves.

  • Crie uma nova cópia de segurança sempre que fizer alterações à chave (por exemplo, atributos da chave, etiquetas, 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).

  • Manter todas as chaves utilizadas anteriormente no Azure Key Vault, mesmo depois de mudar para chaves geridas pelo serviço. Garante que os backups da base de dados podem ser restaurados com os protetores TDE armazenados no Azure Key Vault. Os protetores TDE criados com o Azure Key Vault têm de ser mantidos até que todas as cópias de segurança restantes armazenadas sejam criadas com chaves geridas por serviços. Faça cópias de segurança recuperáveis destas 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 (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.

Rotação do protetor TDE

Ao rodar o protetor TDE, substitui a chave que protege a chave de encriptação da base de dados (DEK). A rotação de chaves é uma operação online e demora apenas alguns segundos. Esta operação desencripta e volta a encriptar apenas a chave de encriptação da base de dados, não toda a base de dados.

Podes rodar 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, esta chave pode ser:

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

A rotação do protetor TDE pode ser feita manualmente ou utilizando a funcionalidade de rotação automática.

Podes ativar a rotação automática do protetor TDE quando configuras o protetor TDE para o servidor. A rotação automatizada está desativada por predefinição. Quando ativado, o servidor verifica continuamente o cofre de chaves para novas versões da chave usada como protetor TDE. Se o servidor detetar uma nova versão da chave, roda automaticamente o protetor TDE no servidor ou base de dados para a versão mais recente da chave dentro de 24 horas.

Note

Quando defines o TDE com o CMK usando rotação manual ou automática das teclas, usas sempre 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 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.

Protetor TDE inacessível

Quando configura o TDE para usar uma chave gerida pelo cliente, a base de dados precisa de acesso contínuo ao protetor TDE para se manter online. Se o servidor perder o acesso ao protetor TDE gerido pelo cliente no Azure Key Vault, a base de dados começa a negar todas as ligações dentro de 10 minutos, apresenta uma mensagem de erro e altera o 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 aceder ao protetor TDE no Azure Key Vault, o serviço introduz um buffer de 24 horas antes de tentar mover a base 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 gerido pelo cliente no Azure Key Vault devido a qualquer erro do Azure Key Vault (como um erro 4XX), a base de dados passa para um estado inacessível após 30 minutos.

Restaurar o acesso à base de dados após um erro no Azure Key Vault

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.

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 o SQL Managed Instance e o Azure Key Vault

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

  • 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 do SQL Managed Instance para o Azure Key Vault que hospeda o protetor TDE.

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

No caso de o teste devolver TcpTestSucceeded: False, reveja a configuração da 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. Uma base de dados inacessível que perdeu o acesso ao protetor TDE aparece como "Não Disponível" após a recusa da primeira ligação à base de dados.

  • 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. Ao criar alertas para estes eventos, pode restabelecer o acesso o mais rapidamente possível.

  • Grupos de Ação podem ser definidos para lhe enviar notificações e alertas com base nas suas preferências, por exemplo, Email, SMS, Push, Voz, Logic App, Webhook, ITSM ou runbook de Automação.

Backup e restauro da base de dados com TDE gerido pelo cliente

Uma vez que uma base de dados é encriptada com TDE usando uma chave do Azure Key Vault, quaisquer backups recentemente gerados também são encriptados 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 encriptado com um protetor TDE do Azure Key Vault, certifique-se de que o material da chave está disponível para o servidor alvo. Por isso, mantenha todas as versões antigas do protetor TDE no cofre de chaves ou HSM gerido, para que os backups da base 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. Estas 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 ficheiro de backup estiver encriptado 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 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 ausentes. Para garantir que todas as cópias de segurança podem ser restauradas, certifique-se de que o servidor de destino para o restauro tem 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 pools SQL dedicados no Azure Synapse Analytics, consulte Recuperar um pool SQL dedicado.

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 ficheiro de registo estiver a usar um protetor TDE armazenado no Azure Key Vault, essa chave é necessária no momento da restauração, mesmo que a base de dados tenha sido alterada para usar TDE gerido pelo serviço entretanto.

Alta disponibilidade com TDE gerenciada pelo cliente

Ao utilizar as múltiplas camadas de redundância do Azure Key Vault, os TDEs que utilizam uma chave gerida pelo cliente podem beneficiar da disponibilidade e resiliência do Azure Key Vault. 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 o acesso às chaves mesmo que componentes individuais de serviço falhem ou que regiões ou zonas de disponibilidade do Azure estejam indisponíveis. Para obter mais informações, consulte Disponibilidade e redundância do Azure Key Vault.

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

Conteúdo relacionado

  • Última atualização a