VLAN de visitante: por que segmentar rede WiFi é design, não paranoia
Implementei rede WiFi separada para visitantes sem acesso à rede interna. Parecia exagero na época. Não era — e o princípio voltou em zero-trust architecture anos depois.
A solicitação parecia simples: colocar WiFi na sala de reuniões para que visitantes pudessem acessar a internet.
A solução simples seria jogar os visitantes na mesma rede interna — SSID diferente, mesma VLAN, mesmo acesso. Funcionaria. Seria rápido.
Não fiz assim.
Criei uma VLAN separada, isolada da rede interna, com acesso apenas à internet. Visitante na sala de espera podia navegar na internet. Não podia acessar os servidores internos, a impressora do escritório, o servidor de arquivos, ou qualquer outro recurso da rede corporativa.
A reação do gestor quando expliquei o que fiz foi "isso era necessário?" com tom de que eu havia complicado sem motivo.
Expliquei em termos de risco: qualquer dispositivo conectado à rede interna tem, por padrão, acesso a todos os recursos daquela rede — a menos que regra explícita diga o contrário. Visitante com notebook infectado conectado na rede interna pode ter acesso aos servidores. Pode iniciar varredura de rede. Pode alcançar recursos que deveriam ser privados.
Não era paranoia. Era princípio de menor privilégio: dar acesso apenas ao que é necessário, nada além.
O gestor entendeu depois que coloquei nesses termos. Aprovou.
Princípio de menor privilégio parece óbvio quando você está falando de segurança de rede. Fica menos óbvio quando você está movendo rápido e cada configuração extra parece atrito desnecessário.
O que a implementação física de VLAN me ensinou é que segmentação tem custo — e vale a pena pagar. O custo de criar VLAN separada era uma tarde de configuração. O custo de um incidente de segurança causado por dispositivo de visitante comprometido seria ordens de magnitude maior.
Análise de custo de segurança raramente aparece até que o incidente acontece. A tendência é optimizar para velocidade e simplicidade agora, e pagar o custo de segurança depois — quando é caro demais.
Anos depois, em arquitetura de plataforma em Kubernetes, o mesmo princípio voltou com vocabulário diferente: network policy entre namespaces, service mesh com mTLS, zero-trust networking.
Zero trust é a versão moderna do que eu implementei naquela sala de reuniões: nenhum dispositivo ou serviço é confiável por padrão. Acesso precisa ser explicitamente autorizado, não apenas implícito por estar na mesma rede.
A intuição — visitante não deveria acessar servidor interno só porque está no mesmo WiFi — é a mesma intuição que está em qualquer pod no Kubernetes que não deveria falar com qualquer outro pod só porque estão no mesmo cluster.
Segmentação não é paranoia. É design.
Essa semana: tem algum serviço na sua infraestrutura que tem acesso a mais recursos do que precisa — só porque é mais fácil deixar assim?