Fiabilidade no Azure Key Vault Managed HSM

O Azure Key Vault Managed HSM é um serviço cloud totalmente gerido, altamente disponível, de inquilino único e compatível com os padrões que lhe permite proteger chaves criptográficas para as suas aplicações cloud utilizando módulos de hardware de segurança validados (HSMs) FIPS 140-3 Nível 3. O HSM gerido oferece uma série de funcionalidades de fiabilidade integradas para ajudar a garantir que as suas chaves permanecem disponíveis.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como o HSM gerido é resiliente a uma variedade de potenciais falhas e problemas, incluindo falhas transitórias, falhas de hardware e interrupções regionais. Descreve também como pode usar backups e o domínio de segurança para recuperar de outros tipos de problemas, funcionalidades de recuperação para evitar eliminações acidentais e destaca algumas informações chave sobre o acordo de nível de serviço (SLA) do HSM Gerido.

Recomendações de implantação de produção para confiabilidade

Para cargas de trabalho de produção, recomendamos que:

Visão geral da arquitetura de confiabilidade

Quando usas HSM Gerido, implementas uma instância, que por vezes também é chamada pool.

O HSM gerido é concebido para alta disponibilidade e durabilidade através da sua arquitetura:

  • Isolamento de inquilino único: Cada instância de HSM gerida é dedicada a um único cliente e consiste num cluster de múltiplas partições HSM que estão criptograficamente isoladas.

  • Partições tripla redundantes: Um pool HSM gerido consiste em três partições HSM balanceadas em carga distribuídas por racks separados dentro de um centro de dados. Esta distribuição proporciona redundância contra falhas de hardware e garante que a perda de um único componente (como a fonte de alimentação de um rack ou um switch de rede) não afete todas as partições.

  • Computação confidencial: Cada instância de serviço corre num ambiente de execução confiável (TEE) que utiliza enclaves Intel SGX. O pessoal da Microsoft, incluindo aqueles com acesso físico aos servidores, não pode aceder ao material da sua chave criptográfica.

  • Cura automática: Se uma falha de hardware ou outro problema afetar uma das três partições, o serviço reconstrói automaticamente a partição afetada em hardware saudável sem qualquer intervenção do cliente e sem expor segredos.

Para mais informações sobre como o HSM Gerido implementa estas capacidades, consulte Supremania, disponibilidade, desempenho e escalabilidade no HSM Gerido.

Domínio de segurança

O domínio da segurança é um componente crítico para a recuperação de desastres. É um blob encriptado que contém todas as credenciais necessárias para reconstruir uma instância de HSM gerida do zero, incluindo a chave proprietária da partição, as credenciais da partição, a chave de enrolamento de dados e um backup inicial do HSM.

Importante

Sem o domínio de segurança, a recuperação de desastres não é possível. A Microsoft não tem forma de recuperar o domínio de segurança e não pode aceder às suas chaves sem ele.

Os domínios de segurança são uma parte crítica da segurança e fiabilidade do seu HSM Gerido. Recomendamos que siga estas melhores práticas:

  • Gerar chaves de forma segura: Para ambientes de produção, gere os pares de chaves RSA que protegem o domínio de segurança num ambiente isolado (como um HSM local ou uma estação de trabalho isolada).
  • Armazenar offline: Armazenar chaves de domínio de segurança em pen drives USB encriptados ou outro armazenamento offline, com cada partilha de chaves num dispositivo separado em locais geográficos distintos.
  • Estabeleça um quórum de múltiplas pessoas: Use pelo menos três detentores de chave para impedir que qualquer pessoa tenha acesso a todas as chaves de quórum e para evitar dependência de qualquer pessoa.

Para obter mais informações, consulte Visão geral do domínio de segurança no HSM gerenciado.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Quando usa serviços Azure que se integram com HSM Gerido, esses serviços tratam automaticamente falhas transitórias.

Se construir aplicações personalizadas que se integram com HSM Gerido, considere as seguintes melhores práticas para lidar com quaisquer falhas transitórias que possam ocorrer:

  • Utilize, os SDKs fornecidos pela Microsoft para o Azure Key Vault, que incluem mecanismos de repetição incorporados. Existem SDKs disponíveis para .NET, Python e JavaScript.

  • Implemente lógica de retentativa quando interajam diretamente com o HSM Gerido, incluindo políticas de retentativas de recuo exponencial.

  • Reduza o número de dependências diretas no HSM Gerido. Armazene em cache os resultados de operações criptográficas sempre que possível para reduzir pedidos diretos ao HSM Gerido. Para operações de chave pública, como criptografia, encapsulamento e verificação, execute essas operações localmente armazenando em cache o material de chave pública. Realizar as operações localmente reduz a dependência do seu HSM gerido e evita falhas transitórias que interrompam essas operações.

Se usar o HSM gerido em cenários de alto rendimento, note que o HSM gerido não limita as operações criptográficas. Utiliza o seu hardware HSM a plena capacidade. Cada instância de HSM gerida tem três partições. Durante operações de manutenção ou reparação, uma partição pode não estar disponível. Para o planeamento da capacidade, assuma que existem duas partições disponíveis. Se precisar de rendimento garantido, planeie com base na disponibilidade de uma partição. Monitorize a métrica de Disponibilidade de HSM Gerida para compreender o estado do serviço.

Para escalar a encriptação de grandes quantidades de dados, utilize-se uma hierarquia de chaves onde apenas a chave de encriptação de chaves (KEK) é armazenada no HSM Gerido e usada para envolver chaves de nível inferior que são armazenadas noutro local seguro de armazenamento de chaves.

Para referências detalhadas de desempenho e orientações de planeamento de capacidade, consulte Azure Managed HSM Scaling Guidance.

Resiliência a falhas nas partições

O HSM gerido alcança alta disponibilidade através da sua arquitetura tripla redundante, onde cada pool HSM consiste em três partições HSM distribuídas por racks de servidores separados dentro de um centro de dados. Esta distribuição ao nível do rack proporciona redundância contra falhas localizadas de hardware.

Diagrama que mostra as três partições de um pool HSM Gerido, cada uma num servidor físico separado e num rack de servidores diferente.

Quando ocorrem falhas de hardware ou falhas localizadas, o HSM gerido redireciona automaticamente os seus pedidos para partições saudáveis e reconstrói as partições afetadas através de um processo chamado cura de serviço confidencial. Partições falhadas são automaticamente reconstruídas em hardware saudável usando enclaves atestados TLS e Intel SGX para proteger segredos durante a recuperação.

Custo

Não existem custos adicionais associados à alta disponibilidade incorporada no HSM Gerido. O preço baseia-se no número de pools HSM e no número de operações efetuadas. Para obter mais informações, consulte Preços do HSM gerenciado do Azure.

Comportamento quando todas as partições funcionam corretamente

Esta secção descreve o que esperar quando os pools de HSM geridos estão operacionais e nenhuma partição está indisponível.

  • Encaminhamento de tráfego: O HSM gerido automaticamente gere o tráfego através das suas três partições. Durante as operações normais, os pedidos são distribuídos entre as partições de forma transparente.

  • Replicação de dados: Todos os dados, incluindo chaves, atribuições de funções e políticas de controlo de acesso, são replicados de forma síncrona entre as três partições. Isto garante consistência e disponibilidade mesmo que uma partição se torne indisponível.

Comportamento durante uma falha de partição

Esta secção descreve o que esperar quando uma ou mais partições se tornam indisponíveis.

  • Deteção e resposta: O serviço HSM gerido é responsável por detetar falhas de partição e responder automaticamente a elas. Não é necessário tomar qualquer medida durante uma falha de partição.

  • Pedidos ativos: Durante uma falha de partição, os pedidos em voo para a partição afetada podem falhar e exigir que as aplicações cliente os tentem novamente. Para minimizar os efeitos das falhas de partição, as aplicações cliente devem seguir práticas de tratamento de falhas transitórias.

  • Perda de dados esperada: Não se espera perda de dados durante uma falha de partição devido à replicação síncrona entre partições.

  • Tempo de inatividade esperado: Para operações de leitura e a maioria das operações criptográficas, deve haver pouco ou nenhum tempo de inatividade durante uma falha de partição. As partições restantes e saudáveis continuam a atender pedidos.

  • Redirecionamento de tráfego: O HSM gerido redireciona automaticamente o tráfego da partição afetada para partições saudáveis sem necessidade de intervenção do cliente.

Recuperação de partições

Quando a partição afetada recupera, o HSM Gerido restaura automaticamente as operações através de recuperação confidencial do serviço. Este processo:

  1. Cria uma nova instância de serviço em hardware saudável.
  2. Estabelece uma ligação TLS atestada com a partição principal.
  3. Troca de forma segura credenciais e material criptográfico.
  4. Sela os dados de serviço ao novo CPU.

A plataforma Azure gerencia totalmente esse processo e não requer nenhuma intervenção do cliente.

Resiliência a falhas na zona de disponibilidade

A elevada disponibilidade do HSM gerido baseia-se na distribuição ao nível do rack dentro de um datacenter, e não na implementação explícita em zonas de disponibilidade. Cada partição corre num servidor separado num rack diferente, o que protege contra falhas ao nível do rack, como problemas na fonte de alimentação ou no switch de rede.

Se precisar de ser resiliente a falhas em datacenters ou zonas de disponibilidade, considere usar uma das abordagens para resiliência a falhas regionais.

Resiliência a falhas em toda a região

Os recursos geridos de HSM são implementados numa única região Azure. Se a região ficar indisponível, o seu HSM Gerido também ficará indisponível. No entanto, existem abordagens que pode usar para ajudar a garantir resiliência face a falhas regionais.

Replicação multi-região

O HSM gerido suporta replicação opcional multi-região, o que permite expandir um pool de HSM gerido de uma região Azure (a região principal) para uma segunda região Azure (a região estendida). Uma vez configurado:

  • Ambas as regiões são ativas e capazes de atender pedidos.
  • Material-chave, funções e permissões são automaticamente replicados entre regiões.
  • Os pedidos são encaminhados para a região disponível mais próxima usando o Azure Traffic Manager.
  • O SLA combinado aumenta.

Requirements

  • Suporte para regiões: Todas as regiões HSM geridas pelo Azure são suportadas como regiões primárias. Não há dependência nas associações de regiões Azure.

    O HSM gerido não suporta todas as regiões como regiões estendidas. Para mais informações, consulte o suporte para regiões Azure.

  • Número máximo de regiões: Podes adicionar uma região estendida, num máximo de duas regiões no total.

Custo

A replicação multi-região implica faturação adicional porque um segundo pool HSM é consumido na região alargada. Para obter mais informações, consulte Preços do HSM gerenciado do Azure.

Configurar a replicação em várias regiões

Comportamento quando todas as regiões estão saudáveis

Quando a replicação multi-região está ativada e ambas as regiões estão operacionais:

  • Encaminhamento de tráfego: Todas as regiões podem atender pedidos. O Azure Traffic Manager encaminha pedidos para a região com a maior proximidade geográfica ou menor latência.

    Se usares Private Link, configura endpoints privados em ambas as regiões para um encaminhamento ótimo durante o failover. Para mais informações, veja Comportamento de ligação privada com replicação multi-região.

  • Replicação de dados: Todas as alterações às chaves, definições de funções e atribuições de funções são replicadas de forma assíncrona para a região estendida em seis minutos. Espere seis minutos após criar ou atualizar uma chave antes de a usar na região estendida.

Comportamento durante uma interrupção regional

Quando a replicação multi-região está ativada e uma região sofre uma falha:

  • Deteção e resposta: O Azure Traffic Manager deteta a região pouco saudável e encaminha pedidos futuros para a região saudável. Os registos DNS têm um TTL de cinco segundos, embora os clientes que fazem buscas DNS em cache possam experienciar tempos de failover ligeiramente mais longos.
  • Notification: A Microsoft não o notifica automaticamente quando uma região está inoperante. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

  • Pedidos ativos: Pedidos em voo para a região afetada podem falhar e exigir uma nova tentativa.

  • Perda de dados esperada: Pode haver perda de dados para alterações feitas dentro de seis minutos antes da falha da região se essas alterações não tivessem concluído a replicação.

  • Tempo de inatividade previsto: Tanto as operações de leitura como de escrita permanecem disponíveis na região saudável durante o failover.

    Aplicações cliente próximas da região insalubre podem continuar a ser direcionadas para essa região até que os registos DNS sejam atualizados, mas esta atualização ocorre em aproximadamente cinco segundos. Para minimizar o tempo de failover, os clientes devem evitar guardar em cache as consultas DNS por mais tempo do que o TTL do registo DNS.

  • Redirecionamento: O Azure Traffic Manager redireciona automaticamente os pedidos para a região saudável.

Recuperação da região

Quando a região afetada recupera, o HSM gerido retoma automaticamente as operações. O Gestor de Tráfego começa novamente a encaminhar pedidos para ambas as regiões com base na proximidade.

Teste para falhas regionais

O Managed HSM gere totalmente o encaminhamento do tráfego, o failover e o failback para falhas de região, portanto não é necessário validar processos de falha de região nem fornecer qualquer informação adicional.

Soluções personalizadas de várias regiões para resiliência

Se a replicação multi-região não for adequada para as suas necessidades, pode implementar recuperação manual de desastres. Isto requer:

  • O domínio de segurança do HSM de origem.
  • As chaves privadas (pelo menos o número de quórum) que encriptam o domínio de segurança.
  • Um backup HSM completo recente da HSM de origem.

Para realizar recuperação de desastres:

  1. Crie uma nova instância de HSM gerido numa região diferente.
  2. Ative o modo de recuperação do domínio de segurança e carregue o domínio de segurança.
  3. Faz uma cópia de segurança do novo HSM (obrigatório antes da restauração).
  4. Restaure o backup a partir do HSM de origem.

Importante

O novo HSM tem um nome diferente e um URI de endpoint de serviço diferente. Deve atualizar a configuração da sua aplicação para usar a nova localização.

Para procedimentos detalhados de recuperação de desastres, consulte Recuperação de desastres de HSM gerida.

Backup e restauração

O HSM gerido suporta backup e restauro completos de todas as chaves, versões, atributos, etiquetas e atribuições de funções. Os backups são armazenados numa conta Azure Storage. Se a sua região o suportar, recomendamos que faça backup do seu HSM gerido numa conta Azure Storage que tenha o armazenamento geo-redundante (GRS) ativado.

Os backups são encriptados usando chaves criptográficas associadas ao domínio de segurança do HSM e só podem ser restaurados num HSM com o mesmo domínio de segurança.

O HSM gerido não suporta backups de agendamento, mas podes construir o teu próprio agendador usando um serviço como Azure Functions ou Azure Automation.

Enquanto um backup está em curso, o HSM pode não operar a plena taxa porque algumas partições estão ocupadas a realizar a operação de backup.

Para procedimentos detalhados de backup e restauro, consulte Backup e restauro completos.

Resiliência à eliminação acidental

O HSM gerido oferece duas funcionalidades principais de recuperação para evitar eliminações acidentais ou maliciosas:

  • Eliminação suave: Quando elimina um HSM ou uma chave, esta permanece recuperável durante um período de retenção configurável (7 a 90 dias, por defeito 90 dias). O soft-delete está sempre ativado e não pode ser desativado.

    Note

    Os recursos de HSM geridos com deleção suave continuam a ser faturados até serem eliminados.

  • Proteção contra purgas: Quando ativada, impede a eliminação permanente do seu HSM Gerido e das suas chaves até ao fim do período de retenção. A proteção contra purgas não pode ser desativada ou anulada por ninguém, incluindo a Microsoft.

Recomendamos vivamente permitir a proteção contra purgas em ambientes de produção. Para mais informações, consulte Proteção contra eliminação suave e purga de HSM gerida.

Resiliência à manutenção de serviços

O HSM gerido gere a manutenção do serviço, incluindo atualizações de firmware, patches e recuperação de hardware, sem intervenção do cliente. Durante a manutenção:

  • As partições podem ficar temporariamente indisponíveis enquanto as atualizações são aplicadas.
  • Pelo menos duas das três divisórias permanecem disponíveis durante a manutenção de rotina.
  • As suas aplicações cliente devem implementar lógica de repetição para gerir interrupções breves.

O processo confidencial de cura por serviço garante que segredos nunca sejam expostos durante as operações de manutenção.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para mais informações, consulte Acordos de Nível de Serviço (SLA) para serviços online.

O HSM gerido fornece um SLA padrão para implantações numa única região. Quando se ativa a replicação multi-região, o SLA combinado para ambas as regiões aumenta.

Conteúdo relacionado

  • Last updated on