Quando as pessoas falam sobre firewalls de aplicação, elas tendem a agrupar várias coisas diferentes sob um mesmo guarda-chuva. Mas nem todos os firewalls são iguais, e entender as diferenças entre eles é importante, especialmente se você está tentando descobrir qual proteção seu aplicativo realmente precisa.
Então, vamos detalhar. Existem três camadas principais de segurança de aplicação que você deve conhecer: WAFs, no aplicativo e no kernel. RASP e alguns ADRs são no aplicativo, enquanto ADRs de nível inferior baseados em eBPF são no kernel. Todos eles têm o mesmo objetivo amplo de impedir que coisas ruins aconteçam ao seu aplicativo, mas a forma como eles fazem isso é muito diferente. Em resumo, o WAF vê a requisição, o in-app vê o código e o in-kernel vê o sistema operacional.
Qual você precisa? Bem, se você busca a postura de segurança mais robusta possível, provavelmente precisará de mais de um. Neste artigo, explicaremos o que são WAFs, RASP, ADR e eBPF, no que cada um é mais eficaz, e o ajudaremos a decidir quais deles você precisa.
WAF VS RASP VS ASP: Como funcionam as três camadas de segurança de aplicação?
Ferramentas de segurança de aplicação operam em três níveis diferentes, e cada uma detecta coisas que as outras não conseguem.
WAF: segurança de borda
WAFs ficam completamente fora do seu aplicativo, inspecionando o tráfego HTTP de entrada antes mesmo que ele chegue ao seu aplicativo. Sem contexto do aplicativo, mas ótimo para ameaças de alto volume.
Segurança de runtime in-app: dentro do aplicativo
Ferramentas de segurança in-app se conectam diretamente ao seu aplicativo. Elas se conectam à execução do seu código, rastreiam como a entrada do usuário flui pelo seu aplicativo e podem bloquear ataques no ponto exato em que se tornam perigosos, antes que um payload malicioso atinja seu driver de banco de dados ou gere um shell. Por ter um contexto completo do aplicativo, é preciso. Ferramentas RASP, uma subcategoria de ADR, se enquadram nesta categoria.
Segurança de runtime no kernel: abaixo do aplicativo
Ferramentas de segurança de runtime no kernel ficam completamente abaixo do seu aplicativo, no nível do sistema operacional (OS). Em vez de se conectar ao código do aplicativo, elas monitoram cada syscall feita por cada processo no host. Elas não têm ideia do que a lógica do seu aplicativo está fazendo, mas veem tudo no nível do OS, incluindo o que acontece depois que um invasor já conseguiu entrar. Ferramentas ADR baseadas em eBPF se enquadram nesta categoria.
Primeiro, analisaremos o WAF, depois o in-app e o in-kernel pela perspectiva de RASP e ADR.
O que é WAF?
Um WAF (Web Application Firewall) fica fora do seu aplicativo, na borda. Antes mesmo que uma requisição chegue ao seu aplicativo, o WAF a intercepta e a verifica contra uma lista de padrões de ataque conhecidos, como strings de SQL injection, cabeçalhos maliciosos ou URLs suspeitas. Se algo corresponde a um padrão, é bloqueado.
Onde os WAFs são realmente insubstituíveis é em ataques volumétricos, como tráfego DDoS, inundações de bots e scrapers. WAFs são construídos para coisas de alto volume e força bruta. Cloudflare, por exemplo, é extremamente eficaz em absorver ataques em larga escala antes que eles interajam com sua infraestrutura. Eles também são fáceis de implantar. Principalmente uma mudança de DNS ou proxy, nenhum código para escrever, nada para instalar dentro do seu aplicativo. WAFs também são muito configuráveis com regras personalizadas, listas de permissão e ajuste de regras, e você também pode decidir se bloqueia algo suspeito ou apenas o detecta.
O problema é que um WAF não tem ideia do que acontece uma vez que uma requisição passa pela porta. Ele pode identificar um payload com aparência suspeita, mas não pode dizer se esse payload realmente fará algo perigoso, porque não tem ideia do que seu aplicativo realmente fará com uma requisição. Ele vê o tráfego chegando, faz a correspondência de padrões com o que foi configurado para parar e decide se o bloqueia.
Como resultado, falsos positivos são um problema real, e ele pode facilmente bloquear requisições em excesso. Um usuário pode pesquisar algo que se pareça com SQL e ser bloqueado, enquanto um invasor inteligente codifica seu payload de forma diferente e consegue passar. E se um WAF quer parar um usuário malicioso, ele bloqueia o IP dele. Então um invasor pode simplesmente usar uma VPN para contorná-lo. Mas se você tentar bloquear todo o tráfego da VPN, você também bloqueará usuários reais.
Como resultado, o ajuste de WAF é um processo contínuo, onde você aperta as regras, monitora falsos positivos e as afrouxa quando necessário. É uma das razões pelas quais os WAFs podem ser de alta manutenção em comparação com o RASP, que precisa de muito menos ajuste contínuo porque tem o contexto do aplicativo para tomar decisões melhores sem intervenção manual.
Exemplos: Cloudflare, AWS WAF, Imperva
Código aberto: ModSecurity (via OWASP)
O que é RASP?
RASP (Runtime Application Self-Protection) e ADR in-app são seguranças em tempo de execução que residem dentro da sua aplicação e a monitoram internamente enquanto ela é executada, em vez de ficar fora da sua aplicação inspecionando o tráfego de entrada como um WAP.
Para entender a importância disso, é preciso conhecer os sinks. Um sink é uma função — no seu código, em uma biblioteca ou em um módulo integrado — onde a entrada do usuário deixa de ser dado e é executada como algo significativo. Podemos usar uma injeção SQL como exemplo. Um atacante insere código malicioso em um campo de formulário, que flui pela sua aplicação, atinge o driver do seu banco de dados (algum db.query()), e nesse ponto, deixa de ser texto e se torna um comando. Essa função de consulta é o sink. O que as ferramentas de segurança in-app como o RASP fazem é se conectar a esses sinks e observar a entrada se movendo pela aplicação, rastreando-a até a função perigosa.
Como essas ferramentas in-app estão sendo executadas, bem, dentro da sua aplicação, elas sabem qual é a entrada, de onde ela veio e para onde está indo. Em vez de adivinhar se ' OR 1=1-- é um ataque ou uma string de busca legítima, uma ferramenta in-app sabe que esta string específica veio de req.body.user, foi concatenada sem sanitização, e está prestes a atingir uma pg.query() chamada. Bloqueie!
As taxas de falsos positivos são muito menores do que as de WAF e ADR baseado em eBPF porque não se trata apenas de correspondência cega de padrões. Ele pode bloquear um ID de usuário em vez de apenas um IP, assim, um atacante não pode simplesmente usar uma VPN. E como ele rastreia o fluxo de dados em vez de corresponder a assinaturas conhecidas, ele pode detectar novos payloads de ataque que ninguém viu antes. Cobertura robusta de zero-day para ataques de classe de injeção!
RASP e ADRs in-app também cobrem dependências de terceiros. Você pode sanitizar seu próprio código perfeitamente, mas se uma biblioteca que você está usando tiver uma vulnerabilidade, isso está fora do seu controle (se o seu scanner SCA também não a detectou). O RASP opera no nível do sink, independentemente da origem do código.
A principal limitação da segurança in-app é que, se um atacante ignorar completamente o runtime, através de um addon nativo ou uma syscall direta, os hooks nunca são acionados. E uma vez que um shell é gerado, o RASP vê a chamada inicial, mas não o que acontece dentro desse shell posteriormente. É aí que entra a terceira camada.
Exemplos: Aikido Zen (open source e versão paga)
O que é ADR?
ADR (Application Detection and Response) é a categoria moderna mais ampla na qual o RASP se enquadra. Todo RASP é ADR, mas nem todo ADR é RASP. O termo ADR abrange qualquer ferramenta que monitora e responde a ataques em tempo de execução, seja de dentro da sua aplicação ou completamente abaixo dela.
Na prática, as ferramentas ADR são divididas em dois tipos. O ADR in-app (o que o RASP sempre foi) reside diretamente na sua aplicação e possui contexto completo em nível de código. Tudo o que foi abordado na seção RASP acima sobre segurança in-app se aplica aqui. O ADR também implica um escopo mais amplo que o RASP, enquanto o RASP é principalmente uma ferramenta de bloqueio, o ADR abrange também capacidades de detecção, visibilidade e resposta a incidentes. Nem toda ferramenta ADR faz tudo isso, mas é a direção para onde a categoria está caminhando.
O outro tipo de ADR, o ADR in-kernel, ou ADR baseado em eBPF, adota uma abordagem diferente para proteger aplicações. Em vez de se conectar à sua aplicação, ele reside no nível do kernel Linux e observa cada syscall feita por cada processo no host. Ele não sabe nada sobre a lógica da sua aplicação, mas vê tudo no nível do sistema operacional.
Uma vez que um atacante tenha gerado um shell, o ADR in-kernel fornece o próximo nível de visibilidade pós-exploração que o ADR in-app não consegue ver. O ADR in-kernel vê cada comando que é executado dentro desse shell, como leituras de arquivos, chamadas de rede e movimento lateral. Se um atacante ignorar completamente o runtime, o ADR ainda vê o execve independentemente de como foi acionado. Na prática, o cenário mais comum para aplicações Node.js é um addon nativo malicioso que se infiltra através de um ataque de cadeia de suprimentos (uma dependência comprometida que inclui código nativo que seu runtime não inspeciona).
eBPF (Extended Berkeley Packet Filter) é a tecnologia de kernel subjacente que impulsiona as ferramentas ADR in-kernel. O eBPF permite anexar um programa de monitoramento seguro ao kernel Linux que pode observar eventos específicos acontecendo no nível do sistema operacional, sem tocar no próprio kernel. Normalmente, se você quiser adicionar monitoramento ou lógica personalizada no nível do kernel, você teria que modificar diretamente o código-fonte do kernel (arriscado, complexo) ou escrever um módulo de kernel (também arriscado, pois um bug pode travar todo o sistema). O eBPF contorna isso permitindo que você injete pequenos programas no kernel que são executados em um ambiente isolado (sandboxed). Esses programas observam syscalls específicas e reportam à ferramenta ADR, que então decide se permite ou bloqueia a ação.
A desvantagem do ADR in-kernel, assim como o WAF, é que ele não possui contexto da aplicação. Ele vê syscalls brutas, como "o processo 4821 executou um programa", mas não tem ideia de qual requisição HTTP ou usuário a acionou. Sem esse contexto, a segurança in-kernel precisa operar com base em políticas, que são regras como "este processo nunca deve gerar um shell" ou "este Container nunca deve gravar neste diretório". Isso funciona para detectar violações claras, mas o torna bastante binário, sem nuances.
Para ataques de classe de injeção, como SQL injection, o ADR no kernel é praticamente cego. No momento em que o ataque atinge a camada de syscall, o payload SQL é apenas bytes brutos dentro de um buffer de rede. Exploits em tempo de execução são outro ponto cego. Alguns ataques são executados inteiramente dentro do runtime da linguagem, então eles nunca criam uma operação incomum em nível de SO até que seja tarde demais.
Ao contrário das ferramentas RASP tradicionais, este tipo de ADR não exige alterações no código do seu aplicativo para ser configurado. No entanto, ele possui mais configuração e requisitos do que WAF ou RASP, pois as ferramentas ADR geralmente precisam de um kernel Linux relativamente moderno e privilégios de sistema elevados.
Exemplos: Tetragon, Falco, KubeArmor (código aberto)
Oligo ADR (comercial)
WAF, RASP, ADR, eBPF: Qual deles eu preciso?
Até agora, abordamos muitos termos — WAF, RASP, ADR, eBPF, in-app, in-kernel. A resposta curta é que você deseja proteção em mais de uma camada. A resposta mais longa depende das camadas. Quando se trata de RASP vs ADR, RASP é uma subcategoria de ADR, então a questão se torna: você quer segurança no aplicativo, segurança no kernel ou ambas?
As diferentes camadas são complementares, não concorrentes, porque cada uma detecta coisas que as outras não conseguem. É por isso que a resposta para "WAF ou RASP?" geralmente é "ambos", e adicionar ADR no kernel por cima oferece a cobertura de pós-exploração e em nível de kernel que completa o cenário.
As três camadas fazem perguntas fundamentalmente diferentes:
- WAF: "Esta requisição HTTP corresponde a um padrão de ataque conhecido?"
- Segurança no aplicativo (RASP e ADR): "Esta entrada do usuário está prestes a atingir uma função perigosa no meu aplicativo?"
- Segurança no kernel (ADR): "Este processo acabou de fazer algo que não deveria em nível de SO?"
TL;DR: Obtenha um WAF e uma ferramenta de segurança no aplicativo primeiro. Obtenha um ADR baseado em eBPF mais tarde, se precisar de processamento específico em nível de kernel.
A segurança no aplicativo, como o RASP, é a única camada que possui contexto sobre como os dados estão interagindo com o aplicativo específico, sendo assim a única camada capaz de realizar um bloqueio realmente preciso. Naturalmente, ela apresenta o menor número de falsos positivos em comparação com as outras duas. Embora a proteção em tempo de execução no aplicativo possa lidar com a maioria dos ataques em nível de aplicação ou de injeção, o WAF é necessário para ataques de alto volume, como DDoS. Como os WAFs ficam fora do aplicativo, eles podem lidar com milhares de requisições de bot antes de atingir seu aplicativo e tocar esses recursos, e isso não exige muito contexto para funcionar. Juntos, a segurança no aplicativo, como o Aikido Zen, combinada com um WAF, cobrirá a grande maioria dos problemas que você encontrará.
Se você está no ponto em que precisa de visibilidade completa de pós-exploração, está preocupado com movimento lateral ou precisa de aplicação de políticas em nível de kernel em múltiplos processos, é quando deve considerar adicionar ADR no kernel. É a ferramenta certa para uma configuração de segurança mais madura, embora não seja necessariamente a primeira opção. Algumas ferramentas ADR no aplicativo cobrem mais do que outras. O Aikido Zen, por exemplo, monitora a atividade de saída (consultas SQL, comandos de shell, leituras de arquivo e chamadas HTTP de saída) que seu aplicativo realiza. E, comparado a uma configuração de ADR no kernel mais complicada, as equipes podem configurar o Zen com um único npm install e uma única linha de código.
A única coisa que o ADR no kernel cobre além do Zen é o que acontece depois que um shell já foi gerado e o atacante está operando em nível de SO. Assim, o Zen não substituirá o eBPF se você precisar dessa visibilidade completa de pós-exploração e aplicação de políticas em nível de kernel em todos os processos, mas para a maioria das equipes, ele cobre a superfície de ataque que mais importa (ataques de injeção, zero-days e lógica de autorização). No entanto, se você tiver um RASP diferente que não cubra a atividade de saída e SQL injections, você pode precisar do eBPF mais cedo.
Zen da Aikido: O ADR moderno no aplicativo
Embora tenham objetivos semelhantes, nem todas as ferramentas de segurança no aplicativo são iguais. Novos ADRs como o Zen, o firewall incorporado no aplicativo de código aberto da Aikido, se situam no território da segurança no aplicativo, mas cobrem um terreno que uma ferramenta RASP padrão não cobre.
O Zen fornece o contexto completo do aplicativo dos RASPs tradicionais, como rastreamento de taint, bloqueio em nível de sink, consciência de ID de usuário, baixos falsos positivos, mas como um ADR moderno, o Zen também monitora a atividade de saída da mesma forma que o ADR no kernel. Isso inclui cada consulta SQL, comando de shell, leitura de arquivo e chamada HTTP de saída que seu aplicativo faz. Seu algoritmo de vulnerabilidade é determinístico desde a primeira requisição, então não há problema de cold start nem manutenção contínua de regras que outros RASPs possuem.
O Zen também vai além dos ataques de classe de injeção. Ele analisa cada consulta SQL em tempo de execução usando um parser SQL completo (construído em Rust) e aplica o escopo de tenant automaticamente. Se uma consulta estiver sem um filtro de tenant ou usar um ID de tenant incorreto, o Zen lança um erro antes que seja enviado. IDORs (referências diretas inseguras a objetos) são a causa mais comum de vazamentos de dados entre tenants em SaaS multi-tenant, e são notoriamente difíceis de detectar em revisões de código. O Zen os torna impossíveis de serem implantados acidentalmente.
Leitura adicional: Prevenção de ataques zero-day para Node.js com Aikido Zen
Perguntas Frequentes
O que é um WAF?
Um WAF (Firewall de Aplicação Web) fica fora do seu aplicativo e inspeciona o tráfego HTTP de entrada em busca de padrões de ataque conhecidos. É particularmente bom em lidar com ameaças volumétricas, como ataques DDoS e tráfego de bot, mas não tem visibilidade sobre o que seu aplicativo realmente faz com uma requisição.
O que é segurança RASP?
RASP (Autoproteção de Aplicação em Tempo de Execução) é uma ferramenta de segurança que executa dentro do seu aplicativo. Ela monitora como a entrada do usuário flui através do seu código e bloqueia ataques no ponto em que se tornam perigosos: o sink. Por ter contexto completo do aplicativo, é muito mais precisa que um WAF para ataques de classe de injeção.
Qual é a diferença entre WAF e RASP?
Um WAF atua fora da sua aplicação e bloqueia o tráfego com base em padrões. Um RASP atua dentro da sua aplicação e bloqueia ataques com base no que seu código realmente fará com a entrada do usuário. WAFs são mais fáceis de implantar e excelentes para ameaças volumétricas. RASPs têm taxas de falsos positivos mais baixas e melhor cobertura para ataques de injeção e zero-days.
Preciso de um WAF e um RASP?
Sim, eles são complementares, não concorrentes. Um WAF lida com proteção de borda e tráfego volumétrico. Um RASP lida com ataques de classe de injeção e zero-days que os WAFs rotineiramente não detectam. A maioria das configurações de segurança maduras utiliza ambos.
O que é ADR vs RASP?
Em geral, ADR abrange ferramentas que fornecem segurança in-app ou in-kernel. RASP refere-se a ferramentas in-app, e elas são um subconjunto de ADR. RASP e ADR in-app são tecnicamente a mesma abordagem, apenas rótulos diferentes ao longo do tempo. O rótulo ADR é mais novo e mais amplo. Às vezes, ADR é usado como abreviação ou de forma intercambiável com eBPF, ferramentas ADR baseadas em kernel. Os termos para RASP e ADR variam ligeiramente dependendo de quem você pergunta. Tenha isso em mente ao fazer mais pesquisas sobre o assunto.
O que é ADR / eBPF em segurança de aplicações?
ADR (Application Detection and Response) abrange segurança in-app e in-kernel. Ferramentas ARD in-kernel como Tetragon ou Falco operam no nível do kernel Linux, monitorando cada syscall em cada processo no host. Elas são fortes em visibilidade pós-exploração e na detecção de bypasses de nível de kernel, mas não possuem contexto de aplicação, tornando-as complementares ao RASP em vez de um substituto. eBPF (Extended Berkeley Packet Filter) é a tecnologia de kernel subjacente que impulsiona as ferramentas ADR in-kernel.
Se eu sanitizar todas as entradas corretamente, ainda preciso de RASP?
Sim. A sanitização é difícil de ser feita perfeitamente o tempo todo. Especialmente se ferramentas SAST e de qualidade de código estiverem ausentes durante o desenvolvimento, bugs de segurança podem encontrar seu caminho para a base de código. Pense nisso menos como um substituto para boas práticas de codificação segura e mais como uma proteção em tempo de execução para quando essas práticas não são perfeitas (o que, na prática, claro, nunca são). O RASP também impede problemas provenientes de dependências de terceiros.
