Firewall, WAF y WAAP suelen aparecer en la misma conversación, a veces como si fueran lo mismo, y en Azion los tres se encuentran, pero cada uno ocupa un lugar distinto en la protección de una aplicación. El Firewall es donde viven las reglas, el Web Application Firewall (WAF) es uno de los módulos que esas reglas llaman, y WAAP es el nombre que el mercado le da a la combinación de protecciones que, aquí, se ejecuta dentro de un mismo firewall.
En la práctica, el firewall que asocias a una aplicación decide, regla por regla y en el orden que definiste, cuándo llamar al WAF, cuándo consultar una Network List, cuándo activar el Bot Manager y cuándo aplicar rate limiting, y cada solicitud queda registrada en Real-Time Events. En un stack armado con herramientas separadas, cada una tiene su propio motor de reglas y su propia consola, y explicar un bloqueo exige cruzar logs de fuentes diferentes.
A continuación, mira cómo funciona esta arquitectura, desde el orden de las reglas hasta la investigación de un bloqueo.
¿Cuál es la diferencia entre Firewall y WAF en Azion?
El Firewall (documentación en inglés) es un recurso de la plataforma, como Applications, Connectors y Workloads, y funciona como el objeto de política que creas, nombras y reutilizas. En este texto, Firewall con mayúscula es el recurso de la plataforma, y firewall con minúscula es cada firewall que creas, que reúne las reglas del Rules Engine y los módulos que esas reglas pueden llamar.
El WAF es un producto de Azion que se ejecuta como uno de esos módulos e inspecciona el contenido de las solicitudes HTTP, en la capa 7, algo que un firewall de red tradicional, enfocado en dirección, puerto y protocolo, no analiza. El concepto está explicado en detalle en ¿Qué es un Web Application Firewall (WAF)?. En Azion, el WAF puntúa cada solicitud en ocho familias de amenazas, entre ellas SQL injection, XSS, directory traversal y remote file inclusion, pero no tiene motor de reglas propio y solo actúa cuando una regla del firewall aplica el comportamiento Set WAF.
Los demás módulos siguen la misma lógica, y la tabla resume qué significa cada nombre:
| Nombre | Qué es | Cómo entra en el firewall |
|---|---|---|
| Firewall | Recurso de la plataforma: el objeto de política, con reglas y módulos | Se asocia a un workload en el deployment |
| WAF | Producto que puntúa solicitudes en ocho familias de amenazas | Módulo activado en el firewall y llamado por reglas con Set WAF |
| Network Shield | Producto que compara la dirección del cliente con Network Lists | Módulo activado por defecto, usado por reglas con el criterio de red |
| Bot Manager | Producto que puntúa solicitudes con reglas de detección de bots | Se ejecuta como función en el firewall (módulo Functions), llamada por reglas con Run Function |
| DDoS Protection | Protección siempre activa, sin configuración | Se ejecuta antes de cualquier regla y no se puede desactivar |
| Rate limiting, Deny, Drop | Comportamientos del Rules Engine | Disponibles en cualquier firewall, sin depender de ningún módulo |
Rate limiting, Deny y Drop aparecen en la tabla como comportamientos porque pertenecen al propio Rules Engine, y por eso una aplicación puede limitar los intentos de inicio de sesión por IP incluso antes de activar el WAF.
WAAP (Web Application and API Protection) es el nombre que el mercado le da a la combinación de WAF, gestión de bots, protección de API y mitigación de DDoS, un concepto que explica el video WAAP sem mistério (en portugués).
En Azion, esa combinación corresponde a una única política de firewall delante de la aplicación, en lugar de un paquete de herramientas con una marca en común, y así la describe la arquitectura de referencia para proteger aplicaciones web, con DDoS Protection actuando primero y, después, una regla de Network Lists, una regla que llama al rule set del WAF y otra que llama al Bot Manager. Como estas etapas están en el mismo firewall, el orden entre ellas es una decisión tuya, y no una consecuencia de qué herramienta recibe el tráfico primero. El post Por qué una plataforma WAAP unificada reduce el riesgo del SOC muestra el efecto de esto en la operación.
¿Cómo pasa una solicitud por el Firewall de Azion?
El camino empieza en el workload, porque es en su deployment donde indicas qué aplicación atiende el dominio y, opcionalmente, qué firewall inspecciona ese tráfico. Un firewall que ningún deployment referencia no inspecciona nada, y, como el vínculo está en el deployment, el mismo firewall puede proteger varios workloads sin copiarse.
Cuando la solicitud llega al data center de Azion, DDoS Protection actúa antes de cualquier regla, y solo entonces el firewall evalúa las reglas en el orden configurado. Cada regla combina criterios con comportamientos como Deny, Drop, Set Rate Limit, Set Custom Response, Set WAF y Run Function. Los criterios disponibles dependen de los módulos activos, ya que la ruta de la solicitud se puede usar en cualquier firewall, mientras que la dirección de red exige Network Shield y el método y los encabezados exigen el WAF, como enumera la página del Rules Engine del Firewall.
El primer comportamiento que termina el procesamiento decide el destino de la solicitud, y solo Set WAF y Run Function permiten que otro comportamiento venga después en la misma regla. Si ninguna regla bloquea, la solicitud sigue hacia la aplicación y, desde ahí, hacia el origen, y si alguna bloquea, no llega al origen, como detalla la página sobre cómo funciona el Firewall.
El orden también tiene efecto en la operación. Cuando la regla de Network Lists va primero, una dirección que ya decidiste rechazar recibe la respuesta de esa regla y ni siquiera llega a ser puntuada por el WAF ni por el Bot Manager, lo que reduce el volumen que esos módulos tienen que procesar y explica por qué la arquitectura de referencia pone esa regla al principio.
¿Un rule set de WAF puede servir para varias aplicaciones?
Sí, y ese es uno de los efectos prácticos de que el WAF sea un módulo. El rule set del WAF guarda la sensibilidad por familia de amenazas, en cinco niveles, y las excepciones para falsos positivos, pero el modo de operación, Logging o Blocking, pertenece a la regla que lo llama. Así, el mismo rule set puede ejecutarse en Logging en una API recién publicada y en Blocking en el checkout, sin duplicar la configuración.
En la API v4, el comportamiento de cada una de esas reglas queda así, con el mismo waf_id y modos diferentes:
Las Network Lists funcionan igual, porque una lista puede alimentar varias reglas en varios firewalls, y un cambio en la lista llega a todas ellas sin que nadie tenga que editar regla por regla. Para los equipos de infraestructura y de seguridad, eso significa menos objetos que mantener y una política que no necesita copiarse.
Si prefieres mantener la política junto al código, puedes declarar el firewall, el rule set y las reglas en un archivo, aprobar el cambio en code review y aplicarlo en el deploy con la CLI, Terraform o la API. El post Cómo integrar la seguridad de aplicaciones al despliegue muestra este flujo en detalle.
El mismo modelo aparece en el servidor MCP secure de Azion, que agentes de programación como Claude Code usan para operar la cuenta. Sus herramientas cubren el firewall, las reglas, las function instances, los rule sets del WAF, las excepciones y las Network Lists, y cada escritura acepta dry_run, que devuelve la solicitud que se enviaría a la API sin enviarla, para que el equipo la revise antes de aplicarla. El post El agente que escribe tu código también sugiere tu política de seguridad muestra a un agente proponiendo estos cambios.
¿Cómo descubrir qué regla bloqueó una solicitud?
Para descubrir qué regla bloqueó una solicitud, empieza por la respuesta de bloqueo. La página 400 que recibe el cliente cuando el WAF bloquea no dice qué regla se activó, pero trae el encabezado x-azion-request-id, y con él encuentras el evento de la solicitud en Real-Time Events, en la fuente de datos HTTP Requests.
Como el WAF, Network Shield y el rate limiting se ejecutan en el mismo firewall, el evento de HTTP Requests concentra lo que hicieron con la solicitud, y ahí empieza la investigación. Lo que ejecutó una función como el Bot Manager aparece en la fuente de datos Functions. El campo Waf Block indica si el WAF bloqueó, Waf Match enumera la infracción junto con el fragmento de la solicitud que la provocó y Waf Score muestra la puntuación por familia de amenazas.
Para bloqueos que no vinieron del WAF, el campo Stack Trace lista las reglas que ejecutó la solicitud. Junto con el estado de la respuesta, que es 400 cuando bloquea el WAF, 403 en Deny, 429 en rate limiting y ninguna respuesta en Drop, esa lista muestra si el bloqueo vino del WAF, de una Network List, de un rate limit o de una función. El post WAF, Bots y DDoS: seguridad con un control plane muestra cómo la demora en cruzar consolas de herramientas separadas abre espacio para ataques coordinados.
Con esa información, el ajuste también ocurre en el mismo lugar, ya sea creando una excepción en el rule set para la regla que generó el falso positivo, ajustando la sensibilidad de la familia de amenazas o manteniendo el WAF en Logging en las rutas que todavía están en observación mientras las demás siguen en Blocking. La guía Find the WAF score of a blocked request (en inglés) muestra el paso a paso.
Los eventos están disponibles durante 7 días, y Data Stream envía los eventos de Applications y del WAF a SIEM como Splunk e IBM QRadar, a herramientas de observabilidad como Datadog y a data warehouses como BigQuery.
Una plataforma unificada empieza en la arquitectura del producto
Hablar de plataforma unificada es fácil cuando los productos comparten una marca, un contrato o un panel, pero la diferencia real aparece en el camino que recorre cada solicitud. En Azion, el WAF, Network Shield, el Bot Manager y el rate limiting funcionan como etapas de un mismo firewall, evaluadas en el orden que defines y registradas en Real-Time Events, sin integraciones que construir después.
Eso cambia el trabajo tanto del equipo de seguridad, que aprueba una política una vez y la ve aplicarse en todas las aplicaciones que referencian ese firewall, incluidas las que todavía van a salir, como de quien opera la infraestructura y necesita explicar un bloqueo sin abrir tres consolas diferentes.
Cuando la protección nace como una única política, la pregunta deja de ser qué herramienta bloqueó y pasa a ser si la regla hizo lo que esperabas.
¿Quieres ver cómo funciona esto en tus aplicaciones? Habla con un especialista de Azion o crea una cuenta gratis y activa el WAF en modo Logging para ver, en Real-Time Events, lo que bloquearía en tu tráfico real.
