Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A replicação multi-região permite expandir um pool de HSM gerido de uma região Azure (chamada de região primária) para uma região Azure adicional (chamada região estendida). A extensão é suportada apenas para uma única região adicional. Uma vez configuradas, ambas as regiões ficam ativas, capazes de atender solicitações e, com a replicação automatizada, compartilham o mesmo material, funções e permissões de chave. A região disponível mais próxima do aplicativo recebe e atende à solicitação, maximizando a taxa de transferência de leitura e a 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. Quando a replicação de várias regiões está habilitada, o SLA para os pools primário e de extensão combinados aumenta para 99,99. Para mais informações sobre SLA, visite SLA para HSM Gerida do Azure Key Vault.
Arquitetura
Quando a replicação de várias regiões é habilitada em um HSM gerenciado, um segundo pool de HSM gerenciado, com três partições HSM com balanceamento de carga, é criado em uma região estendida. Quando as solicitações são emitidas para o ponto de extremidade <hsm-name>.managedhsm.azure.netDNS global 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 pela região, o gerente 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 serão atendidas pelo pool de HSM gerenciado na região estendida.
Latência de replicação
Qualquer operação de gravação no HSM gerenciado, como criar ou atualizar uma chave, criar ou atualizar uma definição de função ou criar ou atualizar uma atribuição de função, pode levar até 6 minutos antes que ambas as regiões sejam totalmente replicadas. Nesta janela, não há garantia de que o material escrito tenha sido replicado entre as regiões. Portanto, é melhor esperar seis minutos entre a criação ou atualização da chave e o uso da chave para garantir que o material da chave tenha sido totalmente replicado entre regiões. O mesmo se aplica a atribuições de função e definições de função.
Observação
Ao estender inicialmente um HSM Gerido para outra região, o comando de extensão regional pode demorar até 30 minutos a ser concluído antes de a região de extensão estar ativa.
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 todas as solicitações. A interrupção pode ser limitada apenas ao seu pool HSM, a todo o serviço HSM Gerido ou a toda a região do Azure. Durante o failover, você pode notar uma mudança no comportamento dependendo da região afetada.
| Região afetada | Leituras permitidas | Permissões de escrita |
|---|---|---|
| Região alargada | Sim | Sim |
| Região Primária | Sim | Sim |
Se uma região primária ou estendida ficar inativa, você ainda poderá executar operações de leitura e gravação.
- Operações de leitura: obter chave, listar chaves, executar operações criptográficas e listar atribuições de função.
- Operações de gravação: crie ou atualize chaves, atribuições de função e definições de função.
Tempo para alternância
Internamente, a resolução DNS lida com o redirecionamento de solicitações para as regiões primárias ou estendidas.
Se ambas as regiões estiverem ativas, o Gerenciador de Tráfego resolverá as solicitações de entrada para o local que tiver a proximidade geográfica mais próxima ou a menor latência de rede para a origem da solicitação. Os registros DNS são configurados com um TTL padrão de 5 segundos.
Se uma região relatar um estado insalubre ao Gestor de Tráfego, as solicitações futuras serão direcionadas para outra região, se disponível. Os clientes que armazenam em cache consultas de DNS podem enfrentar um tempo de failover prolongado. Mas assim que os caches do lado do cliente expirarem, as solicitações futuras deverão ser encaminhadas para a região disponível.
Suporte à região Azure
Todas as regiões HSM Geridas do Azure são suportadas como regiões primárias (regiões de onde se pode replicar um pool de HSM Gerido).
Observação
EUA Este, Canadá Oriental, Europa Ocidental, Qatar Central, Polónia Central e Índia Ocidental não podem ser regiões estendidas neste momento. Outras regiões podem não estar disponíveis para extensão devido a limitações de capacidade na região.
Faturação
A replicação de várias regiões numa região alargada incorre em cobrança extra (x2), à medida que um novo pool de HSM é utilizado numa região alargada. Para mais informações, consulte Azure Preços HSM Geridos.
Comportamento de remoção temporária
O recurso de exclusão suave do HSM gerenciado permite a recuperação de HSMs e chaves 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 suave 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 suave, e a cobrança do HSM removido termina imediatamente. Você sempre pode estender para uma nova região estendida a partir da primária, se necessário.
Comportamento de link privado com replicação de várias regiões
A funcionalidade Azure Private Link permite-lhe aceder ao serviço HSM Gerido através de um endpoint privado na sua rede virtual. Você configuraria o ponto de extremidade privado no HSM gerenciado na região primária da mesma forma que configuraria quando não usasse o recurso de replicação de várias regiões. Para o HSM gerido numa região alargada, recomenda-se criar outro endpoint privado e uma zona DNS privada assim que o HSM gerido na região principal for replicado para o HSM gerido numa região alargada, o que redireciona os pedidos do cliente para o HSM gerido mais próximo da localização do cliente.
Aqui estão alguns cenários com exemplos: HSM gerenciado em uma região primária (Sul do Reino Unido) e outro HSM gerenciado em uma região estendida (US West Central).
Quando ambos os HSMs geridos nas regiões primária e estendida estão ativos e em execução com o endpoint privado habilitado, as solicitações dos clientes são redirecionadas para o HSM gerido mais próximo do local dos clientes. As solicitações do cliente vão para o ponto de extremidade privado da região mais próxima e, em seguida, são direcionadas pelo Gerenciador de Tráfego para o HSM Gerenciado da mesma região.
Quando um dos HSMs geridos (sul do Reino Unido, por exemplo) em um cenário replicado de 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 gerido 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, são direcionadas para o HSM gerido central oeste dos EUA pelo gestor de tráfego.
HSMs geridos em regiões primárias e estendidas, mas apenas um ponto de extremidade privado configurado quer na região primária, quer na estendida. Para que um cliente de uma rede virtual diferente (VNET1) se conecte a um HSM gerenciado por meio de um ponto de extremidade privado em uma rede virtual diferente (VNET2), ele requer emparelhamento de rede virtual entre as duas VNETs. Você pode adicionar um link de rede virtual para a zona DNS privada que é criada durante a criação do ponto de extremidade privado.
Neste diagrama, o ponto de extremidade privado é criado apenas na região Sul do Reino Unido, enquanto há dois HSMs gerenciados em funcionamento, um cada no Sul do Reino Unido e outro no Centro-Oeste dos EUA. As solicitações de ambos os clientes vão para o HSM gerenciado do Sul do Reino Unido, uma vez que as solicitações são roteadas através do ponto de extremidade privado e o local do ponto de extremidade privado, neste caso, está no sul do Reino Unido.
Neste diagrama, o ponto de extremidade privado é criado apenas na região Sul do Reino Unido, o HSM Gerenciado no Centro-Oeste dos EUA é o único disponível e o HSM Gerenciado no Sul do Reino Unido não está disponível. Nesse caso, as solicitações serão redirecionadas para o HSM Gerenciado da região Centro-Oeste dos Estados Unidos através do ponto final privado no Sul do Reino Unido, porque o gestor de tráfego deteta que o HSM Gerenciado do Sul do Reino Unido está indisponível.
Gerir replicação multi-região
Expanda um HSM primário para uma região ampliada
No portal Azure, navegue até ao seu recurso de HSM Gerido.
No menu esquerdo, em Definições, selecione Replicação Multi-Região.
Selecione Adicionar Região, escolha a região-alvo e confirme.
Importante
Após iniciar a extensão para uma nova região, não realize quaisquer operações no HSM primário até que o pool de regiões de extensão esteja totalmente provisionado. Verifique se o Estado de Aprovisionamento da região estendida indica Bem-sucedido antes de prosseguir.
Remover uma região estendida do HSM primário
No portal Azure, navegue até ao seu recurso de HSM Gerido.
No menu esquerdo, em Definições, selecione Replicação Multi-Região.
Seleciona a região estendida que queres remover e confirma a eliminação.
Ver todas as regiões
Navegue até ao seu recurso HSM Gerido no portal Azure e selecione Multi-Region Replication no menu esquerdo para visualizar todas as regiões e o seu estado de provisionamento.