é tempo de reconstruir os muros
Você não precisa esperar um incidente para perceber que a arquitetura de rede da sua empresa está obsoleta. A maioria dos profissionais de infraestrutura passa três anos ou mais operando com segmentação que foi desenhada para outro negócio, outra escala e outra ameaça. O resultado é que os perímetros nunca foram realmente removidos, apenas esquecidos no meio do caminho. O processo de reconstruir os muros — a segmentação de rede e as políticas de segurança perimetral — começa com um inventário honesto de tudo que existe na sua rede hoje. Não o inventário que o sistema de gestão de ativos diz que existe. O inventário real. O que eu fiz no primeiro projeto em que implementei isso foi rodar um scan passivo durante duas semanas inteiras, capturando todo tráfego L2/L3 sem interferir em nada. O relatório mostrou 847 fluxos de comunicação que nenhum documento interno mencionava. Desses, 212 iam diretamente de estações de trabalho para servidores de produção.
Planejamento antes de qualquer mudança
A armadilha mais comum é começar a mover coisas antes de entender o padrão completo de comunicação. Eu vi uma equipe retirar uma VLAN inteira de servidores históricos porque "não constava em nenhum playbook", e esses servidores estavam rodando um sistema de log interno que nenhum monitoramento conseguia substituir. A rede caiu por seis horas. Ninguém ficou sabendo até o suporte receber ligações dos clientes. O método que funciona é o seguinte: separe tudo em três camadas. A camada de acesso, onde os dispositivos dos usuários e prédios periféricos vivem. A camada de serviços, onde rodam banco de dados, autenticação, e sistemas críticos. E a camada de perímetro, que lida com o trânsito externo. Cada uma dessas camadas precisa de políticas próprias. Não tente aplicar as mesmas regras de bloqueio em todas.
Durante o mapeamento, anote não apenas quais máquinas conversam entre si, mas com que frequência e em que horários. Um servidor de backup que só envia dados às 2h da manhã tem necessidades diferentes de um sistema de RH que transmite o dia inteiro. Regras baseadas apenas em portas e protocolos são a principal causa de sobrerestrrição. Eu já Configurei regras que permitiam tráfego na porta 443 entre duas sub-redes e ainda assim bloqueavam o que realmente importava porque o certificado usava um SNI que o inspetor não reconhecia. A solução foi adicionar uma exceção específica para aquele domínio, não abrir a porta globalmente.
Implementação prática
A reconstrução deve ser feita em fases, nunca de uma só vez. Comece pela periferia. Bloqueie o tráfego entre departamentos que nunca deveria existir — marketing acessando servidores de produção, estações de desenvolvimento falando diretamente com a internet sem passar por proxy. Isso gera menos atrito porque não afeta sistemas críticos no início. Use uma abordagem de lista negra que evolui para lista branca. Nas primeiras duas semanas, apenas monitore e registre o que está sendo bloqueado. Anote cada ocorrência. Se um aplicativo legítimo for blocks duas vezes no mesmo período, ajuste a regra. Depois desse período de observação, ative o bloqueio efetivo nas mesmas regras.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Para a camada de serviços, o trabalho é mais delicado. Aqui você vai lidar com aplicações que têm dependências cruzadas que ninguém documentou. O truque é usar microsegmentação com base em identidade, não apenas em endereço IP. Endereços mudam. Identidades de serviço, não. Use certificados mutuos ou tags de workload para definir quem pode falar com quem, independentemente de qual sub-rede cada um está. Firewalls de nova geração com inspeção na camada 7 ajudam muito nessa fase. Eles permitem regras como "o serviço de pagamento só pode se comunicar com o banco de dados na porta 5432 usando TLS 1.2 ou superior". Isso elimina uma categoria inteira de vulnerabilidade que listas de acesso tradicionais simplesmente ignoram.
O que costuma dar errado
A principal dificuldade que eu encontrei pessoalmente foi com legacy systems que dependem de broadcast e netbios para funcionar. Um sistema de inventário interno rodava em Windows Server 2008 e usava descoberta por broadcast para localizar impressoras e arquivos. Quando apliquei a segmentação padrão, o sistema parou de funcionar porque broadcasts não atravessam sub-redes. A solução foi criar uma VLAN dedicada para esse sistema, isolá-lo do resto da rede e configurar um relay de broadcast direcionado apenas para os endereços conhecidos. Levou três dias para mapear todas as dependências, mas depois disso o sistema rodou normalmente sem exposição ao resto da infraestrutura. Outro problema frequente é a configuração de DNS interno. Quando você move servidores de produção para sub-redes diferentes, os clients precisam resolver nomes corretamente de qualquer lugar da rede. Se o DNS não estiver configurado com zonas corretas ou com forwarders adequados, os bloqueios de firewall parecem funcionar, mas as aplicações falham de maneira intermitente e impossível de diagnosticar só olhando os logs de segurança. Configure registros DNS condicionalmente encaminha para cada zona de serviço antes de aplicar as regras de segmentação.
Não existe solução única que cubra todos os casos. Firewalls tradicionais funcionam bem para segmentação entre edifícios ou data centers diferentes. Para segmentação dentro de um mesmo data center entre máquinas virtuais, você precisa de microssegmentação no hipervisor ou em software-defined networking. Usar apenas firewall de perímetro para proteger comunicação east-west é como trancar a porta da frente e deixar as janelas abertas. O custo de manutenção também é real. Cada regra nova precisa ser revisada trimestralmente. Regras que ficaram órfãs — criadas para um projeto que foi descontinuado há dois anos — acumulam e criam brechas. Estabeleça um processo formal de revisão com owners definidos para cada regra. Se o responsável por uma regra não responder em 30 dias, a regra volta para estado de bloqueio automático até que alguém justifique sua existência.
é tempo de reconstruir os muros quando a rede atual já não reflete a realidade operacional da empresa. Não espere um breach para tomar essa decisão. O trabalho leva entre quatro e oito semanas para uma rede de médio porte, dependendo da complexidade das aplicações legado. O investimento em tempo e teste vale a pena porque a alternativa é operar com visibilidade zero do que realmente acontece dentro da sua infraestrutura.
