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 de região primária) para outra região do Azure (chamada de região estendida). 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 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 podem ser 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 é 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.

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. 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 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 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

Faturação

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 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 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

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 em uma região estendida, é recomendável criar outro ponto de extremidade privado e outra zona DNS privada assim que o HSM gerenciado na região primária for replicado para o HSM gerenciado em uma região estendida. 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 estendida (US West Central).

• Quando ambos os HSMs gerenciados nas regiões primária e estendida 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 estendidas, mas apenas um ponto de extremidade privado configurado na região primária ou estendida. 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 uma região estendida, 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 estender o pool de HSM para uma região estendida.

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

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

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

Remover uma região estendida do HSM primário

Depois de remover um HSM estendido, 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

Próximos passos

• Gerenciamento de funções gerenciadas do HSM
• Criptografia de dados do Azure em repouso
• Criptografia de Armazenamento do Azure