Bagikan melalui

Inspeksi lalu lintas Azure Payment HSM

  • Artikel

Modul Keamanan Perangkat Keras Pembayaran Azure (Payment HSM atau PHSM) adalah layanan bare-metal yang menyediakan operasi kunci kriptografi untuk transaksi pembayaran real time dan kritis di cloud Azure. Untuk informasi selengkapnya, lihat Apa itu Azure Payment HSM?.

Ketika Payment HSM disebarkan, HSM dilengkapi dengan antarmuka jaringan host dan antarmuka jaringan manajemen. Ada beberapa skenario penyebaran:

  1. Dengan port host dan manajemen di VNet yang sama
  2. Dengan port host dan manajemen di VNet yang berbeda
  3. Dengan host dan port manajemen dengan alamat IP di VNet yang berbeda

Dalam semua skenario di atas, Payment HSM adalah layanan yang disuntikkan VNet dalam subnet yang didelegasikan: hsmSubnet dan managementHsmSubnet harus didelegasikan ke Microsoft.HardwareSecurityModules/dedicatedHSMs layanan.

Penting

Fitur FastPathEnabled harus terdaftar dan disetujui pada semua langganan yang memerlukan akses ke HSM Pembayaran. Anda juga harus mengaktifkan tag di VNet yang fastpathenabled menghosting subnet yang didelegasikan Payment HSM dan pada setiap VNet yang di-peering yang memerlukan konektivitas ke perangkat Payment HSM.

fastpathenabled Agar tag VNet valid, FastPathEnabled fitur harus diaktifkan pada langganan tempat VNet disebarkan. Kedua langkah harus diselesaikan untuk mengaktifkan sumber daya agar terhubung ke perangkat Payment HSM. Untuk informasi selengkapnya, lihat FastPathEnabled.

PHSM tidak kompatibel dengan topologi vWAN atau peering VNet lintas wilayah, seperti yang tercantum dalam topologi yang didukung. HSM Pembayaran dilengkapi dengan beberapa pembatasan kebijakan pada subnet ini: Kelompok Keamanan Jaringan (NSG) dan Rute yang Ditentukan Pengguna (UDR) saat ini tidak didukung.

Dimungkinkan untuk melewati pembatasan UDR saat ini dan memeriksa lalu lintas yang ditujukan ke HSM Pembayaran. Artikel ini menyajikan dua cara: firewall dengan terjemahan alamat jaringan sumber (SNAT), dan firewall dengan proksi terbalik.

Firewall dengan terjemahan alamat jaringan sumber (SNAT)

Desain ini terinspirasi oleh arsitektur solusi Dedicated HSM.

Firewall melakukan SNAT alamat IP klien sebelum meneruskan lalu lintas ke PHSM NIC, menjamin bahwa lalu lintas kembali akan secara otomatis diarahkan kembali ke Firewall. Baik Azure Firewall atau FW NVA pihak ketiga dapat digunakan dalam desain ini.

Architecture diagram of the firewall with SNAT

Tabel rute diperlukan:

  • Lokal ke PHSM: Tabel Rute yang berisi UDR untuk rentang VNet HSM Pembayaran dan menunjuk ke Firewall hub pusat diterapkan ke GatewaySubnet.
  • Spoke VNet ke PHSM: Tabel Rute yang berisi rute default biasa yang menunjuk ke Firewall hub pusat diterapkan ke subnet Spoke VNet.

Hasil:

  • UDR yang tidak didukung pada subnet PHSM ditangani oleh Firewall yang melakukan SNAT pada IP klien: saat meneruskan lalu lintas ke PHSM, lalu lintas pengembalian akan secara otomatis diarahkan kembali ke Firewall.
  • Aturan pemfilteran yang tidak dapat diberlakukan menggunakan NSG pada subnet PHSM dapat dikonfigurasi pada Firewall.
  • Lalu lintas Spoke dan lalu lintas lokal ke lingkungan PHSM diamankan.

Firewall dengan proksi terbalik

Desain ini adalah opsi yang baik saat melakukan SNAT pada Firewall yang belum disetujui oleh tim keamanan jaringan, mengharuskan sebaliknya untuk menjaga IP sumber dan tujuan tidak berubah untuk lalu lintas yang melintasi Firewall.

Arsitektur ini menggunakan proksi terbalik, disebarkan dalam subnet khusus di VNet PHSM secara langsung atau di VNet yang di-peering. Alih-alih mengirim lalu lintas ke perangkat PHSM, tujuan diatur ke IP proksi terbalik, yang terletak di subnet yang tidak memiliki batasan subnet yang didelegasikan PHSM: NSG dan UDR dapat dikonfigurasi, dan dikombinasikan dengan Firewall di hub pusat.

Architecture diagram of the firewall with reverse proxy

Solusi ini memerlukan proksi terbalik, seperti:

  • F5 (Marketplace Azure; Berbasis VM)
  • NGINXaaS (Marketplace Azure; PaaS dikelola sepenuhnya)
  • Server proksi terbalik menggunakan NGINX (berbasis VM)
  • Server proksi terbalik menggunakan HAProxy (berbasis VM)

Contoh Server proksi terbalik menggunakan konfigurasi NGINX (berbasis VM) untuk menyeimbangkan beban lalu lintas 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; 
    } 
} 

Tabel rute diperlukan:

  • Lokal ke PHSM: Tabel Rute yang berisi UDR untuk rentang VNet HSM Pembayaran dan menunjuk ke Firewall hub pusat diterapkan ke GatewaySubnet.
  • Spoke VNet ke PHSM: Tabel Rute yang berisi rute default biasa yang menunjuk ke Firewall hub pusat diterapkan ke subnet Spoke VNet.

Penting

Propagasi Rute Gateway harus dinonaktifkan pada subnet proksi terbalik, sehingga UDR 0/0 cukup untuk memaksa lalu lintas kembali melalui firewall.

Hasil:

  • UDR yang tidak didukung pada subnet PHSM dapat dikonfigurasi pada subnet proksi terbalik.
  • Proksi terbalik SNAT IP klien: saat meneruskan lalu lintas ke PHSM, lalu lintas kembali akan secara otomatis diarahkan kembali ke proksi terbalik.
  • Aturan pemfilteran yang tidak dapat diberlakukan menggunakan NSG pada subnet PHSM dapat dikonfigurasi pada Firewall dan/atau pada NSG yang diterapkan ke subnet proksi terbalik.
  • Lalu lintas Spoke dan lalu lintas lokal ke lingkungan PHSM diamankan.

Langkah berikutnya