Microsoft AZ-500: Arquitectura de seguridad de red — Guía de estudio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

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

Descripción general

La arquitectura de seguridad de red de Azure impone una conectividad de privilegios mínimos, asume la existencia de brechas de seguridad e implementa una monitorización continua. Combina la microsegmentación dentro de las redes virtuales, planos de control con estado (stateful) para el tráfico este-oeste y de egreso, protecciones de borde para los endpoints expuestos a internet y acceso privado a PaaS. Los diseños sólidos priorizan el acceso basado en identidad en la capa de aplicación, al tiempo que mantienen límites de red fuertes, enrutamiento explícito y telemetría verificable.

Controles y segmentación de la red virtual

Las subredes son el primer límite de segmentación. Ubica las cargas de trabajo con niveles de confianza, ciclo de vida y directivas similares en la misma subred; separa las capas (web, aplicación, datos) para que puedas aplicar directivas y rutas independientes. Evita las subredes planas y “compartidas” que mezclan herramientas de administración, jump hosts y cargas de trabajo de negocio; complican la aplicación de directivas y aumentan el radio de impacto (blast radius).

Los Network Security Groups (NSG) aplican un filtrado con estado (stateful) de L3–L4 por subred o por NIC. Las reglas de entrada y salida se evalúan por prioridad (el número más bajo primero), con un DenyAll implícito al final. Los NSG son stateful: las respuestas a los flujos permitidos se autorizan automáticamente, por lo que rara vez se necesitan reglas para puertos efímeros. Operacionalmente, asocia los NSG a subredes para obtener controles amplios y luego refina en las NIC críticas. Documenta siempre el propietario, el propósito y la expiración de cualquier permiso “temporal”.

Los Application Security Groups (ASG) te permiten hacer referencia a grupos de VM por nombre en lugar de por IP, de modo que las reglas sobreviven al escalado y a la rotación de IP. Etiqueta las VM en ASG basados en roles (p. ej., asg-web, asg-app) y expresa directivas como “asg-web → asg-app TCP 443”. Esto reduce la proliferación de reglas y la deriva operacional.

Las reglas de seguridad efectivas resultan de la fusión de los NSG aplicados tanto a una NIC como a su subred. La regla de permiso/denegación coincidente más específica (por prioridad) es la que se aplica. Valida con “Reglas de seguridad efectivas” en el portal o mediante la verificación de flujo IP de Network Watcher para detectar entradas en conflicto antes de las ventanas de despliegue.

Las etiquetas de servicio (Service tags) (p. ej., AzureLoadBalancer, Storage, Sql, Internet, VirtualNetwork) son mantenidas por Microsoft y agrupan espacios de IP grandes y dinámicos en destinos de regla estables. Prefiere las etiquetas de servicio a las listas manuales de IP para evitar interrupciones por la rotación de IP del servicio. Por ejemplo, restringe el egreso a Storage y Sql mientras deniegas el acceso general a Internet.

La microsegmentación y la Confianza Cero (Zero Trust) se logran mediante:

• La aplicación de NSG con denegación por defecto y la apertura únicamente de rutas explícitas y mínimas.
• El uso de ASG para codificar la intención de la carga de trabajo.
• La restricción del egreso con etiquetas de servicio o filtrado basado en FQDN a través de Azure Firewall.
• La aplicación de la política de “ninguna IP pública en servidores” y el enrutamiento de todo el egreso a través de un punto de inspección controlado.

Ejemplo: crea una regla de NSG que permita la comunicación de la capa web a la de aplicación sobre TLS usando ASG, y deniega explícitamente todo lo demás con una prioridad más alta que la denegación implícita para documentar la intención.

az network nsg rule create \
  --resource-group rg-sec \
  --nsg-name nsg-app \
  --name allow-web-to-app-443 \
  --priority 200 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web \
  --destination-asgs asg-app \
  --destination-port-ranges 443

Servicios de seguridad de red y protección de borde

Azure Firewall es un firewall de alta disponibilidad, totalmente stateful y con directivas centralizadas. Úsalo para:

• Control este-oeste y de egreso cuando los NSG no son suficientes (nombres de dominio, inspección de TLS).
• DNAT para una exposición de entrada limitada cuando Application Gateway no es adecuado.
• Registro centralizado e inteligencia de amenazas.

Los grupos de colecciones de reglas contienen colecciones de reglas (de red, de aplicación, NAT) con prioridades que definen el orden de evaluación. Dentro de un grupo, las colecciones con menor prioridad se evalúan primero; las reglas se cotejan según el criterio más específico. Mantén las reglas de DNAT en su propio grupo con la prioridad de evaluación más alta para capturar el tráfico de entrada de forma determinista.

• Las reglas de red filtran por 5-tupla (IP/puerto/protocolo).
• Las reglas de aplicación filtran por FQDN, categorías de URL (Premium) y pueden usar etiquetas de FQDN.
• Las reglas NAT traducen direcciones/puertos públicos a privados para escenarios de entrada.

El filtrado basado en inteligencia de amenazas bloquea IP/dominios maliciosos conocidos. Ejecútalo en modo Alerta durante la fase inicial de establecimiento de la línea base, y luego en modo Denegar una vez que se hayan resuelto los falsos positivos.

Las características Premium añaden:

• Inspección de TLS con descifrado de salida y entrada, lo que permite visibilidad en L7 e IDPS.
• Detección y Prevención de Intrusiones (IDPS) con firmas y priorización de vulnerabilidades.
• Filtrado de URL y categorías web para un control de egreso granular.
• Controles avanzados de certificados y directivas de TLS.

Operacionalmente, aísla el firewall en una subred dedicada (AzureFirewallSubnet), enruta todo el tráfico con destino a internet hacia él con UDR y habilita las Zonas de Disponibilidad. Usa Firewall Policy (no las reglas clásicas) para una administración escalable, herencia y divergencia entre Desarrollo/Pruebas con una directiva base compartida.

El Web Application Firewall (WAF) mitiga ataques de L7 (SQLi, XSS).

• En Application Gateway, el WAF protege aplicaciones regionales con TLS de extremo a extremo y directivas por sitio; termina la conexión TLS del cliente y opcionalmente vuelve a cifrar hacia el backend.
• En Azure Front Door, el WAF protege aplicaciones distribuidas globalmente en el borde de la red con CDN integrado, protecciones contra bots y controles geográficos.

Crea directivas de WAF y asócialas a gateways, listeners o rutas. Elige el modo Detección inicialmente para ajustar, y luego el modo Prevención para bloquear. Usa conjuntos de reglas administradas (OWASP 3.x) y añade reglas personalizadas para límites de tasa o rangos de IP. Configura exclusiones (p. ej., campos JSON o encabezados específicos) para reducir los falsos positivos sin debilitar la protección general.

Ataque de Denegación de Servicio Distribuido (DDoS):

• El nivel Básico es una protección de plataforma siempre activa, pero no ofrece telemetría por recurso ni ajuste de la mitigación.
• DDoS Protection: Network Protection añade ajuste adaptativo por IP pública, mitigación automática, análisis de ataques, alertas, crédito de protección de costos y acceso a DDoS Rapid Response.

Habilita Network Protection en las VNet que alojen IP públicas (SKU Estándar). Usa la telemetría (Métricas, Registros de diagnóstico) para observar los vectores de ataque, el ciclo de vida de la mitigación y su efectividad. Diseña los recursos protegidos para que estén detrás de balanceadores de carga o de un Application Gateway para absorber la carga volumétrica, y minimiza la exposición pública directa. Combina WAF y DDoS para una defensa por capas.

Acceso privado, conectividad híbrida y enrutamiento

Private Link y los puntos de conexión privados proporcionan acceso por IP privada desde su VNet a los servicios PaaS. Un punto de conexión privado es una NIC en su subred asignada al recurso PaaS; el tráfico permanece en la red troncal (backbone) de Microsoft. Pasos operativos:

• Deshabilite el acceso a la red pública en el recurso PaaS para evitar omisiones (bypass).
• Despliegue zonas de DNS privado (p. ej., privatelink.blob.core.windows.net) y vincúlelas a las VNets para una resolución de nombres fluida.
• Gestione las aprobaciones de forma centralizada; considere el aislamiento por suscripción/inquilino (tenant) con un flujo de trabajo de aprobación manual.

Los puntos de conexión de servicio (service endpoints) extienden la identidad de su subred a los recursos PaaS a través de sus IP públicas, permitiendo que el firewall del PaaS restrinja el acceso a subredes específicas. No crean IP privadas, por lo que el egreso pasa por el borde público pero permanece dentro de la red de Microsoft. Use políticas de punto de conexión de servicio para permitir solo las cuentas de almacenamiento aprobadas. Para cargas de trabajo en contenedores en VM de IaaS, asegúrese de usar Azure CNI para que las IP de los pods/contenedores provengan de la subred; de lo contrario, el punto de conexión de servicio no reconocerá el origen y el acceso puede fallar.

Estrategia de resolución de DNS:

• Para Private Link, asegúrese de que su ruta de DNS resuelva el FQDN del PaaS al punto de conexión privado. Use zonas de Azure Private DNS, reenviadores condicionales (conditional forwarders) en el DNS local (on-prem), o Azure DNS Private Resolver para el reenvío híbrido.
• Mantenga claras las asignaciones autoritativas de horizonte dividido (split-horizon) para evitar la resolución pública intermitente.

Conectividad híbrida:

• VPN Gateway: Para conexiones de sitio a sitio (site-to-site), use una VPN basada en rutas con IKEv2 y cifrados robustos. Use BGP para intercambiar rutas dinámicamente, simplificando el crecimiento y la conmutación por error (failover). Aplique VPN NAT cuando existan espacios de direcciones superpuestos. Para el túnel forzado (forced tunneling), anuncie 0.0.0.0/0 desde el entorno local (on-prem) a través de BGP o aplique UDR que envíen 0/0 a un dispositivo virtual (virtual appliance); asegúrese de tener una ruta de excepción para los rangos privados de PaaS según sea necesario.
• ExpressRoute: Proporciona conectividad privada; el cifrado no es inherente. Use MACsec (para ExpressRoute Direct) o ejecute IPsec sobre ER para la confidencialidad. Use comunidades BGP y filtros de ruta para el peering de Microsoft (Microsoft peering). Soporte activo-activo con ECMP a través de los circuitos para la resiliencia. Para el túnel forzado, acepte las rutas predeterminadas desde el entorno local (on-prem) y asegúrese de que no haya UDR en conflicto que creen un agujero negro (blackhole) para las rutas de internet.

Rutas definidas por el usuario (UDR), NVA y precedencia:

• La selección de ruta utiliza la coincidencia de prefijo más largo (longest prefix match), y luego el origen: UDR > BGP > sistema. Las UDR 0/0 mal aplicadas pueden crear un agujero negro (blackhole) en las rutas de retorno; valide con la función de próximo salto (next-hop) de Network Watcher.
• Para los NVA, habilite el reenvío de IP (IP forwarding) en las NIC y colóquelos detrás de un balanceador de carga o un Gateway Load Balancer para una inserción transparente y escalable. Prefiera Azure Firewall para escenarios gestionados; cuando se requieran características específicas del proveedor, diseñe la alta disponibilidad (HA) con múltiples zonas de disponibilidad y un balanceo de carga con sondeos de estado (health probes).

Administración segura, monitoreo y telemetría

Conectividad administrativa segura:

• Azure Bastion proporciona RDP/SSH sobre TLS desde el portal o cliente nativo sin exponer las IP públicas de las VM. Utilice la SKU Standard para escalabilidad, conexiones basadas en IP y enlaces compartibles. Restrinja el acceso a Bastion mediante RBAC y Just-in-Time.
• El acceso Just-in-Time a VM (Defender for Cloud) cierra los puertos de administración en los NSG y los abre bajo solicitud con límite de tiempo, aprobación y restricciones de IP de origen. Combine con Bastion para una postura sin IP públicas y un registro de auditoría preciso.

Network Watcher proporciona verificación operativa y análisis forense:

• Los registros de flujo de NSG (v2) se escriben en almacenamiento y pueden enviarse a Traffic Analytics en Log Analytics para obtener información sobre los principales comunicadores (top talkers), flujos permitidos/denegados y geografía.
• La solución de problemas de conexión (Connection troubleshoot) prueba activamente la conectividad de extremo a extremo e informa dónde se bloquea una ruta (NSG, UDR, DNS, firewall).
• La captura de paquetes se puede activar bajo demanda o mediante alertas; utilice búferes circulares (ring buffers) para reducir el almacenamiento y capturar solo los puertos relevantes.
• Las rutas efectivas (Effective routes) y la verificación de flujo IP (IP flow verify) mapean las decisiones en tiempo de ejecución a través de UDR, BGP y NSG; automatice estas comprobaciones en la fase de pre-verificación (preflight) de CI/CD.

Habilite rápidamente los registros de flujo de NSG y los análisis:

az network watcher flow-log configure \
  --resource-group rg-sec \
  --nsg nsg-app \
  --enabled true \
  --traffic-analytics true \
  --storage-account saflowlogs \
  --workspace /subscriptions/<sub>/resourceGroups/rg-la/providers/Microsoft.OperationalInsights/workspaces/la-workspace

Escenario de problema práctico

Starbucks está modernizando una plataforma de gestión de pedidos en Azure. Objetivos de seguridad: sin IP públicas en las capas de aplicación/datos, egreso estricto, protección web global y visibilidad operativa.

1. Crear tres subredes por región: web, app, data, cada una con su propio NSG y ASG alineados a su rol.

Justificación: La microsegmentación basada en subredes con ASG codifica los flujos de privilegio mínimo (web→app 443, app→data 1433) y reduce el radio de impacto (blast radius). NSG separados por capa evitan el acoplamiento accidental de políticas.

2. Desplegar Azure Front Door Standard/Premium con una política de WAF en modo de prevención (Prevention) usando OWASP 3.x y reglas personalizadas para limitación de velocidad (rate limiting) y restricciones geográficas.

Justificación: La protección de borde global (edge) absorbe el tráfico volumétrico, bloquea ataques comunes de L7 antes de que lleguen a la región y reduce la latencia mediante anycast. Las políticas de WAF en el borde proporcionan una aplicación consistente en todas las regiones.

3. Colocar un Application Gateway con WAF v2 en cada región frente a la capa web; terminar el TLS en el App Gateway y volver a cifrar hacia el backend.

Justificación: El enrutamiento regional de L7 y el WAF complementan a Front Door, permitiendo mTLS por aplicación hacia los backends, afinidad basada en cookies y despliegues blue/green, manteniendo al mismo tiempo la capacidad de inspección.

4. Habilitar DDoS Protection: Network Protection en las VNet que contienen las IP públicas del Application Gateway.

Justificación: La mitigación adaptativa por IP, la telemetría y la protección de costos reducen el riesgo de ataques volumétricos dirigidos a los puntos de entrada regionales. El alcance a nivel de VNet asegura que todas las IP públicas actuales y futuras estén protegidas sin configuración por recurso.

5. Desplegar Azure Firewall Premium en un hub seguro; enrutar todo el egreso de las subredes de aplicación y datos hacia él con UDR. Habilitar la inspección de TLS y el IDPS para el tráfico saliente, y configurar reglas de aplicación para permitir solo los FQDN requeridos.

Justificación: El control de egreso centralizado con descifrado y detección basada en firmas previene el comando y control (C&C) y la exfiltración de datos. Las reglas de aplicación reducen el mantenimiento en comparación con las reglas basadas en IP y se alinean con un modelo de egreso Zero Trust.

6. Usar Private Link para Azure SQL y Storage; deshabilitar el acceso a la red pública y configurar zonas de DNS privado vinculadas a todas las VNet. Para cargas de trabajo en contenedores, usar Azure CNI.

Justificación: Los private endpoints mantienen las rutas de datos en la red troncal (backbone) y eliminan la exposición pública. El DNS privado asegura una resolución de nombres fluida. Azure CNI garantiza que las IP de los pods se originen en la subred para que Private Link y los service endpoints funcionen correctamente.

7. Establecer ExpressRoute con circuitos duales en modo activo-activo y anunciar las rutas on-premise con BGP; habilitar IPsec sobre ER para tráfico sensible. No anunciar la ruta 0/0 inicialmente; pilotar el túnel forzado (forced tunneling) primero en una subred de preproducción (staging).

Justificación: ER proporciona conectividad privada y predecible; el cifrado por capas protege los flujos de alta sensibilidad. El despliegue controlado del túnel forzado previene el “agujero negro” accidental de internet (internet blackholing) y valida las rutas de excepción.

8. Proporcionar acceso administrativo a través de Azure Bastion y aplicar Just-in-Time en todas las VM; eliminar todas las IP públicas de los servidores.

Justificación: Elimina las superficies de administración expuestas mientras se preserva un acceso auditable y con límite de tiempo, alineado con el principio de privilegio mínimo.

9. Activar los registros de flujo de NSG y Traffic Analytics, configurar los diagnósticos de Firewall y WAF para que envíen a Log Analytics, y establecer alertas para mitigaciones de DDoS y picos de bloqueo de WAF.

Justificación: La telemetría unificada permite la detección proactiva, la planificación de capacidad y una respuesta rápida a incidentes. Las alertas sobre patrones de anomalías detectan ataques y configuraciones erróneas de forma temprana.

10. Implementar Azure Policy para denegar IP públicas en las NIC, requerir NSG en todas las subredes y auditar las VNet que no tengan DDoS habilitado; integrar las comprobaciones de políticas en el CI/CD.

Justificación: Previene la desviación de la configuración (drift), impone barreras de protección (guardrails) a escala y hace que los valores predeterminados seguros sean repetibles para futuras cargas de trabajo.

← Gestión de identidades y accesos · Todos los dominios · Seguridad de computación →

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

Explorar Microsoft →