Aplicación de los principios de Confianza cero para cifrar la comunicación de red basada en Azure

En este artículo se proporciona una guía para aplicar los principios de Confianza cero para cifrar la comunicación de red hacia, desde y en los entornos de Azure de las maneras siguientes.

Principio de Confianza cero Definición Forma de cumplimiento
Comprobación explícita Autentique y autorice siempre en función de todos los puntos de datos disponibles. Uso de directivas de acceso condicional para las conexiones de Azure VPN Gateway y Secure Shell (SSH) y el Protocolo de escritorio remoto (RDP) para las conexiones de usuario a máquina virtual.
Uso del acceso con privilegios mínimos Limite el acceso de los usuarios con los modelos Just-in-Time y Just-in-Time (JIT/JEA), directivas que se adaptan al nivel de riesgo y protección de datos. Configuración de los dispositivos Microsoft Enterprise Edge (MSEE) para usar la clave de asociación de conectividad estática (CAK) para Azure ExpressRoute con puertos directos y uso de la identidad administrada para autenticar los recursos del circuito ExpressRoute.
Dar por hecho que habrá intrusiones al sistema Minimice el radio de explosión y el acceso a los segmentos. Compruebe el cifrado de un extremo a otro y use análisis para obtener visibilidad, impulsar la detección de amenazas y mejorar las defensas. Protección del tráfico de red con protocolos y métodos de cifrado que proporcionan confidencialidad, integridad y autenticidad de los datos en tránsito.

Uso de Azure Monitor para proporcionar métricas y alertas de rendimiento de red de ExpressRoute.

Uso de Azure Bastion para administrar sesiones individuales desde el servicio Bastion y eliminar o forzar una desconexión.

Los niveles de cifrado para el tráfico de red son:

  • Cifrado de capa de red

    • Protección y comprobación de la comunicación desde Internet o la red local hasta las redes virtuales y máquinas virtuales de Azure

    • Protección y comprobación de la comunicación dentro y entre redes virtuales de Azure.

  • Cifrado de la capa de aplicación

    • Protección para aplicaciones web de Azure.
  • Protección para cargas de trabajo que se ejecutan en máquinas virtuales

Arquitectura de referencia

En el diagrama siguiente se muestra la arquitectura de referencia para esta guía de Confianza cero para la comunicación cifrada entre usuarios y administradores locales o en Internet y componentes en el entorno de Azure para los pasos descritos en este artículo.

Arquitectura de referencia de los componentes de red de Azure con los principios de cifrado y de Confianza cero aplicados.

En el diagrama, los números corresponden a los pasos de las siguientes secciones.

¿Cuál es el contenido de este artículo?

Los principios de Confianza cero se aplican en toda la arquitectura de referencia, desde usuarios y administradores de Internet o la red local hasta la nube de Azure y dentro de ella. En la tabla siguiente se describen las recomendaciones para garantizar el cifrado del tráfico de red en toda esta arquitectura.

Paso Tarea Principios de Confianza cero aplicados
1 Implementar el cifrado de la capa de red. Comprobación explícita
Utilizar el acceso con privilegios mínimos
Dar por hecho que habrá intrusiones al sistema
2 Proteger y comprobar la comunicación desde una red local hasta redes virtuales de Azure. Comprobación explícita
Dar por hecho que habrá intrusiones al sistema
3 Proteger y comprobar la comunicación dentro de redes virtuales de Azure y entre ellas. Dar por hecho que habrá intrusiones al sistema
4 Implementar el cifrado de la capa de aplicación. Comprobación explícita
Dar por hecho que habrá intrusiones al sistema
5 Usar Azure Bastion para proteger las máquinas virtuales de Azure. Asunción de que hay brechas

Paso 1: Implementar el cifrado de la capa de red

El cifrado de la capa de red es fundamental al aplicar principios de Confianza cero a su entorno local y de Azure. Cuando el tráfico de red pasa por Internet, siempre debe suponer que existe la posibilidad de que haya atacantes que lo intercepten, por lo que los datos podrían exponerse o modificarse antes de llegar a su destino. Dado que los proveedores de servicios controlan cómo se enrutan los datos a través de Internet, es conveniente asegurarse de que la privacidad y la integridad de los datos se mantienen desde el momento en que salen de la red local hasta que llegan a la nube de Microsoft.

En el diagrama siguiente se muestra la arquitectura de referencia para implementar el cifrado de la capa de red.

Arquitectura de referencia para la implementación del cifrado de la capa de red en redes de Azure.

En las dos secciones siguientes, se describe el protocolo de seguridad de Internet (IPsec) y la seguridad de control de acceso multimedia (MACsec), protocolos que admiten los servicios de red de Azure, y cómo puede asegurarse de que se usan.

IPsec

IPsec es un grupo de protocolos que proporciona seguridad para las comunicaciones del protocolo de Internet (IP). Autentica y cifra los paquetes de red mediante un conjunto de algoritmos de cifrado. IPSec es el protocolo de encapsulación de seguridad que se usa para establecer redes privadas virtuales (VPN). Un túnel VPN de IPsec consta de dos fases, fase 1 conocida como modo principal y fase 2 conocida como modo rápido.

La fase 1 de IPsec es el establecimiento del túnel, donde los nodos del mismo nivel negocian los parámetros para la asociación de seguridad de Intercambio de claves por red (IKE), como el cifrado, la autenticación, la aplicación del algoritmo hash y los algoritmos Diffie-Hellman. Para comprobar sus identidades, los nodos del mismo nivel intercambian una clave previamente compartida. La fase 1 de IPsec puede funcionar en dos modos: modo principal o modo agresivo. Azure VPN Gateway admite dos versiones de IKE: IKEv1 e IKEv2, y solo funciona en modo principal. El modo principal garantiza el cifrado de la identidad de la conexión entre Azure VPN Gateway y el dispositivo local.

En la fase 2 de IPsec, los nodos del mismo nivel negocian los parámetros de seguridad para la transmisión de datos. En esta fase, ambos nodos del mismo nivel acuerdan los algoritmos de cifrado y de autenticación, el valor de duración de la asociación de seguridad (SA) y los selectores de tráfico (TS) que definen qué tráfico se cifra a través del túnel IPsec. El túnel creado en la fase 1 actúa como un canal seguro para esta negociación. IPsec puede proteger los paquetes IP mediante el protocolo de encabezado de autenticación (AH) o el protocolo de encapsulación de la carga de seguridad (ESP). AH proporciona integridad y autenticación, mientras que ESP también proporciona confidencialidad (cifrado). La fase 2 de IPsec puede funcionar en modo de transporte o en modo de túnel. En modo de transporte, solo se cifra la carga del paquete IP, mientras que en modo de túnel se cifra todo el paquete IP y se agrega un nuevo encabezado IP. La fase 2 de IPsec se puede establecer sobre IKEv1 o IKEv2. La implementación actual de IPsec de Azure VPN Gateway solo admite ESP en modo de túnel.

Algunos de los servicios de Azure que admiten IPsec son:

  • Azure VPN Gateway

    • Conexiones VPN de sitio a sitio

    • Conexiones de red virtual a red virtual

    • Conexiones de punto a sitio

  • Azure Virtual WAN

    • Sitios de VPN

    • Configuraciones de VPN de usuario

No hay ningún valor de configuración que necesite modificar para habilitar IPsec para estos servicios. Están habilitados de manera predeterminada.

MACsec y Azure Key Vault

MACsec (IEEE 802.1AE) es un estándar de seguridad de red que aplica el principio de Confianza cero Asumir vulneración en la capa de vínculo de datos, que proporciona autenticación y cifrado a través de un vínculo Ethernet. MACsec supone que cualquier tráfico de red, incluso en la misma red de área local, puede verse comprometido o interceptado por actores malintencionados. MACsec comprueba y protege cada trama mediante una clave de seguridad compartida entre dos interfaces de red. Esta configuración solo se puede efectuar entre dos dispositivos compatibles con MACsec.

MACsec se configura con asociaciones de conectividad, que son un conjunto de atributos que usan las interfaces de red para crear canales de seguridad entrantes y salientes. Una vez creados, el tráfico que pasa por estos canales se intercambia a través de dos vínculos protegidos por MACsec. MACsec tiene dos modos de asociación de conectividad:

  • Modo de clave de asociación de conectividad estática (CAK): los vínculos protegidos por MACsec se establecen mediante una clave precompartida que incluye un nombre de clave de asociación de conectividad (CKN) y la CAK asignada. Estas claves se configuran en ambos extremos del vínculo.
  • Modo CAK dinámico: las claves de seguridad se generan dinámicamente mediante el proceso de autenticación 802.1x, que puede usar un dispositivo de autenticación centralizado, como un servidor de Servicio de autenticación remota telefónica de usuario (RADIUS).

Los dispositivos Microsoft Enterprise Edge (MSEE) admiten CAK estáticas mediante el almacenamiento de la CAK y el CKN en una instancia de Azure Key Vault al configurar Azure ExpressRoute con puertos directos. Para acceder a los valores de Azure Key Vault, configure la identidad administrada para autenticar el recurso del circuito ExpressRoute. Este enfoque sigue el principio de Confianza cero Usar acceso con privilegios mínimos porque solo los dispositivos autorizados pueden acceder a las claves desde Azure Key Vault. Configuración de MACsec en puertos de ExpressRoute Direct.

Paso 2: Proteger y comprobar la comunicación desde una red local hasta redes virtuales de Azure

A medida que la migración a la nube es más frecuente en empresas de distintas escalas, la conectividad híbrida desempeña un papel clave. Es fundamental no solo proteger la comunicación de red entre la red local y Azure, sino también comprobarla y supervisarla.

En el diagrama siguiente se muestra la arquitectura de referencia para proteger y comprobar la comunicación desde una red local hasta redes virtuales de Azure.

La arquitectura de referencia para proteger y comprobar la comunicación desde una red local hasta redes virtuales de Azure.

Azure proporciona dos opciones para conectar la red local a los recursos de una red virtual de Azure:

  • Azure VPN Gateway permite crear un túnel VPN de sitio a sitio mediante IPsec para cifrar y autenticar la comunicación de red entre la red en oficinas centrales o remotas y una red virtual de Azure. También permite a los clientes individuales establecer una conexión de punto a sitio para acceder a los recursos de una red virtual de Azure sin un dispositivo VPN. Para cumplir los principios de Confianza cero, configure la autenticación de Entra ID y las directivas de acceso condicional para las conexiones de Azure VPN Gateway a fin de comprobar la identidad y el cumplimiento de los dispositivos que se conectan. Para más información, consulte Uso de VPN Gateway de Microsoft Tunnel con directivas de acceso condicional.

  • Azure ExpressRoute proporciona una conexión privada de ancho de banda alto que le permite ampliar la red local a Azure con la ayuda de un proveedor de conectividad. Dado que el tráfico de red no viaja a través de la red pública de Internet, los datos no están cifrados de forma predeterminada. Para cifrar el tráfico a través de ExpressRoute, configure el túnel IPsec. Sin embargo, tenga en cuenta que, al ejecutar túneles IPsec a través de ExpressRoute, el ancho de banda se limita al ancho de banda del túnel y es posible que tenga que ejecutar varios túneles para que coincidan con el ancho de banda del circuito ExpressRoute. Conexiones VPN de sitio a sitio a través del emparejamiento privado de ExpressRoute: Azure VPN Gateway.

    Si usa puertos de ExpressRoute Direct, puede aumentar la seguridad de red habilitando la autenticación al establecer nodos del mismo nivel BGP o configurar MACsec para proteger la comunicación de nivel 2. MACsec proporciona cifrado para tramas Ethernet, lo que garantiza la confidencialidad, la integridad y la autenticidad de los datos entre el enrutador perimetral del usuario y el enrutador perimetral de Microsoft.

    Azure ExpressRoute también admite Azure Monitor para proporcionar métricas y alertas de rendimiento de la red.

El cifrado puede proteger los datos de la interceptación no autorizada, pero también presenta una capa adicional de procesamiento para cifrar y descifrar el tráfico de red que puede afectar al rendimiento. El tráfico de red que pasa por Internet también puede ser impredecible, ya que debe viajar por varios dispositivos de red que pueden introducir latencia de red. Para evitar problemas de rendimiento, Microsoft recomienda usar ExpressRoute porque ofrece una asignación confiable de ancho de banda y rendimiento de red que puede personalizar para la carga de trabajo.

Al decidir entre Azure VPN Gateway o ExpressRoute, considere las siguientes cuestiones:

  1. ¿A qué tipos de archivos y aplicaciones accede entre la red local y Azure? ¿Necesita ancho de banda constante para transferir grandes volúmenes de datos?
  2. ¿Necesita una latencia constante y baja para que las aplicaciones funcionen de forma óptima?
  3. ¿Necesita supervisar el rendimiento y el estado de la red de la conectividad híbrida?

Si respondió sí a cualquiera de estas preguntas, Azure ExpressRoute debería ser el método principal para conectar la red local a Azure.

Hay dos escenarios comunes en los que ExpressRoute y Azure VPN Gateway pueden coexistir:

  • Azure VPN Gateway se puede usar para conectar las sucursales a Azure mientras la oficina principal está conectada mediante ExpressRoute.
  • También puede usar Azure VPN Gateway como conexión de copia de seguridad a Azure para la oficina central si el servicio ExpressRoute tiene una interrupción.

Paso 3: Proteger y comprobar la comunicación dentro de redes virtuales de Azure y entre ellas

El tráfico dentro de Azure tiene un nivel de cifrado subyacente. Cuando el tráfico se mueve entre redes virtuales de diferentes regiones, Microsoft usa MACsec para cifrar y autenticar el tráfico de emparejamiento en la capa de vínculo de datos.

En el diagrama siguiente se muestra la arquitectura de referencia para proteger y comprobar la comunicación dentro de virtuales de Azure y entre ellas.

La arquitectura de referencia para proteger y comprobar la comunicación dentro de redes virtuales de Azure y entre ellas.

Sin embargo, el cifrado solo no es suficiente para garantizar Confianza cero. También debe comprobar y supervisar la comunicación de red dentro de redes virtuales de Azure y entre ellas. El cifrado y la comprobación adicionales entre redes virtuales son posibles con la ayuda de Azure VPN Gateway o aplicaciones virtuales de red (NVA), pero no es una práctica habitual. Microsoft recomienda diseñar la topología de red para usar un modelo centralizado de inspección del tráfico que pueda aplicar directivas pormenorizadas y detectar anomalías.

Para reducir la sobrecarga de configurar una puerta de enlace de VPN o una aplicación virtual, habilite la característica de cifrado de red virtual para determinados tamaños de máquina virtual a fin de cifrar y comprobar el tráfico entre máquinas virtuales a nivel de host, dentro de una red virtual y entre emparejamientos de red virtual.

Paso 4: Implementar el cifrado en la capa de aplicación

El cifrado de la capa de aplicación desempeña un factor clave en la Confianza cero que exige que todos los datos y comunicaciones estén cifrados cuando los usuarios interactúan con aplicaciones web o dispositivos. El cifrado de la capa de aplicación garantiza que solo las entidades verificadas y de confianza puedan acceder a aplicaciones web o dispositivos.

En el diagrama siguiente se muestra la arquitectura de referencia para implementar el cifrado en la capa de red.

La arquitectura de referencia para implementar el cifrado en la capa de red.

Uno de los ejemplos más comunes de cifrado en la capa de aplicación es el Protocolo de transferencia de hipertexto con cifrado de Capa de sockets seguros (HTTPS), que cifra los datos entre un explorador web y un servidor web. HTTPS usa el protocolo Seguridad de la capa de transporte (TLS) para cifrar la comunicación entre el servidor y el cliente y emplea un certificado digital TLS para comprobar la identidad y la confiabilidad del sitio web o dominio.

Otro ejemplo de seguridad de la capa de aplicación es Secure Shell (SSH) y el Protocolo de Escritorio remoto (RDP) que cifra los datos entre el cliente y el servidor. Estos protocolos también admiten la autenticación multifactor y las directivas de acceso condicional para tener la seguridad de que solo los dispositivos o usuarios autorizados y compatibles puedan acceder a recursos remotos. Consulte el paso 5 para información sobre cómo proteger las conexiones SSH y RDP a máquinas virtuales de Azure.

Protección para aplicaciones web de Azure

Puede usar Azure Front Door o Azure Application Gateway para proteger las aplicaciones web de Azure.

Azure Front Door

Azure Front Door es un servicio de distribución global que optimiza la entrega de contenido a los usuarios finales mediante las ubicaciones perimetrales de Microsoft. Gracias a características como el firewall de aplicaciones web (WAF) y el servicio Private Link, puede detectar y bloquear ataques malintencionados en las aplicaciones web en el perímetro de la red de Microsoft y acceder de forma privada a sus orígenes mediante la red interna de Microsoft.

Para proteger los datos, el tráfico que va y viene de los puntos de conexión de Azure Front Door se protege mediante HTTPS con TLS de un extremo a otro. El tráfico se cifra desde el cliente hasta el origen y desde el origen hasta el cliente.

Azure Front Door controla las solicitudes HTTPS y determina qué punto de conexión de su perfil tiene el nombre de dominio asociado. Luego, comprueba la ruta de acceso y determina qué regla de enrutamiento coincide con la ruta de acceso de la solicitud. Si el almacenamiento en caché está habilitado, Azure Front Door comprueba su caché para ver si hay una respuesta válida. Si no hay ninguna respuesta válida, Azure Front Door selecciona el mejor origen que puede servir el contenido solicitado. Antes de enviar la solicitud al origen, se puede aplicar un conjunto de reglas a la solicitud para cambiar el encabezado, la cadena de consulta o el destino de origen.

Azure Front Door admite TLS de front-end y de back-end. TLS de front-end cifra el tráfico entre el cliente y Azure Front Door. TLS de back-end cifra el tráfico entre Azure Front Door y el origen. Azure Front Door admite TLS 1.2 y TLS 1.3. Puede configurar Azure Front Door para que se use un certificado TLS personalizado o usar un certificado administrado por Azure Front Door.

Nota:

También puede usar la característica Private Link para la conectividad con las aplicaciones virtuales de red para una inspeccionar más a fondo los paquetes.

Azure Application Gateway

Azure Application Gateway es un equilibrador de carga regional que funciona en la capa 7. Enruta y distribuye el tráfico web en función de los atributos de dirección URL HTTP. Puede enrutar y distribuir el tráfico mediante tres enfoques diferentes:

  • Solo HTTP: Application Gateway recibe y enruta las solicitudes HTTP entrantes al destino adecuado en formato sin cifrar.
  • Terminación SSL: Application Gateway descifra las solicitudes HTTPS entrantes a nivel de instancia, las inspecciona y las enruta sin cifrar al destino.
  • TLS de un extremo a otro: Application Gateway descifra las solicitudes HTTPS entrantes a nivel de instancia, las inspecciona y las vuelve a cifrar antes de enrutarlas al destino.

La opción más segura es TLS de un extremo a otro, que requiere el uso de certificados de autenticación o certificados raíz de confianza para permitir el cifrado y la transmisión de datos confidenciales. También se requiere cargar estos certificados en los servidores back-end y tener la seguridad de que estos servidores back-end se conocen en Application Gateway. Para más información, consulte Configuración de TLS de un extremo a otro con Application Gateway.

Además, los usuarios locales o los usuarios de máquinas virtuales de otra red virtual pueden usar el front-end interno de Application Gateway con las mismas funcionalidades de TLS. Junto con el cifrado, Microsoft recomienda habilitar siempre WAF para mejorar la protección de front-end de los puntos de conexión.

Paso 5: Usar Azure Bastion para proteger máquinas virtuales de Azure

Azure Bastion es un servicio PaaS administrado que permite conectarse de forma segura a las máquinas virtuales a través de una conexión TLS. Esta conectividad se puede establecer desde Azure Portal o mediante un cliente nativo a la dirección IP privada de la máquina virtual. Entre las ventajas de usar Bastion se incluyen:

  • Las máquinas virtuales de Azure no necesitan una dirección IP pública. Las conexiones se realizan a través del puerto TCP 443 para HTTPS y pueden atravesar la mayoría de los firewalls.
  • Las máquinas virtuales están protegidas contra el examen de puertos.
  • La plataforma Azure Bastion se actualiza constantemente y está protegida contra vulnerabilidades de seguridad del día cero.

Con Bastion, puede controlar la conectividad RDP y SSH a la máquina virtual desde un único punto de entrada. Puede administrar sesiones individuales desde el servicio Bastion en Azure Portal. También puede eliminar o forzar una desconexión de una sesión remota en curso si sospecha que un usuario no se está conectando a esa máquina.

En el diagrama siguiente se muestra la arquitectura de referencia para usar Azure Bastion para proteger las máquinas virtuales de Azure.

La arquitectura de referencia para usar Azure Bastion para proteger las máquinas virtuales de Azure.

Para proteger una máquina virtual de Azure, implemente Azure Bastion y empiece a usar RDP y SSH para conectarse a las máquinas virtuales con sus direcciones IP privadas.

Pasos siguientes

Para más información sobre cómo aplicar Confianza cero a las redes de Azure, consulte:

Referencias

Consulte estos vínculos para obtener información sobre los distintos servicios y tecnologías mencionados en este artículo.