Se podría pensar que controlar el tráfico de red en Azure requeriría un dispositivo de firewall dedicado, tablas de enrutamiento complejas y una certificación de red. No es así. Azur Grupos de seguridad de red (NSG) le brindan filtrado de tráfico de capa 4 con estado que puede conectar directamente a subredes o interfaces de red, sin necesidad de infraestructura adicional.

Qué hacen realmente los GSN

Un NSG es un conjunto de reglas de permitir/denegar que Azure evalúa con respecto a un 5-tupla: IP de origen, puerto de origen, IP de destino, puerto de destino y protocolo. Cada paquete que llega a sus recursos se compara con estas reglas en orden de prioridad, el número más bajo primero. En el momento en que un paquete coincide con una regla, el procesamiento se detiene.

El detalle clave que separa a los NSG de las ACL de enrutadores tradicionales: tienen estado. Permita el tráfico entrante en el puerto 443 y el tráfico de retorno volverá automáticamente. No necesita una regla de salida coincidente para la respuesta. Solo eso reduce el número de reglas aproximadamente a la mitad en comparación con los firewalls sin estado.

Requisitos previos

Antes de comenzar a crear NSG, confirme que los tiene listos:

• Una suscripción a Azure con al menos Colaborador de la red permisos

• CLI de Azure instalada y autenticada (az login)

• Un grupo de recursos y una red virtual ya implementados

Verifique que su CLI esté lista:

az account show --query "{subscription:name, tenantId:tenantId}" --output table

Crea tu primer NSG

Comience creando un NSG y adjuntándolo a una subred. La conexión a nivel de subred es el enfoque recomendado: aplica reglas de manera consistente a cada recurso en esa subred sin requerir configuración por máquina virtual.

# Create the NSG
az network nsg create \
  --resource-group myResourceGroup \
  --name mySubnet-nsg \
  --location eastus

# Attach it to a subnet
az network vnet subnet update \
  --resource-group myResourceGroup \
  --vnet-name myVNet \
  --name mySubnet \
  --network-security-group mySubnet-nsg

Cada nuevo NSG viene con reglas de seguridad predeterminadas que no puede eliminar pero que puede anular con reglas personalizadas de mayor prioridad.

Eso AllowInternetOutBound Vale la pena señalar la regla. Significa que cada máquina virtual puede acceder a Internet de forma predeterminada; está bien para entornos de desarrollo, pero querrás anularla en producción con una regla de denegación con un número de prioridad más bajo.

Advertencia: Al conectar diferentes NSG a una subred y a una NIC se crea un filtro doble. El tráfico entrante debe pasar primero por el NSG de subred y luego por el NSG de NIC. El tráfico de salida va en la otra dirección. Esta estratificación parece segura, pero por lo general solo crea dolores de cabeza al solucionar problemas.

Agregar reglas de seguridad personalizadas

Ahora agregue reglas que coincidan con su carga de trabajo real. A continuación se explica cómo permitir el tráfico HTTPS entrante:

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name mySubnet-nsg \
  --name AllowHTTPS \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 443

Y bloquear el acceso directo SSH desde Internet:

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name mySubnet-nsg \
  --name DenySSHFromInternet \
  --priority 200 \
  --direction Inbound \
  --access Deny \
  --protocol Tcp \
  --source-address-prefixes Internet \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 22

Deje espacios entre los números de prioridad (100, 200, 300) para que pueda insertar reglas más adelante sin tener que volver a numerar toda la pila.

Verifique que sus reglas estén vigentes:

az network nsg rule list \
  --resource-group myResourceGroup \
  --nsg-name mySubnet-nsg \
  --output table

Esto enumera todas las reglas en orden de prioridad, para que pueda confirmar que sus reglas personalizadas se encuentran por encima del rechazo total predeterminado en 65500.

Si administra entornos con cientos de direcciones IP, se encontrará con el Límite de 1000 reglas por NSG. Las reglas de seguridad aumentadas ayudan aquí: le permiten especificar hasta 4000 direcciones IP o rangos en el campo de origen o destino de una sola regla, condensando lo que serían cientos de reglas individuales en una. Utilice valores separados por comas en --source-address-prefixes o --destination-address-prefixes:

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name mySubnet-nsg \
  --name AllowPartnerIPs \
  --priority 250 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 10.1.0.0/24 10.2.0.0/24 192.168.5.0/24 \
  --destination-port-ranges 443

Utilice etiquetas de servicio en lugar de direcciones IP

Codificar direcciones IP en reglas NSG es una trampa de mantenimiento. Los rangos de IP de Azure cambian y sus reglas quedan obsoletas en el momento en que Microsoft actualiza su infraestructura. Etiquetas de servicio resuelva esto representando grupos de prefijos de IP que Azure mantiene automáticamente.

Restrinja una subred para llegar solo a Azure Storage en una región específica:

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name mySubnet-nsg \
  --name AllowStorageWestUS \
  --priority 300 \
  --direction Outbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes Storage.WestUS \
  --destination-port-ranges 443

Consejo profesional: puede enumerar todas las etiquetas de servicio disponibles para su región con az network list-service-tags --location eastus. La salida es detallada, así que canalícela jq para filtrar lo que necesitas.

Agrupe máquinas virtuales con grupos de seguridad de aplicaciones

Grupos de seguridad de aplicaciones (ASG) le permiten escribir reglas de NSG basadas en roles de carga de trabajo en lugar de direcciones IP. Etiquete sus servidores web como “WebServers” y sus servidores de bases de datos como “DbServers”, luego escriba reglas que hagan referencia a esos grupos. Cuando agrega un nuevo servidor de base de datos, agrega su NIC al ASG; las reglas se aplican automáticamente.

Cree ASG y utilícelos en una regla:

# Create ASGs
az network asg create --resource-group myResourceGroup --name WebServers --location eastus
az network asg create --resource-group myResourceGroup --name DbServers --location eastus

# Allow web tier to reach database tier on SQL port
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name mySubnet-nsg \
  --name AllowWebToDb \
  --priority 400 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs WebServers \
  --destination-asgs DbServers \
  --destination-port-ranges 1433

Después de crear los ASG, asigne la interfaz de red de su VM al grupo apropiado:

# Add a VM's NIC to the WebServers ASG
az network nic ip-config update \
  --resource-group myResourceGroup \
  --nic-name myWebVM-nic \
  --name ipconfig1 \
  --application-security-groups WebServers

¿Implementar un nuevo servidor web el próximo mes? Agregue su NIC al WebServers ASG y sus reglas existentes se aplican de inmediato. Sin modificaciones de reglas ni búsqueda de direcciones IP.

Los ASG tienen dos limitaciones que vale la pena conocer: son ámbito de una única red virtual (sin abarcar redes virtuales emparejadas) y cada suscripción admite hasta 3000 ASG.

Solucionar problemas con la verificación de flujo de IP

Configuraste tus reglas, pero el tráfico aún no fluye. Antes de comenzar a leer docenas de reglas manualmente, use Verificar flujo de IP en Azure Network Watcher. Prueba un paquete sintético con todas las reglas de NSG activas y le indica exactamente qué regla permite o deniega el tráfico.

az network watcher test-ip-flow \
  --direction Inbound \
  --protocol Tcp \
  --local 10.0.0.4:443 \
  --remote 203.0.113.50:60000 \
  --vm myVM \
  --nic myVM-nic \
  --resource-group myResourceGroup

La salida te dice Access: Allow o Access: Deny y nombra la regla específica responsable. Sin adivinanzas, sin seguimiento manual a través de cadenas de prioridad de reglas.

Para obtener una visión más amplia de todas las reglas efectivas aplicadas a una interfaz de red, utilice Diagnóstico NSG. Agrega reglas predeterminadas, reglas de subred y reglas de NIC en una sola vista, algo esencial cuando necesita detectar conflictos entre capas.

Información clave: Microsoft se retira Registros de flujo de NSG en septiembre de 2027. La creación de un nuevo registro de flujo de NSG se deshabilitó en junio de 2025. Migrar a Registros de flujo de VNet ahora cubren el tráfico a nivel de VNet independientemente de la conexión del NSG y se configuran una vez por VNet en lugar de por NSG.

Qué hacer a continuación

Ahora tiene un NSG conectado a una subred, reglas personalizadas que filtran el tráfico por puerto y protocolo, etiquetas de servicio que mantienen actualizados sus rangos de IP y ASG que agrupan sus cargas de trabajo por función. Eso cubre los fundamentos.

A partir de aquí, considere ajustar su configuración. Anular AllowInternetOutBound con reglas de denegación explícitas para subredes de producción. Configuración Registros de flujo de VNet y conectarlos a Análisis de tráfico para que pueda ver qué máquinas virtuales se comunican con destinos inesperados. Y si está ejecutando una arquitectura de N niveles, cree subredes y NSG separados por nivel para que sus servidores web no puedan llegar directamente a la subred de su base de datos.

Los GSN no reemplazarán un pleno Cortafuegos azul implementación para inspección profunda de paquetes o filtrado de capa de aplicación. Pero para el control del tráfico de Capa 4 en sus redes virtuales, son lo primero que debe configurar y, a menudo, lo único que necesita.