Ninguém quer comprar gato por lebre, especialmente quando se trata de soluções de segurança cibernética (cibersegurança) caras. Portanto, um projeto piloto frequentemente precede o negócio e a integração. Pode parecer simples: instalar a solução de segurança, observar como ela funciona por algumas semanas e decidir comprar (ou não).
Na prática, no entanto, uma "pausa estranha" às vezes surge após o piloto: o cliente não entende como avaliar os resultados do teste e o fornecedor não sabe como proteger ainda mais seu produto porque o input do cliente foi insignificante. O resultado pode ser triste para todos. O fornecedor sai sem um cliente e o potencial cliente sem ciberproteção. Portanto, para que semanas (e às vezes meses) não sejam desperdiçados, você precisa se preparar bem para o piloto. Especialmente quando se trata de sistemas complexos, como um Web Application Firewall (WAF). Como um WAF é um participante completo na arquitetura, ele requer integração adequada com aplicativos protegidos, balanceadores de carga e outros sistemas na infraestrutura do cliente. Vamos examinar cada etapa do piloto separadamente.
O que exatamente estamos "pilotando"?
Para começar, você precisa decidir sobre uma lista de aplicativos que serão colocados atrás do WAF como parte do teste piloto. Não tente proteger tudo de uma vez: para o piloto, é melhor limitar-se a dois aplicativos críticos. Devem ser aplicativos reais com usuários reais, porque sem isso é impossível determinar como o WAF lida com a carga, qual atraso de tráfego ele introduz e, o mais importante, se ele bloqueia usuários legítimos devido a falsos positivos (e quão fácil é criar exceções para falsos positivos).
Cada aplicação web deve ser descrita em detalhe:
- Nome de domínio (FQDN);
- Endereço(s) IP dos servidores backend;
- Portas usadas;
- Protocolos (HTTP / HTTPS);
- Necessidade de TLS / mTLS;
- Tipo de aplicação (web, API, mobile backend, etc.).
Um WAF não é uma caixa preta, mas um "intermediário transparente" que precisa conhecer a rota exata. A maioria dos atrasos e falhas no piloto ocorrem precisamente na fase "para onde devemos enviar o tráfego?". Portanto, parâmetros pré-coletados economizam horas ou até dias.
As aplicações modernas usam protocolos diferentes (e não apenas HTTP) e é necessário entender se o WAF pode funcionar com essa diversidade em princípio. Portanto, para os recursos protegidos, você precisa especificar:
- Uso de protocolos adicionais, por exemplo, WebSocket / HTTP2 / gRPC;
- Disponibilidade de REST / SOAP / GraphQL API;
- Recursos de autenticação (JWT, OAuth, cookies, custom headers);
- Upload de arquivos (multipart/form-data);
- Métodos HTTP não padrão;
- Sensibilidade a alterações de cabeçalhos, atrasos, bloqueio de solicitações individuais;
- Disponibilidade de seus próprios mecanismos de rate limiting ou proteção.
Depois de decidir sobre as principais características das aplicações, você precisa entender quanto tráfego o WAF terá que filtrar. Com base nisso, você pode entender a quantidade de hardware necessária para implantar e operar a solução no lado do cliente. Se não houver recursos suficientes, o WAF não conseguirá processar as solicitações a tempo, o que aumentará os atrasos e a velocidade de resposta para os usuários da aplicação web. Para dimensionar a maioria dos WAFs, os seguintes parâmetros são suficientes:
- RPS médio e de pico;
- Volume de tráfego (Mbps / Gbps);
Arquitetura e esquema de inclusão do WAF
Então, com aplicações e tráfego - está claro. É hora de determinar a arquitetura e o local onde o WAF será integrado. As aplicações web modernas têm uma arquitetura multicamadas e distribuída: balanceadores de carga, reverse proxy, servidores web e serviços backend. Em cada um desses níveis, podem ser aplicadas soluções que afetam o processamento de tráfego, terminação TLS, roteamento de solicitações e transmissão de dados do cliente.
E o WAF deve se encaixar organicamente nesta cadeia. Portanto, é importante entender a arquitetura real da aplicação, sua topologia de rede e as características da interação dos componentes. Isso ajuda a:
- Escolher o local ideal para instalar o WAF;
- Determinar corretamente o ponto de terminação TLS;
- Garantir uma integração transparente sem afetar a operação da aplicação;
- Evitar refinamentos e alterações adicionais durante o piloto.
Uma arquitetura típica de aplicação web se parece com isto:
Onde, neste caso, você pode instalar o WAF:
- WAF antes do LB (User → WAF → LB → App)
- WAF atrás do LB (User → LB → WAF → App)
- WAF como LB (User → WAF → App)
- WAF integrado em LB / Web Servers (módulo para nginx/angie)
Qual opção de integração do WAF escolher depende tanto da arquitetura atual do cliente quanto das características da solução do fornecedor escolhido. Portanto, o ideal é um esquema que leve em consideração todas essas características.
Detalhes importantes
№1. Ponto de terminação TLS
Quase todo o tráfego web moderno é criptografado (HTTPS/TLS). Se o WAF não descriptografá-lo, ele verá apenas endereços IP e cabeçalhos sem o conteúdo das solicitações. Para que o tráfego não se transforme em uma caixa preta, na fase preparatória do piloto, é necessário selecionar um ponto de interrupção de conexão (terminação).
Opção A:
TLS é terminado no WAF. Então você precisará carregar certificados de servidor e chaves privadas no WAF.
Opção B:
TLS é terminado antes do WAF (no LB/servidor proxy existente). O WAF já recebe tráfego descriptografado.
Dependendo do esquema escolhido, você terá que alterar a configuração dos balanceadores, aplicações backend ou registros DNS.
Além disso, deve-se levar em consideração que a re-criptografia do tráfego do WAF para as aplicações protegidas também pode ser necessária, incluindo mTLS. Nesse caso, será necessário emitir novos certificados e/ou adicionar a CA corporativa à lista de confiáveis nos nós WAF.
№2 Problema de IP do cliente
Se o WAF estiver atrás de um balanceador de carga, é fundamental garantir a transmissão do endereço IP real do cliente. Caso contrário:
- A eficácia dos mecanismos de proteção é reduzida.
- O rate limiting não funciona (todas as solicitações serão do IP do balanceador).
- Os logs se tornam inúteis para investigar incidentes.
O que precisa ser acordado:
- Mecanismo de transmissão do LB para o WAF: cabeçalhos HTTP (X-Forwarded-For, X-Real-IP, Forwarded) ou protocolo proxy.
- Sub-redes confiáveis: o WAF deve saber de quais IPs aceitar esses cabeçalhos.
- Transmissão do WAF para o Backend: o backend também deve ver o IP real. Pode ser necessário adicionar os endereços IP dos nós WAF à lista de confiáveis no lado do backend.
Garantindo conectividade de rede e acesso
Provavelmente, há segmentação e firewall na rede do cliente. Com a implantação do WAF na infraestrutura, aparece um novo host e, portanto, é necessário garantir sua conectividade com outros componentes da aplicação, adicionando regras aos firewalls e coordenando o acesso de rede necessário.
A tabela de acesso pode ser assim:
| Fonte | Destinatário | Porta | Protocolo | Comentário
Também, especifique os requisitos de proxy se sua infraestrutura tiver saída direta restrita para a Internet. Isso é necessário para que o WAF possa atualizar seus componentes e bases de conhecimento.
Questões organizacionais e papéis
Técnica é metade do trabalho. A segunda metade são pessoas e processos. Normalmente, a equipe de segurança da informação está envolvida no piloto, mas, na verdade, especialistas de outros departamentos estão envolvidos neste processo.
Funções do lado do cliente:
- Proprietário da aplicação ou serviço (que permite o piloto, concorda com o tempo de inatividade, avalia o impacto nos negócios).
- Especialistas em infraestrutura de TI e engenheiros de rede (para fornecer recursos computacionais e organizar a conectividade de rede).
- Equipe de desenvolvimento (para verificar se o WAF não quebrou nada ou para configurar o backend, se necessário).
- Especialistas em segurança da informação (é autoexplicativo).
O que concordar antes de começar:
- Prazos e plano para o piloto.
- Necessidade de assinar um NDA.
- Fornecer acesso remoto a engenheiros do fornecedor e/ou integrador (se necessário).
- Processo para fazer alterações na infraestrutura (Change Management).
- Pessoas de contato para comunicação operacional e procedimento de escalonamento de incidentes.
Critérios de sucesso do piloto
Imagine: você pilotou o WAF por 2 meses, envolveu colegas de departamentos relacionados além da segurança da informação, gastou tempo e esforço de seus funcionários. E, no final, você não entende como avaliar o resultado. Parece que tudo está funcionando, não há degradação da aplicação, alguns ataques até foram repelidos durante o piloto - este piloto é bem-sucedido e há argumentos suficientes para comprar a solução?
Para que dinheiro e esforço não sejam desperdiçados, aconselhamos que você determine antecipadamente os critérios pelos quais o piloto será considerado bem-sucedido. Por exemplo:
- Ausência de impacto negativo na disponibilidade da aplicação;
- Processamento correto do tráfego legítimo;
- Detecção e/ou bloqueio de ataques de teste;
- Facilidade de operação e administração;
- Qualidade de relatórios e logs.
A avaliação da eficácia do piloto merece um artigo separado, pois é impossível encaixar todos os detalhes em um pequeno capítulo de texto. Falaremos em detalhes sobre os critérios de sucesso do piloto no próximo post, que será lançado muito em breve.
Autor: Vladimir Gridnev, vice-diretor geral de desenvolvimento de negócios da WMX
