Udostępnij za pośrednictwem

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

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. Porty hosta i zarządzania w tej samej sieci wirtualnej.
  2. Porty hosta i zarządzania w różnych VNetach.
  3. Port hosta i port zarządzania z adresami IP w różnych sieciach wirtualnych.

We wszystkich powyższych scenariuszach moduł HSM płatności jest usługą wstrzykiwaną do sieci wirtualnej w delegowanej podsieci: hsmSubnet i managementHsmSubnet muszą zostać delegowane do usługi Microsoft.HardwareSecurityModules/dedicatedHSMs.

Ważne

Funkcja FastPathEnabled musi być zarejestrowana i zatwierdzona we wszystkich subskrypcjach, które wymagają dostępu do modułu HSM płatności. Tag fastpathenabled musi być również włączony w sieci wirtualnej hostującej delegowaną podsieć HSM płatności oraz we wszystkich równorzędnych sieciach wirtualnych wymagających łączności z urządzeniami HSM płatności.

Aby znacznik fastpathenabled sieci wirtualnej był prawidłowy, funkcja FastPathEnabled musi być włączona w subskrypcji, w której wdrożono tę sieć wirtualną. Aby umożliwić zasobom łączenie się z urządzeniami HSM do obsługi 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ń i trasy User-Defined (UDR) nie są obecnie obsługiwane.

Istnieje możliwość obejścia bieżącego ograniczenia UDR i sprawdzenia ruchu kierowanego do Payment HSM. W tym artykule przedstawiono dwa sposoby: zaporę z translacją adresów źródłowych (SNAT) oraz zaporę ze zwrotnym serwerem proxy.

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

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

Zapora sieciowa SNAT adres IP klienta przed przekazaniem ruchu do karty sieciowej PHSM, dzięki czemu ruch powrotny jest automatycznie zwracany do zapory sieciowej. W tym projekcie można użyć Azure Firewall lub zapory (FW) NVA od innej firmy.

Diagram architektury zapory z funkcją SNAT

Wymagane tabele tras:

  • Lokalnie do PHSM: Tabela tras zawierająca UDR dla zakresu sieci wirtualnej Payment HSM i wskazująca na centralną zaporę sieciową koncentratora jest zastosowana do GatewaySubnet.
  • Sieci wirtualne Spoke do PHSM: tabela tras zawierająca standardową trasę domyślną wskazującą zaporę centralnego huba jest stosowana do jednej lub kilku podsieci sieci wirtualnych Spoke.

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 jest automatycznie kierowany 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 Spoke i ruch wewnętrzny do środowiska PHSM są zabezpieczone.

Zapora z odwróconym serwerem proxy

Ten projekt jest dobrym rozwiązaniem, gdy wykonywane jest SNAT na zaporze niezatwierdzonej przez zespoły ds. bezpieczeństwa sieci, co wymaga utrzymania bez zmian źródłowych i docelowych adresów IP 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.

Diagram architektury zapory z odwrotnym serwerem proxy

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

  • F5 (Azure Marketplace; oparty na maszynach wirtualnych)
  • NGINXaaS (Azure Marketplace; Usługa PaaS w pełni zarządzana)
  • Zwrotny serwer proxy przy użyciu serwera NGINX (opartego na maszynie wirtualnej)
  • Serwer proxy zwrotny przy użyciu HAProxy (oparty na maszynie wirtualnej)

Przykład konfiguracji odwróconego serwera proxy z użyciem 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: Do podsieci GatewaySubnet jest stosowana tabela tras zawierająca trasę zdefiniowaną przez użytkownika dla zakresu sieci wirtualnej modułu HSM płatności. Trasa ta wskazuje na zaporę sieciową centralnego koncentratora.
  • Sieci wirtualne typu Spoke do PHSM: Tabela routingu zawierająca zwykłą trasę domyślną wskazującą centralną zaporę w centrali jest stosowana do jednej lub więcej podsieci sieci wirtualnych typu Spoke.

Ważne

Propagacja trasy Gateway musi być wyłączona w podsieci odwrotnego serwera proxy, aby trasa 0/0 UDR wystarczyła do wymuszenia ruchu powrotnego przez zaporę.

Wyniki:

  • Tras UDR nieobsługiwane w podsieci PHSM można skonfigurować w podsieci zwrotnego serwera proxy.
  • Odwrotny serwer proxy zmienia źródłowy adres IP klienta (SNAT): podczas przekazywania ruchu do PHSM ruch powrotny zostanie automatycznie przekierowany z powrotem do odwrotnego 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.

Dalsze kroki