Habilitar a replicação de várias regiões no Azure Managed HSM
A replicação de várias regiões permite estender um pool de HSM gerenciado de uma região do Azure (chamada primária) para outra região do Azure (chamada secundária). 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 assim 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. Para obter mais informações sobre SLA, visite SLA para HSM gerenciado 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 na região secundária. 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 podem ser atendidas pelo pool de HSM gerenciado secundário.
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 é garantido 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.
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 de HSM, a todo o serviço HSM gerenciado 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 | Gravações permitidas |
|---|---|---|
| Secundária | Sim | Sim |
| Primário | Sim | Talvez |
Se a região secundária 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. Operações de gravação (criar e atualizar chaves, criar e atualizar atribuições de função, criar e atualizar definições de função) 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 não, dependendo do escopo da interrupção.
Tempo para failover
Nos bastidores, a resolução DNS lida com o redirecionamento de solicitações para a região primária ou secundária.
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 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 pesquisas de DNS podem enfrentar um tempo de failover estendido. 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 do Azure
As seguintes regiões são suportadas como regiões primárias (regiões de onde você pode replicar um pool de HSM gerenciado)
- E.U.A Leste
- E.U.A. Leste 2
- Norte dos EUA
- Europa Ocidental
- E.U.A. Oeste
- Leste do Canadá
- Catar Central
- Ásia Oriental
- Ásia Sudeste
- Sul do Reino Unido
- E.U.A. Central
- Leste do Japão
- Norte da Suíça
- Sul do Brasil
- Austrália Central
- Índia Central
- Oeste dos EUA 3
- Canadá Central
- Leste da Austrália
- Índia do Sul
- Suécia Central
- Norte da África do Sul
- Coreia do Sul Central
- Norte da Europa
- França Central
- Oeste do Japão
- E.U.A. Centro-Sul
- Polónia Central
- Oeste da Suíça
- Austrália Sudeste
- Oeste da Índia
- E.A.U. Central
- Norte dos E.A.U.
- E.U.A. Oeste 2
- E.U.A. Centro-Oeste
Nota
Centro dos EUA, Leste dos EUA, Centro-Sul dos EUA, Oeste dos EUA 2, Suíça Norte, Europa Ocidental, Índia Central, Canadá Central, Leste do Canadá, Oeste do Japão, Qatar Central, Polônia Central e Centro-Oeste dos EUA não podem ser estendidos como uma região secundária no 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 para a região secundária incorre em cobrança extra (x2), pois um novo pool de HSM é consumido na região secundária. Para obter mais informações, consulte Preços do HSM gerenciado do Azure.
Comportamento de eliminação recuperável
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 um secundário é excluído, ele é limpo imediatamente e não entra em um estado de exclusão suave que interrompe todo o faturamento do secundário. Você sempre pode estender para uma nova região como secundária a partir da primária, se necessário.
Comportamento de link privado com replicação de várias regiões
O recurso Azure Private Link 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 configuraria quando não usasse o recurso de replicação de várias regiões. Para o HSM Gerenciado na região secundária, é recomendável criar outro ponto de extremidade privado assim que o HSM Gerenciado na região primária for replicado para o HSM Gerenciado na região secundária. Isso redirecionará as solicitações do cliente para o HSM gerenciado mais próximo do local 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 secundária (Centro Oeste dos EUA).
Quando ambos os HSMs gerenciados nas regiões primária e secundária estão ativos e em execução com o ponto de extremidade privado habilitado, as solicitações do cliente são redirecionadas para o HSM gerenciado mais próximo do local do cliente. As solicitações do cliente vão para o ponto de extremidade privado da região mais próxima e, em seguida, direcionadas para o HSM gerenciado da mesma região pelo gerente de tráfego.
Quando um dos HSMs gerenciados (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 HSM gerenciado disponível (US West Central). 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, direcionadas para o HSM gerenciado central do oeste dos EUA pelo gerente de tráfego.
HSMs gerenciados em regiões primárias e secundárias, mas apenas um ponto de extremidade privado configurado em primário ou secundário. Para que um cliente de uma VNET diferente (VNET1) se conecte a um HSM gerenciado por meio de um ponto de extremidade privado em uma VNET diferente (VNET2), ele requer emparelhamento de VNET entre as duas VNETs. Você pode adicionar um link VNET para a zona DNS privada que é criada durante a criação do ponto de extremidade privado.
No diagrama abaixo, 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.
No diagrama abaixo, o ponto de extremidade privado é criado apenas na região Sul do Reino Unido, apenas 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. Nesse 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 gerente de tráfego deteta que o HSM Gerenciado do Sul do Reino Unido não está disponível.
Comandos da CLI do Azure
Se estiver criando um novo pool de HSM gerenciado e, em seguida, estendendo-se para um secundário, consulte estas instruções antes de estender. Se estiver se estendendo de um pool de HSM gerenciado já existente, use as instruções a seguir para criar um HSM secundário em outra região.
Nota
Esses comandos exigem a CLI do Azure versão 2.48.1 ou superior. Para instalar a versão mais recente, consulte Como instalar a CLI do Azure.
Adicionar um HSM secundário em outra região
Para estender um pool de HSM gerenciado para outra região, execute o seguinte comando que criará automaticamente um segundo HSM.
az keyvault region add --hsm-name "ContosoMHSM" --region "australiaeast"
Nota
"ContosoMHSM" neste exemplo é o nome do pool HSM primário; "AustraliaEast" é a região secundária para a qual você está estendendo-o.
Remover um HSM secundário em outra região
Depois de remover um HSM secundário, as partições 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 suavemente ou limpo. Somente secundários podem ser excluídos usando este comando. O primário só pode ser excluído usando os comandos soft-delete e purge
az keyvault region remove --hsm-name ContosoMHSM --region australiaeast
Listar todas as regiões
az keyvault region list --hsm-name ContosoMHSM