Rede HSM dedicada do Azure
O HSM Dedicado do Azure requer um ambiente de rede altamente seguro. Isso é verdade se for da nuvem do Azure de volta para o ambiente de TI do cliente (local), usando aplicativos distribuídos ou para cenários de alta disponibilidade. O Azure Networking fornece isso e há quatro áreas distintas que devem ser abordadas.
- Criando dispositivos HSM dentro de sua Rede Virtual (VNet) no Azure
- Conectando recursos locais a recursos baseados em nuvem para a configuração e o gerenciamento de dispositivos HSM
- Criação e conexão de redes virtuais para interconectar recursos de aplicativos e dispositivos HSM
- Conectando redes virtuais entre regiões para intercomunicação e também para permitir cenários de alta disponibilidade
Rede virtual para seus HSMs dedicados
HSMs dedicados são integrados em uma Rede Virtual e colocados na própria rede privada do cliente no Azure. Isso permite o acesso aos dispositivos a partir de máquinas virtuais ou recursos de computação na rede virtual.
Para obter mais informações sobre a integração dos serviços do Azure na rede virtual e os recursos que ela fornece, consulte Rede virtual para documentação de serviços do Azure.
Redes virtuais
Antes de provisionar um dispositivo HSM dedicado, os clientes precisarão primeiro criar uma Rede Virtual no Azure ou usar uma que já exista na assinatura do cliente. A rede virtual define o perímetro de segurança para o dispositivo HSM dedicado. Para obter mais informações sobre como criar redes virtuais, consulte a documentação da rede virtual.
Sub-redes
As sub-redes segmentam a rede virtual em espaços de endereços separados que são utilizados pelos recursos do Azure que põe nas mesmas. HSMs dedicados são implantados em uma sub-rede na rede virtual. Cada dispositivo HSM dedicado implantado na sub-rede do cliente receberá um endereço IP privado dessa sub-rede. A sub-rede na qual o dispositivo HSM é implantado precisa ser explicitamente delegada ao serviço: Microsoft.HardwareSecurityModules/dedicatedHSMs. Isso concede determinadas permissões ao serviço HSM para implantação na sub-rede. A delegação a HSMs dedicados impõe certas restrições de política na sub-rede. Atualmente, não há suporte para NSGs (Grupos de Segurança de Rede) e UDRs (Rotas Definidas pelo Usuário) em sub-redes delegadas. Como resultado, uma vez que uma sub-rede é delegada a HSMs dedicados, ela só pode ser usada para implantar recursos de HSM. A implantação de quaisquer outros recursos do cliente na sub-rede falhará. Não há nenhum requisito sobre quão grande ou pequena deve ser a sub-rede para HSM dedicado, no entanto, cada dispositivo HSM consumirá um IP privado, portanto, deve-se garantir que a sub-rede seja grande o suficiente para acomodar tantos dispositivos HSM quanto necessário para implantação.
Gateway de Rota Expressa
Um requisito da arquitetura atual é a configuração de um gateway de Rota Expressa na sub-rede de clientes onde um dispositivo HSM precisa ser colocado para permitir a integração do dispositivo HSM no Azure. Esse gateway de Rota Expressa não pode ser utilizado para conectar locais locais aos dispositivos HSM dos clientes no Azure.
Conectando sua TI local ao Azure
Ao criar recursos baseados em nuvem, é um requisito típico para uma conexão privada de volta aos recursos de TI locais. No caso do HSM dedicado, isso será predominantemente para o software cliente HSM configurar os dispositivos HSM e também para atividades como backups e extração de logs de HSMs para análise. Um ponto de decisão fundamental aqui é a natureza da conexão, pois há opções. A opção mais flexível é a VPN Site a Site, pois provavelmente haverá vários recursos locais que exigem comunicação segura com recursos (incluindo HSMs) na nuvem do Azure. Isso exigirá que uma organização cliente tenha um dispositivo VPN para facilitar a conexão. Uma conexão VPN ponto a site pode ser usada se houver apenas um único ponto de extremidade local, como uma única estação de trabalho de administração. Para obter mais informações sobre opções de conectividade, consulte Opções de planejamento do Gateway VPN.
Nota
No momento, a Rota Expressa não é uma opção para conexão com recursos locais. Também deve ser observado que o ExpressRoute Gateway usado como descrito acima, não é para conexões com a infraestrutura local.
VPN Ponto a Site
Uma Rede Privada Virtual ponto a site é a forma mais simples de conexão segura com um único ponto de extremidade local. Isso pode ser relevante se você pretende ter apenas uma única estação de trabalho de administração para HSMs dedicados baseados no Azure.
VPN site a site
Uma Rede Privada Virtual site a site permite uma comunicação segura entre HSMs dedicados baseados no Azure e sua TI local. Um motivo para fazer isso é ter um recurso de backup para o HSM local e precisar de uma conexão entre os dois para executar o backup.
Conectando redes virtuais
Uma arquitetura de implantação típica para HSM dedicado começará com uma única rede virtual e sub-rede correspondente na qual os dispositivos HSM são criados e provisionados. Dentro dessa mesma região, poderia muito bem haver redes virtuais e sub-redes adicionais para componentes de aplicativos que fariam uso do HSM dedicado. Para permitir a comunicação entre essas redes, usamos o Emparelhamento de Rede Virtual.
Peering de rede virtual
Quando há várias redes virtuais dentro de uma região que precisam acessar os recursos umas das outras, o Emparelhamento de Rede Virtual pode ser usado para criar canais de comunicação seguros entre elas. O emparelhamento de rede virtual fornece não apenas comunicações seguras, mas também garante conexões de baixa latência e alta largura de banda entre os recursos no Azure.
Conectando-se entre regiões do Azure
Os dispositivos HSM têm a capacidade, através de bibliotecas de software, de redirecionar o tráfego para um HSM alternativo. O redirecionamento de tráfego é útil se os dispositivos falharem ou o acesso a um dispositivo for perdido. Os cenários de falha em nível regional podem ser atenuados implantando HSMs em outras regiões e permitindo a comunicação entre redes virtuais entre regiões.
HA entre regiões usando gateway VPN
Para aplicativos distribuídos globalmente ou para cenários de failover regional de alta disponibilidade, é necessário conectar redes virtuais entre regiões. Com o HSM Dedicado do Azure, a alta disponibilidade pode ser alcançada usando um Gateway VPN que fornece um túnel seguro entre as duas redes virtuais. Para obter mais informações sobre conexões Vnet-to-Vnet usando VPN Gateway, consulte o artigo intitulado O que é VPN Gateway?
Nota
O emparelhamento Vnet global não está disponível em cenários de conectividade entre regiões com HSMs dedicados no momento, e o gateway VPN deve ser usado em vez disso.
Restrições de rede
Nota
Uma restrição do serviço HSM dedicado usando delegação de sub-rede é imposta restrições que devem ser consideradas ao projetar a arquitetura de rede de destino para uma implantação de HSM. O uso da delegação de sub-rede significa que NSGs, UDRs e Global VNet Peering não são suportados para HSM dedicado. As seções abaixo fornecem ajuda com técnicas alternativas para alcançar o mesmo resultado ou um resultado semelhante para esses recursos.
A NIC do HSM que reside na VNet HSM Dedicada não pode usar Grupos de Segurança de Rede ou Rotas Definidas pelo Usuário. Isso significa que não é possível definir políticas de negação padrão do ponto de vista da VNet HSM Dedicada e que outros segmentos de rede devem ser permitidos para obter acesso ao serviço HSM Dedicado.
Adicionar a solução de proxy NVA (Network Virtual Appliances) também permite que um firewall NVA no hub de trânsito/DMZ seja logicamente colocado na frente da placa de rede HSM, fornecendo assim a alternativa necessária para NSGs e UDRs.
Arquitetura da Solução
Este design de rede requer os seguintes elementos:
- Uma VNet de hub de trânsito ou DMZ com uma camada de proxy NVA. Idealmente, dois ou mais NVAs estão presentes.
- Um circuito ExpressRoute com um emparelhamento privado habilitado e uma conexão com a VNet do hub de trânsito.
- Um emparelhamento de VNet entre a VNet do hub de trânsito e a VNet HSM dedicada.
- Um firewall NVA ou um Firewall do Azure pode ser implantado oferecendo serviços DMZ no hub como uma opção.
- As VNets de carga de trabalho adicionais podem ser emparelhadas para a VNet do hub. O cliente da Gemalto pode acessar o serviço HSM dedicado por meio da VNet do hub.
Uma vez que a adição da solução de proxy NVA também permite que um firewall NVA no hub de trânsito/DMZ seja logicamente colocado na frente da placa de rede HSM, fornecendo assim as políticas de negação padrão necessárias. Em nosso exemplo, usaremos o Firewall do Azure para essa finalidade e precisaremos dos seguintes elementos:
- Um Firewall do Azure implantado na sub-rede "AzureFirewallSubnet" na VNet do hub DMZ
- Uma Tabela de Roteamento com um UDR que direciona o tráfego direcionado para o ponto de extremidade privado do ILB do Azure para o Firewall do Azure. Esta Tabela de Roteamento será aplicada à Sub-rede Gateway, onde reside o Gateway Virtual de Rota Expressa do cliente
- Regras de segurança de rede no AzureFirewall para permitir o encaminhamento entre um intervalo de origem confiável e a escuta do ponto de extremidade privado IBL do Azure na porta TCP 1792. Essa lógica de segurança adicionará a política de "negação padrão" necessária em relação ao serviço HSM dedicado. Ou seja, apenas intervalos de IP de origem confiável serão permitidos no serviço HSM dedicado. Todos os outros intervalos serão descartados.
- Uma Tabela de Roteamento com um UDR que direciona o tráfego direcionado para o local para o Firewall do Azure. Esta tabela de roteamento será aplicada à sub-rede proxy NVA.
- Um NSG aplicado à sub-rede NVA do Proxy para confiar apenas no intervalo de sub-redes do Firewall do Azure como origem e para permitir apenas o encaminhamento para o endereço IP da NIC HSM pela porta TCP 1792.
Nota
Como a camada de proxy NVA SNAT o endereço IP do cliente à medida que encaminha para a NIC do HSM, não são necessárias UDRs entre a VNet do HSM e a VNet do hub DMZ.
Alternativa aos UDRs
A solução de camada NVA mencionada acima funciona como uma alternativa aos UDRs. Há alguns pontos importantes a observar.
- A conversão de endereços de rede deve ser configurada no NVA para permitir que o tráfego de retorno seja roteado corretamente.
- Os clientes devem desativar o ip check do cliente na configuração do Luna HSM para usar o VNA para NAT. Os comandos a seguir servce como exemplo.
Disable:
[hsm01] lunash:>ntls ipcheck disable
NTLS client source IP validation disabled
Command Result : 0 (Success)
Show:
[hsm01] lunash:>ntls ipcheck show
NTLS client source IP validation : Disable
Command Result : 0 (Success)
- Implante UDRs para tráfego de entrada na camada NVA.
- De acordo com o design, as sub-redes HSM não iniciarão uma solicitação de conexão de saída para a camada da plataforma.
Alternativa ao uso do Global VNET Peering
Há algumas arquiteturas que você pode usar como alternativa ao emparelhamento Global VNet.
- Usar conexão de gateway VPN vnet-to-vnet
- Conecte a VNET HSM com outra VNET com um circuito ER. Isso funciona melhor quando é necessário um caminho local direto ou uma VNET VPN.
HSM com conectividade direta de Rota Expressa
