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 das Azure Payment HSM?.
Wenn ein Payment HSM bereitgestellt wird, verfügt es über eine Hostnetzwerkschnittstelle und eine Verwaltungsnetzwerkschnittstelle. Es gibt mehrere Bereitstellungsszenarien:
- Mit Host- und Verwaltungsports im selben VNet
- Mit Host- und Verwaltungsports in unterschiedlichen VNets
- Mit Host- und Verwaltungsport mit IP-Adressen in unterschiedlichen VNets
In allen obigen Szenarien ist das Payment HSM ein in VNet eingefügter Dienst in einem delegierten Subnetz hsmSubnet, und managementHsmSubnet muss an den Microsoft.HardwareSecurityModules/dedicatedHSMs-Dienst delegiert werden.
Wichtig
Das FastPathEnabled-Feature muss für alle Abonnements registriert und genehmigt werden, die Zugriff auf das 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 ist. Beide Schritte müssen abgeschlossen sein, damit Ressourcen eine Verbindung mit den Payment HSM-Geräten herstellen können. 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 Payment HSM enthält einige Richtlinieneinschränkungen für diese Subnetze: Netzwerksicherheitsgruppen (Network Security Groups, NSGs) und benutzerdefinierte Routen (User-Defined Routes, 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 vorgestellt: eine Firewall mit Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) und eine Firewall mit Reverseproxy.
Firewall mit Quellnetzwerkadressübersetzung (SNAT)
Dieser Entwurf ist von der Dedicated 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. In diesem Entwurf kann entweder ein Azure Firewall oder ein FW-NVA von Drittanbietern verwendet werden.
Routingtabellen erforderlich:
- Lokal zu PHSM: Eine Routingtabelle mit einem UDR für den Payment HSM-VNET-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 die Spoke-VNet-Subnetze angewendet.
Ergebnisse:
- UDRs, die im PHSM-Subnetz nicht unterstützt werden, werden von der Firewall behoben, die SNAT auf der Client-IP-Adresse ausführt: Beim Weiterleiten von Datenverkehr an PHSM wird der zurückkehrende Datenverkehr automatisch an die Firewall zurück geleitet.
- Filterregeln, die nicht mithilfe von NSGs im PHSM-Subnetz erzwungen werden können, können auf der Firewall konfiguriert werden.
- Sowohl Spoke-Datenverkehr als auch lokaler Datenverkehr für die PHSM-Umgebung sind gesichert.
Firewall mit Reverseproxy
Dieser Entwurf ist eine gute Option, wenn SNAT auf einer Firewall ausgeführt wird, die nicht von Netzwerksicherheitsteams genehmigt wurde, und stattdessen verlangt, dass die Quell- und Ziel-IPs für den Datenverkehr, der die Firewall passiert, unverändert bleiben müssen.
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.
Für diese Lösung ist ein Reverseproxy 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 einen Reverseproxyserver mit NGINX-Konfiguration (VM-basiert) zum Lastenausgleich von TCP-Datenverkehr:
# 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-VNET-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 die Spoke-VNet-Subnetze angewendet.
Wichtig
Das Propagieren von Gatewayrouten muss im Reverseproxysubnetz deaktiviert werden, damit ein 0/0-UDR ausreicht, um den zurückkehrenden Datenverkehr über die Firewall zu erzwingen.
Ergebnisse:
- UDRs, die im PHSM-Subnetz nicht unterstützt werden, können im Reverseproxysubnetz 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 in der Firewall und/oder in NSGs konfiguriert werden, die auf das Reverseproxysubnetz angewendet werden.
- Sowohl Spoke-Datenverkehr als auch lokaler Datenverkehr für die PHSM-Umgebung sind gesichert.