Partager via

Inspection du trafic HSM de paiement Azure

  • Article

Hardware Security Module de paiement Azure (HSM de paiement ou PHSM) est un service nu fournissant des opérations de clé de chiffrement pour les transactions de paiement en temps réel et critiques dans le cloud Azure. Pour plus d’informations, consultez Qu’est-ce qu’HSM de paiement Azure ?.

Lorsqu’HSM de paiement est déployé, il est fourni avec une interface réseau hôte et une interface réseau de gestion. Il existe plusieurs scénarios de déploiement :

  1. Avec des ports hôte et de gestion dans le même réseau virtuel
  2. Avec des ports hôte et de gestion dans des réseaux virtuels différents
  3. Avec des ports hôte et de gestion ayant des adresses IP dans différents réseaux virtuels

Dans tous les scénarios ci-dessus, l’HSM de paiement est un service injecté de réseau virtuel dans un sous-réseau délégué : hsmSubnet et managementHsmSubnet doivent être délégués au service Microsoft.HardwareSecurityModules/dedicatedHSMs.

Important

La fonctionnalité FastPathEnabled doit être inscrite et approuvée sur tous les abonnements qui ont besoin d’accéder à l’HSM de paiement. Vous devez également activer la balise fastpathenabled sur le réseau virtuel hébergeant le sous-réseau délégué HSM de paiement et sur chaque réseau virtuel appairé nécessitant une connectivité aux appareils HSM de paiement.

Pour que la balise de réseau virtuel fastpathenabled soit valide, la fonctionnalité FastPathEnabled doit être activée sur l’abonnement où ce réseau virtuel est déployé. Les deux étapes doivent être effectuées pour permettre aux ressources de se connecter aux appareils HSM de paiement. Pour plus d’informations, consultez FastPathEnabled.

PHSM n’est pas compatible avec les topologies vWAN ou le peering de réseaux virtuels entre régions, comme indiqué dans la topologie prise en charge. L’HSM de paiement est fourni avec certaines restrictions de stratégie sur ces sous-réseaux : les groupes de sécurité réseau (NSG) et les itinéraires définis par l’utilisateur (UDR) ne sont actuellement pas pris en charge.

Il est possible de contourner la restriction UDR actuelle et d’inspecter le trafic destiné à un HSM de paiement. Cet article présente deux façons : un pare-feu avec traduction d’adresses réseau sources (SNAT) et un pare-feu avec proxy inverse.

Pare-feu avec traduction d’adresses réseau sources (SNAT)

Cette conception est inspirée par l’architecture de solution HSM dédiée.

Le pare-feu effectue une opération SNAT sur l’adresse IP du client avant de transférer le trafic vers la carte réseau PHSM, garantissant que le trafic de retour sera automatiquement redirigé vers le pare-feu. Un Pare-feu Azure ou une appliance virtuelle réseau FW tierce peut être utilisée dans cette conception.

Diagramme d’architecture du pare-feu avec SNAT

Tables de routage requises :

  • Local vers PHSM : une table de routage contenant un UDR pour la plage de réseau virtuel HSM de paiement et pointant vers le pare-feu de hub central est appliquée au GatewaySubnet.
  • Réseau(s) virtuel(s) Spoke vers PHSM : une table de routage contenant l’itinéraire par défaut habituel pointant vers le pare-feu de hub central est appliquée aux sous-réseaux virtuels Spoke.

Résultats :

  • Les UDR non pris en charge sur le sous-réseau PHSM sont traités par le pare-feu effectuant l’opération SNAT sur l’adresse IP du client : lors du transfert du trafic vers PHSM, le trafic de retour est automatiquement redirigé vers le pare-feu.
  • Les règles de filtrage qui ne peuvent pas être appliquées à l’aide de groupes de sécurité réseau sur le sous-réseau PHSM peuvent être configurées sur le pare-feu.
  • Le trafic Spoke et le trafic local vers l’environnement PHSM sont sécurisés.

Pare-feu avec proxy inverse

Cette conception est une bonne option lors de l’exécution de SNAT sur un pare-feu qui n’a pas été approuvé par les équipes de sécurité réseau, ce qui nécessite de conserver les adresses IP source et de destination inchangées pour le trafic traversant le pare-feu.

Cette architecture utilise un proxy inverse, déployé directement dans un sous-réseau dédié du réseau virtuel PHSM ou dans un réseau virtuel appairé. Au lieu d’envoyer du trafic aux appareils PHSM, la destination est définie sur l’adresse IP du proxy inverse, située dans un sous-réseau qui n’a pas les restrictions du sous-réseau délégué PHSM : les groupes de sécurité réseau et les UDR peuvent être configurés et combinés avec un pare-feu dans le hub central.

Diagramme d’architecture du pare-feu avec proxy inverse

Cette solution nécessite un proxy inverse, par exemple :

  • F5 (Place de marché Azure ; basé sur une machine virtuelle)
  • NGINXaaS (Place de marché Azure ; PaaS complètement managé)
  • Serveur proxy inverse utilisant NGINX (basé sur une machine virtuelle)
  • Serveur proxy inverse utilisant HAProxy (basé sur une machine virtuelle)

Exemple de serveur proxy inverse utilisant la configuration NGINX (basée sur une machine virtuelle) pour équilibrer la charge du trafic 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; 
    } 
} 

Tables de routage requises :

  • Local vers PHSM : une table de routage contenant un UDR pour la plage de réseau virtuel HSM de paiement et pointant vers le pare-feu de hub central est appliquée au GatewaySubnet.
  • Réseau(s) virtuel(s) Spoke vers PHSM : une table de routage contenant l’itinéraire par défaut habituel pointant vers le pare-feu de hub central est appliquée aux sous-réseaux virtuels Spoke.

Important

La propagation de l’itinéraire de passerelle doit être désactivée sur le sous-réseau du proxy inverse, afin qu’un UDR de 0/0 soit suffisant pour forcer le trafic de retour via le pare-feu.

Résultats :

  • Les UDR non pris en charge sur le sous-réseau PHSM peuvent être configurés sur le sous-réseau proxy inverse.
  • Le proxy inverse effectue une opération SNAT sur l’adresse IP du client : lors du transfert du trafic vers PHSM, le trafic de retour est automatiquement redirigé vers le proxy inverse.
  • Les règles de filtrage qui ne peuvent pas être appliquées à l’aide de groupes de sécurité réseau sur le sous-réseau PHSM peuvent être configurées sur le pare-feu et/ou sur les groupes de sécurité réseau appliqués au sous-réseau proxy inverse.
  • Le trafic Spoke et le trafic local vers l’environnement PHSM sont sécurisés.

Étapes suivantes