Redes de HSM dedicadas de Azure

Azure Dedicated HSM exige una infraestructura de red sólida y segura en todos los escenarios de implementación. Tanto si se conecta desde la nube de Azure al entorno local, se implementan aplicaciones distribuidas o se establecen configuraciones de alta disponibilidad, es esencial la seguridad completa. Las redes de Azure ofrecen seguridad a través de cuatro áreas de red críticas que requieren una planeación e implementación cuidadosas.

• Creación de dispositivos HSM dentro de la red virtual (VNet) en Azure
• Conexión local a recursos basados en la nube para la configuración y administración de dispositivos HSM
• Creación y conexión de redes virtuales para la conexión entre recursos de aplicaciones y dispositivos HSM
• Conexión de redes virtuales entre regiones para la comunicación entre regiones y también para habilitar escenarios de alta disponibilidad

Red virtual para los HSM dedicados

Los HSM dedicados se integran en una red virtual y se colocan en la propia red privada de los clientes en Azure. Esto permite el acceso a los dispositivos desde máquinas virtuales o recursos de proceso en la red virtual.
Para más información sobre la integración de servicios de Azure en la red virtual y las funcionalidades que proporciona, consulte la documentación sobre la red virtual para los servicios de Azure .

Redes virtuales

Los clientes deben crear una red virtual en Azure antes del aprovisionamiento o usar una que ya exista en la suscripción de los clientes. La red virtual define el perímetro de seguridad para el dispositivo HSM dedicado. Para más información sobre la creación de redes virtuales, consulte la documentación de red virtual.

Subredes

Las subredes segmentan la red virtual en espacios de direcciones independientes utilizables por los recursos de Azure que coloque en ellos. Los HSM dedicados se implementan en una subred de la red virtual. Cada dispositivo HSM dedicado que se implementa en la subred del cliente recibe una dirección IP privada de esta subred.

La subred en la que se implementa el dispositivo HSM debe delegarse explícitamente en el servicio: Microsoft.HardwareSecurityModules/dedicatedHSMs. Esto concede determinados permisos al servicio HSM para la implementación en la subred. La delegación a HSM dedicados impone ciertas restricciones de directiva en la subred. Los grupos de seguridad de red (NSGs) y User-Defined Routes (UDRs) no son compatibles actualmente en subredes delegadas. Como resultado, una vez que se delega una subred a los HSMs dedicados, solo se puede usar para implementar recursos de HSM. Se produce un error en la implementación de cualquier otro recurso de cliente en la subred. No hay ningún requisito sobre lo grande o pequeña que debe ser la subred para HSM dedicados; sin embargo, cada dispositivo HSM consume una dirección IP privada, por lo que debe asegurarse de que la subred sea lo suficientemente grande para acomodar tantos dispositivos HSM como sea necesario para la implementación.

Puerta de enlace de ExpressRoute

Un requisito de la arquitectura actual es la configuración de una puerta de enlace de ExpressRoute en la subred de clientes donde se debe colocar un dispositivo HSM para habilitar la integración del dispositivo HSM en Azure. La puerta de enlace de ExpressRoute no se puede usar para conectar ubicaciones locales a los dispositivos HSM de clientes en Azure.

Conexión de TI local a Azure

Al crear recursos basados en la nube, establecer una conexión privada a los recursos de TI locales es un requisito típico. En el caso de las implementaciones de Azure Dedicated HSM, estas conexiones sirven principalmente a las necesidades de software cliente de HSM para la configuración del dispositivo, las operaciones de copia de seguridad y la recuperación de registros de HSM para su análisis.

Al elegir opciones de conectividad, la naturaleza de la conexión representa un punto de decisión clave. Vpn de sitio a sitio ofrece la mayor flexibilidad, especialmente cuando varios recursos locales necesitan una comunicación segura con los recursos en la nube de Azure, incluidos los HSM. La implementación de una VPN de sitio a sitio requiere que las organizaciones implementen un dispositivo VPN para facilitar la conexión. Como alternativa, las conexiones VPN de punto a sitio funcionan bien cuando solo existe un único punto de conexión local, como una estación de trabajo de administración.

Para más información sobre las opciones de conectividad, consulte Opciones de planeación de VPN Gateway.

VPN de punto a sitio

Una red privada virtual de punto a sitio es la forma más sencilla de conexión segura a un único punto de conexión local. Esto puede ser relevante si solo tiene una sola estación de trabajo de administración para HSM dedicados basados en Azure.

VPN de sitio a sitio

Una red privada virtual de sitio a sitio permite una comunicación segura entre los HSM dedicados basados en Azure y la infraestructura de TI local. Las organizaciones suelen implementar estas conexiones al mantener una instalación de copia de seguridad local para HSM, ya que el túnel seguro admite transferencias de datos necesarias para las operaciones de copia de seguridad entre ambos entornos.

Conexión de redes virtuales

Una arquitectura de implementación típica para Dedicated HSM comienza con una sola red virtual y la subred correspondiente en la que se crean y aprovisionan los dispositivos HSM. Dentro de esa misma región, puede haber más redes virtuales y subredes para los componentes de aplicación que usan dedicated HSM. Para habilitar la comunicación entre estas redes, usamos emparejamiento de redes virtuales.

Emparejamiento de redes virtuales

Cuando hay varias redes virtuales dentro de una región que necesitan acceder a los recursos de los demás, el emparejamiento de redes virtuales crea canales de comunicación seguros entre ellos. El emparejamiento de redes virtuales no solo proporciona comunicaciones seguras, sino que también garantiza conexiones de baja latencia y ancho de banda alto entre los recursos de Azure.

Conexión entre regiones de Azure

Los dispositivos HSM tienen la capacidad, a través de bibliotecas de software, de redirigir el tráfico a un HSM alternativo. El redireccionamiento del tráfico es útil si se produce un error en los dispositivos o se pierde el acceso a un dispositivo. Los escenarios de error de nivel regional se pueden mitigar mediante la implementación de HSM en otras regiones y la habilitación de la comunicación entre redes virtuales entre regiones.

Alta disponibilidad entre regiones mediante VPN Gateway

Para las aplicaciones distribuidas globalmente o para escenarios de conmutación por error regionales de alta disponibilidad, es necesario conectar redes virtuales entre regiones. Con Azure Dedicated HSM, se puede lograr una alta disponibilidad mediante una instancia de VPN Gateway que proporciona un túnel seguro entre las dos redes virtuales. Para más información sobre las conexiones de red virtual a red virtual mediante VPN Gateway, consulte el artículo titulado ¿Qué es VPN Gateway?

Restricciones de red

Limitaciones de seguridad de red

La tarjeta de interfaz de red (NIC) de HSM ubicada dentro de la red virtual de HSM dedicada no puede usar grupos de seguridad de red (NSG) ni rutas definidas por el usuario (UDR) debido a los requisitos de delegación de subred. Esto crea una consideración de seguridad importante: no se pueden implementar directivas de denegación predeterminada directamente desde la perspectiva de la red virtual de HSM dedicada. En su lugar, la seguridad debe implementarse al permitir explícitamente el acceso desde segmentos de red específicos al servicio Dedicated HSM a través de métodos alternativos.

La adición de la solución de proxy de aplicaciones virtuales de red (NVA) también permite que un firewall de NVA en el concentrador de tránsito/DMZ se coloque lógicamente delante de la NIC de HSM, lo que proporciona la alternativa necesaria a los NSG y UDR.

Arquitectura de la solución

Este diseño de red requiere los siguientes elementos:

1. Una red virtual de centro de conectividad de tránsito o DMZ con un nivel de proxy de NVA. Idealmente, hay presentes dos o más NVAs.
2. Un circuito ExpressRoute con un emparejamiento privado habilitado y una conexión a la red virtual del centro de tránsito.
3. Un emparejamiento de VNet entre la red virtual del centro de tránsito y la red virtual de Dedicated HSM.
4. Como opción, se puede implementar un firewall de NVA o Azure Firewall para ofrecer servicios de DMZ en el centro de conectividad.
5. Se pueden emparejar redes virtuales radiales de carga de trabajo adicionales a la red virtual del centro. El cliente de Gemalto puede acceder al servicio HSM dedicado a través del VNet del concentrador.

Dado que agregar la solución de proxy de NVA también permite colocar lógicamente un firewall de NVA en el centro de tránsito o DMZ delante de la NIC de HSM, lo que proporciona las directivas de denegación predeterminada necesarias. En nuestro ejemplo, usamos Azure Firewall para este propósito y necesitamos los siguientes elementos en su lugar:

1. Una instancia de Azure Firewall implementada en la subred "AzureFirewallSubnet" en la red virtual del nodo central de red perimetral
2. Una tabla de enrutamiento con una UDR que dirija hacia Azure Firewall el tráfico que se envía al punto de conexión privado de Azure ILB. Esta tabla de enrutamiento se aplica a gatewaySubnet donde reside la puerta de enlace virtual de ExpressRoute del cliente.
3. Reglas de seguridad de red dentro de Azure Firewall para permitir el reenvío entre un intervalo de orígenes de confianza y el punto de conexión privado de Azure IBL escuchando en el puerto TCP 1792. Esta lógica de seguridad agrega la política de "denegación predeterminada" necesaria contra el servicio HSM dedicado. Lo que significa que solo se permiten intervalos IP de origen de confianza en el servicio HSM dedicado. Se quitan todos los demás intervalos.
4. Una tabla de enrutamiento con una UDR que dirige el tráfico destinado al entorno local hacia un Firewall de Azure. Esta tabla de enrutamiento se aplica a la subred del proxy de NVA.
5. Un NSG aplicado a la subred de NVA del proxy para confiar solo en el intervalo de subredes de Azure Firewall como origen, y para permitir el reenvío solo a la dirección IP de la NIC de HSM a través del puerto TCP 1792.

Alternativa a las UDR

La solución de nivel NVA mencionada funciona como alternativa a las UDR. Hay algunos puntos importantes que se deben tener en cuenta.

1. La traducción de direcciones de red debe configurarse en NVA para permitir que el tráfico devuelto se enrute correctamente.
2. Los clientes deben deshabilitar la comprobación ip del cliente en la configuración de Luna HSM para usar VNA para NAT. Los siguientes comandos sirven como ejemplo.

Disable:
[hsm01] lunash:>ntls ipcheck disable
NTLS client source IP validation disabled
Command Result : 0 (Success)

Show:
[hsm01] lunash:>ntls ipcheck show
NTLS client source IP validation : Disable
Command Result : 0 (Success)

1. Implementación de UDR para el tráfico de entrada en el nivel de NVA.
2. Según el diseño, las subredes HSM no iniciarán una solicitud de conexión saliente al nivel de plataforma.

Alternativa al uso del emparejamiento de VNET global

Hay un par de arquitecturas que puede usar como alternativa al Emparejamiento de VNET global.

1. Use la conexión de VPN Gateway de red virtual a red virtual.
2. Conecte la red virtual de HSM con otra red virtual con un circuito ER. Esto funciona mejor cuando se requiere una ruta de acceso local directa o una red virtual VPN.

HSM con conectividad directa de ExpressRoute

Pasos siguientes

• Preguntas más frecuentes
• Compatibilidad
• Alta disponibilidad
• Seguridad física
• Monitoring
• Arquitectura de implementación