Inspección del tráfico de Azure Payment HSM
Azure Payment Hardware Security Module (Payment HSM o PHSM) es un servicio sin sistema operativo que proporciona operaciones de clave criptográfica para transacciones de pago críticas en tiempo real en la nube de Azure. Para más información, consulte ¿Qué es Azure Payment HSM?.
Cuando se implementa, Payment HSM viene con una interfaz de red de host y una interfaz de red de administración. Hay varios escenarios de implementación:
- Con puertos de administración y host en la misma red virtual
- Con puertos de administración y host en diferentes redes virtuales
- Con puertos de administración y host con direcciones IP en diferentes redes virtuales
En todos los escenarios anteriores, Payment HSM es un servicio insertado en una red virtual en una subred delegada: hsmSubnet y managementHsmSubnet deben delegarse al servicio Microsoft.HardwareSecurityModules/dedicatedHSMs.
Importante
La característica FastPathEnabled se debe registrar y aprobar en todas las suscripciones que necesitan acceso a Payment HSM. También se debe habilitar la etiqueta fastpathenabled en la red virtual que hospeda la subred delegada de Payment HSM y en cada red virtual emparejada que requiera conectividad con los dispositivos de Payment HSM.
Para que la etiqueta de red virtual fastpathenabled sea válida, se debe habilitar la característica FastPathEnabled en la suscripción donde se implementa esa red virtual. Deben completarse ambos pasos para permitir que los recursos se conecten a los dispositivos de Payment HSM. Para más información, consulte FastPathEnabled.
PHSM no es compatible con las topologías de vWAN ni con el emparejamiento de VNET entre regiones, como se muestra en las topologías admitidas. Payment HSM viene con algunas restricciones de directiva en esas subredes: actualmente no se admiten los grupos de seguridad de red (NSG) ni las rutas definidas por el usuario (UDR).
Es posible omitir la restricción de UDR actual e inspeccionar el tráfico destinado a un Payment HSM. En este artículo se presentan dos maneras: un firewall con traducción de direcciones de red de origen (SNAT) y un firewall con proxy inverso.
Firewall con traducción de direcciones de red de origen (SNAT)
Este diseño está inspirado en la arquitectura de la solución Dedicated HSM.
El firewall traduce la dirección de red de origen de la dirección IP del cliente antes de reenviar el tráfico a la NIC de PHSM, lo que garantiza que el tráfico devuelto se dirigirá automáticamente al firewall. En este diseño se puede usar tanto una instancia de Azure Firewall como una aplicación virtual de red (NVA) de firewall de terceros.
Tablas de rutas necesarias:
- Local a PHSM: se aplica a GatewaySubnet una tabla de rutas que contiene una UDR para el intervalo de VNet de Payment HSM y que apunta al firewall del centro principal.
- VNet de radio a PHSM: se aplica a las subredes de las VNet de radio una tabla de rutas que contiene la ruta predeterminada habitual que apunta al firewall del centro principal.
Resultados:
- El firewall que traduce la dirección de red de origen de la dirección IP del cliente se ocupa de las UDR que no se admiten en la subred PHSM: al reenviar el tráfico a PHSM, el tráfico devuelto se redirigirá automáticamente al firewall.
- Las reglas de filtrado que no se pueden aplicar mediante grupos de seguridad de red en la subred PHSM se pueden configurar en el firewall.
- Tanto el tráfico de radio como el tráfico local al entorno PHSM están protegidos.
Firewall con proxy inverso
Este diseño es una buena opción para traducir direcciones de red de origen en un firewall que no ha sido aprobado por los equipos de seguridad de red, lo que obliga a mantener sin cambios las direcciones IP de origen y destino del tráfico que pasa por el firewall.
Esta arquitectura usa un proxy inverso, implementado en una subred dedicada en la red virtual PHSM directamente o en una red virtual emparejada. En lugar de enviar tráfico a los dispositivos PHSM, el destino se establece en la dirección IP de proxy inverso, ubicada en una subred que no tiene las restricciones de la subred delegada PHSM: se pueden configurar grupos de seguridad de red y rutas definidas por el usuario y combinarlos con un firewall en el centro principal.
Esta solución requiere un proxy inverso, por ejemplo:
- F5 (Azure Marketplace; basado en máquinas virtuales)
- NGINXaaS (Azure Marketplace; PaaS totalmente administrada)
- Servidor proxy inverso mediante NGINX (basado en máquinas virtuales)
- Servidor proxy inverso mediante HAProxy (basado en máquinas virtuales)
Ejemplo de servidor proxy inverso mediante la configuración de NGINX (basado en máquinas virtuales) para equilibrar la carga del tráfico 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;
}
}
Tablas de rutas necesarias:
- Local a PHSM: se aplica a GatewaySubnet una tabla de rutas que contiene una UDR para el intervalo de VNet de Payment HSM y que apunta al firewall del centro principal.
- VNet de radio a PHSM: se aplica a las subredes de las VNet de radio una tabla de rutas que contiene la ruta predeterminada habitual que apunta al firewall del centro principal.
Importante
La propagación de rutas de puerta de enlace debe deshabilitarse en la subred de proxy inverso, de modo que una UDR 0/0 sea suficiente para forzar el tráfico devuelto a través del firewall.
Resultados:
- Las UDR que no se admiten en la subred PHSM se pueden configurar en la subred de proxy inverso.
- El proxy inverso traduce la dirección de red de origen de la dirección IP del cliente: al reenviar el tráfico a PHSM, el tráfico devuelto se redirigirá automáticamente al proxy inverso.
- Las reglas de filtrado que no se pueden aplicar mediante grupos de seguridad de red en la subred PHSM se pueden configurar en el firewall o en grupos de seguridad de red aplicados a la subred de proxy inverso.
- Tanto el tráfico de radio como el tráfico local al entorno PHSM están protegidos.