Cover do episódio 26: Firewall na prática: o que passa, o que não passa, e o que todo mundo esquece de documentar
#0262 de agosto, 20163 min leituraInfra que Aprendi na PráticaS1 · 2013–2016

Firewall na prática: o que passa, o que não passa, e o que todo mundo esquece de documentar

Assumi manutenção de um firewall com 200 regras. Metade delas, ninguém sabia mais por que existiam. O que isso me ensinou sobre princípio de menor privilégio antes de eu saber o nome.

FirewallSegurançaInfraestruturaMenor Privilégio

Assumi a manutenção de um firewall que tinha 200 regras acumuladas ao longo de anos.

Precisei liberar acesso de um sistema novo para um servidor interno. Simples. Mas antes de adicionar a regra, quis entender o que já existia.

Comecei a revisar. Regra 47: allow any any port 8080. Sem comentário, sem data, sem nome de quem criou. Por que qualquer endereço pode acessar qualquer destino na porta 8080?

Perguntei para os mais antigos do time. Ninguém sabia. "Deve ter sido para algum projeto." "Talvez seja o sistema X." "Melhor não mexer."

Tinha 23 regras assim.


Firewall é lista de permissões e bloqueios. Tráfego que não é explicitamente permitido é bloqueado — esse é o princípio. Mas com o tempo, regras se acumulam, contexto se perde, e o que era "temporário para aquele projeto" vira permanente que ninguém questiona.

O resultado é um firewall que parece restritivo mas tem buracos que ninguém mapeou.

O que aprendi trabalhando com isso:

Regra sem comentário é regra sem dono. Toda regra precisa de: quem pediu, quando, para qual propósito, e por quanto tempo. Sem isso, não há como auditar. Não há como limpar. Acumula até ninguém mais entender o que está bloqueado e o que não está.

Menor privilégio é padrão, não exceção. A regra allow any any é conveniente quando você não quer pensar. É problema de segurança quando alguém explora. O trabalho correto é liberar o mínimo necessário: esse IP específico, para esse servidor específico, nessa porta específica. Mais trabalhoso para configurar. Muito mais fácil para auditar.

Regra temporária precisa de data de expiração. "Vou liberar isso por enquanto e depois a gente ajusta" nunca tem ajuste. A regra temporária de 2019 ainda está lá em 2024 porque ninguém foi atrás. Ou você coloca data de revisão obrigatória, ou você aceita que temporário é permanente.

Auditoria periódica é trabalho, não evento. Revisei aquelas 200 regras, documentei o que consegui entender, removi 31 que claramente não eram mais necessárias. Seis meses depois, tinha 15 regras novas sem documentação. É processo contínuo, não tarefa única.


Quando comecei a trabalhar com Kubernetes e vi network policy, reconheci o problema.

Cluster sem network policy é rede plana — qualquer pod pode falar com qualquer pod. Isso é equivalente ao firewall sem regras: conveniente para começar, problema quando você precisa entender quem pode falar com quem.

Network policy bem escrita especifica: esse serviço pode receber tráfego de esses namespaces, nessas portas. Exatamente como a regra de firewall que deveria ter sido escrita desde o início.

O princípio de menor privilégio não mudou entre 2016 e agora. O vocabulário mudou. A necessidade é a mesma.

Essa semana: tem alguma permissão no sistema que você opera que existe há mais de um ano e ninguém questiona por quê?