Blog Azure Azure
Azure

Azure Firewall: Características según SKU y ejemplos prácticos

11 min lectura
Comparativa de características de Azure Firewall por SKU

Introducción

Azure Firewall es un servicio de seguridad de red administrado para proteger recursos desplegados en redes virtuales de Azure. Proporciona filtrado con estado, reglas de red y aplicación, NAT de entrada y salida, alta disponibilidad integrada y capacidades adicionales según el SKU elegido.

Actualmente, Azure Firewall se organiza en tres SKUs principales:

  • Basic: orientado a entornos con necesidades de seguridad y rendimiento más acotadas.
  • Standard: opción general para filtrado de red, aplicación, amenazas conocidas y escenarios corporativos habituales.
  • Premium: añade capacidades avanzadas como inspección TLS, filtrado de URL e IDPS administrado.

La elección del SKU no debería basarse solo en coste, sino en el nivel de inspección requerido, el rendimiento esperado, el modelo operativo y los riesgos que se quieren mitigar.

Comparación rápida de SKUs

La siguiente tabla resume algunas diferencias relevantes entre Azure Firewall Basic, Standard y Premium.

Capacidad Basic Standard Premium
Firewall con estado basado en reglas de red Sí Sí Sí
SNAT y DNAT Sí Sí Sí
Alta disponibilidad integrada Sí Sí Sí
Zonas de disponibilidad Sí Sí Sí
Filtrado de aplicación por FQDN Sí Sí Sí
Filtrado de FQDN a nivel de red No Sí Sí
Filtrado por inteligencia de amenazas Solo alerta Alerta y denegación Alerta y denegación
Categorías web No Sí Sí
Filtrado de URL con ruta completa No No Sí
Inspección TLS saliente No No Sí
IDPS administrado No No Sí
DNS proxy y DNS personalizado No Sí Sí
Escalabilidad de rendimiento Hasta 250 Mbps Hasta 30 Gbps Hasta 30 Gbps

La disponibilidad exacta de capacidades puede evolucionar. Antes de diseñar una arquitectura definitiva, valida siempre la matriz oficial de características del SKU que vayas a desplegar.

Basic, Standard y Premium: cuándo usar cada uno

Azure Firewall Basic

Azure Firewall Basic encaja en escenarios donde se necesita una puerta de salida/entrada controlada, pero sin requerimientos avanzados de inspección.

Casos típicos:

  • Entornos pequeños o de laboratorio.
  • Segmentos de red con bajo volumen de tráfico.
  • Cargas que necesitan reglas básicas de red, aplicación y NAT.
  • Escenarios donde basta con recibir alertas de inteligencia de amenazas, sin bloqueo automático.

Limitaciones importantes:

  • No ofrece filtrado FQDN a nivel de red para todos los puertos y protocolos.
  • No incluye inspección TLS.
  • No incluye IDPS.
  • No incluye DNS proxy ni DNS personalizado según la matriz de características.
  • Tiene un límite de rendimiento menor que Standard y Premium.

Azure Firewall Standard

Azure Firewall Standard suele ser el punto de partida para arquitecturas empresariales que necesitan control centralizado de tráfico norte-sur y este-oeste, sin llegar a inspección TLS avanzada.

Casos típicos:

  • Hub-and-spoke con salida centralizada a Internet.
  • Control de tráfico entre redes virtuales.
  • DNAT para publicar servicios internos.
  • Reglas de aplicación por FQDN.
  • Filtrado por inteligencia de amenazas en modo alerta y denegación.
  • Uso de DNS proxy y DNS personalizado.

Standard es adecuado cuando necesitas un firewall administrado robusto, pero no necesitas inspeccionar el contenido cifrado de conexiones TLS ni aplicar IDPS administrado.

Azure Firewall Premium

Azure Firewall Premium está orientado a entornos con mayores requisitos de seguridad e inspección.

Añade sobre Standard capacidades como:

  • Inspección TLS saliente.
  • Filtrado de URL con ruta completa.
  • IDPS administrado.
  • Capacidades avanzadas de inspección para tráfico cifrado, cuando se configura correctamente.

Casos típicos:

  • Entornos regulados.
  • Arquitecturas con controles de seguridad de salida más estrictos.
  • Necesidad de inspeccionar tráfico HTTPS saliente.
  • Requisitos de detección y prevención de intrusiones gestionados.
  • Políticas más granulares basadas en URL completa, no solo en dominio.

Premium no elimina la necesidad de otros controles. Para publicación de aplicaciones web, especialmente con requisitos de WAF o terminación TLS de entrada, suele ser habitual combinar Azure Firewall con servicios como Azure Application Gateway WAF, según el patrón de arquitectura.

FQDN tags, FQDNs y service tags: diferencias importantes

Uno de los errores habituales al diseñar reglas en Azure Firewall es mezclar tres conceptos distintos:

  • FQDN: nombre DNS explícito, por ejemplo api.contoso.com.
  • FQDN tag: etiqueta mantenida por Microsoft que agrupa dominios necesarios para determinados servicios conocidos.
  • Service tag: etiqueta que representa rangos de IP de un servicio de Azure, usada en reglas de red.

No son intercambiables.

Por ejemplo, si quieres permitir tráfico HTTPS hacia un dominio concreto, normalmente usarás una regla de aplicación con FQDN. Si quieres permitir tráfico hacia un servicio de Azure representado por rangos de IP publicados por Microsoft, puede tener más sentido una regla de red con service tag. Si el servicio está soportado mediante FQDN tag, puedes simplificar la regla usando esa etiqueta en lugar de mantener manualmente una lista de dominios.

Ejemplo práctico: permitir actualizaciones de Windows

Escenario: varias máquinas virtuales en una subred necesitan acceder a Windows Update, pero no quieres permitir salida abierta a Internet.

Diseño recomendado:

  1. Crear una colección de reglas de aplicación.
  2. Definir como origen la subred o grupo de IPs de las máquinas.
  3. Permitir los protocolos necesarios, normalmente HTTP/HTTPS según el caso.
  4. Usar el FQDN tag correspondiente si está disponible para el servicio.
  5. Registrar los logs en Log Analytics para validar que no faltan destinos.

Ventajas:

  • Evitas mantener manualmente una lista extensa de dominios.
  • Reduces exposición frente a una regla de salida genérica.
  • Centralizas el control en la política del firewall.

Precauciones:

  • No todos los servicios tienen FQDN tag.
  • Un FQDN tag no equivale a un service tag.
  • Debes validar el comportamiento real con logs antes de cerrar reglas existentes.

SNAT: traducción de salida

SNAT, o Source Network Address Translation, permite que los recursos de una red privada salgan hacia destinos externos usando las IPs públicas asociadas a Azure Firewall.

En términos prácticos:

  • Una máquina virtual con IP privada inicia conexión hacia Internet.
  • El tráfico se enruta a Azure Firewall.
  • Azure Firewall aplica las reglas configuradas.
  • Si el tráfico está permitido, se traduce la IP de origen a una IP pública del firewall.
  • La respuesta vuelve al firewall, que mantiene el estado de la conexión y la entrega al origen interno.

Ejemplo práctico: salida centralizada a Internet

Escenario: tienes una arquitectura hub-and-spoke y quieres que todas las subredes de aplicación salgan a Internet a través del firewall.

Diseño recomendado:

  1. Desplegar Azure Firewall en la red hub.
  2. Asociar una o varias IPs públicas al firewall.
  3. Configurar rutas definidas por el usuario en las subredes spoke para enviar el tráfico 0.0.0.0/0 al firewall.
  4. Crear reglas de aplicación o red con el mínimo acceso necesario.
  5. Activar diagnóstico y enviar logs a Log Analytics.
  6. Monitorizar métricas de uso, tráfico permitido, tráfico denegado y consumo de puertos SNAT.

Aspectos a vigilar:

  • El agotamiento de puertos SNAT puede aparecer en escenarios con muchas conexiones simultáneas hacia los mismos destinos.
  • Añadir más IPs públicas o usar prefijos de IP pública puede ayudar a aumentar la capacidad disponible de SNAT.
  • No conviene resolver problemas de conectividad abriendo salida completa a Internet; es preferible revisar logs y ajustar reglas de forma controlada.

DNAT: publicación controlada de servicios internos

DNAT, o Destination Network Address Translation, permite publicar un servicio interno usando una IP pública del firewall y traducir el tráfico entrante hacia una IP privada.

Es útil cuando necesitas exponer un servicio concreto sin asignar IP pública directamente a la máquina o appliance interno.

Ejemplo práctico: publicar un servicio HTTP interno

Escenario:

  • IP pública del firewall: 203.0.113.10
  • Servidor interno: 10.10.2.4
  • Puerto público: 80
  • Puerto interno: 8080

Diseño lógico de la regla DNAT:

Campo Valor de ejemplo
Origen IPs públicas autorizadas o Internet si debe ser público
Destino IP pública del firewall
Puerto destino 80
Protocolo TCP
Dirección traducida 10.10.2.4
Puerto traducido 8080

Buenas prácticas:

  • Limita los orígenes siempre que sea posible.
  • Evita publicar servicios administrativos directamente a Internet.
  • Complementa la regla DNAT con NSG y controles en el sistema destino.
  • Usa Application Gateway WAF delante de aplicaciones web cuando necesites protección de capa 7.
  • Revisa logs de NAT y tráfico denegado para validar que solo se expone lo previsto.

DNAT está disponible en los tres SKUs, pero las capacidades avanzadas de inspección no son iguales. Si necesitas inspección profunda o controles HTTP/HTTPS de aplicación, revisa si el patrón adecuado requiere Premium, Application Gateway WAF u otro componente adicional.

Inspección TLS en Premium

La inspección TLS es una de las diferencias más relevantes de Azure Firewall Premium.

Sin inspección TLS, un firewall puede tomar decisiones basadas en metadatos como IP, puerto, protocolo, SNI o FQDN, pero no puede inspeccionar el contenido cifrado de la sesión HTTPS. Con inspección TLS configurada, Azure Firewall Premium puede terminar y volver a establecer sesiones TLS salientes para aplicar controles más profundos.

Cuándo tiene sentido

  • Necesitas aplicar filtrado de URL con mayor granularidad.
  • Quieres detectar amenazas dentro de tráfico HTTPS saliente.
  • Tienes requisitos de auditoría o cumplimiento que exigen inspección de tráfico cifrado.
  • Puedes gestionar correctamente certificados, confianza de clientes y excepciones.

Precauciones

  • Requiere una configuración cuidadosa de certificados y confianza en los clientes.
  • Puede afectar a aplicaciones con certificate pinning.
  • Debe evaluarse el impacto operativo y de privacidad.
  • No debería activarse de forma indiscriminada sin pruebas previas.

IDPS en Premium

Azure Firewall Premium incluye IDPS administrado, que permite detectar y prevenir patrones asociados a actividad maliciosa.

Puede ser útil para:

  • Detectar explotación de vulnerabilidades conocidas.
  • Identificar patrones de comando y control.
  • Reforzar controles de salida desde cargas internas.
  • Añadir una capa gestionada de prevención sobre reglas de firewall tradicionales.

No obstante, IDPS no sustituye a:

  • Gestión de vulnerabilidades.
  • EDR en servidores y endpoints.
  • Buen diseño de identidad y segmentación.
  • Monitorización centralizada con SIEM.
  • Revisión continua de reglas y excepciones.

Recomendaciones de diseño

1. Elige el SKU por requisito, no por defecto

Usa Basic para escenarios pequeños o de bajo rendimiento. Usa Standard como base para arquitecturas empresariales comunes. Usa Premium cuando realmente necesites inspección TLS, URL filtering avanzado o IDPS.

2. Centraliza la política

Siempre que sea posible, gestiona reglas mediante Azure Firewall Policy. Facilita reutilización, gobierno y consistencia entre entornos.

3. Diseña reglas con mínimo privilegio

Evita reglas amplias como Any a Internet salvo excepciones justificadas. Prioriza:

  • FQDNs concretos.
  • FQDN tags cuando apliquen.
  • Service tags cuando el criterio correcto sea rango de IP de servicio.
  • Orígenes limitados por subred o grupo de IPs.
  • Puertos estrictamente necesarios.

4. Activa observabilidad desde el inicio

Un firewall sin logs útiles acaba convirtiéndose en una caja negra. Envía diagnósticos a Log Analytics o a la plataforma de monitorización corporativa y revisa:

  • Tráfico permitido.
  • Tráfico denegado.
  • Reglas más utilizadas.
  • Destinos frecuentes.
  • Eventos de inteligencia de amenazas.
  • Métricas de rendimiento y SNAT.

5. Prueba antes de cerrar tráfico

En migraciones, empieza observando los flujos existentes y construye reglas de forma iterativa. Cerrar tráfico sin visibilidad suficiente suele provocar incidencias difíciles de diagnosticar.

Conclusión

Azure Firewall ofrece una base sólida para proteger tráfico en Azure, pero sus capacidades dependen de forma significativa del SKU elegido.

  • Basic cubre escenarios sencillos y de menor rendimiento.
  • Standard proporciona el conjunto más habitual para arquitecturas corporativas: filtrado, NAT, DNS proxy, categorías web e inteligencia de amenazas con bloqueo.
  • Premium añade inspección TLS, filtrado de URL avanzado e IDPS administrado para entornos con requisitos de seguridad más exigentes.

Para una arquitectura bien diseñada, combina la elección correcta de SKU con reglas de mínimo privilegio, rutas bien definidas, observabilidad continua y pruebas controladas antes de aplicar restricciones más estrictas.

Fuente