Reestudando sua infraestrutura

Recentemente, parei para rever/revisar o IaC de infra/redes e sua infraestrutura aplicada, de um ecossistema de uma fintech (que chamaremos aqui de GlobalPay). O objetivo era avaliar a postura de segurança de seus apps diferentes que compõem o produto principal.

O que parecia ser uma varredura de rotina revelou uma lição valiosa: a segurança não é apenas um problema técnico, mas um desafio de governança e automação e também, revisão.

Aqui estão os principais aprendizados para quem trabalha com DevOps, Cloud e Segurança de Aplicações que pude tirar reestudando meu próprio código.

1. O perigo dos Templates de IaC Inadequados

Um dos achados mais curiosos foi que nos apps analisados apresentavam exatamente a mesma falha: a fuga de nomes internos de Load Balancers de staging e regiões da no cabeçalho Location de redirecionamentos HTTP.

O aprendizado: Quando usamos ferramentas como Terraform ou CloudFormation, um erro no template original é replicado em escala. Adversários usam essas informações para mapear ambientes de teste, que geralmente possuem controles de segurança menos rigorosos.

2. A Inconsistência é o seu maior inimigo

Durante a minha análise, encontramos um cenário de "dois mundos". Enquanto um app apresentava uma postura exemplar (o nosso benchmark), com HSTS, CSP e X-Frame-Options configurados corretamente, os apps adjacentes — teoricamente mais sensíveis — não possuíam poucos desses controles.

A lição: A segurança não pode ser seletiva. A falta de uma baseline mínima obrigatória centralizada faz com que cada time de desenvolvimento implemente sua própria versão de "segurança", criando buracos previsíveis no perímetro.

3. Vulnerabilidades "Clássicas" ainda derrubam gigantes

Identificamos uma vulnerabilidade ao ataque Slowloris DoS (CVE-2007-6750) em um dos endpoints. É uma falha de 2009 que ainda assombra ambientes que não configuram corretamente os timeouts de conexão em seus Load Balancers ou WAFs.

Além disso, o Bypass de Rate Limit no endpoint de autenticação foi classificado como crítico. Sem um limite rigoroso, a aplicação fica exposta a ataques de Account Takeover (ATO) via Credential Stuffing.

4. Hardening de Borda: Mais que apenas HTTPS

Muitos desenvolvedores acreditam que subir um certificado SSL/TLS é o suficiente. No entanto, a análise revelou que:

• CORS Permissivo: Configurações de access-control-allow-origin: * (wildcard) em APIs financeiras permitem que qualquer site malicioso faça requisições em nome de usuários autenticados.
• Fingerprinting de Tecnologia: Manter o cabeçalho X-Powered-By: Express facilita a vida do atacante, que pode buscar exploits específicos para aquela versão do framework.
• Segurança de Cabeçalhos: A ausência de cabeçalhos críticos (como CSP para evitar XSS e HSTS para forçar HTTPS) foi uma falha abrangente.

5. Do Manual para o "Security as Code"

A maior conclusão deste relato não foi sobre quais portas estavam abertas, mas sobre a ausência de validações automáticas em pipelines de CI/CD.

Se tivesse implementado verificações de segurança automatizadas, seria impossível um app chegar à produção sem os cabeçalhos obrigatórios ou com políticas de CORS abertas.

Conclusão: O Projeto Arquitetônico Digital

A infraestrutura de uma empresa é como um edifício residencial. Não adianta o andar de investimentos ter portas blindadas se o andar de gestão de contas foi construído com janelas que não trancam.

A solução definitiva para os problemas encontrados não é consertar cada domínio manualmente, mas atualizar o único projeto arquitetônico digital (os templates de IaC) e garantir que cada novo andar construído siga o mesmo padrão de segurança máxima desde o alicerce.