Azure Network Security (AZ-104) — NSG, Azure Firewall y Private Endpoints
0. Cómo entra la seguridad de red en AZ-104
En AZ-104 la seguridad de red cubre todas las capas desde la VNet hasta el WAF de aplicaciones.
Debes ser capaz de:
- Diseñar subredes y NSG coherentes con el principio de mínimo privilegio.
- Saber cuándo usar Azure Firewall frente a NSG o NVAs.
- Proteger aplicaciones web con WAF (Web Application Firewall) en Application Gateway o Front Door.
- Publicar servicios PaaS de forma privada mediante Private Endpoints.
Mantra de examen: NSG controla tráfico de red (L3/L4) hacia/desde subredes y NICs. Azure Firewall y WAF controlan tráfico hacia/desde Internet con inspección más avanzada. Private Endpoints evitan Internet exponiendo servicios PaaS sólo en redes privadas.
1. Modelo básico: VNets, subredes y NICs
Piensa en la VNet como tu “datacenter lógico” en Azure.
- Las VNets son aisladas por defecto entre sí (salvo peering o VPN).
- Dentro de una VNet creas subredes para separar tipos de carga: frontend, backend, datos, gestión.
- Las VMs se conectan a una subred a través de una NIC que puede tener una IP pública o sólo privada.
# Crear VNet y subred de aplicación
az network vnet create \
-g rg-az104-netsec \
-n vnet-hub \
--address-prefixes 10.10.0.0/16 \
--subnet-name snet-app \
--subnet-prefixes 10.10.1.0/24
2. Network Security Groups (NSG) y Application Security Groups (ASG)
Los NSG son el firewall básico a nivel de red. Funcionan con reglas de entrada y salida.
Elementos clave de un NSG
- Priority: cuanto menor, antes se evalúa.
- Direction: Inbound o Outbound.
- Source/Destination: IPs, rangos, etiquetas (
Internet,VirtualNetwork, etc.). - Service: protocolo y puerto (por ejemplo, TCP 80, 443, 22, 3389).
- Action: Allow o Deny.
# NSG que sólo permite SSH desde una IP concreta
az network nsg create -g rg-az104-netsec -n nsg-web
az network nsg rule create \
-g rg-az104-netsec \
--nsg-name nsg-web \
-n allow-ssh-admin \
--priority 100 \
--access Allow --direction Inbound --protocol Tcp \
--source-address-prefixes 1.2.3.4/32 \
--destination-port-ranges 22
Application Security Groups (ASG)
Los ASG te permiten agrupar NICs lógicamente (por ejemplo, “servidores web”) y referenciarlas en reglas NSG.
Si el enunciado habla de “definir reglas basadas en roles de servidor, no en direcciones IP” la respuesta correcta suele incluir Application Security Groups.
3. Azure Firewall y reglas de aplicación
Azure Firewall es un firewall gestionado L3–L7 con alta disponibilidad integrada.
Características clave
- Escala automática y SLA integrado.
- Reglas de Application (FQDN), Network (IP/puerto) y NAT.
- Integración con Threat Intelligence para bloquear tráfico malicioso conocido.
- Registro completo de tráfico en Log Analytics/Storage/Event Hub.
Si la organización necesita “un único punto central de salida a Internet inspeccionado” la opción que busca el examen es casi siempre Azure Firewall (a veces en un hub de vWAN).
4. Application Gateway y WAF
Application Gateway es un balanceador L7 para HTTP/HTTPS que puede incluir un WAF.
- Soporta routing basado en URL y host (path-based, multi-site).
- Offload de TLS/SSL y afinidad de sesión (cookies).
- Integración con Web Application Firewall (reglas OWASP).
¿Cuándo usar WAF?
- Cuando el requisito diga “proteger frente a ataques de capa 7” o “SQL injection / XSS”.
- Cuando se pida cumplimiento de normativas de seguridad para aplicaciones web expuestas a Internet.
5. Private Endpoints y acceso privado a PaaS
Los Private Endpoints exponen servicios PaaS (Storage, SQL, Web Apps, etc.) a través de una IP privada dentro de tu VNet.
Beneficios clave
- El tráfico pasa por la red de Azure, no por Internet pública.
- Puedes bloquear tráfico público al servicio PaaS y obligar a usar el endpoint privado.
- Se integra con Private DNS Zones para resolver el FQDN al endpoint privado.
En el examen, si una empresa quiere limitar el acceso a una cuenta de Storage o base de datos a “sólo desde redes internas de Azure”, la respuesta correcta suele ser: Private Endpoints + Private DNS.
6. DNS privado y resolución de nombres
Para que los Private Endpoints funcionen de forma transparente, necesitas configurar Private DNS Zones.
- Creas una zona privada, por ejemplo
privatelink.blob.core.windows.net. - La asocias a las VNets donde vivirán los clientes.
- Azure crea automáticamente registros A apuntando a la IP del private endpoint.
# Ejemplo: zona privada para Storage
az network private-dns zone create \
-g rg-az104-netsec \
-n privatelink.blob.core.windows.net
7. Patrones HUB/SPOKE típicos de examen
Un diseño muy frecuente es el modelo HUB/SPOKE:
- El HUB contiene servicios compartidos: Azure Firewall, VPN/ExpressRoute, DNS, etc.
- Los spokes son VNets por aplicación, entorno (prod/dev) o unidad de negocio.
- Los spokes se conectan al hub por peering (a veces con vWAN en despliegues más grandes).
Si el enunciado pide “centralizar la salida a Internet y el filtrado” o “implementar microsegmentación entre aplicaciones” lo más habitual es un diseño HUB/SPOKE con Azure Firewall o NVAs en el hub.
8. Laboratorios sugeridos y casos prácticos
Laboratorio 1 — Segmentación con NSG y ASG
- Crea una VNet con subred de frontend y backend.
- Despliega una VM en cada subred.
- Crea ASG
asg-webyasg-dby asígnalos a las NICs. - Define reglas NSG para permitir tráfico HTTP sólo desde
asg-webhaciaasg-db.
Laboratorio 2 — Private Endpoint para Storage
- Crea una cuenta de Storage y un private endpoint en una subred.
- Configura Private DNS Zone para
privatelink.blob.core.windows.net. - Desde una VM en la VNet, accede a la cuenta usando el FQDN y comprueba que la ruta va por la IP privada.