Udostępnij za pośrednictwem

Inspekcja ruchu modułu HSM w usłudze Azure Payment

  • Artykuł

Azure Payment Hardware Security Module (Payment HSM lub PHSM) to bez systemu operacyjnego usługa zapewniająca operacje kluczy kryptograficznych dla transakcji płatności w czasie rzeczywistym i krytycznych transakcji płatniczych w chmurze platformy Azure. Aby uzyskać więcej informacji, zobacz Co to jest moduł HSM usługi Azure Payment?

Po wdrożeniu modułu HSM płatności jest dostarczany z interfejsem sieciowym hosta i interfejsem sieciowym zarządzania. Istnieje kilka scenariuszy wdrażania:

  1. W przypadku portów hosta i zarządzania w tej samej sieci wirtualnej
  2. W przypadku portów hosta i zarządzania w różnych sieciach wirtualnych
  3. Z hostem i portem zarządzania z adresami IP w różnych sieciach wirtualnych

We wszystkich powyższych scenariuszach moduł HSM płatności jest usługą wstrzykiwaną przez sieć wirtualną w delegowanej podsieci: hsmSubnet i managementHsmSubnet musi być delegowana do Microsoft.HardwareSecurityModules/dedicatedHSMs usługi.

Ważne

Funkcja musi być zarejestrowana i zatwierdzona FastPathEnabled we wszystkich subskrypcjach, które wymagają dostępu do modułu HSM płatności. Należy również włączyć fastpathenabled tag w sieci wirtualnej obsługującej podsieć delegowana modułu HSM płatności oraz w każdej równorzędnej sieci wirtualnej wymagającej łączności z urządzeniami z modułem HSM płatności.

fastpathenabled Aby tag sieci wirtualnej był prawidłowy, funkcja musi być włączona w subskrypcji, FastPathEnabled w której wdrożono tę sieć wirtualną. Aby umożliwić zasobom łączenie się z urządzeniami z modułem HSM płatności, należy wykonać oba kroki. Aby uzyskać więcej informacji, zobacz FastPathEnabled.

Funkcja PHSM nie jest zgodna z topologiami vWAN ani komunikacją równorzędną sieci wirtualnych między regionami, jak pokazano w obsługiwanej topologii. Moduł HSM płatności zawiera pewne ograniczenia zasad w tych podsieciach: sieciowe grupy zabezpieczeń (NSG) i trasy zdefiniowane przez użytkownika (UDR) nie są obecnie obsługiwane.

Istnieje możliwość obejścia bieżącego ograniczenia trasy zdefiniowanej przez użytkownika i sprawdzenia ruchu kierowanego do modułu HSM płatności. W tym artykule przedstawiono dwa sposoby: zaporę z translacjami adresów sieciowych (SNAT) i zaporą z zwrotnym serwerem proxy.

Zapora z tłumaczeniem źródłowych adresów sieciowych (SNAT)

Ten projekt jest inspirowany architekturą dedykowanego rozwiązania HSM.

Zapora SNAT adres IP klienta przed przekazaniem ruchu do karty sieciowej PHSM, gwarantując, że ruch powrotny zostanie automatycznie przekierowany z powrotem do zapory. W tym projekcie można użyć usługi Azure Firewall lub urządzenia WUS innej firmy.

Architecture diagram of the firewall with SNAT

Wymagane tabele tras:

  • Lokalnie do phSM: tabela tras zawierająca trasę zdefiniowaną przez użytkownika dla zakresu sieci wirtualnej modułu HSM płatności i wskazująca centralną zaporę koncentratora jest stosowana do podsieci GatewaySubnet.
  • Sieci wirtualne będące szprychami do phSM: tabela tras zawierająca zwykłą trasę domyślną wskazującą centralną zaporę piasty jest stosowana do podsieci sieci wirtualnych szprych.

Wyniki:

  • Trasy zdefiniowane przez użytkownika nieobsługiwane w podsieci PHSM są rozwiązywane przez zaporę wykonującą SNAT na adresIE IP klienta: podczas przekazywania ruchu do phSM ruch powrotny zostanie automatycznie przekierowany z powrotem do zapory.
  • Reguły filtrowania, których nie można wymusić przy użyciu sieciowych grup zabezpieczeń w podsieci PHSM, można skonfigurować w zaporze.
  • Ruch szprychy i ruch lokalny do środowiska PHSM są zabezpieczone.

Zapora z zwrotnym serwerem proxy

Ten projekt jest dobrym rozwiązaniem w przypadku wykonywania protokołu SNAT w zaporze, która nie została zatwierdzona przez zespoły ds. zabezpieczeń sieci, wymagając zamiast tego zachowania źródłowych i docelowych adresów IP bez zmian dla ruchu przechodzącego przez zaporę.

Ta architektura używa zwrotnego serwera proxy wdrożonego w dedykowanej podsieci w sieci wirtualnej PHSM bezpośrednio lub w równorzędnej sieci wirtualnej. Zamiast wysyłać ruch do urządzeń PHSM, obiekt docelowy jest ustawiony na zwrotny adres IP serwera proxy znajdujący się w podsieci, która nie ma ograniczeń dotyczących delegowanej podsieci PHSM: można skonfigurować zarówno sieciowe grupy zabezpieczeń, jak i trasy zdefiniowane przez użytkownika, a także w połączeniu z zaporą w centrum centralnym.

Architecture diagram of the firewall with reverse proxy

To rozwiązanie wymaga zwrotnego serwera proxy, takiego jak:

  • F5 (Azure Marketplace; Oparte na maszynie wirtualnej)
  • NGINXaaS (Azure Marketplace; Usługa PaaS w pełni zarządzana)
  • Zwrotny serwer proxy przy użyciu serwera NGINX (opartego na maszynie wirtualnej)
  • Zwrotny serwer proxy przy użyciu haProxy (opartego na maszynie wirtualnej)

Przykład konfiguracji zwrotnego serwera proxy używającego serwera NGINX (opartego na maszynie wirtualnej) w celu równoważenia obciążenia ruchu tcp:

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

Wymagane tabele tras:

  • Lokalnie do phSM: tabela tras zawierająca trasę zdefiniowaną przez użytkownika dla zakresu sieci wirtualnej modułu HSM płatności i wskazująca centralną zaporę koncentratora jest stosowana do podsieci GatewaySubnet.
  • Sieci wirtualne będące szprychami do phSM: tabela tras zawierająca zwykłą trasę domyślną wskazującą centralną zaporę piasty jest stosowana do podsieci sieci wirtualnych szprych.

Ważne

Propagacja trasy bramy musi być wyłączona w podsieci zwrotnego serwera proxy, dzięki czemu trasa zdefiniowana przez użytkownika 0/0 wystarczy, aby wymusić ruch powrotny przez zaporę.

Wyniki:

  • Trasy zdefiniowane przez użytkownika nie są obsługiwane w podsieci PHSM można skonfigurować w podsieci zwrotnego serwera proxy.
  • Zwrotny serwer proxy SNATs adres IP klienta: podczas przekazywania ruchu do PHSM ruch powrotny zostanie automatycznie przekierowany z powrotem do zwrotnego serwera proxy.
  • Reguły filtrowania, których nie można wymusić przy użyciu sieciowych grup zabezpieczeń w podsieci PHSM, można skonfigurować w zaporze i/lub w sieciowych grupach zabezpieczeń zastosowanych do odwrotnej podsieci serwera proxy.
  • Ruch szprychy i ruch lokalny do środowiska PHSM są zabezpieczone.

Następne kroki