Azure Payment HSM-verkeersinspectie
Azure Payment Hardware Security Module (Payment HSM of PHSM) is een bare-metalservice die cryptografische sleutelbewerkingen biedt voor realtime en kritieke betalingstransacties in de Azure-cloud. Zie Wat is Azure Payment HSM? voor meer informatie.
Wanneer Payment HSM wordt geïmplementeerd, wordt deze geleverd met een hostnetwerkinterface en een beheernetwerkinterface. Er zijn verschillende implementatiescenario's:
- Met host- en beheerpoorten in hetzelfde VNet
- Met host- en beheerpoorten in verschillende VNets
- Met host- en beheerpoort met IP-adressen in verschillende VNets
In alle bovenstaande scenario's is Payment HSM een door VNet geïnjecteerde service in een gedelegeerd subnet: hsmSubnet en managementHsmSubnet moet worden gedelegeerd aan Microsoft.HardwareSecurityModules/dedicatedHSMs de service.
Belangrijk
De FastPathEnabled functie moet worden geregistreerd en goedgekeurd voor alle abonnementen die toegang nodig hebben tot De HSM voor betaling. U moet de fastpathenabled tag ook inschakelen op het VNet dat als host fungeert voor het gedelegeerde subnet van de betalings-HSM en op elk gekoppeld VNet waarvoor connectiviteit met de betaal-HSM-apparaten is vereist.
Als u wilt dat de fastpathenabled VNet-tag geldig is, moet de FastPathEnabled functie zijn ingeschakeld voor het abonnement waarin dat VNet is geïmplementeerd. Beide stappen moeten worden voltooid om resources in staat te stellen verbinding te maken met de HSM-apparaten voor betaling. Zie FastPathEnabled voor meer informatie.
PHSM is niet compatibel met vWAN-topologieën of VNet-peering tussen regio's, zoals vermeld in de ondersteunde topologie. Betalings-HSM wordt geleverd met enkele beleidsbeperkingen voor deze subnetten: Netwerkbeveiligingsgroepen (NSG's) en door de gebruiker gedefinieerde routes (UDR's) worden momenteel niet ondersteund.
Het is mogelijk om de huidige UDR-beperking te omzeilen en verkeer te inspecteren dat is bestemd voor een betalings-HSM. Dit artikel bevat twee manieren: een firewall met SNAT (Source Network Address Translation) en een firewall met omgekeerde proxy.
Firewall met SNAT (Source Network Address Translation)
Dit ontwerp is geïnspireerd op de dedicated HSM-oplossingsarchitectuur.
De firewall-SNATs het IP-adres van de client voordat verkeer naar de PHSM-NIC wordt doorgestuurd, zodat het retourverkeer automatisch naar de firewall wordt doorgestuurd. Een Azure Firewall of een externe FW NVA kan in dit ontwerp worden gebruikt.
Routetabellen vereist:
- On-premises naar PHSM: een routetabel met een UDR voor het VNet-bereik van de betalings-HSM en die verwijst naar de firewall van de centrale hub wordt toegepast op het GatewaySubnet.
- Spoke-VNet('s) naar PHSM: een routetabel met de gebruikelijke standaardroute die verwijst naar de centrale hubfirewall wordt toegepast op de spoke-VNet(s) subnetten.
Resultaten:
- UDR's die niet worden ondersteund in het PHSM-subnet, worden geadresseerd door de firewall die SNAT uitvoert op het IP-adres van de client: bij het doorsturen van verkeer naar PHSM wordt het retourverkeer automatisch teruggeleid naar de firewall.
- Filterregels die niet kunnen worden afgedwongen met behulp van NSG's in het PHSM-subnet, kunnen worden geconfigureerd op de firewall.
- Zowel spoke-verkeer als on-premises verkeer naar de PHSM-omgeving worden beveiligd.
Firewall met omgekeerde proxy
Dit ontwerp is een goede optie bij het uitvoeren van SNAT op een firewall die niet is goedgekeurd door netwerkbeveiligingsteams, waarbij in plaats daarvan de bron- en doel-IP-adressen ongewijzigd moeten blijven voor verkeer dat de firewall oversteekt.
Deze architectuur maakt gebruik van een omgekeerde proxy, geïmplementeerd in een toegewezen subnet in het PHSM-VNet rechtstreeks of in een gekoppeld VNet. In plaats van verkeer naar de PHSM-apparaten te verzenden, wordt de bestemming ingesteld op het omgekeerde proxy-IP-adres, dat zich in een subnet bevindt dat niet beschikt over de beperkingen van het gedelegeerde PHSM-subnet: zowel NSG's als UDR's kunnen worden geconfigureerd en gecombineerd met een firewall in de centrale hub.
Voor deze oplossing is een omgekeerde proxy vereist, zoals:
- F5 (Azure Marketplace; Op vm's gebaseerd)
- NGINXaaS (Azure Marketplace; PaaS volledig beheerd)
- Omgekeerde proxyserver met behulp van NGINX (op vm gebaseerd)
- Omgekeerde proxyserver met HAProxy (op vm gebaseerd)
Voorbeeld van omgekeerde proxyserver met behulp van NGINX-configuratie (vm-gebaseerde) om tcp-verkeer te verdelen:
# 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;
}
}
Routetabellen vereist:
- On-premises naar PHSM: een routetabel met een UDR voor het VNet-bereik van de betalings-HSM en die verwijst naar de firewall van de centrale hub wordt toegepast op het GatewaySubnet.
- Spoke-VNet('s) naar PHSM: een routetabel met de gebruikelijke standaardroute die verwijst naar de centrale hubfirewall wordt toegepast op de spoke-VNet(s) subnetten.
Belangrijk
Doorgifte van gatewayroute moet worden uitgeschakeld op het subnet van de omgekeerde proxy, zodat een UDR van 0/0 voldoende is om het retourverkeer via de firewall af te dwingen.
Resultaten:
- UDR's die niet worden ondersteund in het PHSM-subnet, kunnen worden geconfigureerd op het subnet van de omgekeerde proxy.
- De omgekeerde proxy-SNATs het ip-adres van de client: bij het doorsturen van verkeer naar PHSM wordt het retourverkeer automatisch teruggeleid naar de omgekeerde proxy.
- Filterregels die niet kunnen worden afgedwongen met behulp van NSG's in het PHSM-subnet, kunnen worden geconfigureerd op de firewall en/of op NSG's die zijn toegepast op het subnet omgekeerde proxy.
- Zowel spoke-verkeer als on-premises verkeer naar de PHSM-omgeving worden beveiligd.