Aracılığıyla paylaş

Azure Ödeme HSM trafik denetimi

  • Makale

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:

  1. Aynı sanal ağda konak ve yönetim bağlantı noktalarıyla
  2. Farklı sanal ağlarda konak ve yönetim bağlantı noktalarıyla
  3. Farklı sanal ağlarda IP adresleri olan ana bilgisayar ve yönetim bağlantı noktası ile

Yukarıdaki senaryoların tamamında Ödeme HSM, temsilci alt ağına sanal ağ eklenmiş bir hizmettir ve hsmSubnetmanagementHsmSubnet hizmete temsilci Microsoft.HardwareSecurityModules/dedicatedHSMs olarak atanmalıdır.

Önemli

Özellik FastPathEnabled, Ödeme HSM'sine erişmesi gereken tüm aboneliklerde kayıtlı ve onaylanmalıdır . Etiketi, Ödeme HSM temsilcisi alt akını barındıran sanal ağda ve Payment HSM cihazlarına bağlantı gerektiren eşlenmiş her sanal ağda da 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ına olanak tanımak 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 Kullanıcı Tanımlı 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 salar 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 FW NVA kullanılabilir.

Architecture diagram of the firewall with SNAT

Yol tabloları gerekli:

  • Şirket içinden PHSM'ye: Ödeme HSM sanal ağ aralığı için UDR içeren ve merkezi hub'a işaret eden bir Rota Tablosu GatewaySubnet'e uygulanır.
  • Uç sanal ağlardan PHSM'ye: Uç sanal ağlarına, merkezi merkez Güvenlik Duvarı'nı işaret eden normal varsayılan yolu içeren bir Rota Tablosu uygulanır.

Sonuçlar:

  • PHSM alt akta desteklenmeyen UDR'ler güvenlik duvarı tarafından istemci IP'sinde SNAT ile giderilir: PHSM'ye trafik iletilirken dönüş trafiği otomatik olarak Güvenlik Duvarı'na geri yönlendirilir.
  • PHSM alt ağına NSG'ler kullanılarak uygulanamayan 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ı'nı 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. Hedef, PHSM cihazlarına trafik göndermek yerine, PHSM temsilcisi alt ağdaki kısıtlamalara 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.

Architecture diagram of the firewall with reverse proxy

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 kullanarak ters proxy Sunucusu (VM tabanlı)
  • 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; 
    } 
} 

Yol tabloları gerekli:

  • Şirket içinden PHSM'ye: Ödeme HSM sanal ağ aralığı için UDR içeren ve merkezi hub'a işaret eden bir Rota Tablosu GatewaySubnet'e uygulanır.
  • Uç sanal ağlardan PHSM'ye: Uç sanal ağlarına, merkezi merkez Güvenlik Duvarı'nı işaret eden normal varsayılan yolu içeren bir Rota Tablosu uygulanır.

Önemli

0/0 UDR'nin güvenlik duvarı üzerinden dönüş trafiğini zorlamak için yeterli olması için ters ara sunucu alt ağından Ağ Geçidi Yolu yayma devre dışı bırakılmalıdır.

Sonuçlar:

  • PHSM alt akta desteklenmeyen UDR'ler ters ara sunucu alt akta yapılandırılabilir.
  • Ters ara sunucu, istemci IP'sini YÖNLENDIRIR: Trafiği PHSM'ye iletirken dönüş trafiği otomatik olarak ters ara sunucuya yönlendirilir.
  • PHSM alt ağına NSG'ler kullanılarak uygulanamayan filtreleme kuralları, Güvenlik Duvarı'nda ve/veya ters ara sunucu alt ağına uygulanan NSG'lerde 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.

Sonraki adımlar