Quando alguém fala em segurança num projeto web, a conversa costuma ir direto pra OWASP, SQL injection e XSS. Isso importa, mas tem uma camada antes, mais básica e mais barata de acertar: como a aplicação está exposta e quem consegue falar com quem.
São quatro práticas. Nenhuma é sofisticada, e juntas resolvem boa parte do risco real.
1. Least-privilege nas regras de firewall
Cada recurso recebe só o acesso mínimo de que precisa, e todo o resto é negado por padrão.
- O load balancer aceita
443(e80só pra redirecionar). - A aplicação aceita tráfego só do load balancer.
- O banco aceita conexão só da aplicação, na porta dele.
- SSH, se existir, fica restrito a um IP ou bastion. Nunca
0.0.0.0/0.
A ideia não é impedir que algo seja comprometido. É garantir que, se for, o estrago fique contido naquela peça.
2. Secrets fora do código, dentro de um cofre
Senha de banco, API key e token não vão no repositório, nem num .env versionado “só por enquanto”. Vão pra um cofre (HashiCorp Vault, AWS Secrets Manager, SSM Parameter Store), e a aplicação lê em tempo de execução.
O ganho não é só esconder a senha:
- controle de acesso centralizado: quem pode ler o quê;
- auditoria: quem leu e quando;
- rotação sem redeploy: trocar uma credencial vazada vira operação, não incidente.
3. HTTPS pra expor a aplicação
Todo tráfego público passa por TLS. Sem isso, dados e cookies de sessão trafegam em texto puro e qualquer um no meio do caminho pode ler ou alterar.
Na prática, o certificado fica no load balancer ou proxy (ACM, Let’s Encrypt), com redirect de HTTP pra HTTPS e HSTS ligado, pra o navegador nem tentar HTTP de novo.
4. Tiers de subnet: LB, app e banco
A rede é separada em camadas, cada uma com uma função:
| Camada | Subnet | Quem acessa |
|---|---|---|
| Load balancer | Pública | Internet |
| Aplicação | Privada | Só o LB (sai via NAT, se precisar) |
| Banco | Privada | Só a aplicação, sem rota pra internet |
Somado ao least-privilege, isso vira defesa em camadas. Pra chegar no banco, um atacante teria que passar pelo LB e comprometer a aplicação antes. O banco simplesmente não existe pra internet.
O que isso não cobre
Isso é segurança de infraestrutura da aplicação. Não substitui validação de input, autenticação e autorização bem feitas, dependências atualizadas e logs decentes. Mas sem essa base, o resto fica em cima de areia: não adianta ter o código mais bem validado do mundo se o banco está com a porta aberta pra internet.
Checklist
- Regras de firewall negam tudo por padrão e liberam só o necessário
- Nenhuma porta de banco ou SSH aberta pra
0.0.0.0/0 - Secrets num cofre, nada no repositório
- Rotação de credenciais possível sem redeploy
- HTTPS em todo tráfego público, com redirect e HSTS
- LB em subnet pública; app e banco em subnets privadas
- Banco sem rota pra internet