Azure Ödeme HSM trafik denetimi

Makale
04/19/2023

Azure Ödeme Donanımı Güvenlik Modülü (Ödeme HSM veya PHSM), Azure bulutunda gerçek zamanlı ve kritik ödeme işlemleri için şifreleme anahtarı işlemleri sağlayan çıplak bir hizmettir . Daha fazla bilgi için bkz. Azure Payment HSM nedir?.

Ödeme HSM dağıtıldığında, bir konak ağ arabirimi ve bir yönetim ağ arabirimi ile birlikte gelir. Çeşitli dağıtım senaryoları vardır:

Yukarıdaki senaryoların tamamında, Payment HSM, temsilci olarak atanan bir alt ağa hsmSubnet sanal ağ eklenmiş bir hizmettir ve managementHsmSubnet hizmete temsilci Microsoft.HardwareSecurityModules/dedicatedHSMs olarak atanmalıdır.

Önemli

Bu FastPathEnabled özellik, Ödeme HSM'sine erişmesi gereken tüm aboneliklerde kayıtlı ve onaylanmalıdır . Ayrıca, Ödeme HSM temsilci alt akını barındıran sanal ağda ve Payment HSM cihazlarına bağlantı gerektiren eşlenmiş her sanal ağda etiketi etkinleştirmeniz fastpathenabled gerekir.

VNet etiketinin fastpathenabled geçerli olması için özelliğin FastPathEnabled , sanal ağın dağıtıldığı abonelikte etkinleştirilmesi gerekir. Kaynakların Ödeme HSM cihazlarına bağlanmasını sağlamak için her iki adımın da tamamlanması gerekir. Daha fazla bilgi için bkz. FastPathEnabled.

PHSM, desteklenen topolojide listelendiği gibi vWAN topolojileri veya bölgeler arası sanal ağ eşlemesi ile uyumlu değildir. Ödeme HSM,bu alt ağlarda bazı ilke kısıtlamalarıyla birlikte gelir: Ağ Güvenlik Grupları (NSG) ve User-Defined Yolları (UDR) şu anda desteklenmemektedir.

Geçerli UDR kısıtlamasını atlamak ve Bir Ödeme HSM'sine yönelik trafiği incelemek mümkündür. Bu makalede iki yöntem sunulur: kaynak ağ adresi çevirisi (SNAT) içeren bir güvenlik duvarı ve ters ara sunucu içeren bir güvenlik duvarı.

Kaynak ağ adresi çevirisi (SNAT) ile güvenlik duvarı

Bu tasarım, Ayrılmış HSM çözüm mimarisinden ilham alır.

Güvenlik duvarı, trafiği PHSM NIC'ye iletmeden önce istemci IP adresini engeller ve dönüş trafiğinin otomatik olarak Güvenlik Duvarı'na geri yönlendirileceğini garanti eder. Bu tasarımda bir Azure Güvenlik Duvarı veya üçüncü taraf bir FW NVA kullanılabilir.

Yol tabloları gerekli:

Şirket içinde PHSM'ye: Ödeme HSM sanal ağ aralığı için UDR içeren ve merkezi hub'a işaret eden Bir Yönlendirme Tablosu GatewaySubnet'e uygulanır.
Uç sanal ağlardan PHSM'ye: Merkez merkez Güvenlik Duvarı'na işaret eden her zamanki varsayılan yolu içeren bir Yönlendirme Tablosu Uç sanal ağlarına uygulanır.

Sonuçlar:

PHSM alt akta desteklenmeyen UDR'ler, güvenlik duvarı tarafından istemci IP'sinde SNAT yaparak ele alınır: TRAFIĞI PHSM'ye iletirken dönüş trafiği otomatik olarak Güvenlik Duvarı'na yönlendirilir.
PHSM alt ağındaki NSG'ler kullanılarak zorlanamayan filtreleme kuralları Güvenlik Duvarı'nda yapılandırılabilir.
Hem Uç trafiği hem de PHSM ortamına yönelik şirket içi trafiğin güvenliği sağlanır.

Ters ara sunucu içeren güvenlik duvarı

Bu tasarım, ağ güvenlik ekipleri tarafından onaylanmamış bir Güvenlik Duvarında SNAT gerçekleştirirken iyi bir seçenektir ve bunun yerine Güvenlik Duvarı'ndan geçen trafik için kaynak ve hedef IP'lerin değişmeden kalmasını zorunlu tutar.

Bu mimari, doğrudan PHSM sanal ağındaki ayrılmış bir alt ağda veya eşlenmiş bir sanal ağda dağıtılan bir ters ara sunucu kullanır. PhSM cihazlarına trafik göndermek yerine hedef, PHSM temsilci alt ağı kısıtlamalarına sahip olmayan bir alt ağda bulunan ters ara sunucu IP'sine ayarlanır: hem NSG'ler hem de UDF'ler yapılandırılabilir ve merkezi hub'daki bir Güvenlik Duvarı ile birleştirilebilir.

Bu çözüm için ters ara sunucu gerekir, örneğin:

F5 (Azure Market; VM tabanlı)
NGINXaaS (Azure Market; PaaS tam olarak yönetiliyor)
NGINX (VM tabanlı) kullanarak ters proxy Sunucusu
HAProxy kullanarak ters proxy Sunucusu (VM tabanlı)

Tcp trafiğinin yükünü dengelemek için NGINX (VM tabanlı) yapılandırması kullanan ters ara sunucu örneği:

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