Freigeben über

Datenverkehrsüberprüfung für Azure Payment HSM

Das Azure Payment Hardware Security Module (Payment HSM oder PHSM) ist ein Bare-Metal-Dienst , der kryptografische Schlüsselvorgänge für Echtzeit- und kritische Zahlungstransaktionen in der Azure-Cloud bereitstellt. Weitere Informationen finden Sie unter Was ist Azure Payment HSM?.

Wenn Das Zahlungs-HSM bereitgestellt wird, verfügt es über eine Hostnetzwerkschnittstelle und eine Verwaltungsnetzwerkschnittstelle. Es gibt mehrere Bereitstellungsszenarien:

  1. Host- und Management-Ports im selben VNet.
  2. Host- und Management-Ports in verschiedenen VNets.
  3. Verwaltungs- und Hostport mit IP-Adressen in verschiedenen VNets.

In allen oben genannten Szenarien ist Payment HSM ein VNet-injizierter Dienst in einem delegierten Subnetz: hsmSubnet Und managementHsmSubnet muss an den Microsoft.HardwareSecurityModules/dedicatedHSMs Dienst delegiert werden.

Wenn Sie eine Routentabelle (UDR-Route) konfigurieren möchten, um das Routing von Paketen über eine virtuelle Netzwerkanwendung oder Firewall zu steuern, die zu einem Azure Payment HSM von einer Quelle im selben VNet oder einem verbundenen VNet geleitet werden, muss das UDR-Präfix spezifischer oder gleich groß sein wie die delegierte Subnetzgröße des Azure Payment HSM. Wenn das UDR-Präfix weniger spezifisch als die delegierte Subnetzgröße ist, ist es nicht effektiv. Wenn Ihr delegiertes Subnetz beispielsweise x.x.x.x/24 ist, müssen Sie Ihren UDR auf x.x.x.x/24 (gleich) oder x.x.x.x/32 (spezifischer) konfigurieren. Wenn Sie die UDR-Route so konfigurieren, dass sie x.x.x.x/16 ist, können nicht definierte Verhaltensweisen wie asymmetrisches Routing zu einem Netzwerkabbruch in der Firewall führen.

Von Bedeutung

Das FastPathEnabled Feature muss für alle Abonnements registriert und genehmigt werden, die Zugriff auf Payment HSM benötigen. Sie müssen auch das fastpathenabled-Tag im VNET aktivieren, welches das delegierte Payment HSM-Subnetz hostet, und auf jedem Peering-VNet, das Konnektivität mit den Payment HSM-Geräten erfordert.

Damit das fastpathenabled VNet-Tag gültig ist, muss das FastPathEnabled Feature für das Abonnement aktiviert sein, in dem dieses VNet bereitgestellt wird. Beide Schritte müssen abgeschlossen sein, um Ressourcen die Verbindung zu den Zahlungs-HSM-Geräten zu ermöglichen. Weitere Informationen finden Sie unter FastPathEnabled.

PHSM ist nicht mit vWAN-Topologien oder regionsübergreifendem VNet-Peering kompatibel, wie in der unterstützten Topologie aufgeführt. Das Zahlungs-HSM enthält einige Richtlinieneinschränkungen für diese Subnetze: Netzwerksicherheitsgruppen (NSGs) und User-Defined Routen (UDRs) werden derzeit nicht unterstützt.

Es ist möglich, die aktuelle UDR-Einschränkung zu umgehen und den Datenverkehr zu überprüfen, der für ein Payment HSM bestimmt ist. In diesem Artikel werden zwei Möglichkeiten beschrieben: eine Firewall mit SNAT (Source Network Address Translation) und eine Firewall mit Reverseproxy.

Firewall mit Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT)

Dieses Design wird von der Dedizierten HSM-Lösungsarchitektur inspiriert.

Die Firewall führt eine SNAT für die Client-IP-Adresse durch, bevor sie den Datenverkehr an die PHSM-NIC weiterleitet, wodurch gewährleistet wird, dass der zurückkehrende Datenverkehr automatisch an die Firewall zurückgeleitet wird. Entweder eine Azure-Firewall oder ein Drittanbieter FW NVA kann in diesem Design verwendet werden.

Architekturdiagramm der Firewall mit SNAT

Routingtabellen erforderlich:

  • Lokal zu PHSM: Eine Routingtabelle mit einem UDR für den Payment HSM-Subnetz-Bereich, der auf die Firewall des zentralen Hubs verweist, wird auf das GatewaySubnet angewendet.
  • Spoke-VNets zu PHSM: Eine Routingtabelle mit der üblichen Standardroute, die auf die zentrale Hubfirewall verweist, wird auf mindestens ein Spoke-VNet-Subnetz angewendet.

Ergebnisse:

  • UDRs, die im PHSM-Subnetz nicht unterstützt werden, werden von der Firewall adressiert, die SNAT auf der Client-IP ausführt: Beim Weiterleiten des Datenverkehrs an PHSM wird der Rückgabedatenverkehr automatisch zurück zur Firewall geleitet.
  • Filterregeln, die nicht mithilfe von NSGs im PHSM-Subnetz erzwungen werden können, können in der Firewall konfiguriert werden.
  • Sowohl Spoke-Datenverkehr als auch lokaler Datenverkehr für die PHSM-Umgebung sind gesichert.

Firewall mit Reverseproxy

Dieses Design ist eine gute Option, wenn SNAT für eine Firewall ausgeführt wird, die von Netzwerksicherheitsteams nicht genehmigt wird, und stattdessen die Quell- und Ziel-IPs für den Datenverkehr, der die Firewall durchquert, unverändert halten muss.

Diese Architektur verwendet einen Reverseproxy, der direkt in einem dedizierten Subnetz im PHSM-VNET oder in einem VNet mit Peering bereitgestellt wird. Anstatt Datenverkehr an die PHSM-Geräte zu senden, wird das Ziel auf die Reverseproxy-IP festgelegt, die sich in einem Subnetz befindet, das nicht über die Einschränkungen des delegierten PHSM-Subnetzes verfügt: Sowohl NSGs als auch UDRs können konfiguriert und mit einer Firewall im zentralen Hub kombiniert werden.

Architekturdiagramm der Firewall mit Reverseproxy

Für diese Lösung ist ein Reverse-Proxy erforderlich, z. B.:

  • F5 (Azure Marketplace; VM-basiert)
  • NGINXaaS (Azure Marketplace; PaaS vollständig verwaltet)
  • Reverseproxyserver mit NGINX (VM-basiert)
  • Reverseproxyserver mit HAProxy (VM-basiert)

Beispiel für Reverseproxyserver mit NGINX-Konfiguration (VM-basiert) zum Lastenausgleich des TCP-Datenverkehrs:

# 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; 
    } 
} 

Routingtabellen erforderlich:

  • Lokal zu PHSM: Eine Routingtabelle mit einem UDR für den Payment HSM-Subnetz-Bereich, der auf die Firewall des zentralen Hubs verweist, wird auf das GatewaySubnet angewendet.
  • Spoke-VNet(s) zu PHSM: Eine Routingtabelle mit der üblichen Standardroute, die auf die zentrale Hubfirewall verweist, wird auf mindestens ein Spoke-VNet-Subnetz angewendet.

Von Bedeutung

Die Verbreitung von Gatewayrouten muss im Reverseproxy-Subnetz deaktiviert werden, sodass ein 0/0 UDR ausreicht, um den Rückverkehr über die Firewall zu erzwingen.

Ergebnisse:

  • UDRs, die im PHSM-Subnetz nicht unterstützt werden, können im Reverse-Proxy-Subnetz konfiguriert werden.
  • Der Reverseproxy führt eine SNATs für die Client-IP durch: Wenn Datenverkehr an PHSM weitergeleitet wird, wird der zurückkehrende Datenverkehr automatisch zurück an den Reverseproxy zurück geleitet.
  • Filterregeln, die nicht mithilfe von NSGs im PHSM-Subnetz erzwungen werden können, können für die Firewall und/oder für NSGs konfiguriert werden, die auf das Reverseproxy-Subnetz angewendet werden.
  • Sowohl Spoke-Datenverkehr als auch lokaler Datenverkehr für die PHSM-Umgebung sind gesichert.

Nächste Schritte

  • Last updated on