Rede HSM Dedicado do Azure

O HSM Dedicado do Azure dedicado requer um ambiente de rede altamente seguro. Isso ocorre se for da nuvem de Azure de volta para ambiente de TI do cliente (local), usando aplicativos distribuídos ou para cenários de alta disponibilidade. A Rede do Azure fornece isso e há quatro áreas distintas que devem ser abordadas.

• Criar dispositivos HSM dentro de sua Rede Virtual (VNet) do Microsoft Azure
• Conexão local a recursos baseados em nuvem para a configuração e gerenciamento dos dispositivos HSM
• Criar e conectar redes virtuais para a conexão entre recursos de aplicativos e dispositivos HSM
• Como conectar redes virtuais entre regiões para comunicação interna e também para habilitar cenários de alta disponibilidade

Rede virtual para seus HSMs Dedicados

HSMs Dedicados são integrados a uma Rede Virtual e colocados na própria rede privada dos clientes no Azure. Isso permite o acesso aos dispositivos de máquinas virtuais ou recursos de computação na rede virtual.
Para obter mais informações sobre como integrar serviços do Azure com a rede virtual e os recursos que ele fornece, consulte a documentação dos serviços da Rede virtual para os serviços do Azure.

Redes virtuais

Antes de provisionar um dispositivo HSM Dedicado, os clientes primeiro precisarão criar uma rede Virtual no Azure ou usar um que já existe na assinatura dos clientes. A rede virtual define o perímetro de segurança para o Dispositivo HSM Dedicado. Para obter mais informações sobre redes virtuais do Azure, consulte Documentação da Rede Virtual do Azure.

Sub-redes

As sub-redes segmentam a rede virtual em espaços de endereço separados utilizáveis pelos recursos do Azure colocados neles. HSMs Dedicados são implantados em uma sub-rede em uma rede virtual. Cada dispositivo HSM Dedicado que é implantado na sub-rede do cliente receberá um endereço IP privado dessa sub-rede. A sub-rede na qual o dispositivo do HSM está implantado precisa ser delegada explicitamente para o serviço: Microsoft.HardwareSecurityModules/dedicatedHSMs. Isso concede determinadas permissões para o serviço HSM para implantação na sub-rede. A delegação para os HSMs Dedicados impõe determinadas restrições de política na sub-rede. Grupos de Segurança de Rede (NSGs) e rotas definidas pelo usuário (UDRs) atualmente não têm suporte em sub-redes delegadas. Como resultado, depois que uma sub-rede é delegada aos HSMs Dedicados, ela só pode ser usada para implantar recursos do HSM. Ocorrerá falha na implantação de todos os outros recursos de cliente para a sub-rede. Não há nenhum requisito de quão grande ou pequena a sub-rede do HSM Dedicado deve ser, porém, cada dispositivo HSM consumirá um IP privado e, portanto, é necessário garantir que a sub-rede seja grande o suficiente para acomodar tantos dispositivos HSM quanto necessário para implantação.

Gateway de ExpressRoute

Um requisito da arquitetura atual é a configuração de um gateway de ExpressRoute na sub-rede de clientes em que um dispositivo HSM precisa ser colocado para habilitar a integração do dispositivo HSM para o Microsoft Azure. Esse gateway de ExpressRoute não pode ser utilizado para se conectar a fontes locais para os dispositivos HSM de clientes no Microsoft Azure.

Conexão de sua TI local ao Microsoft Azure

Ao criar recursos baseados em nuvem, isso é um requisito típico para uma conexão privada de volta os recursos de IT locais. No caso do HSM Dedicado, será predominantemente para o software do cliente do HSM configurar os dispositivos HSM e também para atividades, como backups e extrair 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 é VPN de Site a Site, pois é provável que haja vários recursos de locais que exigem uma comunicação segura com recursos (incluindo HSMs) na nuvem do Azure. Isso exigirá uma organização do cliente para ter um dispositivo VPN para facilitar a conexão. Uma conexão VPN de Site a Site pode ser usada se houver apenas um ponto de extremidade local como uma estação de trabalho de administração. Para obter mais informações sobre as opções de conectividade, consulte Opções de planejamento do Gateway de VPN.

Observação

Neste momento, o ExpressRoute não é uma opção de conexão para recursos locais. Também deve-se observar que o Gateway de ExpressRoute usado conforme descrito acima, não é para conexões com a infraestrutura local.

VPN ponto a site

Uma rede Virtual Privada de ponto a site é a forma mais simples de conexão segura para um ponto de extremidade local. Isso pode ser relevante se você pretende ter apenas uma estação de trabalho de administração para HSMs Dedicados com base no Azure.

VPN de site a site

Uma rede Virtual privada de site a site permite a comunicação segura entre os HSMs Dedicados baseados no Azure e sua TI no local. Um motivo para fazer isso é ter um recurso de backup para o local do HSM e que precisa de uma conexão entre os dois para executar o backup.

Conexão de redes virtuais

Uma arquitetura de implantação típica para o HSM Dedicado começa com uma única rede virtual e uma sub-rede correspondente no qual os dispositivos HSM são criados e provisionados. Nessa mesma região, pode haver outras redes virtuais e sub-redes para componentes de aplicativos que fariam uso do HSM Dedicado. Para habilitar a comunicação entre essas redes, usamos o Emparelhamento da Rede Virtual do Microsoft Azure.

Emparelhamento de rede virtual

Quando houver várias redes virtuais dentro de uma região que precisam acessar recursos uns dos outros, o Emparelhamento da Rede Virtual do Microsoft Azure pode ser usado para criar canais de comunicação seguros entre eles. O Emparelhamento de rede virtual fornece não apenas proteção às comunicações, mas também garante uma conexão de baixa latência e largura de banda alta entre os recursos no Azure.

Conexões em Regiões do Azure

Os dispositivos HSM têm a capacidade de, por meio de bibliotecas de software, redirecionar o tráfego para um HSM alternativo. O redirecionamento do tráfego é útil se os dispositivos falharem ou ao acessar um dispositivo perdido. Cenários de falha de nível regional podem ser reduzidos pela implantação de HSMs em outras regiões e habilitar a comunicação entre redes virtuais através das regiões.

Entre a HA de região usando gateway de VPN

Para aplicativos distribuídos globalmente ou para cenários de alta disponibilidade de failover regional, é necessário conectar redes virtuais entre regiões. Com o HSM Dedicado do Azure, a alta disponibilidade pode ser obtida usando um Gateway de VPN que fornece um túnel seguro entre as duas redes virtuais. Para obter mais informações sobre conexões de Rede Virtual para Rede Virtual usando o Gateway de VPN, consulte o artigo intitulado O que é o Gateway de VPN?

Observação

O emparelhamento de Rede Virtual global não está disponível em cenários de conectividade entre regiões com os HSMs Dedicados neste momento e, em vez disso, o gateway de VPN deve ser usado.

Restrições de rede

Observação

Uma restrição do serviço HSM Dedicado que usa a 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 não há suporte para NSGs, UDRs e Peering VNet Global para HSM Dedicado. As seções a seguir dão ajuda com técnicas alternativas para obter o mesmo resultado ou um resultado semelhante para esses recursos.

A NIC 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 reservados para obter acesso ao serviço HSM Dedicado.

Adicionar a solução de Proxy de NVA (Soluções de Virtualização de Rede) também permite que um firewall NVA no hub de trânsito/DMZ seja colocado logicamente na frente da NIC do HSM, fornecendo a alternativa necessária para NSGs e UDRs.

Arquitetura da solução

Esse design de rede requer os seguintes elementos:

1. Uma VNet de hub DMZ ou trânsito com uma camada de proxy NVA. O ideal é que dois ou mais NVAs estão presentes.
2. Um circuito do ExpressRoute com um peering privado habilitado e uma conexão com a VNet do hub de trânsito.
3. Um peering de VNet entre a VNet do hub de trânsito e a VNet HSM Dedicada.
4. Um firewall ou Firewall do Azure NVA pode ser implantado oferecendo serviços DMZ no hub como uma opção.
5. VNets spoke de carga de trabalho adicionais podem ser pares com a VNet do hub. O cliente Gemalto pode acessar o serviço HSM dedicado por meio da VNet do hub.

Como adicionar a solução de proxy NVA também permite que um firewall NVA no hub de trânsito/DMZ seja colocado logicamente na frente da NIC do HSM, fornecendo as políticas de negação padrão necessárias. Em nosso exemplo, vamos usar o Firewall do Azure para essa finalidade e precisaremos dos seguintes elementos em ação:

1. Um firewall do Azure implantado na sub-rede "AzureFirewallSubnet" na VNet do Hub DMZ
2. Uma tabela de roteamento com um UDR que direciona o tráfego para o ponto de extremidade privado do Azure ILB para o Firewall do Azure. Esta tabela de roteamento será aplicada ao GatewaySubnet onde reside o gateway virtual ExpressRoute do cliente
3. Regras de segurança de rede dentro do AzureFirewall para permitir o encaminhamento entre um intervalo de origem confiável e o ponto de extremidade privado do Azure IBL escutando na porta TCP 1792. Essa lógica de segurança adicionará a política "padrão de negação" necessária ao serviço HSM dedicado. Ou seja, somente os intervalos de IP de origem confiáveis serão permitidos no serviço HSM dedicado. Todos os outros intervalos serão descartados.
4. Uma tabela de roteamento com um UDR que direciona o tráfego para o local para o Firewall do Azure. Essa tabela de roteamento será aplicada à sub-rede do proxy NVA.
5. Um NSG aplicado à sub-rede NVA do proxy para confiar apenas no intervalo de sub-rede do firewall do Azure como uma fonte e permitir somente o encaminhamento para o endereço IP da NIC HSM pela porta TCP 1792.

Observação

Como a camada proxy NVA irá SNAT do endereço IP do cliente à medida que ele encaminha para a NIC HSM, nenhum UDRs é necessário entre a VNet do HSM e a VNet do Hub DMZ.

Alternativa para UDRs

A solução de camada NVA mencionada acima funciona como uma alternativa ao UDRs. Aqui estão alguns pontos importantes a considerar.

1. A conversão de endereços de rede deve ser configurada em NVA para permitir que o tráfego de retorno seja roteado corretamente.
2. Os clientes devem desabilitar a verificação de IP do cliente na configuração do HSM Luna para usar o VNA para NAT. Os comandos a seguir servcem 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)

3. Implante o UDRs para o tráfego de entrada na camada NVA.
4. 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 de plataforma.

Alternativa ao uso do Emparelhamento VNET global

Há algumas arquiteturas que você pode usar como uma alternativa ao emparelhamento VNet global.

1. Usar a conexão de Gateway de VPN de VNet para VNet
2. Conecte a VNET HSM com outra VNET com um circuito er. Isso funciona melhor quando um caminho local direto é necessário ou uma VNET VPN.

HSM com conectividade direta do Express Route

Próximas etapas

• Perguntas frequentes
• Capacidade de suporte
• Alta disponibilidade
• Segurança física
• Monitoring
• Arquitetura de implantação