Entrada de Internet: exponga la aplicación a Internet.

Este artículo le ayuda a elegir el servicio Azure adecuado para que la aplicación sea accesible desde Internet. Compara direcciones IP públicas, Azure Load Balancer, Application Gateway, Azure Front Door y Azure Traffic Manager. Elija la opción que se ajuste al protocolo, la escala y los requisitos de seguridad de la carga de trabajo.

Lo que trata este artículo

Cada Azure carga de trabajo que atiende a los usuarios externos necesita una ruta de acceso de entrada: una manera de que el tráfico de Internet llegue a la aplicación de forma segura y confiable. Elegir el servicio de entrada incorrecto conduce a un sobreaprovisionamiento, brechas de seguridad o complejidad innecesaria. Este artículo le ayuda a evaluar siete servicios Azure que aceptan conexiones entrantes de usuarios externos y enrutan esas conexiones a los recursos back-end dentro de una red virtual. Puede seleccionar la combinación que coincida con el protocolo, la escala, la geografía y la posición de seguridad.

Note

Este artículo se centra en cómo entra el tráfico en la red de Azure desde Internet. Para saber cómo equilibrar y entregar ese tráfico entre los back-end de la aplicación (incluidas comparaciones detalladas de Azure Load Balancer, Application Gateway y Azure Front Door), consulte Entrega y rendimiento de aplicaciones.

Quién necesita este artículo

Lea este artículo si se aplican una o varias de estas condiciones:

• La aplicación debe aceptar conexiones entrantes de usuarios o sistemas en Internet.
• Debe elegir entre ip pública, Load Balancer, Application Gateway, Front Door o Traffic Manager en función del protocolo y el ámbito.
• Debe diseñar un punto de entrada público seguro para cargas de trabajo web, API o TCP/UDP.
• Debe combinar la exposición a Internet con WAF, protección contra DDoS, terminación de TLS o distribución del tráfico regional o global.

Sugerencia

¿Sigue la ruta del escenario? Seleccione el escenario en la parte superior de la página para obtener instrucciones adaptadas. La guía básica siguiente se aplica a todos los lectores.

Enfoque lift-and-shift: Su aplicación migrada debe ser accesible desde Internet. Evalúe si necesita Application Gateway, Front Door o un enfoque de IP pública más sencillo. Muchas cargas de trabajo de lift-and-shift son de solo uso interno, por lo que puede omitir este artículo por completo si las aplicaciones migradas no sirven a usuarios externos.

Lea este artículo si:

• Están migrando una aplicación web local a Azure y necesitan decidir cómo exponerla públicamente.
• Es necesario evaluar si realmente se requiere acceso entrante desde Internet para las cargas de trabajo migradas.
• ¿Desea conocer la opción de entrada más sencilla y lista para producción para una aplicación migrada?

Enfoque de modernización: Los patrones de tráfico orientados al cliente determinan la forma externa de la arquitectura. Front Door controla las aplicaciones web, Traffic Manager controla las aplicaciones móviles y de API. Sus cargas de trabajo PaaS modernizadas (App Service, AKS) necesitan una ruta de entrada bien definida que se integre con su modelo de seguridad hub-spoke.

Lea este artículo si:

• Implemente una aplicación pública a la que los usuarios externos accedan a través de Internet.
• Debe elegir entre Azure Front Door para aplicaciones web y Traffic Manager para cargas de trabajo móviles o de API.
• ¿Desea saber cómo se integra la entrada con su firewall hub como destino DNAT?
• Debe proteger los puntos de conexión accesibles desde Internet con un firewall de aplicaciones web (WAF) o la protección contra DDoS.

Enfoque multinube: Incluya tráfico de entrada desde Internet solo si la aplicación migrada es de cara al público. Muchas aplicaciones entre nubes son de solo uso interno y se comunican entre nubes a través de rutas de tránsito privadas. Si la carga de trabajo está orientada al público (por ejemplo, una aplicación web orientada al cliente migrada desde otra nube), necesita una ruta de acceso de entrada en Azure.

Lea este artículo si:

• Están migrando una aplicación orientada al público desde AWS o Google Cloud a Azure.
• Necesita Application Gateway con WAF en una VNet spoke para la carga de trabajo migrada.
• Quiere evitar la asignación directa de ip pública a las máquinas virtuales durante la migración entre nubes.

servicios y características de Azure

Azure proporciona varios servicios para la entrada a Internet. Cada servicio funciona en una capa diferente de la pila de redes y sirve un caso de uso diferente.

Servicio	Nivel	Ámbito	Qué proporciona	Cuándo usarlo
Dirección IP pública (SKU estándar)	3	Regional	Dirección IPv4 o IPv6 enrutable asignada directamente. Redundancia de zona de forma predeterminada.	Escenarios sencillos y de poco tráfico. No se recomienda para producción sin un equilibrador de carga.
Azure Load Balancer (estándar, público)	4 (TCP/UDP)	Regional	Distribuye el tráfico TCP/UDP entrante entre máquinas virtuales de back-end. Front-end con redundancia de zona. Las pruebas de estado eliminan las instancias que no funcionan correctamente.	Cargas de trabajo que no son HTTP/S que requieren alta disponibilidad. Servidores de juegos, puntos de conexión de IoT u otros servicios TCP/UDP.
Azure Load Balancer (estándar, interno)	4 (TCP/UDP)	Regional	Equilibrio de carga de nivel 4 dentro de una red virtual. No hay ninguna dirección IP pública. Enruta el tráfico entre niveles internos.	Aplicaciones de varios niveles en las que un front-end público distribuye a máquinas virtuales (VM) de back-end. Tráfico este-oeste de tipo hub-and-spoke. No directamente accesible desde Internet, pero comúnmente emparejado con un servicio de entrada público.
Puerta de enlace de aplicaciones Azure	7 (HTTP/S)	Regional	Equilibrio de carga HTTP/S con enrutamiento basado en direcciones URL, terminación SSL/TLS, afinidad de sesión y escalado automático.	Aplicaciones HTTP/S de una sola región que requieren enrutamiento basado en rutas de acceso, afinidad basada en cookies o descarga SSL.
Application Gateway + WAF	7 (HTTP/S)	Regional	Puerta de enlace de aplicaciones con firewall de aplicaciones web. Protege contra los 10 ataques principales de OWASP mediante el conjunto de reglas predeterminado (DRS), incluidas las reglas de inteligencia sobre amenazas de Microsoft.	Aplicaciones web de cara al público que requieren balanceo de carga de capa 7 y protección WAF en una sola región.
Azure Front Door (portal de entrada de Azure)	7 (HTTP/S)	Global	Equilibrador de carga HTTP/S global con red CDN integrada, WAF y enrutamiento de tráfico. Termina TCP/TLS en los puntos de presencia (PoP) periféricos cercanos a los usuarios mediante la aceleración Split TCP.	Aplicaciones de varias regiones con una base de usuarios global. Cargas de trabajo que requieren almacenamiento en caché CDN, WAF global y conmutación automática ante errores.
Administrador de tráfico de Azure	DNS	Global	Enrutamiento de tráfico basado en DNS. Devuelve un CNAME al punto de conexión regional más cercano o más saludable. Los clientes se conectan directamente. Traffic Manager nunca ve el tráfico de la aplicación.	Conmutación ante errores a nivel de DNS en varias regiones. Protocolos que no son HTTP/S en los que Front Door no se aplica. Enrutamiento por geografía, rendimiento o prioridad.

Note

Las direcciones IP públicas de SKU Basic se retirarán en septiembre de 2025. Las direcciones IP básicas existentes permanecen operativas, pero no son compatibles con ningún Acuerdo de Nivel de Servicio. Use la SKU estándar para todas las implementaciones nuevas.

Funcionamiento de cada servicio

Comprender la arquitectura interna de cada servicio le ayuda a predecir el rendimiento, solucionar problemas y planear el ajuste de tamaño de subred.

Dirección IP pública

Una dirección IP pública de SKU estándar es un recurso definido por software que asigna una dirección IPv4 o IPv6 enrutable directamente a una interfaz de red, front-end del equilibrador de carga o puerta de enlace. La dirección cuenta con redundancia de zona de forma predeterminada en las regiones compatibles, lo que significa que la plataforma administra la conmutación ante errores entre zonas de disponibilidad sin que el usuario tenga que realizar ningún cambio. Las direcciones IP públicas no tienen procesamiento de tráfico. Los paquetes fluyen directamente al recurso asociado sin lógica de comprobación de estado ni de distribución.

Azure Load Balancer (estándar, público)

Standard Load Balancer usa un algoritmo de distribución basado en hash en flujos de 5 tuplas (IP de origen, puerto de origen, IP de destino, puerto de destino, protocolo). Funciona completamente en la ruta de acceso de datos en la capa 4, por lo que nunca finaliza las conexiones ni inspecciona las cargas. Las sondas de estado (TCP, HTTP o HTTPS) supervisan continuamente las instancias de backend y retiran de la rotación las instancias no aptas en cuestión de segundos. Load Balancer escala automáticamente. No hay planificación de capacidad ni dimensionamiento de instancias.

Azure Load Balancer (estándar, interno)

La Load Balancer interna funciona igual que su homólogo público, pero usa una dirección IP de front-end privada desde la subred de la red virtual. Distribuye el tráfico entre niveles internos, como un nivel web que envía tráfico a un clúster de API de nivel intermedio. Porque no tiene ninguna dirección IP pública, es invisible para Internet. Combínelo con un servicio de entrada pública, como Front Door, Application Gateway o un equilibrador de carga público, que gestiona el perímetro externo.

Puerta de enlace de aplicaciones Azure

Application Gateway es una aplicación virtual dedicada implementada en la subred de la red virtual. Termina las conexiones TLS en la pasarela, inspecciona los encabezados HTTP y las URL, y enruta las solicitudes a los grupos de servidores de fondo en función de reglas de ruta, encabezados de host o pruebas de estado personalizadas. La SKU v2 admite el escalado automático (de 0 a 125 instancias) y la redundancia de zona. Dado que está dentro de la red virtual, puede acceder a servicios back-end privados sin necesidad de que esos servicios back-end tengan direcciones IP públicas.

Application Gateway con WAF

Al agregar el nivel WAF, habilita el Conjunto de reglas principales de OWASP y las reglas de inteligencia sobre amenazas de Microsoft directamente en la canalización de procesamiento de Application Gateway. Cada solicitud HTTP pasa por el motor de WAF antes de alcanzar las reglas de enrutamiento. WAF admite directivas por sitio, por lo que puede tener distintas configuraciones de reglas para diferentes combinaciones de listener o host en el mismo gateway. WAF opera en modo de detección (solo registra) o de prevención (bloquea y registra).

Azure Front Door (portal de entrada de Azure)

Front Door funciona desde la red perimetral global Microsoft (más de 190 puntos de presencia). Cuando un usuario se conecta, el protocolo de enlace TCP y la negociación TLS tienen lugar en el punto de presencia más cercano mediante Split TCP. El punto de presencia mantiene una conexión persistente y activa con tu origen, lo que elimina la latencia de arranque en frío que experimentarían los usuarios al conectarse directamente. Front Door realiza el enrutamiento de nivel 7, la inspección de WAF, el almacenamiento en caché y la compresión en el borde antes de reenviar la solicitud al origen correcto más cercano a través de la red troncal de Microsoft.

Administrador de tráfico de Azure

Traffic Manager es un servicio basado en DNS sin intervención en la ruta de acceso de datos. Cuando un cliente resuelve el nombre de host de Traffic Manager, este devuelve un CNAME que apunta al punto de extremo más estable o más cercano en función de su método de enrutamiento (prioridad, ponderado, rendimiento, geográfico, multivalor o subred). Traffic Manager sondea continuamente el estado del punto de conexión y actualiza las respuestas dns en consecuencia. Dado que nunca ve el tráfico de la aplicación, funciona con cualquier protocolo: HTTP, TCP, UDP o protocolos propietarios.

Comparación del modelo de costos

Cada servicio de entrada sigue un modelo de facturación diferente. Use esta tabla para calcular los costos en el volumen de tráfico esperado.

Servicio	Modelo de facturación	Controladores clave de costos	Características de nivel gratis o incluidas
Dirección IP pública	Por hora (asociado) + por GB saliente	Número de horas asociadas; cargos por salida	Los primeros 100 GB salientes al mes son gratuitos (a nivel global)
Balanceador de carga estándar	Por hora por regla + por GB procesado	Número de reglas de equilibrio de carga; datos procesados a través del LB	Ninguno
Application Gateway	Por hora, por instancia y por unidades de capacidad consumidas	Horas de instancia; unidades de capacidad de cómputo, conexión y rendimiento	Ninguno
Application Gateway + WAF	Por hora y por instancia (precios del nivel de WAF) + unidades de capacidad	Igual que Application Gateway pero con la tarifa horaria del nivel WAF	Ninguno
Azure Front Door (portal de entrada de Azure)	Por solicitud + por GB transferido + solicitudes WAF	Enrutamiento de solicitudes, transferencia de datos desde el extremo de la red hasta el cliente, evaluación de reglas del WAF	El nivel estándar incluye funciones básicas de enrutamiento
Administrador de tráfico de Azure	Por millón de consultas DNS + por punto de conexión de comprobación de estado	Volumen de consultas DNS; número de puntos de conexión supervisados	Los primeros 100 millones de consultas tienen precios por niveles

Sugerencia

En el caso de cargas de trabajo de bajo tráfico (menos de 1 millón de solicitudes al mes), el modelo por solicitud de Front Door puede ser más económico que el costo fijo por hora de Application Gateway. A medida que aumenta el tráfico, los modelos por hora se vuelven más predecibles. Use la calculadora de precios de Azure con el rendimiento previsto para comparar.

Cómo elegir

Use las siguientes tablas de decisión para seleccionar el servicio de entrada adecuado para la carga de trabajo. Comience con la tabla de decisión de alto nivel y, a continuación, use la comparación detallada para confirmar su elección.

Application Gateway frente a Front Door frente a Traffic Manager

Esta tabla le ayuda a elegir entre los tres servicios de entrada HTTP y HTTPS más comunes.

Su necesidad	Servicio recomendado	Por qué
Tráfico HTTP/S, región única, protección de WAF	Application Gateway con WAF	Servicio regional de capa 7 con enrutamiento basado en rutas y WAF. Se ejecuta dentro de la red virtual.
Tráfico HTTP/S, varias regiones, usuarios globales, CDN + WAF	Azure Front Door (portal de entrada de Azure)	Servicio global de capa 7 que termina en los puntos de presencia (PoP) periféricos. CDN integrada, WAF y conmutación automática en caso de error.
Enrutamiento de varias regiones para protocolos que no son HTTP/S o enrutamiento de nivel DNS solo	Administrador de tráfico de Azure	Enrutamiento basado en DNS que funciona con cualquier protocolo. Sin terminación de conexión.
HTTP/S de varias regiones con requisitos de procesamiento enlazados a la red virtual regional	Application Gateway + Traffic Manager	Válido para cargas de trabajo que requieren una integración profunda con VNet o soberanía de datos regional con inspección WAF regional. En la mayoría de los escenarios http/S de varias regiones, prefiera Front Door en su lugar.

Sugerencia

Para la mayoría de las cargas de trabajo HTTP y HTTPS multirregión, Front Door es la opción preferida frente a Application Gateway combinado con Traffic Manager. Front Door ofrece WAF, CDN y conmutación automática por error integrados, sin necesidad de administrar varias instancias regionales de Application Gateway. La combinación de Application Gateway + Traffic Manager sigue siendo válida para cargas de trabajo que requieren procesamiento enlazado a la red virtual regional, Private Link orígenes accesibles solo dentro de una red virtual o requisitos normativos que exigen soberanía de datos regionales.

Comparación de servicios de entrada

Use esta comparación detallada cuando necesite comprender las funcionalidades de cada servicio.

Servicio	Nivel	Global o regional	Terminación de la conexión	WAF disponible	Comprobaciones de salud	Más adecuado para
Dirección IP pública	3	Regional	No (directo a la máquina virtual)	No	No	Desarrollo y pruebas, cargas de trabajo de instancia única sin requisitos de alta disponibilidad
Standard Load Balancer (público)	4	Regional	No (transferencia directa)	No	Sí (TCP, HTTP, HTTPS)	Cargas de trabajo que no son HTTP: juegos, IoT, TCP/UDP personalizados
Equilibrador de carga Estándar (interno)	4	Regional	No (transferencia directa)	No	Sí (TCP, HTTP, HTTPS)	Nivel interno detrás de un servicio de entrada público
Application Gateway	7	Regional	Sí (terminación de TLS)	No (agregar el nivel WAF)	Sí (HTTP/S personalizado)	HTTP/S de región única con enrutamiento basado en rutas
Application Gateway + WAF	7	Regional	Sí (terminación de TLS)	Sí (conjunto de reglas DRS)	Sí (HTTP/S personalizado)	Aplicaciones web de una sola región que necesitan WAF
Azure Front Door (portal de entrada de Azure)	7	Mundial	Sí (división de TCP en el PoP)	Sí (integrado)	Sí (HTTP/S)	HTTP/S de varias regiones con aceleración global
Administrador de tráfico de Azure	DNS	Global	No (solo DNS)	No	Sí (HTTP/S, TCP)	Conmutación por error multirregional a nivel de DNS, cualquier protocolo

Arquitectura de entrada de Internet

El siguiente diagrama muestra patrones comunes de encadenamiento de servicios para el tráfico entrante dirigido a las cargas de trabajo de Azure. Cada patrón combina los servicios de nivel 7 y 4 para que coincidan con un protocolo específico, un ámbito regional y una posición de seguridad.

Patrones de entrada comunes

Los patrones siguientes combinan varios servicios para una arquitectura de entrada completa. Elija el patrón que coincida con los requisitos del protocolo, el ámbito regional y la posición de seguridad.

Patrón 1: Aplicación web global con seguridad perimetral

Servicios: Front Door → Application Gateway (con WAF) → máquinas virtuales o contenedores

Escenario: Una aplicación SaaS que atiende a los clientes en Norteamérica, Europa y Asia necesita aceleración global, protección contra DDoS en el perímetro y enrutamiento regional basado en rutas de acceso a diferentes microservicios.

Front Door finaliza las conexiones de usuario en el punto de presencia más cercano (PoP), aplica reglas de WAF globales y almacena en caché el contenido estático. El tráfico se enruta a través de la red troncal de Microsoft a la puerta de enlace de aplicaciones regional, que realiza el enrutamiento basado en direcciones URL (por ejemplo, /api/* al grupo de API, /static/* a un back-end de almacenamiento). Este patrón proporciona dos capas de inspección de WAF: una en el borde y otra en la región.

Patrón 2: Multirregional no HTTP con conmutación por error de DNS

Servicios: Traffic Manager → Standard Load Balancer (por región) → máquinas virtuales

Escenario: Una empresa de juegos ejecuta servidores de juegos dedicados en el puerto UDP 7777 en tres regiones. Los jugadores se conectan automáticamente a la región operativa más cercana.

Traffic Manager usa el método de enrutamiento de rendimiento para devolver el registro DNS para la región de latencia más baja. Cada región cuenta con un equilibrador de carga estándar que distribuye el tráfico UDP entre un conjunto de escalado de máquinas virtuales. Si los sondeos de estado detectan un error regional, Traffic Manager actualiza DNS para enrutar los jugadores a la región más cercana.

Patrón 3: Aplicación web regional sencilla con WAF

Servicios: Application Gateway (con WAF) → máquinas virtuales

Escenario: Una aplicación interna de línea de negocio que se expone a asociados externos. Una sola región, tráfico moderado, requiere protección OWASP y terminación TLS.

Application Gateway proporciona enrutamiento basado en rutas de acceso, afinidad de cookies para la administración de sesiones y protección de WAF, todo ello desde un único recurso regional dentro de la red virtual. Este patrón evita la complejidad y el costo de un servicio global cuando el tráfico se concentra geográficamente.

Patrón 4: Front Door con orígenes privados bloqueados

Servicios: Front Door Premium → Private Link → Load Balancer interno → máquinas virtuales

Escenario: Una aplicación de servicios financieros con requisitos estrictos que exigen que el origen no tenga exposición de IP pública. Todo el tráfico debe atravesar la red troncal de Microsoft sin saltos de Internet públicos.

Front Door Premium se conecta al origen a través de un punto de conexión de Private Link. El back-end de origen no tiene ninguna dirección IP pública y ninguna exposición a Internet. Este patrón proporciona la seguridad de un origen totalmente privado combinado con las ventajas de rendimiento de la red perimetral global de Front Door.

Ingreso multirregional con Front Door

El siguiente diagrama muestra Azure Front Door como punto de entrada global, que redirige a los usuarios al origen regional operativo más cercano con conmutación automática por error.

Prerequisites

Antes de exponer la aplicación a Internet, asegúrese de que tiene implementados los siguientes componentes:

• Red virtual implementada: Los recursos de back-end deben ejecutarse dentro de una red virtual Azure con subredes de tamaño correcto. Consulte Diseño de la red virtual y las subredes para obtener instrucciones de planeamiento de subredes.
• Ejecución de la carga de trabajo: Necesita al menos un recurso back-end (máquina virtual, contenedor o servicio de plataforma) listo para atender el tráfico.
• Nombre DNS: Un nombre DNS público que usan los usuarios externos para llegar a la aplicación. Puede usar Azure DNS o un proveedor DNS de terceros.
• Planeamiento de subredes para los servicios de entrada: Application Gateway requiere una subred dedicada (se recomienda /24 como mínimo para producción). Las instancias de back-end de Standard Load Balancer pueden compartir una subred con otros recursos.

Consideraciones de diseño

Evalúa si es necesario el tráfico de entrada desde Internet para tus cargas de trabajo migradas. Muchas aplicaciones locales son solo internas y permanecen así después de la migración. Si se requiere tráfico de entrada, mantén la arquitectura sencilla:

• Application Gateway con WAF proporciona un punto de entrada de capa 7 en una sola región con terminación TLS y protección de OWASP. Este enfoque es el más habitual para aplicaciones web migradas que anteriormente se encontraban detrás de un proxy inverso local.
• La dirección IP pública con NSG es aceptable para cargas de trabajo que no son HTTP de tráfico bajo (por ejemplo, un servicio TCP al que se conectan los asociados). Restrinja el NSG a direcciones IP de origen conocidas.
• Evite asignar direcciones IP públicas directamente a las máquinas virtuales. Coloque un equilibrador de carga o Application Gateway entre Internet y el back-end.

Si sus aplicaciones migradas no dan servicio a usuarios externos, omita este artículo y continúe con Acceso saliente a Internet.

Las cargas de trabajo modernizadas tienen patrones de entrada distintos en función del tipo de aplicación:

• Azure Front Door para aplicaciones web orientadas al cliente (por ejemplo, ContosoBiz). Front Door proporciona aceleración global, WAF integrado, almacenamiento en caché de CDN y conmutación automática por error entre regiones. Utiliza el enrutamiento ponderado para implementaciones activas-activas.
• Azure Traffic Manager para aplicaciones móviles y de API (por ejemplo, ContosoCare). Traffic Manager proporciona enrutamiento basado en DNS para protocolos que no son HTTP o cuando los clientes necesitan conectividad regional directa.
• Firewall del hub como destino de DNAT: Todo el tráfico de entrada pasa por el Azure Firewall del hub antes de llegar a los niveles de aplicación. El firewall realiza una traducción de direcciones de destino (DNAT) para enrutar el tráfico depurado al spoke correcto. Este patrón garantiza que ningún tráfico de Internet no inspeccionado eluda sus controles de seguridad centralizados.

Combina Front Door con Application Gateway en cada región para obtener una inspección WAF de dos capas: una en el perímetro global y otra en el límite regional.

En el caso de las aplicaciones orientadas al público migradas desde AWS o Google Cloud, implemente Application Gateway con WAF en la red virtual radial donde reside la carga de trabajo:

• Application Gateway + WAF en la VNet del spoke: Implementa una Application Gateway regional con WAF habilitado en modo Prevención. Este enfoque mantiene el tráfico de entrada cerca de la carga de trabajo sin necesidad de que el tráfico atraviese el hub para la inspección HTTP.
• No hay direcciones IP públicas directas en máquinas virtuales: Nunca asigne direcciones IP públicas directamente a las máquinas virtuales migradas. Todo el tráfico accesible desde Internet entra a través de Application Gateway.
• Proteja los orígenes: Si la aplicación se encontraba anteriormente detrás de un Load Balancer de aplicaciones (ALB) de AWS o del equilibrio de carga de Google Cloud, asigne ese patrón de entrada a Application Gateway para las cargas de trabajo regionales o a Front Door para las cargas de trabajo globales.

Si la carga de trabajo multinube es solo interna (es decir, se comunica entre nubes mediante tránsito privado), omita este artículo y continúe con Azure Firewall y la inspección del tráfico.

Consideraciones de seguridad

La entrada desde Internet es la puerta principal de su aplicación. Es el límite en el que el tráfico de Internet que no es de confianza entra en el entorno de Azure. Siga estas prácticas para proteger la ruta de entrada.

Nunca exponga máquinas virtuales directamente con direcciones IP públicas

No asigne una dirección IP pública directamente a la interfaz de red de una máquina virtual para atender el tráfico de aplicaciones en los puertos 80 o 443. En su lugar, coloque un equilibrador de carga o Application Gateway entre Internet y las máquinas virtuales. Este enfoque le ofrece:

• Pruebas de estado para eliminar las instancias erróneas de la rotación
• Un único punto para la terminación SSL o TLS
• Un lugar para aplicar reglas de WAF y limitación de velocidad
• Registro centralizado de todo el tráfico entrante

Caution

Una dirección IP pública directamente en una máquina virtual expone todos los puertos abiertos a Internet. Si el grupo de seguridad de red de la máquina virtual tiene una regla mal configurada, los atacantes obtienen acceso directo al sistema operativo.

Habilitación de WAF en modo de prevención

Si implementa Application Gateway con WAF o Azure Front Door con WAF, establezca WAF en Modo de prevención para cargas de trabajo de producción. El modo de prevención bloquea las solicitudes malintencionadas antes de llegar a la aplicación. El modo de detección solo registra amenazas sin bloquearlas. Use el modo de detección solo durante las pruebas iniciales para ajustar las reglas e identificar falsos positivos.

El conjunto de reglas predeterminados de WAF (DRS) protege contra los 10 ataques principales de OWASP, como la inyección de código SQL, el scripting entre sitios y la ejecución remota de código. DRS también incluye Microsoft reglas de inteligencia sobre amenazas que detectan direcciones IP y cargas malintencionadas conocidas.

Habilitación de la protección contra DDoS

Todas las redes virtuales con recursos orientados al público deben tener habilitada la protección contra DDoS. Azure DDoS Network Protection proporciona optimización adaptable, telemetría de ataques y protección de costos para las direcciones IP públicas. Sin protección contra DDoS, un ataque volumétrico puede saturar el ancho de banda de entrada y hacer que la aplicación sea inaccesible.

Para más información, consulte Protección contra DDoS para la red.

Utilice los grupos de seguridad de red (NSG) para una defensa en profundidad

Incluso cuando se usa un equilibrador de carga o Application Gateway, configure reglas de grupo de seguridad de red en las subredes de back-end para restringir los orígenes de tráfico que pueden llegar a las máquinas virtuales. Un grupo de seguridad de red configurado correctamente:

• Permite el tráfico solo desde la subred o la etiqueta de servicio del equilibrador de carga.
• Deniega el tráfico entrante directo de Internet a las máquinas virtuales de back-end
• Registre el tráfico denegado para la supervisión de la seguridad

Para la planificación de NSG, consulte los grupos de seguridad de red y los grupos de seguridad de aplicaciones.

Exigir TLS 1.2 o posterior

Configure todos los servicios de entrada para que solo acepten TLS 1.2 o TLS 1.3. Deshabilite TLS 1.0 y 1.1, que tienen vulnerabilidades conocidas. Application Gateway y Front Door admiten la configuración mínima de la versión de TLS a través de su configuración de directiva TLS. Use directivas predefinidas, como AppGwSslPolicy20220101 para Application Gateway, en lugar de configuraciones de cifrado personalizadas, a menos que tenga requisitos de cumplimiento específicos.

Proteja los orígenes para Front Door

Al usar Azure Front Door, restrinja los servidores de origen para que acepten el tráfico solo desde Front Door. Si el origen acepta tráfico desde cualquier origen, los agentes maliciosos pueden eludir el WAF de Front Door conectándose directamente a la IP del origen, lo que hace que toda su inversión en WAF resulte ineficaz.

El bloqueo de origen usa dos mecanismos de verificación independientes. Aplique ambas medidas para una defensa en profundidad:

Restricción de etiquetas de servicio (capa de red)

Configure el grupo de seguridad de red (NSG) de origen o Azure Firewall para permitir tráfico HTTP/HTTPS entrante únicamente desde la etiqueta de servicio AzureFrontDoor.Backend. Esta etiqueta de servicio contiene todos los intervalos de direcciones IP que Front Door utiliza para conectarse a los orígenes. Aplique esta regla en la subred o la NIC donde reside el origen:

• Regla de NSG: Prioridad 100, Origen = etiqueta de servicio AzureFrontDoor.Backend, Destino = su subred de back-end, Puertos = 80, 443, Acción = Permitir.
• Denegación predeterminada: Asegúrese de que ninguna otra regla permita el tráfico entrante en los puertos 80/443 desde Internet. La regla predeterminada DenyAllInbound del NSG se encarga de esto, a menos que añada una regla Allow más amplia.

La etiqueta de servicio por sí sola no basta, porque todas las instancias de Front Door de todos los clientes de Azure comparten los mismos intervalos de direcciones IP de la etiqueta de servicio. Un atacante podría crear su propio perfil de Front Door y redirigirlo a su IP de origen, eludiendo sus reglas de WAF.

Validación del encabezado X-Azure-FDID (capa de aplicación)

Cada solicitud de Front Door incluye un X-Azure-FDID encabezado que contiene el identificador único (GUID) de la instancia de Front Door que envió la solicitud. Valida este encabezado en tu aplicación o en tu proxy inverso para confirmar que la solicitud proviene de tu perfil de Front Door y no de un actor malicioso:

1. Busque el identificador de Front Door en el portal de Azure en la página Información general del perfil de Front Door (el campo "Front Door ID").
2. En el código de su aplicación o en la configuración del servidor web, rechace cualquier solicitud en la que X-Azure-FDID no coincida con el GUID esperado.
3. Devuelve HTTP 403 para las solicitudes con un valor de encabezado que falta o es incorrecto.

La combinación de la etiqueta de servicio (que bloquea el tráfico que no es de Front Door en la red) con la validación de encabezados (que bloquea el tráfico de Front Door de otros clientes en la aplicación) garantiza que solo tu instancia de Front Door pueda acceder a tu origen.

orígenes de Private Link (bloqueo más fuerte)

Para las cargas de trabajo que requieren el máximo nivel de aislamiento del origen, Front Door Premium admite orígenes de Private Link. El origen no necesita ninguna dirección IP pública. Front Door se conecta a través de un punto de conexión privado a través de la red troncal de Microsoft. Este enfoque elimina la necesidad de reglas de etiquetas de servicio o validación de encabezados porque el origen no es accesible desde la red pública de Internet por completo.

Artículos relacionados

• Diseñe su red virtual y sus subredes: dimensionamiento de subredes para Application Gateway y los backends de Load Balancer
• Grupos de seguridad de red y grupos de seguridad de aplicaciones: reglas de NSG para restringir el acceso de back-end después de la entrada
• Entrega y rendimiento de la aplicación: ajuste del rendimiento después de establecer la ruta de acceso de entrada
• Acceso de salida a Internet: Control del tráfico de salida, la contraparte de salida del tráfico entrante
• Acceso administrativo seguro: patrones de acceso de administrador, distintos de la entrada de Internet para los usuarios de la aplicación
• Firewall de aplicaciones web: configuración detallada de WAF y ajuste de reglas
• Protección contra DDoS para la red: planeación de la protección contra DDoS para todos los recursos orientados al público

Aprende más

• ¿Qué es Azure Load Balancer?
• ¿Qué es Azure Application Gateway?
• ¿Qué es Azure Front Door?
• ¿Qué es Azure Traffic Manager?
• Direcciones IP públicas en Azure
• Azure Web Application Firewall en Application Gateway
• Introducción a la protección de red de Azure DDoS

Pasos siguientes

Sugerencia

¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.

A continuación, en el itinerario de lift-and-shift:

Entrega y rendimiento de la aplicación: agregue equilibrio de carga de nivel 7 y entrega global para la carga de trabajo migrada.

Si tu carga de trabajo migrada no necesita equilibrio de carga de capa 7, pasa directamente a Acceso a Internet saliente.

A continuación en su proceso de modernización:

Entrega y rendimiento de aplicaciones: optimice la entrega global y el rendimiento de las cargas de trabajo de PaaS orientadas al cliente.

A continuación, en el itinerario entre nubes:

Web Application Firewall: proteja las aplicaciones orientadas al público frente a ataques de capa HTTP en todo el patrimonio de la nube.

Si la carga de trabajo no usa HTTP/HTTPS, pase directamente a Azure Firewall e inspección del tráfico.