Confiabilidade no HSM Gerenciado do Azure Key Vault

Azure Key Vault O HSM Gerenciado é 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 para FIPS 140-3 Nível 3. O HSM gerenciado fornece uma variedade de recursos internos de confiabilidade 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 várias possíveis interrupções e problemas, incluindo falhas transitórias, falhas de partição e interrupções de região. Ele também descreve como usar backups e o domínio de segurança para recuperação de desastre, como os recursos de recuperação protegem contra exclusão acidental e informações importantes sobre o SLA (contrato de nível de serviço) do HSM gerenciado.

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

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 é chamada de pool.

A arquitetura do HSM Gerenciado foi projetada para alta disponibilidade e durabilidade.

• 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. Os funcionários da Microsoft, incluindo pessoas com acesso físico aos servidores, não podem acessar o material da sua 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 saber 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 do HSM Gerenciado para fins de 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.

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:

• Gere 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 isolado da rede, como um HSM no local 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 quórum multipessoal: Use pelo menos três detentores de chaves para impedir que uma única pessoa tenha acesso a todas as chaves do quórum e para evitar a dependência de uma única 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, incluindo backoff exponencial, em qualquer código que interaja diretamente com o HSM Gerenciado.

• 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. Execute operações de chave pública, como criptografia, encapsulamento e verificação, localmente armazenando em cache o material da chave pública. A execução das operações reduz localmente a dependência do HSM Gerenciado e reduz a probabilidade de falhas transitórias interromperem essas operações.

Se você usar o HSM Gerenciado em cenários de alta taxa de transferência, o HSM Gerenciado não limitará 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 do HSM Gerenciado para entender a saúde do serviço.

Para dimensionar a criptografia para grandes volumes de dados, use uma hierarquia de chaves. Armazene apenas a KEK (chave de criptografia de chave) no HSM Gerenciado e use-a para encapsular chaves de criptografia de dados de nível inferior armazenadas em outro lugar no armazenamento seguro de chaves.

Para obter mais informações sobre parâmetros de comparação de desempenho e planejamento de capacidade, consulte Azure diretrizes de dimensionamento de HSM gerenciado.

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.

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

A alta disponibilidade interna no HSM Gerenciado não adiciona custos extras. 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 gerencia automaticamente o roteamento de tráfego em suas três partições. Durante operações normais, ele distribui de forma transparente as solicitações entre partições.

• Replicação de dados: O HSM gerenciado replica de forma síncrona todos os dados, incluindo chaves, atribuições de função e políticas de controle de acesso, em todas as três partições. Essa abordagem garante a consistência e a disponibilidade mesmo que uma partição fique 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 detecta falhas de partição e responde 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 andamento para a partição afetada podem falhar e exigir 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 mínimo ou nenhum tempo de inatividade 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 exigir nenhuma 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 no 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 fonte de alimentação ou problemas de comutador de rede.

Para proteger contra interrupções em toda a zona de disponibilidade ou em todo o datacenter, use uma das abordagens descritas em Resiliência para 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, que você pode usar para estender um pool de HSM gerenciado de uma região de Azure (a região primária) para uma segunda região Azure (a região estendida). Quando configurar esta funcionalidade:

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

Requisitos

• Suporte à região: Todas as regiões que dão suporte ao HSM Gerenciado podem ser usadas 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 gera cobrança extra porque a região estendida consome um segundo pool de HSM. Para obter mais informações, consulte Preços do HSM Gerenciado do Azure.

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

• Adicione uma região estendida: Para obter detalhes sobre como adicionar uma região estendida a uma região primária existente, consulte Estender um HSM primário para uma região estendida.

  Estender um HSM gerenciado para outra região pode levar até 30 minutos.

• Remova uma região estendida: Para obter detalhes sobre como remover uma região estendida de uma região primária existente, consulte Remover uma região estendida do HSM primário.

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

Esta seção descreve o que esperar quando você configura a replicação de várias regiões 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 do Azure para acessar o Managed HSM, configure pontos de extremidade privados em ambas as regiões para obter 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 em 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

Esta seção descreve o que esperar quando você configura a replicação de várias regiões e há uma interrupção em uma das regiões de réplica.

• Detecção e resposta: 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 uma TTL (vida útil) 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 Integridade do Serviço do Azure 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 nova tentativa.

• Perda de dados esperada: As alterações feitas em seis minutos antes da falha na região podem não ser replicadas para a região estendida. Essas alterações podem ser perdidas se a região primária não puder ser recuperada.

• 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 Gerenciador de Tráfego do Azure 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. Gerenciador de Tráfego do Azure 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. Essa abordagem 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.

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 que você faça backup do HSM Gerenciado em uma conta Armazenamento do Azure que tenha o GRS (armazenamento com redundância geográfica) habilitado.

O HSM criptografa backups usando chaves criptográficas associadas ao domínio de segurança do HSM. Você só pode restaurar backups 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: HSMs e chaves excluídas não são limpas imediatamente. Eles permanecem recuperáveis por um período de retenção configurável de 7 a 90 dias (padrão: 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 exclusão definitiva: Quando habilitada, impede a exclusão permanente do seu HSM gerenciado e de 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:

• O serviço pode tornar temporariamente as partições indisponíveis enquanto aplica atualizações.
• 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 recuperação de serviço confidencial garante que o serviço nunca exponha segredos durante 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 de disponibilidade padrão para implantações de região única. Habilitar a replicação multirregional aumenta a disponibilidade geral esperada, pois as solicitações podem ser atendidas por qualquer uma das regiões se uma delas ficar indisponível.

Conteúdo relacionado

• O que é o HSM Gerenciado do Azure Key Vault?
• Habilitar a replicação de várias regiões
• Recuperação de desastre do HSM gerenciado
• Backup e restauração completos
• Visão geral do domínio de segurança no HSM gerenciado
• Proteção de exclusão reversível e contra purga do HSM gerenciado
• Diretrizes de dimensionamento de HSM gerenciado do Azure
• O que é a documentação de confiabilidade do Azure?