Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure Payment Hardware Security Module (Payment HSM eller PHSM) är en tjänst utan operativsystem som tillhandahåller kryptografiska nyckelåtgärder för realtids- och kritiska betalningstransaktioner i Azure-molnet . Mer information finns i Vad är Azure Payment HSM?.
När Payment HSM distribueras levereras det med ett värdnätverksgränssnitt och ett hanteringsnätverksgränssnitt. Det finns flera distributionsscenarier:
- Värdgränssnitt och hanteringsgränssnitt i samma VNet.
- Värd- och hanteringsportar i olika virtuella nätverk.
- Värd- och administrationsport med IP-adresser i olika virtuella nätverk.
I alla ovanstående scenarier är Payment HSM en VNet-inmatad tjänst i ett delegerat undernät: hsmSubnet
och managementHsmSubnet
måste delegeras till Microsoft.HardwareSecurityModules/dedicatedHSMs
tjänsten.
Viktigt!
Funktionen FastPathEnabled
måste vara registrerad och godkänd för alla prenumerationer som behöver åtkomst till Payment HSM. Du måste också aktivera taggen fastpathenabled
på det virtuella nätverk som är värd för det betalningshSM-delegerade undernätet och på varje peer-kopplat virtuellt nätverk som kräver anslutning till Payment HSM-enheterna.
För att VNet-taggen fastpathenabled
ska vara giltig FastPathEnabled
måste funktionen vara aktiverad i prenumerationen där det virtuella nätverket distribueras. Båda stegen måste slutföras för att resurser ska kunna ansluta till HSM-betalningsenheterna. Mer information finns i FastPathEnabled.
PHSM är inte kompatibelt med vWAN-topologier eller VNet-peering mellan regioner, som anges i topologin som stöds. Betalnings-HSM levereras med vissa principbegränsningar för dessa undernät: Nätverkssäkerhetsgrupp (NSG:er) och User-Defined rutter (UDR) är inte för närvarande stödda.
Det går att kringgå den aktuella UDR-begränsningen och inspektera trafik som är avsedd för en betalnings-HSM. I den här artikeln beskrivs två sätt: en brandvägg med källnätverksadressöversättning (SNAT) och en brandvägg med omvänd proxy.
Brandvägg med källnätverksadressöversättning (SNAT)
Den här designen är inspirerad av den dedikerade HSM-lösningsarkitekturen.
Brandväggen använder SNAT på klientens IP-adress innan trafiken vidarebefordras till PHSM-nätverkskortet (Primary Host Security Module), vilket garanterar att trafiken automatiskt dirigeras tillbaka till brandväggen. Antingen en Azure Firewall eller en FW NVA från tredje part kan användas i den här designen.
Routningstabeller krävs:
- Lokalt till PHSM: en routningstabell som innehåller en UDR för VNet-intervallet Payment HSM och som pekar på den centrala hubbens brandvägg tillämpas på GatewaySubnet.
- Spoke VNets till PHSM: en routetabell som innehåller den vanliga standardvägen som pekar på den centrala hubbens brandvägg appliceras på ett eller flera undernät för Spoke VNets-nätverk.
Resultat:
- UDR:er som inte stöds i PHSM-undernätet åtgärdas av brandväggen som utför SNAT på klient-IP:en: Vid vidarebefordran av trafik till PHSM dirigeras returtrafiken automatiskt tillbaka till brandväggen.
- Filtreringsregler som inte kan tillämpas med hjälp av NSG:er i PHSM-undernätet kan konfigureras i brandväggen.
- Både Spoke-trafik och lokal trafik till PHSM-miljön skyddas.
Brandvägg med omvänd proxy
Den här designen är ett bra alternativ när du utför SNAT på en brandvägg som inte godkänts av nätverkssäkerhetsteam, vilket i stället kräver att käll- och mål-IP-adresserna inte ändras för trafik som passerar brandväggen.
Den här arkitekturen använder en omvänd proxy som distribueras i ett dedikerat undernät i det virtuella PHSM-nätverket direkt eller i ett peer-kopplat virtuellt nätverk. I stället för att skicka trafik till PHSM-enheterna är målet inställt på den omvända proxy-IP-adressen, som finns i ett undernät som inte har begränsningarna för det PHSM-delegerade undernätet: både NSG:er och UDR:er kan konfigureras och kombineras med en brandvägg i den centrala hubben.
Den här lösningen kräver en omvänd proxy, till exempel:
- F5 (Azure Marketplace; VM-baserad)
- NGINXaaS (Azure Marketplace; Fullständigt hanterad PaaS)
- Omvänd proxyserver med NGINX (VM-baserad)
- Omvänd proxyserver med HAProxy (VM-baserad)
Exempel på omvänd proxyserver med NGINX-konfiguration (VM-baserad) för att belastningsutjämna tcp-trafik:
# 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;
}
}
Routningstabeller krävs:
- Lokalt till PHSM: en routningstabell som innehåller en UDR för VNet-intervallet Payment HSM och som pekar på den centrala hubbens brandvägg tillämpas på GatewaySubnet.
- Virtuella ekernätverk till PHSM: en routningstabell som innehåller den vanliga standardvägen som pekar på den centrala hubbens brandvägg tillämpas på ett eller flera eker-VNets-undernät.
Viktigt!
Gateway-ruttspridning måste inaktiveras i det omvända proxyundernätet, så att en 0/0 UDR är tillräcklig för att styra returtrafiken via brandväggen.
Resultat:
- UDR:er som inte stöds i PHSM-undernätet kan konfigureras i det omvända proxyundernätet.
- Den omvända proxyn SNAT-ar klientens IP-adress: Vid vidarebefordran av trafik till PHSM dirigeras returtrafiken automatiskt tillbaka till den omvända proxyn.
- Filtreringsregler som inte kan tillämpas med hjälp av NSG:er i PHSM-undernätet kan konfigureras i brandväggen och/eller på NSG:er som tillämpas på det omvända proxyundernätet.
- Både trafiken i Spoke-nätverk och lokalnätstrafik till PHSM-miljön är säkrade.