Firewalls de aplicativos da Web (WAFs) baseados em proxy são um componente integral da proteção de aplicativos. Além de ser um requisito para conformidade com o PCI-DSS, os WAFs são excelentes na proteção contra o OWASP Top 10. Eles também são uma solução ideal para lidar com vulnerabilidades de dia zero, seja por meio do lançamento rápido de atualizações de assinatura ou, em alguns casos, do uso de funções programáticas para corrigir aplicativos virtualmente enquanto uma solução de longo prazo está sendo implantada.
A questão é: onde você coloca essa proteção?
Há opções, é claro. O caminho de dados contém vários pontos de inserção nos quais um WAF pode ser implantado. Mas isso não significa que todo ponto de inserção seja uma boa ideia. Alguns são menos eficientes que outros, alguns introduzem pontos de falha inaceitáveis e outros introduzem dívidas arquitetônicas que incorrem em pesadas penalidades de juros ao longo do tempo.
O ideal é que você implante um WAF por trás da sua camada de balanceamento de carga. Isso otimiza a utilização, o desempenho e a confiabilidade, ao mesmo tempo em que fornece a proteção necessária para todos os aplicativos, mas principalmente para aqueles expostos na Internet.
Os requisitos de recursos (CPU e similares) envolvidos na tomada de uma decisão de balanceamento de carga são mínimos. Geralmente é por isso que um LB consegue dar suporte a milhões de usuários simultaneamente, e os WAFs exigem mais utilização, porque eles inspecionam toda a carga útil e a avaliam em relação a assinaturas e políticas para determinar se a solicitação é válida e segura.
Os modelos modernos de data center se baseiam muito na nuvem e em sua estrutura de custos baseada no uso. A utilização se torna um fator-chave nos custos operacionais. Maior utilização leva a requisitos de recursos adicionais, o que consome orçamentos. Otimizar a utilização é, portanto, uma estratégia sólida para restringir custos tanto no data center quanto em ambientes de nuvem pública.
É prática comum dimensionar WAFs horizontalmente. Ou seja, você usa o LB para dimensionar WAFs. Esta decisão arquitetônica está diretamente relacionada à utilização. Embora muitos WAFs sejam bem escaláveis, eles ainda podem ser sobrecarregados por tráfego flash ou ataques. Se o WAF estiver posicionado na frente do LB, você precisará de outra camada de LB para dimensioná-lo separadamente ou correrá o risco de afetar o desempenho e a disponibilidade.
O desempenho é uma preocupação fundamental em uma economia de aplicativos . Com tantas variáveis e sistemas interagindo com os dados conforme eles percorrem o caminho dos dados, pode ser frustrante identificar exatamente onde o desempenho está sendo prejudicado, e muito menos ajustar cada um sem impactar os outros. Como já foi observado muitas vezes, à medida que a carga em um sistema aumenta, o desempenho diminui. Essa é uma das consequências não intencionais de não otimizar a utilização e um dos principais motivos pelos quais arquitetos de rede experientes usam um limite de utilização de 60% em dispositivos de rede.
A implantação de um WAF atrás da camada LB elimina a necessidade de uma camada de balanceamento de carga WAF designada upstream, o que remove uma camada inteira de rede da equação. Embora o tempo de processamento eliminado possa não parecer muito, aqueles preciosos microssegundos gastos gerenciando conexões e dimensionando serviços WAF e, em seguida, fazendo isso novamente para escolher uma instância/servidor de aplicativo de destino são importantes. A eliminação dessa camada por meio da implantação do WAF atrás da camada LB devolve microssegundos preciosos que os usuários de hoje não apenas notarão, mas apreciarão.
A visibilidade é um requisito fundamental para soluções de segurança no caminho de dados. Sem a capacidade de inspecionar todo o fluxo – incluindo a carga útil – muitas das funções de segurança de um WAF tornam-se inúteis. Afinal, a maior parte do código malicioso é encontrada na carga útil, não nos cabeçalhos do protocolo. Posicionar um WAF atrás da camada LB permite a descriptografia de SSL/TLS antes que o tráfego seja passado para o WAF para inspeção. Essa é uma arquitetura mais desejável porque é provável que o balanceador de carga precise de visibilidade do tráfego protegido de qualquer maneira, para determinar como rotear solicitações corretamente.
Dito isso, um WAF se encaixa no caminho de dados praticamente em qualquer lugar que você quiser. É um serviço de segurança baseado em proxy L7 implantado como intermediário no caminho da rede. Ele poderia ficar ostensivamente na borda da rede, se você quisesse. Mas se você quiser otimizar sua arquitetura para desempenho, confiabilidade e utilização ao mesmo tempo, sua melhor aposta é posicionar esse WAF atrás da camada de balanceamento de carga, mais próximo do aplicativo que ele está protegendo.
Com as ferramentas certas, a cobertura abrangente do WAF pode reduzir significativamente suas exposições, bem como seus custos operacionais. Saiba mais sobre como proteger seus aplicativos do OWASP Top 10 e outras ameaças com os webinars sob demanda da F5 e explore as muitas maneiras de implantar os recursos do F5 WAF, incluindo o serviço gerenciado Silverline WAF baseado em nuvem da empresa.
O arquiteto de segurança da F5, Brian McHenry, e o principal evangelista de pesquisa de ameaças, David Holmes, contribuíram para este artigo. Pequenas edições feitas em agosto de 2019.