Segmentar redes IT/OT significa separar ativos e fluxos de comunicação de tecnologia da informação (IT) e tecnologia operacional (OT) em domínios de segurança definidos conforme função, criticidade e consequências de incidentes. Em ambientes industriais, a segmentação não se resume a configurar VLANs: exige inventário de ativos, caracterização dos fluxos necessários, modelagem de zonas e conduítes, […]
Confira!
Segmentar redes IT/OT significa separar ativos e fluxos de comunicação de tecnologia da informação (IT) e tecnologia operacional (OT) em domínios de segurança definidos conforme função, criticidade e consequências de incidentes. Em ambientes industriais, a segmentação não se resume a configurar VLANs: exige inventário de ativos, caracterização dos fluxos necessários, modelagem de zonas e conduítes, políticas de acesso, mecanismos de filtragem e testes que comprovem simultaneamente proteção e continuidade do processo. A família ISA/IEC 62443 oferece uma base para definir o sistema sob consideração, analisar riscos e estabelecer zonas e conduítes. A engenharia deve combinar segregação lógica e física, conforme risco, requisitos de disponibilidade e tolerância dos sistemas existentes.
O problema técnico: conectividade necessária e exposição excessiva
Muitas redes industriais evoluíram por expansão sucessiva de máquinas, estações de engenharia, supervisórios, servidores históricos, sistemas corporativos e acessos remotos de fornecedores. A conectividade frequentemente surge antes da documentação de interfaces. Como resultado, um segmento inicialmente destinado à supervisão pode passar a transportar manutenção remota, atualização de softwares, dados de produção e acesso administrativo, sem fronteiras explícitas entre usuários e serviços. O risco não é abstrato: um erro de configuração, credencial comprometida ou tráfego indevido pode propagar efeitos entre domínios com requisitos muito diferentes.
A primeira decisão de projeto é identificar aquilo que precisa se comunicar, por qual protocolo, com qual destino, sob qual responsabilidade e em que condição operacional. Bloquear todo o tráfego entre IT e OT seria inviável em muitos processos; permitir comunicação irrestrita, por sua vez, elimina a utilidade de uma arquitetura segmentada. O resultado esperado é um conjunto mínimo, justificável e verificável de caminhos autorizados, com controles proporcionais ao impacto de sua indisponibilidade ou comprometimento.
Zonas e conduítes segundo a abordagem ISA/IEC 62443
| Componente | Definição de projeto | Evidência para aceite |
|---|---|---|
| Zona OT | Ativos com requisitos comparáveis de segurança | Inventário e diagrama validado |
| Conduíte | Comunicação necessária entre zonas | Matriz de fluxos aprovada |
| Controle de fronteira | Regras de inspeção e autorização | Configuração e testes negativos |
| Exceção | Permissão restrita com responsabilidade | Prazo e registro de aprovação |
Quando a rede industrial não possui inventário confiável, a segmentação pode interromper comunicações essenciais. Antes de definir zonas e conduítes, é necessário identificar ativos, fluxos legítimos, dependências operacionais e requisitos de continuidade. Uma avaliação independente permite estabelecer prioridades, riscos e uma baseline verificável para o projeto.
A avaliação da condição existente define premissas verificáveis antes do desenvolvimento do projeto, reduzindo incertezas e risco de incompatibilidades.
Quando informações sobre a condição existente e as interfaces são insuficientes, a estimativa de esforço e a seleção da arquitetura tornam-se frágeis. Um diagnóstico técnico permite quantificar os riscos antes do projeto.
Uma zona reúne ativos que compartilham requisitos de segurança comparáveis. Um conduíte representa o agrupamento de canais de comunicação sujeitos a requisitos de proteção comuns entre zonas. Na prática, a organização deve distinguir, por exemplo, estações corporativas, serviços intermediários, operações industriais, células de automação e sistemas instrumentados de segurança quando pertinentes. Não há topologia única imposta a todos os empreendimentos: os limites decorrem da análise de riscos e das funções do processo.
O modelo começa pelo sistema sob consideração, seguido do levantamento de ativos, dependências e pontos de entrada. As zonas devem ser descritas com seu propósito, proprietários, criticidade, interfaces e pressupostos de confiança. Cada conduíte deve registrar origem, destino, protocolo, direção, justificativa operacional, método de autenticação, ponto de fiscalização e condição de contingência. A classificação de risco precede a seleção de equipamentos.
VLANs, ACLs, roteamento e firewalls têm funções distintas
A VLAN cria domínios de broadcast e permite organizar segmentos lógicos em infraestrutura compartilhada. Isoladamente, contudo, não comprova a existência de uma política de segurança completa. Roteamento entre VLANs pode restabelecer ampla conectividade caso as regras sejam permissivas; equipamentos mal geridos, trunks inadequados e acessos administrativos compartilhados podem comprometer a separação pretendida. O projeto precisa demonstrar o comportamento do tráfego interzona, não apenas a distribuição de VLAN IDs.
ACLs oferecem filtragem em interfaces e equipamentos de rede conforme parâmetros suportados. São úteis para estabelecer limites, mas normalmente exigem controle rigoroso de ordenação, endereçamento e gestão de mudanças. Firewalls industriais ou outros controles específicos podem proporcionar inspeção, registro e políticas de comunicação conforme o equipamento e os protocolos envolvidos. A decisão entre ACLs, firewall, segmentação física e mecanismos adicionais depende do cenário, das propriedades dos protocolos e da capacidade de operação e manutenção.
Separação física pode ser justificável em domínios cuja consequência de comprometimento ou indisponibilidade não seja aceitável em infraestrutura compartilhada. Isso não elimina a necessidade de controlar os pontos legítimos de intercâmbio. A engenharia precisa identificar também tráfego de broadcast, multicast, descoberta de dispositivos, sincronismo de tempo, dependências de DNS, licenças, autenticação e atualização, frequentemente omitidos em desenhos simplificados.
DMZ industrial, acesso remoto e fornecedores
A DMZ industrial pode abrigar serviços de intermediação entre redes corporativas e zonas de operação, reduzindo comunicações diretas. Sua existência não basta: devem ser definidos os serviços efetivamente hospedados, a direção dos fluxos, os mecanismos de autenticação, a gestão de patches e o monitoramento. Historiadores replicados, servidores de transferência, jump hosts e serviços de atualização exigem análise individual de exposição e continuidade.
Acesso remoto de integradores e fabricantes demanda procedimentos próprios: identidade individual, autorização temporária, janela de manutenção, registro das sessões, restrição de destinos e revogação ao término. O ponto de entrada não pode ser uma exceção permanente à arquitetura. Sistemas legados podem impor limitações técnicas, o que exige medidas compensatórias documentadas e testes compatíveis com as condições de produção.
Método de engenharia: do levantamento ao comissionamento
O projeto de segmentação precisa ser verificável antes da implantação. A matriz de fluxos deve vincular requisitos de segurança, responsabilidades, regras de acesso e critérios de aceitação. A engenharia consultiva auxilia na definição dessas interfaces e na revisão de alternativas, reduzindo ajustes improvisados em redes críticas.
Os requisitos devem ser transformados em documentação técnica compatível com contratação, implantação, fiscalização e testes.
Os requisitos precisam ser convertidos em documentos de engenharia capazes de orientar contratação, implantação, fiscalização e testes de aceite.
Levantamento e diagnóstico: identificar ativos, firmware, endereçamento, topologia, dependências e responsáveis; distinguir evidências observadas de informações não verificadas.Análise funcional e de risco: classificar criticidade, consequências, ameaças, requisitos de disponibilidade e restrições de manutenção.Arquitetura conceitual: definir zonas, conduítes, domínios administrativos e pontos de aplicação de políticas.Projeto detalhado: estabelecer diagramas lógicos e físicos, endereçamento, VLANs, rotas, ACLs, firewalls, integrações e critérios de reversão.Implementação controlada: executar mudanças em janelas aprovadas, com backups, plano de retorno e responsabilidade definida.Testes e aceite: verificar fluxos permitidos e negados, comportamento sob falhas, disponibilidade do processo e rastreabilidade das configurações.Operação: manter inventário, política de exceções, revisão periódica de regras e procedimento de gestão de mudanças.
O comissionamento deve contemplar testes positivos — comunicação indispensável funcionando nas condições previstas — e negativos — comunicações não autorizadas efetivamente impedidas. É necessário registrar as exceções, pois uma regra temporária não tratada pode se tornar uma vulnerabilidade permanente. O resultado de um teste de laboratório não substitui análise dos efeitos de alterações em ambiente operacional.
Riscos de projeto e critérios de aceite
| Risco | Possível consequência | Verificação |
|---|---|---|
| Permissão excessiva | Movimentação não autorizada | Teste negativo interzona |
| Protocolo não documentado | Interrupção de processo | Teste positivo funcional |
| Falha de equipamento comum | Perda de comunicação crítica | Teste de recuperação |
| Mudança sem registro | Perda de rastreabilidade | Revisão de configuração e As-Built |
Uma arquitetura aparentemente segura pode falhar por depender de credenciais compartilhadas, rotas de contingência não documentadas ou dispositivos sem capacidade de aplicar controles previstos. Também há o risco inverso: filtros projetados sem conhecer protocolos industriais podem afetar supervisão, comandos, alarmes e sincronismo. Por isso, cada requisito deve estar associado a sua fonte, consequência e evidência de verificação.
O pacote de aceite deve conter baseline da rede, inventário validado, matriz de comunicações, diagramas revisados, políticas implementadas, casos de teste, resultados, exceções aceitas e instruções de operação. A rastreabilidade entre requisito, configuração e teste é mais informativa do que a simples entrega de um arquivo de configuração do firewall.
Como contratar a engenharia de segmentação IT/OT
O recebimento técnico deve demonstrar coerência entre baseline, projetos, resultados de testes e condição construída, mantendo rastreabilidade de pendências.
Um escopo consultivo deve começar pela definição do perímetro técnico e do inventário disponível. Se a documentação da condição existente for insuficiente, o levantamento precisa ser tratado como etapa contratual própria, evitando orçamento baseado em premissas indefinidas. A contratação deve explicitar estudos de risco, workshops com operação e TI, diagramas e matrizes de fluxo, requisitos dos equipamentos, critérios de compatibilidade e plano de migração sem interrupção indevida da planta.
Também devem ser definidos entregáveis de projeto, responsabilidade pelas configurações, acompanhamento de implantação, testes integrados, procedimento de rollback, As-Built e treinamento de operação. O aceite não deve depender apenas de um desenho: requer evidências de implementação, teste e conformidade com os requisitos acordados.
Política de conduítes: da análise de risco às regras técnicas
A implementação das regras não comprova, isoladamente, que a rede está segura e operacional. Testes positivos e negativos devem demonstrar a disponibilidade dos fluxos necessários e o bloqueio das comunicações indevidas, registrando exceções, pendências e a configuração As-Built.
O aceite deve confrontar as funções requeridas com a configuração e os resultados efetivamente demonstrados, mantendo rastreabilidade de pendências.
A engenharia deve começar pela identificação do sistema sob consideração e de suas interfaces com redes externas, recursos de manutenção e fornecedores. Zonas agrupam ativos com requisitos de segurança comparáveis; conduítes representam comunicações sujeitas a controles. Uma zona pode conter vários segmentos de rede, e uma VLAN não constitui automaticamente uma zona de segurança. O documento de arquitetura precisa demonstrar quais ativos pertencem a cada zona e por que suas necessidades de disponibilidade, integridade e controle de acesso são compatíveis.
A matriz de conduítes deve documentar os serviços autorizados, quem inicia a comunicação, o que acontece em caso de falha, onde a política é aplicada e como será auditada. Quando não houver evidência suficiente de um fluxo, ele deve constar como pendência de levantamento; não se deve transformá-lo em permissão ampla e permanente. Em ambientes legados, uma exceção pode ser necessária, mas precisa de responsável, medida compensatória, prazo e critério de reavaliação. Esse modelo permite que a arquitetura seja utilizada para especificação, implantação e fiscalização, em vez de permanecer apenas um desenho conceitual.
Redundância, capacidade e tráfego de protocolos industriais
Em redes industriais, nem todo equipamento tolera inspeção profunda ou mudanças rápidas de topologia. Protocolos podem utilizar comunicações periódicas, multicast, descoberta local e dependências temporais que não aparecem em testes superficiais. O projeto deve registrar requisitos do fabricante e comportamento das aplicações em condição nominal e após perda de conectividade. Ao inserir firewalls, gateways ou roteadores, a engenharia precisa avaliar throughput, latência, tratamento de tráfego, capacidade de conexões e retomada de sessões.
Um conjunto de dois firewalls em alta disponibilidade pode continuar vulnerável à alimentação comum, a um único enlace, a falha da configuração replicada ou ao próprio mecanismo de failover. Por isso, a análise de disponibilidade deve considerar pontos comuns de falha e procedimentos de manutenção. Em determinadas instalações, a separação física ou uma topologia mais simples pode ser preferível à adição de componentes complexos, desde que preserve os requisitos de segurança. A escolha deve ser justificada pelo processo industrial, pela análise de riscos e pelos ensaios que poderão ser executados com segurança.
Acesso de fornecedores e administração segura
O acesso remoto de fabricantes é uma necessidade operacional frequente, mas também um dos caminhos possíveis para introdução de riscos na rede industrial. O desenho deve definir como se identifica o usuário, quais ativos ele pode alcançar, em que período, com qual autorização e que evidência será preservada. Estações intermediárias administradas, autenticação apropriada e registros podem ajudar a concentrar controles, desde que a própria infraestrutura de acesso seja protegida e mantida.
A identidade e a autorização não devem ficar implícitas em uma conta compartilhada ou em uma conexão VPN permanente. O processo precisa contemplar revogação, alteração de profissionais, atividades emergenciais e acesso sem conectividade externa. Também deve prever como eventos de segurança serão investigados sem comprometer indiscriminadamente o controle de processo. A governança de mudanças mantém a relação entre política aprovada, configuração operante, justificativas e procedimentos de restauração, reduzindo a chance de permissões excepcionais se tornarem permanentes.
Planejamento de implantação, testes e comissionamento
Uma migração controlada começa com validação da baseline, backup de configurações e identificação dos processos afetados. Deve existir uma sequência de implantação por zona ou conduíte, com critérios para avançar, interromper ou reverter. O plano precisa identificar responsáveis da operação, automação, redes, segurança e fornecedores. Uma arquitetura que atende ao objetivo teórico pode ser inadequada à implantação se exige uma parada de produção não prevista.
O aceite precisa incluir testes positivos e negativos, desempenho sob carga representativa quando aplicável, failover e recuperação. Um resultado positivo de conectividade não comprova isolamento; da mesma maneira, o bloqueio de uma porta não comprova que todo tráfego indevido está impedido. Os registros devem informar cenário, origem, destino, versão das regras, resultado esperado, evidência e responsável pela aprovação. A entrega final reúne topologia As-Built, matriz de comunicação, configurações aprovadas, backup, registro de pendências e procedimento de administração da arquitetura.
Critérios de contratação para engenharia consultiva
O escopo deve separar levantamento, análise de risco, arquitetura, projeto detalhado, acompanhamento da implantação e verificação independente. O esforço varia com número de ativos e dependências, diversidade de protocolos, qualidade da documentação, necessidade de observação em campo e restrições para testes. Contar switches ou VLANs é insuficiente para estimar uma tarefa que depende de análise de interfaces e continuidade operacional.
Se o inventário e os requisitos não estiverem documentados, uma etapa preliminar de diagnóstico pode reduzir premissas e contingências na contratação do projeto. A proposta deve especificar entregáveis e exclusões, responsabilidades de configuração, interface com fabricantes, critérios de teste, formatos de As-Built, riscos de acesso e janelas de intervenção. Uma revisão técnica independente pode ser contratada para verificar se as decisões efetivas correspondem ao projeto aprovado, especialmente em infraestrutura industrial crítica.
Critérios de aceitação para zonas e conduítes
Em uma instalação de automação, a delimitação de zonas precisa estar ligada a requisitos verificáveis. Uma zona que contém controladores e um servidor de supervisão não deve ser definida apenas porque ambos pertencem ao mesmo setor. A análise deve considerar criticidade, permissões, serviços, consequências de parada e capacidade de administração segura. Entre zonas, cada conduíte deve existir para uma função conhecida; seu projeto precisa definir políticas de bloqueio, observabilidade e resposta a falhas. Regras amplas usadas temporariamente durante migração devem ter expiração e critérios de revisão. O objetivo final é permitir inspeção independente: uma equipe distinta deve conseguir compreender por que cada caminho está aberto e qual requisito operacional sustenta essa decisão.
O requisito de aceite não pode ser reduzido a uma fotografia da tela de firewall. Devem ser apresentados identificadores de regras, matriz aprovada, inventário de ativos, versões de configuração e resultados de testes positivos e negativos. É necessário registrar especialmente conexões de manutenção, servidores compartilhados e interfaces de administração, porque elas podem estabelecer percursos não evidentes no diagrama lógico. A ausência de evidência sobre determinado serviço deve permanecer como pendência técnica e não ser interpretada automaticamente como autorização para tráfego irrestrito.
Indicadores de governança e manutenção da segmentação
Após o recebimento, a arquitetura precisa continuar controlável. Podem ser acompanhados indicadores como quantidade de exceções vencidas, fluxos sem proprietário, regras não utilizadas, divergências entre inventário e rede observada, mudanças emergenciais sem revisão e testes de restauração pendentes. Esses indicadores servem à gestão técnica e não precisam ser transformados em metas arbitrárias. A responsabilidade por acompanhá-los deve ser contratualmente definida, inclusive quando redes, automação e segurança pertencem a departamentos distintos.
O gerenciamento de configuração deve preservar a referência entre requisito, aprovação, equipamento, versão e procedimento de mudança. As alterações operacionais recorrentes fornecem informação para revisão do projeto: se uma célula necessita sempre de um fluxo não previsto, pode haver erro na arquitetura, não apenas inadequação de regra. A revisão periódica deve considerar expansão da planta, atualização tecnológica, novos fornecedores e mudança das consequências de indisponibilidade. Sem esse ciclo, a segmentação tende a deteriorar-se gradualmente e volta a reproduzir a conectividade excessiva que buscava corrigir.
Exemplo de avaliação de uma célula de produção
Imagine uma linha industrial com controladores, supervisório local, servidor de históricos e suporte remoto do fabricante. A equipe inicialmente identifica os equipamentos e entrevista a operação para esclarecer quais fluxos são contínuos, quais ocorrem apenas durante manutenção e quais transportam dados ao ambiente corporativo. A arquitetura define uma zona para a célula, um conduíte para a supervisão autorizada e um caminho intermediado para publicação de históricos. O suporte remoto passa a utilizar acesso com autorização temporal e registro, em vez de roteamento amplo para todos os controladores.
No teste, a supervisão deve continuar apresentando estados corretos quando os controles estão ativos. A tentativa de acesso não autorizado entre o ambiente corporativo e a célula deve falhar, e o fabricante somente deve conseguir o acesso expressamente permitido durante a janela aprovada. A conclusão não é que uma determinada VLAN ou marca de firewall seja universalmente correta, mas que os controles foram derivados de uma análise de risco e demonstrados por resultados reproduzíveis. Esse mesmo raciocínio precisa constar dos documentos de projeto e aceite.
Caso de engenharia: migração controlada de células industriais
Imagine uma planta com células de produção, supervisão central, historiador e acesso remoto do fabricante. Antes de segmentar, a equipe precisa observar os fluxos efetivos e conhecer as tarefas de operação, manutenção e recuperação que dependem da rede. O zoneamento diferencia ativos com requisitos distintos e estabelece conduítes para supervisão, dados corporativos e manutenção. Cada fluxo autorizado é vinculado a finalidade, responsável, prazo quando aplicável e política de registro.
A migração pode começar por uma célula piloto com critérios de aceitação aprovados pela operação. Os testes verificam não apenas o bloqueio de tráfego indevido, mas também alarmes, atualização dos estados no supervisório, recuperação após falha e acesso de manutenção autorizado. Havendo degradação da função de processo, a equipe deve interromper a expansão, registrar a não conformidade e aplicar o procedimento de retorno. A continuidade operacional constitui um requisito de projeto e precisa ser comprovada, não apenas presumida a partir de um desenho de rede.
Responsabilidades e evidências para recebimento
A equipe de automação conhece as funções de controle e os protocolos; redes conhece a arquitetura e a capacidade; segurança estabelece políticas e mecanismos de observação; operação valida impactos e janelas; o responsável pela engenharia integra todas essas entradas em documentação consistente. A matriz de responsabilidades deve explicitar quem autoriza novas permissões e quem pode restaurar uma versão de configuração. Interfaces sem proprietário tornam-se riscos recorrentes em ambientes com diversos integradores.
O pacote de recebimento precisa incluir inventário conciliado, matrizes de zonas e fluxos, topologia As-Built, versão de configuração, relatórios de testes, exceções temporárias e procedimentos de gestão de mudanças. A questão decisiva para a fiscalização não é se houve instalação de dispositivos, mas se os requisitos aprovados são rastreáveis às evidências produzidas. Esse nível de documentação também reduz dependência de profissionais específicos e facilita futuras modernizações.
Considerações finais
A segmentação de redes IT/OT não pode ser avaliada pela quantidade de VLANs ou firewalls. O resultado de engenharia é demonstrar que cada comunicação permitida corresponde a uma função legítima, que as fronteiras escolhidas reduzem os riscos identificados e que a continuidade do processo permanece protegida. Esse julgamento exige considerar controles cibernéticos, segurança operacional e manutenção como partes da mesma arquitetura.
O maior risco está em confundir configuração com projeto. Uma regra instalada sem justificativa, uma exceção sem responsável ou um diagrama incompatível com a rede real comprometem a governança da instalação. Por isso, o recebimento precisa reunir matriz de fluxos aprovada, controles implementados, testes positivos e negativos, tratamento de pendências e As-Built conciliado. São essas evidências que permitem a revisão independente e a evolução controlada da infraestrutura.
Quando o inventário e as dependências de processo são insuficientes, a atuação tecnicamente responsável começa por diagnóstico e levantamento, não pela compra imediata de equipamentos. Quando as premissas estão estabelecidas, projeto e comissionamento devem converter requisitos em comportamentos verificáveis. O objetivo não é alcançar uma segregação abstratamente máxima, mas entregar fronteiras justificadas, seguras e sustentáveis ao longo do ciclo de vida industrial.
Referências técnicas
[1] INTERNATIONAL SOCIETY OF AUTOMATION. ISA/IEC 62443 Series of Standards. Disponível em: https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards.
[2] CISA. Industrial Control Systems. Disponível em: https://www.cisa.gov/topics/industrial-control-systems.
Perguntas frequentes
Com documentação aprovada, matriz de requisitos, evidências de ensaio e registros da condição construída.
Não. A avaliação depende de arquitetura, capacidade, pontos comuns, configuração e cenários de teste.
Quando a baseline é insuficiente para dimensionar a solução e identificar interfaces ou riscos com confiabilidade.
