Microsoft AZ-700: Seguridad de Red — Guía de estudio

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Network Engineer AZ-700 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Control de acceso a la red: diseño de NSG y ASG, enrutamiento y emparejamiento

Los Network Security Groups (NSG) siguen siendo el mecanismo principal y de bajo costo para filtrar el tráfico de entrada y salida de las subredes y las NIC. Los NSG son stateful (con estado), pueden hacer referencia a etiquetas de servicio (p. ej., Internet, Storage) y admiten Application Security Groups (ASG) para agrupar las NIC de las VM y escalar el mantenimiento de reglas para flotas grandes. Aplique los NSG a nivel de subred para una segmentación amplia y a nivel de NIC para excepciones específicas del host; recuerde que ambos se evalúan y se aplica el conjunto efectivo más restrictivo. Las trampas comunes incluyen olvidar las reglas predeterminadas (reglas del sistema de denegación/permiso con prioridades altas), ordenar mal las prioridades (las prioridades de las reglas de NSG van de 100 a 4096; los valores predeterminados del sistema se sitúan en 65 000+) y suponer que los NSG proporcionan capacidades de IDS/antivirus, ya que no inspeccionan las cargas útiles (payloads). Al emparejar redes virtuales, los NSG siguen gobernando el tráfico entre los pares, pero las UDR (rutas definidas por el usuario) pueden anular las rutas del sistema y crear un agujero negro (blackhole) de tráfico involuntariamente si un próximo salto (por ejemplo, a un Azure Firewall) no es accesible en ese contexto. Las decisiones de diseño sopesan el costo y la simplicidad de los NSG/ASG frente a la visibilidad y los controles avanzados de un firewall centralizado: los NSG son económicos y de alto rendimiento para un filtrado general; utilice un firewall administrado para el registro centralizado, el control de DNAT/NAT y las políticas de capa de aplicación.

Controles perimetrales y este-oeste: Azure Firewall, DNAT, reglas de aplicación e IDPS

Azure Firewall proporciona un perímetro stateful (con estado) administrado capaz de aplicar reglas de DNAT, SNAT y de capa de aplicación. Diséñelo en una AzureFirewallSubnet dedicada y utilice tablas de rutas para dirigir el tráfico este-oeste de tipo hub-spoke a través del firewall para su inspección. Utilice colecciones de DNAT para publicar servicios internos: especifique los rangos de origen, la IP de destino, los puertos de destino y la IP:puerto traducidos. Las colecciones de reglas de aplicación le permiten autorizar por FQDN para HTTP/S (p. ej., *.microsoft.com), lo que evita las frágiles listas de permisos de IP. Para la inspección profunda de paquetes y la inspección de tráfico cifrado, Azure Firewall Premium añade un motor de IDPS e inspección de TLS, con un costo y una complejidad operativa mayores para la gestión de certificados y una posible latencia. Los NVA de terceros siguen siendo una opción válida cuando se necesitan firmas especializadas o características de rendimiento específicas. Las decisiones de escalabilidad y resiliencia incluyen el uso del autoescalado (v2) de Firewall o implementaciones con redundancia de zona frente a instancias fijas: el autoescalado alivia las restricciones de rendimiento (throughput), pero es más caro. Supervise las métricas y los registros del firewall en Log Analytics para detectar el agotamiento de DNAT/SNAT y ajustar el orden de las reglas y el número de IP públicas cuando sea necesario.

Azure Firewall Standard: filtrado stateful de L3 a L7, NAT/DNAT, reglas de aplicación y de red, servicio administrado con opciones de autoescalado y registro integrado.
Azure Firewall Premium: incluye las características de Standard más IDPS, inspección de TLS, inteligencia de amenazas avanzada y filtrado de URL; tiene un costo mayor y requiere la gestión de certificados/claves para la inspección de TLS.

Protección de la capa de aplicación, Private Link y DDoS

Proteja las aplicaciones web en el perímetro (edge) con WAF y servicios de perímetro distribuidos. Application Gateway WAF_v2 proporciona un WAF regional con integración en una VNet y es ideal cuando los backends son privados (App Service con ASE o VM). Azure Front Door (perímetro) proporciona equilibrio de carga global y WAF en el perímetro de la CDN y reduce la latencia para los clientes globales; elija Front Door para la conmutación por error global y App Gateway para la protección regional de backends privados. La protección contra DDoS (Básica incluida) debe actualizarse a DDoS Protection Standard cuando las IP públicas alojan servicios importantes; perfila automáticamente el tráfico y mitiga los ataques volumétricos para los recursos en una red virtual protegida. Para el acceso privado, Private Link/Private Endpoints proporcionan una IP privada en su VNet para los servicios de la plataforma, eliminando la exposición pública. Los errores comunes incluyen olvidar deshabilitar el acceso a la red pública en el recurso PaaS, manejar incorrectamente la integración de DNS privado (debe poseer y mapear las zonas de privatelink o configurar reenviadores condicionales) y esperar que los WAF de perímetro alcancen los private endpoints sin un proxy regional; a menudo, un pequeño proxy inverso reforzado (Application Gateway o Firewall) en una subred perimetral enruta el tráfico desde el front-door hasta el private endpoint.

Controles operativos: registro, políticas, monitoreo y trampas comunes para ingenieros

La higiene operativa es a menudo el diferenciador entre entornos de red seguros y frágiles. Habilite los NSG Flow Logs (v2) y los diagnósticos de Azure Firewall en un área de trabajo de Log Analytics gestionada de forma centralizada y conéctelos a Azure Monitor y Sentinel para análisis, búsqueda de amenazas y alertas. Utilice Traffic Analytics para obtener topología agregada, los principales comunicadores y anomalías de flujo; recuerde que Traffic Analytics requiere Network Watcher y un área de trabajo de Log Analytics en la misma región. Para enlaces híbridos, Network Performance Monitor (NPM) y Connection Monitor proporcionan latencia periódica, fluctuación (jitter) y estado de la ruta, lo que ayuda a demostrar los SLA para ExpressRoute y SD-WAN. Aplique barreras de protección (guardrails) con Azure Policy: exija Azure Firewall en los concentradores (hubs), prohíba la creación de IP públicas en recursos exclusivamente privados y audite los rangos de prioridad de las reglas de NSG o las reglas sin etiquetar. Las trampas comunes incluyen la precedencia de rutas (una UDR anula las rutas del sistema), el agotamiento de puertos SNAT cuando muchas conexiones salen a través de una única IP pública (mitíguelo añadiendo IP públicas o utilizando el autoescalado del firewall) y los requisitos de nomenclatura de subredes (AzureFirewallSubnet debe existir para el Firewall). Las decisiones sobre resiliencia frente a costo son iterativas: centralice la inspección para obtener visibilidad, pero localice para rutas sensibles a la latencia y utilice el autoescalado/redundancia zonal donde las cargas de trabajo sean críticas.

Problema práctico: Escenario de caso de uso

Escenario: Contoso Ltd. opera una red hub-and-spoke en Azure que abarca dos regiones con una VNet de concentrador (hub) central que contiene un Azure Firewall zonal y servicios compartidos. Las sucursales se conectan a través de SD-WAN BGP a los concentradores regionales. Varias aplicaciones web PaaS utilizan puntos de conexión privados (private endpoints) en las VNet radiales (spoke).

Desafío: Los clientes de Internet deben llegar a una puerta de entrada pública (front door) para el enrutamiento global, pero el tráfico del backend de la aplicación web debe terminar en puntos de conexión privados y todo el tráfico de salida (egress) desde los radios debe ser inspeccionado y registrado sin exponer públicamente los recursos PaaS.

Enfoque recomendado:

Despliegue Azure Front Door Standard/Premium como el punto de entrada público global y adjunte un Application Gateway regional en cada concentrador como origen privado, o utilice Front Door Premium con una configuración de origen privado seguro donde sea compatible.
Sitúe un Application Gateway v2 en la subred de la VNet del concentrador (dedicada por cada AGW) y configúrelo para reenviar el tráfico al App Service Private Endpoint a través del emparejamiento de VNet (VNet peering); habilite WAF_v2 en el Application Gateway y asocie una política WAF gestionada.
Enrute todo el tráfico de salida de los radios a través del Azure Firewall Premium del concentrador (en AzureFirewallSubnet) utilizando UDR en los radios; habilite reglas DNAT para las traducciones de entrada necesarias y reglas de aplicación para la salida por FQDN; habilite la inspección IDPS y TLS en la SKU Premium para obtener visibilidad del tráfico cifrado.
Centralice los registros en un área de trabajo de Log Analytics, habilite NSG Flow Logs y Traffic Analytics, habilite DDoS Protection Standard en las IP públicas del concentrador y refuerce la arquitectura con Azure Policy (exigir Firewall, no permitir el acceso a la red pública en PaaS).

Justificación: Front Door proporciona disponibilidad global y baja latencia, Application Gateway con WAF_v2 protege los backends privados, y Azure Firewall Premium proporciona inspección centralizada, DNAT e IDPS tanto para el tráfico de salida (egress) como de entrada (ingress). El registro centralizado y la aplicación de políticas garantizan la visibilidad y el cumplimiento, manteniendo al mismo tiempo la privacidad de los puntos de conexión PaaS.

← Azure DNS y Resolución de Nombres · Todos los dominios · Equilibrio de Carga y Gestión de Tráfico →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →