Redes separadas no desenho não são, necessariamente, ambientes isolados na prática. Controlar os caminhos entre sistemas exige combinar regras de tráfego, identidade, testes e capacidade de recuperação.
A pergunta que precisa vir depois do primeiro alerta
Em dois cenários hipotéticos, o incidente inicial é idêntico: um computador de atendimento foi comprometido. No primeiro, esse equipamento só consegue alcançar os serviços necessários ao trabalho. No segundo, também tem acesso de rede a servidores administrativos, interfaces de gerenciamento e repositórios de arquivos. A diferença não está apenas na infecção: está no conjunto de oportunidades disponíveis depois dela.
As falhas na segmentação de rede aparecem justamente nessa diferença. A pergunta operacional é: quais sistemas um invasor conseguiria alcançar a partir de um ativo comprometido? Conseguir estabelecer uma conexão não significa, por si só, conseguir invadir o destino. Mas deixar caminhos desnecessários disponíveis aumenta as possibilidades que a defesa terá de controlar.
A segmentação divide ambientes e estabelece limites de comunicação entre dispositivos, aplicações e sistemas. O MITRE ATT&CK a descreve como medida para restringir movimentação lateral e proteger ativos críticos, combinando separação lógica ou física com políticas efetivamente aplicadas. Sua função não é prometer invulnerabilidade, mas reduzir as oportunidades de propagação. Network Segmentation — MITRE ATT&CK
O que uma pesquisa sobre projetos malsucedidos realmente mostra
No The Segmentation Report 2026, atualizado em 20 de maio de 2026, a Cisco apresenta pesquisa encomendada à Vanson Bourne com 400 profissionais de empresas dos Estados Unidos com pelo menos 500 funcionários. Cada participante respondeu a partir de um projeto de segmentação malsucedido ocorrido nos 24 meses anteriores.
Essa seleção importa: o relatório analisa por que projetos que falharam não atingiram seus objetivos; não demonstra que todos os projetos, nem determinada porcentagem de todas as empresas, fracassam. Entre os fatores avaliados aparecem visibilidade insuficiente dos ativos, dificuldade para identificar comunicações legítimas, esforço manual e receio de indisponibilidade. A pesquisa também identifica problemas de escopo, coordenação e liderança. Não é um levantamento representativo das empresas brasileiras. The Segmentation Report 2026 — Cisco
A análise desses resultados exige separar a compra de tecnologia da implantação de uma política sustentável. Um projeto precisa demonstrar o que restringiu e quem continuará responsável por essa restrição quando o ambiente mudar.
Onde o isolamento pode existir apenas no desenho
A segmentação pode separar grandes zonas, como estações, servidores e administração. A microssegmentação leva a restrição a uma granularidade mais fina, como aplicações ou cargas de trabalho. Nos dois casos, o resultado depende das comunicações efetivamente permitidas, e não da quantidade de divisões representadas no diagrama.
Em outro exemplo hipotético, a equipe separa estações e servidores em redes distintas, mas mantém uma autorização ampla de comunicação entre elas para evitar chamados. A topologia mudou; a capacidade de um equipamento alcançar serviços sensíveis pode ter mudado muito pouco. A revisão deve olhar a autorização efetiva, não apenas os nomes das redes.
O MITRE recomenda agrupar sistemas por função, sensibilidade e risco, restringir tanto o tráfego externo quanto o interno, revisar regras e testar acessos indevidos entre segmentos. Servidores expostos à internet precisam de comunicação controlada com o restante do ambiente. Network Segmentation — MITRE ATT&CK
Para transformar a intenção em controle, cada conexão permitida precisa de uma justificativa verificável: qual serviço depende dela, quais são as origens e os destinos necessários, quem é responsável e como uma exceção será encerrada? Uma permissão temporária sem responsável ou prazo merece investigação, não a presunção de que continua necessária.
Cloud e Kubernetes exigem conferir o controle que realmente está ativo
Na AWS, os security groups controlam o tráfego permitido de entrada e saída dos recursos associados. A documentação recomenda restringir portas às origens ou aos destinos necessários e limitar quem pode criar ou modificar esses grupos. Também destaca que são controles com estado: respostas a conexões permitidas têm tratamento próprio. Portanto, uma avaliação precisa considerar o comportamento do mecanismo, não transportar automaticamente regras pensadas para outro tipo de firewall. Control traffic to your AWS resources using security groups — AWS
Em Kubernetes, criar um objeto NetworkPolicy não garante sua aplicação: o componente de rede precisa oferecer suporte e executar a política. Pela semântica padrão da API, sem políticas que isolem os pods na direção correspondente, o tráfego permanece permitido. Entrada e saída são avaliadas separadamente, e permissões de políticas aplicáveis se somam. Assim, uma autorização abrangente pode contrariar a restrição pretendida por outra política. A validação deve verificar a comunicação real dos workloads. Network Policies — Kubernetes
No exemplo de uma aplicação com camada web e banco de dados, a pergunta útil não é apenas se existem dois grupos ou namespaces. É se somente a aplicação autorizada consegue iniciar a conexão necessária com o banco, enquanto os demais caminhos previstos como proibidos realmente falham.
Identidade não pode ficar fora da arquitetura
O NIST SP 800-207 estabelece que a localização de um ativo ou usuário na rede não é motivo suficiente para conceder confiança implícita. A abordagem Zero Trust concentra a proteção em recursos e exige tratar autenticação e autorização antes de estabelecer acesso. Segmentação, portanto, não é sinônimo de Zero Trust nem substitui a gestão de identidades. Zero Trust Architecture — NIST SP 800-207
Um cenário hipotético ilustra o limite: se uma conta administrativa comprometida mantém autorização para alterar as próprias regras de segurança, bloquear determinados caminhos de dados pode não resolver o problema de controle. A avaliação de risco precisa separar duas perguntas: quem pode usar o serviço e quem pode modificar as condições de acesso a ele? Tratar essas permissões como equivalentes deixa uma parte importante do risco sem avaliação.
A relação com a cobertura anterior do Blog está na combinação de fronteiras de rede, isolamento de execução e identidade. Os conteúdos relacionados aprofundam essas camadas; não significam que os casos tenham a mesma causa ou que a segmentação, isoladamente, resolva todos eles.
Da estação comprometida ao impacto no negócio
No exemplo hipotético do atendimento, o problema pode deixar de ser a substituição de um computador e se tornar uma interrupção do faturamento, caso o invasor obtenha também acesso indevido ao sistema financeiro. Se alcançar arquivos e conseguir lê-los ou alterá-los, surgem riscos de exposição de dados e perda de integridade. Cada avanço exige condições adicionais: conectividade, permissões, credenciais ou uma vulnerabilidade explorável.
Esse encadeamento mostra por que a priorização deve considerar dependências de negócio. Um serviço compartilhado de identidade ou administração merece atenção não apenas por seus próprios dados, mas pelo alcance que seu comprometimento poderia oferecer. Para a gestão, a pergunta é quais processos precisariam parar, ser investigados ou restaurados se aquele limite de segurança falhasse.
Contenção e recuperação precisam ser avaliadas juntas
A discussão não termina quando se decide quais conexões bloquear. A recuperação depende de cópias utilizáveis e protegidas contra o mesmo incidente. O MITRE recomenda endurecer os sistemas de backup, manter cópias isoladas do ambiente comprometido, considerar armazenamento imutável e testar restaurações. Em ambientes cloud, também descreve a separação de cópias em outras contas ou regiões como medida possível de isolamento. Data Backup — MITRE ATT&CK
Como exercício de continuidade, a empresa pode perguntar: se a administração do ambiente de produção ficar indisponível ou comprometida, quem consegue iniciar a restauração, com quais credenciais e a partir de qual infraestrutura? Uma resposta que depende exclusivamente dos componentes afetados merece revisão. A presença de arquivos de backup, isoladamente, não responde a essa pergunta.
Um plano de verificação orientado ao negócio
Um caminho prático é começar por um serviço crítico e definir um teste de aceitação verificável. Em vez de exigir “segmentar tudo”, a primeira entrega pode ser demonstrar que estações comuns não acessam interfaces administrativas daquele serviço, preservando as conexões necessárias à operação. O exemplo deve ser adaptado ao ambiente e não representa uma receita universal.
A equipe responsável pode registrar a situação inicial, as conexões justificadas, os caminhos que devem ser proibidos e as condições de reversão. Os testes precisam ser autorizados e compatíveis com a disponibilidade exigida pelo serviço. Uma política que bloqueia a atividade legítima também falha como solução operacional; o objetivo é reduzir exposição sem trocar um risco por uma interrupção evitável.
Antes de aplicar bloqueios, uma etapa de observação pode mapear dependências com os responsáveis pelas aplicações. A proposta é separar tráfego observado de tráfego autorizado: uma conexão frequente não se torna legítima por frequência. Um piloto com escopo limitado, critérios de sucesso e reversão documentada permite ajustar a política antes de ampliar sua cobertura.
Testes de penetração autorizados devem verificar caminhos proibidos, mas também confirmar que as operações essenciais continuam funcionando. No exemplo, tentar uma conexão direta da estação ao banco serve para avaliar a restrição; não exige extrair dados reais nem interromper o serviço. O resultado precisa registrar origem, destino, regra esperada, evidência e responsável pela correção.
Como indicadores propostos, fazem mais sentido a cobertura de ativos críticos validada por testes, as exceções sem revisão e o tempo necessário para conter um cenário ensaiado do que a simples contagem de regras instaladas. Esses indicadores sugeridos medem resultados operacionais, em vez de confundir atividade da equipe com redução de risco.
Conclusão: medir o limite, não presumir a proteção
O objetivo de uma estratégia de segmentação deve ser expresso em resultados verificáveis: comunicações necessárias preservadas, caminhos indevidos interrompidos e capacidade de recuperação demonstrada. A pergunta decisiva não é quantas zonas existem no diagrama, mas quais limites permanecem efetivos quando um componente deixa de ser confiável.
Essa mudança de foco ajuda a aproximar arquitetura e risco de negócio. O desenho mostra a intenção; as permissões, os testes e a operação mostram o controle que a organização realmente possui.
Be the first to comment