Inspeção de tráfego do Azure Payment HSM

  • Artigo

O Módulo de Segurança de Hardware de Pagamento do Azure (HSM ou PHSM de Pagamento) é um serviço bare-metal que fornece operações de chave criptográfica para transações de pagamento críticas e em tempo real na nuvem do Azure. Para obter mais informações, consulte O que é o Azure Payment HSM?.

Quando o HSM de pagamento é implantado, ele vem com uma interface de rede host e uma interface de rede de gerenciamento. Há vários cenários de implantação:

  1. Com portas de host e gerenciamento na mesma VNet
  2. Com portas de host e gerenciamento em diferentes redes virtuais
  3. Com host e porta de gerenciamento com endereços IP em diferentes redes virtuais

Em todos os cenários acima, o HSM de pagamento é um serviço de injeção de rede virtual em uma sub-rede delegada: hsmSubnet e managementHsmSubnet deve ser delegado ao Microsoft.HardwareSecurityModules/dedicatedHSMs serviço.

Importante

O FastPathEnabled recurso deve ser registrado e aprovado em todas as assinaturas que precisam de acesso ao HSM de pagamento. Você também deve habilitar a fastpathenabled tag na VNet que hospeda a sub-rede delegada do HSM de pagamento e em cada rede virtual emparelhada que exija conectividade com os dispositivos HSM de pagamento.

Para que a fastpathenabled marca VNet seja válida, o FastPathEnabled recurso deve ser habilitado na assinatura em que a VNet está implantada. Ambas as etapas devem ser concluídas para permitir que os recursos se conectem aos dispositivos HSM de pagamento. Para obter mais informações, consulte FastPathEnabled.

O PHSM não é compatível com topologias vWAN ou emparelhamento de VNet entre regiões, conforme listado na topologia suportada. O HSM de pagamento vem com algumas restrições de política nessas sub-redes: Grupos de Segurança de Rede (NSGs) e Rotas Definidas pelo Usuário (UDRs) não são suportados no momento.

É possível contornar a restrição UDR atual e inspecionar o tráfego destinado a um HSM de pagamento. Este artigo apresenta duas maneiras: um firewall com conversão de endereços de rede de origem (SNAT) e um firewall com proxy reverso.

Firewall com conversão de endereços de rede de origem (SNAT)

Este design é inspirado na arquitetura da solução HSM dedicada.

O firewall SNATs o endereço IP do cliente antes de encaminhar o tráfego para a placa de rede PHSM, garantindo que o tráfego de retorno será automaticamente direcionado de volta para o firewall. Um Firewall do Azure ou um NVA FW de terceiros pode ser usado nesse design.

Diagrama de arquitetura do firewall com SNAT

Tabelas de rotas necessárias:

  • Local para PHSM: uma Tabela de Rotas contendo um UDR para o intervalo de VNet do HSM de Pagamento e apontando para o Firewall do hub central é aplicada à Sub-rede Gateway.
  • VNet(s) Spoke para PHSM: uma Tabela de Rotas contendo a rota padrão usual apontando para o Firewall do hub central é aplicada às sub-redes Spoke VNet(s).

Resultados:

  • UDRs que não são suportados na sub-rede PHSM são endereçados pelo Firewall que faz SNAT no IP do cliente: ao encaminhar o tráfego para o PHSM, o tráfego de retorno será automaticamente direcionado de volta para o Firewall.
  • As regras de filtragem que não podem ser impostas usando NSGs na sub-rede PHSM podem ser configuradas no Firewall.
  • O tráfego Spoke e o tráfego local para o ambiente PHSM são protegidos.

Firewall com proxy reverso

Este design é uma boa opção ao executar SNAT em um Firewall que não foi aprovado pelas equipes de segurança de rede, exigindo, em vez disso, manter os IPs de origem e destino inalterados para o tráfego que atravessa o Firewall.

Essa arquitetura usa um proxy reverso, implantado em uma sub-rede dedicada na VNet PHSM diretamente ou em uma VNet emparelhada. Em vez de enviar tráfego para os dispositivos PHSM, o destino é definido como o IP do proxy reverso, localizado em uma sub-rede que não tem as restrições da sub-rede delegada do PHSM: NSGs e UDRs podem ser configurados e combinados com um Firewall no hub central.

Diagrama de arquitetura do firewall com proxy reverso

Esta solução requer um proxy reverso, como:

  • F5 (Azure Marketplace; Baseado em VM)
  • NGINXaaS (Azure Marketplace; PaaS totalmente gerenciado)
  • Servidor proxy reverso usando NGINX (baseado em VM)
  • Servidor proxy reverso usando HAProxy (baseado em VM)

Exemplo de servidor proxy reverso usando configuração NGINX (baseada em VM) para balancear a carga do tráfego tcp:

# Nginx.conf  
stream { 
    server { 
        listen 1500; 
        proxy_pass 10.221.8.4:1500; 
    } 

    upstream phsm { 
        server 10.221.8.5:443; 
    } 

    server { 
        listen 443; 
        proxy_pass phsm; 
        proxy_next_upstream on; 
    } 
} 

Tabelas de rotas necessárias:

  • Local para PHSM: uma Tabela de Rotas contendo um UDR para o intervalo de VNet do HSM de Pagamento e apontando para o Firewall do hub central é aplicada à Sub-rede Gateway.
  • VNet(s) Spoke para PHSM: uma Tabela de Rotas contendo a rota padrão usual apontando para o Firewall do hub central é aplicada às sub-redes Spoke VNet(s).

Importante

A propagação da Rota do Gateway deve ser desabilitada na sub-rede do proxy reverso, para que um UDR 0/0 seja suficiente para forçar o tráfego de retorno através do firewall.

Resultados:

  • UDRs que não são suportados na sub-rede PHSM podem ser configurados na sub-rede proxy reverso.
  • O proxy reverso SNATs o IP do cliente: ao encaminhar o tráfego para o PHSM, o tráfego de retorno será automaticamente direcionado de volta para o proxy reverso.
  • As regras de filtragem que não podem ser impostas usando NSGs na sub-rede PHSM podem ser configuradas no Firewall e/ou em NSGs aplicados à sub-rede de proxy reverso.
  • O tráfego Spoke e o tráfego local para o ambiente PHSM são protegidos.

Próximos passos