Megosztás a következőn keresztül:

Azure Payment HSM forgalomvizsgálata

  • Cikk

Az Azure Payment Hardver biztonsági modul (Payment HSM vagy PHSM) egy operációs rendszer nélküli szolgáltatás , amely titkosítási kulcsműveleteket biztosít a valós idejű és kritikus fizetési tranzakciókhoz az Azure-felhőben. További információ: Mi az Azure Payment HSM?

A fizetési HSM üzembe helyezésekor gazdagép hálózati adapterrel és felügyeleti hálózati adapterrel rendelkezik. Számos üzembe helyezési forgatókönyv létezik:

  1. Gazdagép- és felügyeleti portok ugyanazon a virtuális hálózaton
  2. Gazdagép- és felügyeleti portokkal különböző virtuális hálózatokon
  3. Gazdagép- és felügyeleti port ip-címekkel különböző virtuális hálózatokon

A fenti forgatókönyvek mindegyikében a fizetési HSM egy virtuális hálózatba injektált szolgáltatás egy delegált alhálózatban, hsmSubnet amelyet managementHsmSubnet a szolgáltatáshoz Microsoft.HardwareSecurityModules/dedicatedHSMs kell delegálni.

Fontos

A FastPathEnabled funkciót regisztrálni kell és jóvá kell hagyni minden olyan előfizetésen, amelyhez hozzá kell férni a fizetési HSM-hez. Emellett engedélyeznie kell a címkét a fastpathenabled fizetési HSM delegált alhálózatot üzemeltető virtuális hálózaton, valamint minden olyan társhálózaton, amelyhez csatlakozni kell a fizetési HSM-eszközökhöz.

Ahhoz, hogy a fastpathenabled virtuális hálózat címkéje érvényes legyen, a FastPathEnabled funkciót engedélyezni kell azon az előfizetésen, amelyben a virtuális hálózat telepítve van. Mindkét lépést el kell végezni ahhoz, hogy az erőforrások csatlakozni tudjanak a fizetési HSM-eszközökhöz. További információ: FastPathEnabled.

A PHSM nem kompatibilis a vWAN-topológiákkal vagy a régiók közötti virtuális hálózatok közötti társviszony-létesítéssel, ahogyan az a támogatott topológiában szerepel. A fizetési HSM-hez bizonyos szabályzatkorlátozások tartoznak ezekre az alhálózatokra: A hálózati biztonsági csoportok (NSG-k) és a felhasználó által megadott útvonalak (UDR-ek) jelenleg nem támogatottak.

Megkerülheti a jelenlegi UDR-korlátozást, és megvizsgálhatja a fizetési HSM felé irányuló forgalmat. Ez a cikk két módszert mutat be: a forráshálózati címfordítással (SNAT) rendelkező tűzfalat és a fordított proxyval rendelkező tűzfalat.

Tűzfal forráshálózati címfordítással (SNAT)

Ezt a kialakítást a dedikált HSM-megoldásarchitektúra ihlette.

A tűzfal az ügyfél IP-címét továbbítja a PHSM hálózati adapternek, így garantálva, hogy a rendszer automatikusan visszairányítja a visszatérési forgalmat a tűzfalra. Ebben a kialakításban egy Azure Firewall vagy egy harmadik féltől származó FW NVA is használható.

A tűzfal architektúradiagramja az SNAT használatával

Útvonaltáblák megadása kötelező:

  • Helyszíni a PHSM-be: a rendszer egy UDR-t tartalmazó útvonaltáblát alkalmaz a HSM virtuális hálózat fizetési tartományához, és a központi központi tűzfalra mutat a GatewaySubnetre.
  • Küllős virtuális hálózatok a PHSM-hez: a rendszer a központi központi tűzfalra mutató szokásos alapértelmezett útvonalat tartalmazó útvonaltáblát alkalmazza a küllős virtuális hálózatok alhálózataira.

Eredmények:

  • A PHSM-alhálózaton nem támogatott UDR-eket a tűzfal kezeli, amely SNAT-t végez az ügyfél IP-címén: amikor a forgalmat a PHSM-hez továbbítja, a visszatérési forgalom automatikusan vissza lesz irányítva a tűzfalra.
  • A PHSM-alhálózat NSG-kkel nem kényszeríthető szűrési szabályai konfigurálhatók a tűzfalon.
  • A küllős forgalom és a PHSM-környezet helyszíni forgalma is biztonságos.

Tűzfal fordított proxyval

Ez a kialakítás akkor jó választás, ha olyan tűzfalon hajtja végre az SNAT-t, amelyet a hálózati biztonsági csapatok nem hagytak jóvá, ehelyett a forrás- és cél IP-címeket változatlanul kell tartani a tűzfalon áthaladó forgalom esetében.

Ez az architektúra fordított proxyt használ, amelyet egy dedikált alhálózatban helyez üzembe közvetlenül a PHSM virtuális hálózaton vagy egy társhálózaton. Ahelyett, hogy forgalmat küldene a PHSM-eszközökre, a cél egy fordított proxy IP-címre van állítva, amely egy olyan alhálózatban található, amely nem rendelkezik a PHSM delegált alhálózat korlátozásaival: az NSG-k és az UDR-ek is konfigurálhatók, és kombinálhatók a központi központban található tűzfallal.

A tűzfal architektúradiagramja fordított proxyval

Ehhez a megoldáshoz fordított proxy szükséges, például:

  • F5 (Azure Marketplace; Virtuálisgép-alapú)
  • NGINXaaS (Azure Marketplace; PaaS teljes mértékben felügyelt)
  • Proxykiszolgáló megfordítása NGINX használatával (VM-alapú)
  • Proxykiszolgáló megfordítása HAProxy használatával (virtuálisgép-alapú)

Példa fordított proxykiszolgálóra az NGINX (VM-alapú) konfigurációval a TCP-forgalom terheléselosztásához:

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

Útvonaltáblák megadása kötelező:

  • Helyszíni a PHSM-be: a rendszer egy UDR-t tartalmazó útvonaltáblát alkalmaz a HSM virtuális hálózat fizetési tartományához, és a központi központi tűzfalra mutat a GatewaySubnetre.
  • Küllős virtuális hálózatok a PHSM-hez: a rendszer a központi központi tűzfalra mutató szokásos alapértelmezett útvonalat tartalmazó útvonaltáblát alkalmazza a küllős virtuális hálózatok alhálózataira.

Fontos

Az átjáróútvonal propagálását le kell tiltani a fordított proxy alhálózatán, hogy a 0/0 UDR elegendő legyen a visszatérési forgalom tűzfalon keresztüli kényszerítéséhez.

Eredmények:

  • A PHSM alhálózaton nem támogatott UDR-ek konfigurálhatók a fordított proxy alhálózaton.
  • A fordított proxy az ügyfél IP-címét továbbítja: a forgalom PHSM-hez való továbbításakor a visszatérési forgalom automatikusan vissza lesz irányítva a fordított proxyra.
  • A PHSM alhálózat NSG-kkel nem kényszeríthető szűrési szabályai konfigurálhatók a tűzfalon és/vagy a fordított proxy alhálózatra alkalmazott NSG-ken.
  • A küllős forgalom és a PHSM-környezet helyszíni forgalma is biztonságos.

Következő lépések