Compartilhar via


Habilitar a replicação de várias regiões no HSM Gerenciado do Azure

A replicação de várias regiões permite que você estenda um pool de HSM gerenciado de uma região do Azure (chamada de região primária) para outra região do Azure (chamada de região estendida). Uma vez configuradas, ambas as regiões estão ativas, podem atender a solicitações e, com a replicação automatizada, compartilham o mesmo material-chave, funções e permissões. A região disponível mais próxima do aplicativo recebe e atende à solicitação, maximizando assim a taxa de transferência de leitura e latência. Embora as interrupções regionais sejam raras, a replicação em várias regiões aumenta a disponibilidade de chaves criptográficas de missão crítica caso uma região fique indisponível. Para obter mais informações sobre o SLA, visite SLA para HSM Gerenciado do Azure Key Vault.

Arquitetura

Diagrama de arquitetura de Replicação de Várias Regiões do HSM gerenciado.

Quando a replicação em várias regiões está habilitada em um HSM gerenciado, um segundo pool de HSM gerenciado, com três partições de HSM com balanceamento de carga, é criado em uma região estendida. Quando as solicitações são emitidas para o ponto de extremidade do DNS global <hsm-name>.managedhsm.azure.net do Gerenciador de Tráfego, a região disponível mais próxima recebe e atende à solicitação. Embora cada região mantenha individualmente a alta disponibilidade regional devido à distribuição de HSMs na região, o gerenciador de tráfego garante que, mesmo que todas as partições de um HSM gerenciado em uma região estejam indisponíveis devido a uma catástrofe, as solicitações ainda poderão ser atendidas pelo pool do HSM gerenciado na região estendida.

Replication latency

Qualquer operação de gravação no HSM Gerenciado, como a criação ou atualização de uma chave, a criação ou atualização de uma definição de função ou a criação ou atualização de uma atribuição de função, pode levar até 6 minutos para que as duas regiões sejam totalmente replicadas. Dentro dessa janela, não é garantido que o material gravado tenha se replicado entre as regiões. Portanto, é melhor esperar seis minutos entre criação ou atualização da chave e o uso da chave para garantir que o material da chave tenha sido totalmente replicado entre as regiões. O mesmo se aplica às atribuições e definições de funções.

Comportamento de failover

O failover ocorre quando uma das regiões em um HSM Gerenciado de várias regiões fica indisponível devido a uma interrupção e a outra região começa a atender a todas as solicitações. A interrupção pode se limitar apenas ao seu pool de HSM, a todo o serviço de HSM gerenciado ou a toda a região do Azure. Durante o failover, você pode notar uma alteração no comportamento, dependendo da região afetada.

Região Afetada Leituras Permitidas Gravações Permitidas
Região estendida Sim Sim
Região Primária Sim Talvez

Se uma região estendida ficar indisponível, as operações de leitura (obter chave, listar chaves, todas as operações de criptografia, listar atribuições de função) estarão disponíveis se a região primária estiver ativa. As operações de gravação (criar e atualizar chaves, criar e atualizar atribuições de funções, criar e atualizar definições de funções) também estão disponíveis.

Se a região primária não estiver disponível, as operações de leitura estarão disponíveis, mas as operações de gravação talvez não, dependendo do escopo da interrupção.

Tempo para o failover

Nos bastidores, a resolução de DNS lida com o redirecionamento de solicitações para as regiões primária ou estendida.

Se ambas as regiões estiverem ativas, o Gerenciador de Tráfego resolverá as solicitações de entrada para o local que tiver a maior proximidade geográfica ou a menor latência de rede em relação à origem da solicitação. Os registros DNS são configurados com um TTL padrão de 5 segundos.

Se uma região relatar um status não íntegro ao Gerenciador de Tráfego, as solicitações futuras serão resolvidas para a outra região, se disponível. Os clientes que armazenam em cache as pesquisas de DNS podem ter um tempo de failover estendido. Porém, quando os caches do lado do cliente expirarem, as solicitações futuras deverão ser roteadas para a região disponível.

Suporte entre região do Azure

As seguintes regiões são compatíveis como regiões primárias (regiões de onde você pode replicar um pool de HSM gerenciado)

  • Leste dos EUA
  • Leste dos EUA 2
  • Norte do Reino Unido
  • Europa Ocidental
  • Oeste dos EUA
  • Leste do Canadá
  • Catar Central
  • Leste da Ásia
  • Sudeste da Ásia
  • Sul do Reino Unido
  • EUA Central
  • Leste do Japão
  • Norte da Suíça
  • Sul do Brasil
  • Austrália Central
  • Centro da Índia
  • Oeste dos EUA 3
  • Canadá Central
  • Leste da Austrália
  • Sul da Índia
  • Suécia Central
  • Norte da África do Sul
  • Coreia Central
  • Norte da Europa
  • França Central
  • Oeste do Japão
  • Centro-Sul dos EUA
  • Polônia Central
  • Oeste da Suíça
  • Sudeste da Austrália
  • Oeste da Índia
  • EAU Central
  • Norte dos EAU
  • Oeste dos EUA 2
  • Centro-Oeste dos EUA

Observação

EUA Central, Leste dos EUA, Centro-Sul dos EUA, Oeste dos EUA 2, Norte da Suíça, Oeste da Europa, Índia Central, Canadá Central, Leste do Canadá, Oeste do Japão, Catar Central, Polônia Central e Centro-Oeste dos EUA não podem ser regiões estendidas neste momento. Outras regiões podem estar indisponíveis para extensão devido a limitações de capacidade na região.

Cobrança

A replicação de várias regiões em uma região estendida incorre em cobrança extra (x2), pois um novo pool de HSM é consumido em uma região estendida. Para obter mais informações, consulte Preços do HSM Gerenciado do Azure.

Comportamento de exclusão reversível

O Recurso de exclusão reversível do HSM Gerenciado permite a recuperação de chaves e HSMs excluídos; no entanto, em um cenário habilitado para replicação em várias regiões, há diferenças sutis em que o HSM secundário deve ser excluído antes que a exclusão reversível possa ser executada no HSM primário. Além disso, quando uma região estendida é removida do HSM primário, o HSM na região removida é limpo em vez de entrar em um estado de exclusão reversível, e a cobrança pelo HSM limpo é encerrada imediatamente. Você sempre pode estender para uma nova região estendida da primária, se necessário.

O Recurso Link Privado do Azure permite que você acesse o serviço HSM Gerenciado por meio de um ponto de extremidade privado em sua rede virtual. Você configuraria o ponto de extremidade privado no HSM Gerenciado na região primária da mesma forma que faria ao não estivesse usando o recurso de replicação de várias regiões. Para o HSM Gerenciado em uma região estendida, é recomendável criar outro ponto de extremidade privado e uma zona DNS privada depois que o HSM Gerenciado na região primária for replicado para o HSM gerenciado em uma região estendida. Isto redirecionará as solicitações do cliente para o HSM Gerenciado mais próximo da localização do cliente.

Alguns cenários abaixo com exemplos: HSM Gerenciado em uma região primária (Sul do Reino Unido) e outro HSM Gerenciado em uma região estendida (Centro-Oeste dos EUA).

  • Quando os dois HSMs Gerenciados nas regiões primária e estendida estiverem em execução com o ponto de extremidade privado em funcionamento, as solicitações do cliente são redirecionadas para o HSM Gerenciado mais próximo da localização do cliente. As solicitações dos clientes vão para o ponto de extremidade privado da região mais próxima e, em seguida, são direcionadas para o HSM Gerenciado da mesma região pelo gerenciador de tráfego.

    Diagrama que ilustra o primeiro cenário de várias regiões do HSM gerenciado.

  • Quando um dos HSMs Gerenciados (Sul do Reino Unido, por exemplo) em um cenário replicado em várias regiões não está disponível com pontos de extremidade privados habilitados, as solicitações do cliente são redirecionadas para o HSM Gerenciado disponível (Centro-Oeste dos EUA). As solicitações de clientes do Sul do Reino Unido irão primeiro para o ponto de extremidade privado do Sul do Reino Unido e, em seguida, serão direcionadas para o HSM Gerenciado do Centro-Oeste dos EUA pelo gerenciador de tráfego.

    Diagrama que ilustra o segundo cenário de várias regiões do HSM gerenciado.

  • HSMs Gerenciados em regiões primárias e estendidas, mas apenas um ponto de extremidade privado configurado na região primária ou estendida. Para que um cliente de uma VNET (VNET1) diferente se conecte a um HSM Gerenciado por meio de um ponto de extremidade privado em uma VNET (VNET2) diferente, é necessário um emparelhamento VNET entre as duas VNETs. Você pode adicionar o link VNET para a zona DNS privada que é criada durante a criação do ponto de extremidade privado.

    Diagrama que ilustra o terceiro cenário de várias regiões do HSM gerenciado.

No diagrama abaixo, o ponto de extremidade privado é criado apenas na região Sul do Reino Unido, enquanto há dois HSMs Gerenciados em execução, um no Sul do Reino Unido e o outro no Centro-Oeste dos EUA. As solicitações de ambos os clientes vão para o HSM Gerenciado do Sul do Reino Unido, pois as solicitações são roteadas por meio do ponto de extremidade privado e a localização do ponto de extremidade privado, neste caso, está no sul do Reino Unido.

Diagrama que ilustra o quarto cenário de várias regiões do HSM gerenciado.

No diagrama abaixo, o ponto de extremidade privado é criado apenas na região Sul do Reino Unido, somente o HSM Gerenciado no Centro-Oeste dos EUA está disponível e o HSM Gerenciado no Sul do Reino Unido não está disponível. Neste caso, as solicitações serão redirecionadas para o HSM Gerenciado do Centro-Oeste dos EUA por meio do ponto de extremidade privado no Sul do Reino Unido porque o gerenciador de tráfego detecta que o HSM Gerenciado do Sul do Reino Unido não está disponível.

Diagrama que ilustra o quinto cenário de várias regiões do HSM gerenciado.

Comandos da CLI do Azure

Se estiver criando um novo pool de HSM Gerenciado e, depois, for estendê-lo para uma região estendida, confira essas instruções antes de fazer isso. Se estiver estendendo a partir de um pool de HSM Gerenciado já existente, use as instruções a seguir para estender o pool de HSM para uma região estendida.

Observação

Esses comandos requerem a versão 2.48.1 ou superior da CLI do Azure. Para instalar a versão mais recente consulte Como instalar a CLI do Azure.

Estender um HSM primário para uma região estendida

Para estender um pool de HSM gerenciado para outra região, execute o comando a seguir, que criará um novo HSM automaticamente em uma região estendida.

az keyvault region add --hsm-name "ContosoMHSM" --region "australiaeast"

Observação

Neste exemplo, "ContosoMHSM" é o nome do pool de HSM primário; e "australiaeast" é a região estendida para a qual você o está estendendo.

Remover uma região estendida do HSM primário

Assim que remover um HSM estendido, as partições do HSM na outra região serão limpas. Todos os secundários devem ser excluídos antes que um HSM gerenciado primário possa ser excluído reversivelmente ou limpo. Somente os secundários podem ser excluídos com esse comando. O primário só pode ser excluído usando os comandos exclusão reversível e limpar

az keyvault region remove --hsm-name ContosoMHSM --region australiaeast

Lista de todas as regiões

az keyvault region list --hsm-name ContosoMHSM

Próximas etapas