Confiabilidade no HSM Gerenciado do Azure Key Vault

O HSM Gerenciado do Azure Key Vault é um serviço de nuvem totalmente gerenciado, altamente disponível, de locatário único e compatível com padrões que permite proteger chaves criptográficas para seus aplicativos de nuvem usando HSMs (módulos de segurança de hardware validados) fips 140-3 nível 3. O HSM gerenciado fornece uma variedade de recursos de confiabilidade internos para ajudar a garantir que suas chaves permaneçam disponíveis.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar 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 Gerenciado é resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, falhas de hardware e interrupções de região. Ele também descreve como você pode usar backups e o domínio de segurança para se recuperar de outros tipos de problemas, recursos de recuperação para evitar exclusão acidental e realça algumas informações importantes sobre o contrato de nível de serviço do HSM gerenciado (SLA).

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

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

Visão geral da arquitetura de confiabilidade

Ao usar o HSM Gerenciado, você implanta uma instância, que às vezes também é chamada de pool.

O HSM gerenciado foi projetado para alta disponibilidade e durabilidade por meio de sua arquitetura:

  • Isolamento de locatário único: cada instância de HSM gerenciada é dedicada a um único cliente e consiste em um cluster de várias partições HSM isoladas criptograficamente.

  • Partições com redundância tripla: um pool de HSM gerenciado consiste em três partições HSM com balanceamento de carga distribuídas entre racks separados em um datacenter. Essa distribuição fornece redundância contra falhas de hardware e garante que a perda de um único componente (como a fonte de alimentação ou o comutador de rede de um rack) não afete todas as partições.

  • Computação confidencial: cada instância de serviço é executada em um TEE (ambiente de execução confiável) que usa enclaves Intel SGX. O pessoal da Microsoft, incluindo aqueles com acesso físico aos servidores, não pode acessar seu material de chave criptográfica.

  • Recuperação automática: se uma falha de hardware ou outro problema afetar uma das três partições, o serviço recriará automaticamente a partição afetada em hardware íntegro sem nenhuma intervenção do cliente e sem expor segredos.

Para obter mais informações sobre como o HSM Gerenciado implementa esses recursos, consulte a soberania, a disponibilidade, o desempenho e a escalabilidade chave no HSM gerenciado.

Domínio de segurança

O domínio de segurança é um componente crítico para recuperação de desastre. É um blob criptografado que contém todas as credenciais necessárias para recompilar uma instância de HSM gerenciada do zero, incluindo a chave de proprietário da partição, as credenciais de partição, a chave de encapsulamento de dados e um backup inicial do HSM.

Importante

Sem o domínio de segurança, a recuperação de desastre não é possível. A Microsoft não tem como recuperar o domínio de segurança e não pode acessar suas chaves sem ele.

Os domínios de segurança são uma parte crítica da segurança e confiabilidade do HSM Gerenciado. Recomendamos que você siga estas práticas recomendadas:

  • Gerar chaves com segurança: para ambientes de produção, gere os pares de chaves RSA que protegem o domínio de segurança em um ambiente sem conexão com a rede (como um HSM interno ou uma estação de trabalho isolada).
  • Armazene offline: armazene chaves de domínio de segurança em unidades USB criptografadas ou outro armazenamento offline, com cada compartilhamento de chaves em um dispositivo separado em locais geográficos separados.
  • Estabeleça um quorum de várias pessoas: use pelo menos três titulares de chave para impedir que qualquer pessoa tenha acesso a todas as chaves de quorum e para evitar uma dependência em qualquer pessoa.

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

Resiliência a falhas transitórias

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

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

Quando você usa os serviços do Azure que se integram ao HSM Gerenciado, esses serviços lidam com falhas transitórias automaticamente.

Se você criar aplicativos personalizados que se integram ao HSM Gerenciado, considere as seguintes práticas recomendadas para lidar com quaisquer falhas transitórias que possam ocorrer:

  • Use os SDKs fornecidos pela Microsoft para o Azure Key Vault, que incluem mecanismos de repetição internos. Os SDKs estão disponíveis para .NET, Python e JavaScript.

  • Implemente a lógica de nova tentativa ao interagir diretamente com o HSM Gerenciado, incluindo políticas de backoff exponencial.

  • Reduza o número de dependências diretas no HSM Gerenciado. Armazena em cache os resultados da operação criptográfica quando possível para reduzir as solicitações diretas para o HSM Gerenciado. Para operações de chave pública, como criptografia, encapsulamento e verificação, execute essas operações localmente armazenando em cache o material da chave pública. Executar as operações localmente reduz a dependência do HSM Gerenciado e evita que falhas transitórias interrompam essas operações.

Se você usar o HSM Gerenciado em cenários de alta taxa de transferência, observe que o HSM Gerenciado não limita as operações criptográficas. Ele usa seu hardware HSM em sua capacidade total. Cada instância do HSM Gerenciado tem três partições. Durante operações de manutenção ou recuperação, uma partição pode estar indisponível. Para planejamento de capacidade, suponha que duas partições estejam disponíveis. Se você precisar de taxa de transferência garantida, planeje com base em uma partição disponível. Monitore a métrica de disponibilidade de HSM gerenciado para entender a integridade do serviço.

Para dimensionar a criptografia de grandes quantidades de dados, use uma hierarquia de chaves em que apenas a KEK (chave de criptografia de chave) seja armazenada no HSM Gerenciado e usada para encapsular chaves de nível inferior armazenadas em outro local de armazenamento de chave segura.

Para obter referências detalhadas de desempenho e diretrizes de planejamento de capacidade, consulte As diretrizes de dimensionamento de HSM gerenciado do Azure.

Resiliência a falhas de partição

O HSM gerenciado obtém alta disponibilidade por meio de sua arquitetura com redundância tripla, em que cada pool de HSM consiste em três partições de HSM distribuídas entre racks de servidor separados em um datacenter. Essa distribuição em nível de rack fornece redundância contra falhas de hardware localizadas.

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

Quando ocorrem falhas de hardware ou interrupções localizadas, o HSM Gerenciado redireciona automaticamente suas solicitações para partições íntegras e recria partições afetadas por meio de um processo chamado recuperação de serviço confidencial. Partições com falha são recriadas automaticamente em hardware íntegro usando enclaves TLS e Intel SGX atestados para proteger segredos durante a recuperação.

Custo

Não há custos extras associados à alta disponibilidade interna no Managed HSM. O preço é baseado no número de pools de HSM e no número de operações executadas. Para obter mais informações, consulte Preços do HSM Gerenciado do Azure.

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

Esta seção descreve o que esperar quando os pools de HSM gerenciados estão operacionais e nenhuma partição não está disponível.

  • Roteamento de tráfego: o HSM gerenciado automaticamente controla o roteamento de tráfego em suas três partições. Durante as operações normais, as solicitações são distribuídas entre partições de forma transparente.

  • Replicação de dados: todos os dados, incluindo chaves, atribuições de função e políticas de controle de acesso, são replicados de forma síncrona em todas as três partições. Isso garante a consistência e a disponibilidade mesmo se uma partição ficar indisponível.

Comportamento durante uma falha de partição

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

  • Detecção e resposta: o serviço HSM gerenciado é responsável por detectar falhas de partição e responder automaticamente a elas. Você não precisa tomar nenhuma ação durante uma falha de partição.

  • Solicitações ativas: Durante uma falha de partição, as solicitações em trânsito para a partição afetada podem falhar, necessitando que os aplicativos cliente tentem novamente. Para minimizar os efeitos das interrupções de partição, os aplicativos cliente devem seguir práticas transitórias de tratamento de falhas.

  • Perda de dados esperada: nenhuma perda de dados é esperada 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 um tempo de inatividade mínimo ou nenhum durante uma falha de partição. As partições saudáveis restantes continuam a atender solicitações.

  • Redirecionamento de tráfego: o HSM gerenciado redireciona automaticamente o tráfego da partição afetada para partições íntegras sem a necessidade de intervenção do cliente.

Recuperação de partição

Quando a partição afetada se recupera, o HSM Gerenciado restaura automaticamente as operações através da restauração de serviços confidenciais. Este processo:

  1. Cria uma nova instância de serviço em hardware saudável.
  2. Estabelece uma conexão TLS atestada com a partição primária.
  3. Troca credenciais com segurança e material criptográfico.
  4. Vincula os dados de serviço à nova CPU.

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

Resiliência a falhas de zona de disponibilidade

A alta disponibilidade do HSM gerenciado baseia-se na distribuição em nível de rack em um datacenter, não na implantação de zona de disponibilidade explícita. Cada partição é executada em um servidor separado em um rack diferente, que protege contra falhas no nível do rack, como problemas de alimentação ou comutador de rede.

Se você precisar ser resiliente a interrupções em toda a zona de disponibilidade ou datacenter, considere usar uma das abordagens para resiliência a falhas em toda a região.

Resiliência a falhas em toda a região

Os recursos de HSM gerenciados são implantados em uma única região do Azure. Se a região ficar indisponível, o HSM Gerenciado também ficará indisponível. No entanto, há abordagens que você pode usar para ajudar a garantir a resiliência a interrupções de região.

Replicação entre regiões

O HSM gerenciado dá suporte à replicação opcional de várias regiões, o que permite estender um pool de HSM gerenciado de uma região do Azure (a região primária) para uma segunda região do Azure (a região estendida). Depois de configurado:

  • Ambas as regiões estão ativas e podem atender às solicitações.
  • Material de chave, funções e permissões são replicados automaticamente entre regiões.
  • As solicitações são roteadas para a região mais próxima disponível usando o Gerenciador de Tráfego do Azure.
  • O SLA combinado aumenta.

Requisitos

  • Suporte à região: todas as regiões do HSM Gerenciado do Azure têm suporte como regiões primárias. Não há dependência em relação aos emparelhamentos de região do Azure.

    O HSM gerenciado não dá suporte a todas as regiões como regiões estendidas. Para obter mais informações, consulte o suporte à região do Azure.

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

Custo

A replicação de várias regiões incorre em cobrança extra porque um segundo pool de HSM é consumido na região estendida. Para obter mais informações, consulte Preços do HSM Gerenciado do Azure.

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

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

Quando a replicação de várias regiões está habilitada e ambas as regiões estão operacionais:

  • Roteamento de tráfego: todas as regiões podem atender às solicitações. O Gerenciador de Tráfego do Azure roteia solicitações para a região com a proximidade geográfica mais próxima ou a menor latência.

    Se você usar o Link Privado, configure pontos de extremidade privados em ambas as regiões para o roteamento ideal durante o failover. Para obter mais informações, consulte Comportamento de link privado com replicação de várias regiões.

  • Replicação de dados: todas as alterações em chaves, definições de função e atribuições de função são replicadas de forma assíncrona para a região estendida dentro de seis minutos. Aguarde seis minutos depois de criar ou atualizar uma chave antes de usá-la na região estendida.

Comportamento durante uma falha de região

Quando a replicação de várias regiões está habilitada e uma região experimenta uma interrupção:

  • Detecção e resposta: o Gerenciador de Tráfego do Azure detecta a região não íntegra e encaminha solicitações futuras para a região íntegra. Os registros DNS têm um TTL de cinco segundos, embora os clientes que armazenam pesquisas DNS em cache possam experimentar tempos de failover um pouco mais longos.
  • Notificação: A Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto, você pode usar Azure Service Health para entender a integridade geral do serviço, incluindo eventuais falhas na região, e pode configurar alertas Service Health para notificar você sobre problemas.

  • Solicitações ativas: As solicitações em andamento para a região afetada podem falhar e exigir novas tentativas.

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

  • Tempo de inatividade esperado: As operações de leitura e gravação permanecem disponíveis na região saudável durante o failover.

    Os aplicativos cliente que estão próximos à região não íntegra podem continuar a ser direcionados para essa região até que os registros DNS sejam atualizados, mas essa atualização ocorre dentro de aproximadamente cinco segundos. Para minimizar o tempo de failover, os clientes devem evitar o armazenamento em cache de consultas DNS por mais tempo do que o TTL do registro DNS.

  • Redirecionamento: O Microsoft Azure Traffic Manager redireciona automaticamente as solicitações para a região saudável.

Recuperação de região

Quando a região afetada se recupera, o HSM Gerenciado retoma automaticamente as operações. O Gerenciador de Tráfego inicia o roteamento de solicitações para ambas as regiões novamente com base na proximidade.

Teste de falhas na região

O HSM gerenciado gerencia totalmente o roteamento de tráfego, o failover e o failback para falhas regionais, portanto, você não precisa validar processos de falha de região ou fornecer qualquer informação adicional.

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

Se a replicação de várias regiões não for adequada para suas necessidades, você poderá implementar a recuperação manual de desastres. Isso requer:

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

Para executar a recuperação de desastre:

  1. Crie uma nova instância de HSM gerenciada em uma 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. Faça um backup do novo HSM (necessário antes da restauração).
  4. Restaure o backup do HSM de origem.

Importante

O novo HSM tem um nome e um URI de ponto de extremidade de serviço diferentes. Você deve atualizar a configuração do aplicativo para usar o novo local.

Para obter procedimentos detalhados de recuperação de desastre, consulte Recuperação de desastre do HSM gerenciado.

Backup e restauração

O HSM gerenciado dá suporte a backup completo e restauração de todas as chaves, versões, atributos, marcas e atribuições de função. Os backups são armazenados em uma conta de Armazenamento do Azure. Se sua região der suporte a ela, recomendamos fazer backup do HSM Gerenciado em uma conta de Armazenamento do Azure que tenha o GRS (armazenamento com redundância geográfica) habilitado.

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

O HSM gerenciado não dá suporte ao agendamento de backups, mas você pode criar seu próprio agendador usando um serviço como o Azure Functions ou a Automação do Azure.

Enquanto um backup está em andamento, o HSM pode não operar em taxa de transferência total porque algumas partições estão ocupadas executando a operação de backup.

Para obter procedimentos detalhados de backup e restauração, consulte Backup completo e restauração.

Resiliência à exclusão acidental

O HSM gerenciado fornece dois principais recursos de recuperação para evitar exclusão acidental ou mal-intencionada:

  • Exclusão reversível: quando você exclui um HSM ou uma chave, eles permanecem recuperáveis por um período de retenção configurável (7 a 90 dias, valor padrão de 90 dias). A exclusão suave está sempre habilitada e não pode ser desabilitada.

    Note

    Os recursos de HSM gerenciados excluídos de forma reversível continuam a incorrer na cobrança até que sejam removidos permanentemente.

  • Proteção contra expurgo: quando habilitada, impede a exclusão permanente do HSM Gerenciado e suas chaves até que o período de retenção termine. A proteção contra limpeza não pode ser desabilitada ou anulada por ninguém, incluindo a Microsoft.

É altamente recomendável habilitar a proteção contra exclusão para ambientes de produção. Para obter mais informações, consulte a proteção contra exclusão reversível e limpeza do HSM gerenciado.

Resiliência à manutenção do serviço

O HSM gerenciado manipula a manutenção do serviço, incluindo atualizações de firmware, aplicação de patch 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 partições permanecem disponíveis durante a manutenção de rotina.
  • Seus aplicativos cliente devem implementar a lógica de repetição para lidar com breves interrupções.

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

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de 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 obter mais informações, consulte SLAs para serviços online.

O HSM gerenciado fornece um SLA padrão para implantações de região única. Quando você habilita a replicação de várias regiões, o SLA combinado para ambas as regiões aumenta.

Conteúdo relacionado

  • Last updated on