Firewall, WAF e WAAP costumam aparecer na mesma conversa, às vezes como se fossem a mesma coisa, e na Azion os três se encontram, mas cada um ocupa um lugar diferente na proteção de uma aplicação. O Firewall é onde ficam as regras, o Web Application Firewall (WAF) é um dos módulos que essas regras chamam, e WAAP é o nome que o mercado dá à combinação de proteções que, aqui, roda dentro de um mesmo firewall.
Na prática, o firewall que você associa a uma aplicação decide, regra a regra e na ordem que você definiu, quando chamar o WAF, quando consultar uma Network List, quando acionar o Bot Manager e quando aplicar rate limiting, e cada requisição fica registrada no Real-Time Events. Em um stack montado com ferramentas separadas, cada uma tem seu próprio motor de regras e seu próprio console, e explicar um bloqueio exige cruzar logs de fontes diferentes.
A seguir, veja como essa arquitetura funciona, da ordem das regras à investigação de um bloqueio.
Qual a diferença entre Firewall e WAF na Azion?
O Firewall é um recurso da plataforma, assim como Applications, Connectors e Workloads, e funciona como o objeto de política que você cria, nomeia e reutiliza. Neste texto, Firewall com maiúscula é o recurso da plataforma, e firewall com minúscula é cada firewall que você cria, que reúne as regras do Rules Engine e os módulos que essas regras podem chamar.
O WAF é um produto da Azion que roda como um desses módulos e inspeciona o conteúdo das requisições HTTP, na camada 7, que um firewall de rede tradicional, focado em endereço, porta e protocolo, não analisa. O conceito está detalhado em O que é um Web Application Firewall. Na Azion, o WAF pontua cada requisição em oito famílias de ameaça, entre elas SQL injection, XSS, directory traversal e remote file inclusion, mas não tem motor de regras próprio, e só age quando uma regra do firewall aplica o comportamento Set WAF.
Os outros módulos seguem a mesma lógica, e a tabela resume o que cada nome significa:
| Nome | O que é | Como entra no firewall |
|---|---|---|
| Firewall | Recurso da plataforma: o objeto de política, com regras e módulos | É associado a um workload no deployment |
| WAF | Produto que pontua requisições em oito famílias de ameaça | Módulo ativado no firewall e chamado por regras com Set WAF |
| Network Shield | Produto que compara o endereço do cliente com Network Lists | Módulo ativado por padrão, usado por regras com o critério de rede |
| Bot Manager | Produto que pontua requisições com regras de detecção de bots | Roda como função no firewall (módulo Functions), chamada por regras com Run Function |
| DDoS Protection | Proteção sempre ativa, sem configuração | Roda antes de qualquer regra e não pode ser desligado |
| Rate limiting, Deny, Drop | Comportamentos do Rules Engine | Ficam disponíveis em qualquer firewall, sem depender de módulo |
Rate limiting, Deny e Drop aparecem na tabela como comportamentos porque pertencem ao próprio Rules Engine, e é por isso que uma aplicação pode limitar as tentativas de login por IP antes mesmo de o WAF ser ativado.
WAAP (Web Application and API Protection) é o nome que o mercado dá à combinação de WAF, gerenciamento de bots, proteção de APIs e mitigação de DDoS, conceito que o vídeo WAAP sem mistério explica.
Na Azion, essa combinação corresponde a uma única política de firewall na frente da aplicação, em vez de um pacote de ferramentas com uma marca em comum, e é assim que a arquitetura de referência para proteger aplicações web a descreve, com o DDoS Protection agindo primeiro e, em seguida, uma regra de Network Lists, uma regra que chama o rule set de WAF e outra que chama o Bot Manager. Como essas etapas ficam no mesmo firewall, a ordem entre elas é uma decisão sua, e não uma consequência de qual ferramenta recebe o tráfego primeiro. O post Por que uma plataforma WAAP unificada reduz o risco do SOC mostra o efeito disso na operação.
Como uma requisição passa pelo Firewall da Azion?
O caminho começa no workload, porque é no deployment dele que você indica qual aplicação atende o domínio e, opcionalmente, qual firewall inspeciona esse tráfego. Um firewall que nenhum deployment referencia não inspeciona nada, e, como o vínculo fica no deployment, o mesmo firewall pode proteger vários workloads sem ser copiado.
Quando a requisição chega ao data center da Azion, o DDoS Protection age antes de qualquer regra, e só então o firewall avalia as regras na ordem configurada. Cada regra combina critérios com comportamentos como Deny, Drop, Set Rate Limit, Set Custom Response, Set WAF e Run Function. Os critérios disponíveis dependem dos módulos ativos, já que o caminho da requisição pode ser usado em qualquer firewall, enquanto o endereço de rede exige o Network Shield e o método e os cabeçalhos exigem o WAF, como lista a página do Rules Engine para Firewall.
O primeiro comportamento que encerra o processamento decide o destino da requisição, e só Set WAF e Run Function permitem que outro comportamento venha depois deles na mesma regra. Se nenhuma regra bloquear, a requisição segue para a aplicação e, de lá, para a origem, e se alguma bloquear, ela não chega à origem, como detalha a página sobre como o Firewall funciona.
A ordem também tem efeito na operação. Quando a regra de Network Lists vem primeiro, um endereço que você já decidiu recusar recebe a resposta dessa regra e nem chega a ser pontuado pelo WAF ou pelo Bot Manager, o que reduz o volume que esses módulos precisam processar e explica por que a arquitetura de referência coloca essa regra no topo.
Um rule set de WAF pode valer para várias aplicações?
Pode, e esse é um dos efeitos práticos de o WAF ser um módulo. O rule set de WAF guarda a sensibilidade por família de ameaça, em cinco níveis, e as exceções para falsos positivos, mas o modo de operação, Logging ou Blocking, pertence à regra que o chama. Assim, o mesmo rule set pode rodar em Logging em uma API recém-publicada e em Blocking no checkout, sem duplicar a configuração.
Na API v4, o comportamento de cada uma dessas regras fica assim, com o mesmo waf_id e modos diferentes:
As Network Lists funcionam do mesmo jeito, porque uma lista pode alimentar várias regras em vários firewalls, e uma mudança na lista chega a todas elas sem que alguém precise editar regra por regra. Para os times de infraestrutura e de segurança, isso significa menos objetos para manter e uma política que não precisa ser copiada.
Quem prefere manter a política junto do código pode declarar o firewall, o rule set e as regras em arquivo, aprovar a mudança em code review e aplicar no deploy pela CLI, pelo Terraform ou pela API. O post Do código aprovado à proteção em produção mostra esse fluxo em detalhe.
O mesmo modelo aparece no servidor MCP secure da Azion, que agentes de codificação como o Claude Code usam para operar a conta. As ferramentas dele cobrem o firewall, as regras, as function instances, os rule sets de WAF, as exceções e as Network Lists, e cada escrita aceita dry_run, que devolve a requisição que seria enviada à API sem enviá-la, para que o time revise antes de aplicar. O post O agente que escreve seu código também sugere sua política de segurança mostra um agente propondo essas mudanças.
Como descobrir qual regra bloqueou uma requisição?
Para descobrir qual regra bloqueou uma requisição, comece pela resposta de bloqueio. A página 400 que o cliente recebe quando o WAF bloqueia não diz qual regra disparou, mas traz o cabeçalho x-azion-request-id, e com ele você encontra o evento da requisição no Real-Time Events, na fonte de dados HTTP Requests.
Como o WAF, o Network Shield e o rate limiting rodam no mesmo firewall, o evento de HTTP Requests concentra o que eles fizeram com a requisição, e é ali que a investigação começa. O que uma função como o Bot Manager executou aparece na fonte de dados Functions. O campo Waf Block indica se o WAF bloqueou, o Waf Match lista a infração junto com o trecho da requisição que a disparou e o Waf Score mostra a pontuação por família de ameaça.
Para bloqueios que não vieram do WAF, o campo Stack Trace lista as regras que a requisição executou. Somada ao status da resposta, que é 400 quando o WAF bloqueia, 403 no Deny, 429 no rate limit e nenhuma resposta no Drop, essa lista mostra se o bloqueio veio do WAF, de uma Network List, de um rate limit ou de uma função. O post WAF, Bot e DDoS: segurança com control plane único mostra como a demora em cruzar consoles de ferramentas separadas abre espaço para ataques coordenados.
Com essa informação, o ajuste também acontece no mesmo lugar, seja criando uma exceção no rule set para a regra que gerou o falso positivo, seja ajustando a sensibilidade da família de ameaça, seja mantendo o WAF em Logging nos caminhos ainda em observação enquanto os demais seguem em Blocking. O guia Encontre o score de uma requisição bloqueada mostra o passo a passo.
Os eventos ficam disponíveis por 7 dias, e o Data Stream envia os eventos de Applications e de WAF para SIEMs como Splunk e IBM QRadar, para ferramentas de observabilidade como o Datadog e para data warehouses como o BigQuery.
Plataforma unificada começa na arquitetura do produto
Falar em plataforma unificada é fácil quando os produtos dividem uma marca, um contrato ou um painel, mas a diferença real aparece no caminho que cada requisição percorre. Na Azion, o WAF, o Network Shield, o Bot Manager e o rate limiting funcionam como etapas de um mesmo firewall, avaliadas na ordem que você define e registradas no Real-Time Events, sem integração para construir depois.
Isso muda o trabalho tanto do time de segurança, que aprova uma política uma vez e a vê valer em todas as aplicações que referenciam aquele firewall, inclusive as que ainda vão subir, quanto de quem opera a infraestrutura e precisa explicar um bloqueio sem abrir três consoles diferentes.
Quando a proteção nasce como uma única política, a pergunta deixa de ser qual ferramenta bloqueou e passa a ser se a regra fez o que você esperava.
Quer ver como isso funciona nas suas aplicações? Fale com um especialista da Azion ou crie uma conta gratuita e ative o WAF em modo Logging para acompanhar, no Real-Time Events, o que ele bloquearia no seu tráfego real.
