Rede HSM dedicada do Azure
O HSM dedicado do Azure requer um ambiente de rede altamente seguro. Isto é verdade quer seja da cloud do Azure de volta ao ambiente de TI do cliente (no local), através de aplicações distribuídas ou para cenários de elevada disponibilidade. O Azure Networking fornece-o e existem quatro áreas distintas que têm de ser abordadas.
- Criar dispositivos HSM no seu Rede Virtual (VNet) no Azure
- Ligar no local a recursos baseados na cloud para a configuração e gestão de dispositivos HSM
- Criar e ligar redes virtuais para interligar recursos de aplicações e dispositivos HSM
- Ligar redes virtuais entre regiões para inter-comunicação e também para ativar cenários de elevada disponibilidade
Rede virtual para os HSMs dedicados
Os HSMs dedicados são integrados num Rede Virtual e colocados na própria rede privada dos clientes no Azure. Isto 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 as capacidades que fornece, veja Documentação da Rede virtual dos serviços do Azure .
Redes virtuais
Antes de aprovisionar um dispositivo HSM dedicado, os clientes terão primeiro de criar um Rede Virtual no Azure ou utilizar um que já exista na subscrição dos clientes. A rede virtual define o perímetro de segurança do dispositivo HSM dedicado. Para obter mais informações sobre como criar redes virtuais, veja 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. Os HSMs dedicados são implementados numa sub-rede na rede virtual. Cada dispositivo HSM dedicado implementado na sub-rede do cliente receberá um endereço IP privado desta sub-rede. A sub-rede na qual o dispositivo HSM é implementado tem de ser explicitamente delegada ao serviço: Microsoft.HardwareSecurityModules/dedicatedHSMs. Isto concede determinadas permissões ao serviço HSM para implementação na sub-rede. A delegação para HSMs dedicados impõe determinadas restrições de política à sub-rede. Atualmente, os Grupos de Segurança de Rede (NSGs) e as Rotas de User-Defined (UDRs) não são suportados em sub-redes delegadas. Como resultado, uma vez delegada uma sub-rede a HSMs dedicados, só pode ser utilizada para implementar recursos HSM. A implementação de quaisquer outros recursos do cliente na sub-rede falhará. A sub-rede para O HSM Dedicado não deve ser grande ou pequena. No entanto, cada dispositivo HSM consumirá um IP privado, pelo que deve garantir que a sub-rede é suficientemente grande para acomodar o número de dispositivos HSM necessários para a implementação.
Gateway do ExpressRoute
Um requisito da arquitetura atual é a configuração de um gateway do ExpressRoute na sub-rede de clientes onde é necessário colocar um dispositivo HSM para permitir a integração do dispositivo HSM no Azure. Este gateway do ExpressRoute não pode ser utilizado para ligar localizações no local aos dispositivos HSM dos clientes no Azure.
Ligar as TI no local ao Azure
Ao criar recursos baseados na cloud, é um requisito típico para uma ligação privada de volta aos recursos de TI no local. No caso do HSM dedicado, isto será predominantemente para o software de cliente HSM configurar os dispositivos HSM e também para atividades como cópias de segurança e extração de registos de HSMs para análise. Um ponto de decisão chave aqui é a natureza da ligação, uma vez que existem opções. A opção mais flexível é a VPN Site a Site, uma vez que provavelmente existirão vários recursos no local que requerem uma comunicação segura com recursos (incluindo HSMs) na cloud do Azure. Isto exigirá que uma organização do cliente tenha um dispositivo VPN para facilitar a ligação. Uma ligação VPN Ponto a Site pode ser utilizada se existir apenas um ponto final no local, como uma única estação de trabalho de administração. Para obter mais informações sobre as opções de conectividade, veja Gateway de VPN opções de planeamento.
Nota
Neste momento, o ExpressRoute não é uma opção para ligação a recursos no local. Note-se também que o Gateway do ExpressRoute utilizado, conforme descrito acima, não se destina a ligações à infraestrutura no local.
VPN Ponto a Site
Uma Rede Privada Virtual ponto a site é a forma mais simples de ligação segura a um único ponto final no local. Isto pode ser relevante se pretender 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 os HSMs dedicados baseados no Azure e as suas TI no local. Uma razão para tal é ter uma instalação de cópia de segurança para o HSM no local e precisar de uma ligação entre os dois para executar a cópia de segurança.
Ligar redes virtuais
Uma arquitetura de implementação típica do HSM dedicado começará com uma única rede virtual e uma sub-rede correspondente na qual os dispositivos HSM são criados e aprovisionados. Nessa mesma região, pode muito bem haver redes virtuais e sub-redes adicionais para componentes de aplicações que utilizariam o HSM dedicado. Para ativar a comunicação através destas redes, utilizamos Rede Virtual Peering.
Peering de rede virtual
Quando existem várias redes virtuais numa região que precisam de aceder aos recursos uns dos outros, Rede Virtual Peering pode ser utilizado para criar canais de comunicação seguros entre elas. O peering de rede virtual fornece não só comunicações seguras, mas também garante uma baixa latência e ligações de largura de banda elevada entre os recursos no Azure.
Ligar 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 de nível regional podem ser mitigados através da implementação de HSMs noutras regiões e da ativação da comunicação entre redes virtuais entre regiões.
HA entre regiões com o gateway de VPN
Para aplicações distribuídas globalmente ou para cenários de ativação pós-falha regional de elevada disponibilidade, é necessário ligar redes virtuais entre regiões. Com o HSM Dedicado do Azure, a elevada disponibilidade pode ser obtida através de um Gateway de VPN que fornece um túnel seguro entre as duas redes virtuais. Para obter mais informações sobre ligações Vnet a Vnet com Gateway de VPN, consulte o artigo intitulado O que é Gateway de VPN?
Nota
O VNet Peering Global não está disponível em cenários de conectividade entre regiões com HSMs dedicados neste momento e o gateway de VPN deve ser utilizado.
Restrições de Rede
Nota
Uma restrição do serviço HSM dedicado com a delegação de sub-rede é imposta restrições que devem ser consideradas ao conceber a arquitetura de rede de destino para uma implementação de HSM. A utilização da delegação de sub-rede significa que os NSGs, os UDRs e o VNet Peering Global não são suportados para O HSM Dedicado. As secções abaixo ajudam com técnicas alternativas para alcançar o mesmo resultado ou um resultado semelhante para estas capacidades.
O NIC do HSM que reside na VNet de HSM dedicada não pode utilizar Grupos de Segurança de Rede ou Rotas Definidas pelo Utilizador. Isto significa que não é possível definir políticas de negação predefinidas do ponto de vista da VNet de HSM dedicada e que outros segmentos de rede têm de estar na lista de permissões para obter acesso ao serviço HSM dedicado.
Adicionar a solução de Proxy de Aplicações Virtuais de Rede (NVA) também permite que uma firewall NVA no hub de trânsito/DMZ seja colocada logicamente à frente da NIC do HSM, fornecendo assim a alternativa necessária aos NSGs e UDRs.
Arquitetura da Solução
Esta estrutura de rede requer os seguintes elementos:
- Uma VNet de hub DMZ ou de trânsito com um escalão de proxy NVA. Idealmente, estão presentes duas ou mais NVAs.
- Um circuito do ExpressRoute com um peering privado ativado e uma ligação à VNet do hub de trânsito.
- Um VNet peering entre a VNet do hub de trânsito e a VNet de HSM dedicada.
- Uma firewall ou Azure Firewall da NVA pode ser implementada oferecendo serviços DMZ no hub como uma opção.
- As VNets spoke de carga de trabalho adicionais podem ser apresentadas em modo de peering para a VNet do hub. O cliente Gemalto pode aceder ao serviço HSM dedicado através da VNet do hub.
Uma vez que adicionar a solução de proxy da NVA também permite que uma firewall NVA no hub de trânsito/DMZ seja colocada logicamente à frente do NIC do HSM, fornecendo assim as políticas de negação predefinidas necessárias. No nosso exemplo, vamos utilizar o Azure Firewall para este fim e precisaremos dos seguintes elementos:
- Uma Azure Firewall implementada na sub-rede "AzureFirewallSubnet" na VNet do hub DMZ
- Uma Tabela de Encaminhamento com um UDR que direciona o tráfego para o ponto final privado do ILB do Azure para o Azure Firewall. Esta Tabela de Encaminhamento será aplicada à GatewaySubnet onde reside o Gateway Virtual do ExpressRoute do cliente
- Regras de segurança de rede no AzureFirewall para permitir o reencaminhamento entre um intervalo de origem fidedigno e o ponto final privado ibL do Azure a escutar na porta TCP 1792. Esta lógica de segurança irá adicionar a política de "negação predefinida" necessária ao serviço HSM dedicado. Ou seja, apenas os intervalos de IP de origem fidedigna serão permitidos no serviço HSM dedicado. Todos os outros intervalos serão removidos.
- Uma Tabela de Encaminhamento com um UDR que direciona o tráfego para o local no local para o Azure Firewall. Esta Tabela de Encaminhamento será aplicada à sub-rede proxy da NVA.
- Um NSG aplicado à sub-rede NVA do Proxy para confiar apenas no intervalo de sub-rede do Azure Firewall como uma origem e permitir apenas o reencaminhamento para o endereço IP do NIC do HSM através da porta TCP 1792.
Nota
Uma vez que o escalão de proxy da NVA irá SNATar o endereço IP do cliente à medida que reencaminha para o NIC do HSM, não são necessários UDRs entre a VNet HSM e a VNet do hub DMZ.
Alternativa aos UDRs
A solução de escalão NVA mencionada acima funciona como uma alternativa aos UDRs. Existem alguns pontos importantes a ter em atenção.
- A Tradução de Endereços de Rede deve ser configurada na NVA para permitir que o tráfego de retorno seja encaminhado corretamente.
- Os clientes devem desativar a verificação ip do cliente na configuração do Luna HSM para utilizar a VNA para NAT. Os seguintes comandos sãovce 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)
- Implementar UDRs para tráfego de entrada na camada NVA.
- De acordo com a estrutura, as sub-redes HSM não iniciarão um pedido de ligação de saída para o escalão de plataforma.
Alternativa à utilização do Peering de VNET Global
Existem algumas arquiteturas que pode utilizar como alternativa ao VNet Peering Global.
- Utilizar a Ligação de Vnet a Vnet Gateway de VPN
- Ligue a VNET HSM a outra VNET com um circuito ER. Isto funciona melhor quando é necessário um caminho direto no local ou uma VNET de VPN.
HSM com conectividade direta do Express Route
