Compartilhar via

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

  • Artigo

O Módulo de Segurança de Hardware de Pagamento (HSM de Pagamento ou PHSM) do Azure é 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, confira O que é o HSM de Pagamento do Azure?.

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

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

Em todos os cenários acima, o HSM de Pagamento é um serviço injetado por VNet em uma sub-rede delegada: hsmSubnet e managementHsmSubnet devem ser delegados ao serviço Microsoft.HardwareSecurityModules/dedicatedHSMs.

Importante

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

Para que a tag de VNet fastpathenabled seja válida, o recurso FastPathEnabled precisa estar habilitado na assinatura em que essa VNet estiver implantada. Ambas as etapas devem ser executadas para permitir que os recursos se conectem aos dispositivos de HSM de Pagamento. Para saber mais, confira Fastpathenabled.

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

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

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

Esse design é inspirado na Arquitetura da solução de HSM dedicado do Azure.

O firewall faz a SNAT do endereço IP do cliente antes de encaminhar o tráfego para o NIC do PHSM, garantindo que o tráfego de retorno seja direcionado de volta para o Firewall automaticamente. Tanto um Firewall do Azure quanto um NVA de FW de terceiros podem ser usados nesse design.

Architecture diagram of the firewall with SNAT

Tabelas de rotas obrigatórias:

  • Do local para o PHSM: uma Tabela de Rotas que contém um UDR para o intervalo de VNet do HSM de Pagamento apontando para o Firewall do hub central é aplicada ao GatewaySubnet.
  • De VNets Spoke para o PHSM: uma Tabela de Rotas que contém a rota padrão usual apontando para o Firewall do hub central é aplicada às sub-redes das VNets spoke.

Resultados:

  • UDRs sem suporte na sub-rede do PHSM são endereçados pelo Firewall fazendo SNAT no IP do cliente: quando estiver encaminhando o tráfego para o PHSM, o tráfego de retorno será direcionado de volta para o Firewall automaticamente.
  • As regras de filtragem que não podem ser implementadas usando NSGs na sub-rede do PHSM podem ser configuradas no Firewall.
  • Tanto o tráfego Spoke quanto o tráfego local para o ambiente do PHSM são protegidos.

Firewall com proxy reverso

Esse design é uma boa opção quando você estiver executando o SNAT em um Firewall que não foi aprovado pelas equipes de segurança de rede, exigindo, em vez disso, que os IPs de origem e de destino sejam mantidos inalterados para o tráfego que atravessa o Firewall.

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

Architecture diagram of the firewall with reverse proxy

Essa solução requer um proxy reverso, como, por exemplo:

  • 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 a 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 obrigatórias:

  • Do local para o PHSM: uma Tabela de Rotas que contém um UDR para o intervalo de VNet do HSM de Pagamento apontando para o Firewall do hub central é aplicada ao GatewaySubnet.
  • De VNets Spoke para o PHSM: uma Tabela de Rotas que contém a rota padrão usual apontando para o Firewall do hub central é aplicada às sub-redes das VNets spoke.

Importante

A propagação de Rota do Gateway precisa ser desabilitada na sub-rede do proxy reverso de modo que um UDR 0/0 seja suficiente para forçar o tráfego de retorno por meio do firewall.

Resultados:

  • Os UDRs sem suporte na sub-rede do PHSM podem ser configurados na sub-rede do proxy reverso.
  • O proxy reverso faz o SNAT do IP do cliente: quando estiver encaminhando o tráfego para o PHSM, o tráfego de retorno será direcionado de volta para o proxy reverso automaticamente.
  • As regras de filtragem que não podem ser implementadas usando NSGs na sub-rede do PHSM podem ser configuradas no Firewall e/ou nos NSGs aplicados à sub-rede do proxy reverso.
  • Tanto o tráfego Spoke quanto o tráfego local para o ambiente do PHSM são protegidos.

Próximas etapas