NIS2 em profundidade: arquitetura de rede OT/IT para fábricas portuguesas

Um plant manager mostrou-me o rack de comunicações de uma malharia perto de Guimarães: 28 dispositivos ligados ao mesmo switch não gerido. PLCs Siemens, terminais de recolha, uma câmara IP com firmware de 2016, o PC do gabinete da qualidade e — a jóia da coroa — o portátil do técnico da assistência da máquina de tinturaria, com acesso remoto permanente por TeamViewer. Tudo na mesma VLAN. O diagnóstico e o plano já lhe disseram que tem de segmentar. Aqui resolve-se o como: a arquitetura de rede OT/IT em detalhe técnico, ao nível do desenho de zonas, das regras de firewall e dos pitfalls que rebentam projetos.

Antes de avançar, uma nota sobre o público. Este texto não é para o CFO — é para o herói auto-didacta de TI que a maioria das fábricas portuguesas familiares tem em vez de um departamento de segurança. Aquele que sabe onde está cada cabo, quem tem 15 anos de conhecimento de negócio e nenhum diploma de redes, e que vai ser o único a perceber por que razão a linha parou às 14h37 de uma terça-feira. É a essa pessoa que falamos, porque é ela quem vai desenhar e defender a topologia perante um CEO que só quer saber quando é que fica feito e quanto custa.

1: Arquitetura recomendada

A tese deste artigo é simples e desconfortável: a maioria das fábricas portuguesas não precisa de comprar mais firewalls — precisa de parar de tratar a rede OT como uma extensão da rede de escritório. Segmentar não é um produto. É uma decisão de topologia que se paga em VLANs, conduítes e uma DMZ industrial. O hardware que já tem chega, na maioria dos casos, se for reconfigurado com disciplina.

O modelo de referência é o Purdue Enterprise Reference Architecture, consolidado na norma IEC 62443. Não é teoria académica — é a linguagem que o auditor NIS2 vai usar. Organize a rede em zonas hierárquicas:

• Nível 0-1 (OT puro): sensores, atuadores, PLCs, drives. Determinístico, sensível a latência. Nunca fala diretamente com a Internet.
• Nível 2 (supervisão): SCADA, HMIs, historian local, terminais de recolha de produção.
• Nível 3 (operações de fábrica): MES, servidores de aplicação de chão-de-fábrica, gestão de qualidade.
• DMZ industrial (Nível 3.5): a zona-tampão. É aqui que vive tudo o que precisa de atravessar a fronteira OT/IT — replicação de historian, brokers, jump servers.
• Nível 4-5 (IT/enterprise): ERP, e-mail, BI, Internet.

Porque é que o modelo de escritório não serve o chão-de-fábrica

Uma rede de escritório optimiza para conveniência: tudo acessível a partir de tudo, DHCP dinâmico, dispositivos que aparecem e desaparecem. Uma rede OT optimiza para determinismo e disponibilidade. Um PLC não precisa de aceder ao Google. Uma máquina de tinturaria não precisa de fazer update automático a meio de um banho. O erro estrutural que vemos repetido em malharias, confeções e fábricas de moldes é aplicar a lógica do escritório ao chão-de-fábrica — porque foi o mesmo técnico, o mesmo fornecedor de rede, o mesmo switch de gama doméstica que serviu os dois mundos ao longo de 15 anos de crescimento orgânico.

O resultado é uma rede que ninguém desenhou. Cresceu por acreção. Cada máquina nova, cada atualização de linha, cada visita de fornecedor deixou um cabo, uma regra, um acesso remoto que ficou. É por isso que, quando abre o rack, encontra 28 dispositivos numa VLAN plana e uma câmara IP de 2016 a servir de porta de entrada para toda a produção.

A DMZ industrial é a peça que ninguém quer pagar

A regra de ouro: nenhum fluxo atravessa da zona IT para a zona OT sem parar na DMZ. O ERP não lê diretamente do historian do chão-de-fábrica. Lê de uma réplica na DMZ. O KORA Productivity não expõe o terminal industrial à rede de escritório — a captura de OEE flui para um broker na DMZ, e é de lá que o ERP consome.

Se o seu integrador diz que "não é preciso DMZ, mete-se uma regra na firewall", ele está a poupar-lhe dinheiro hoje para lhe custar uma paragem de linha amanhã.

A objeção que vamos ouvir do CFO é previsível: mais um servidor, mais licenças, mais complexidade para uma coisa que "está a funcionar". A resposta honesta é que a DMZ industrial não é um custo de segurança abstrato — é um seguro contra a paragem de linha que já aconteceu a fábricas vizinhas. Quando o ransomware entra pela rede de escritório (que é onde entra quase sempre, via e-mail ou credenciais roubadas), a DMZ é a diferença entre perder o servidor de faturação e perder a produção inteira durante dias. Uma confeção que fornece a Inditex e falha uma janela de entrega não perde só faturação — perde a posição na cadeia de subcontratação, que demora anos a reconquistar.

Segmentação horizontal, não só vertical

Purdue resolve a hierarquia vertical. Mas o transversal — máquina a falar com máquina no mesmo nível — é onde o ransomware se propaga. A tinturaria não tem de comunicar com a linha de corte. Isole células produtivas em micro-segmentos, cada célula na sua VLAN, com o tráfego inter-célula a passar obrigatoriamente pela firewall. Aquela malharia de Guimarães, com uma VLAN plana, permitia que um portátil comprometido varresse os 28 dispositivos em segundos.

A distinção prática entre os dois eixos:

Na prática portuguesa, a maioria das fábricas começa pelo eixo vertical — porque é o que a auditoria NIS2 verifica primeiro — e adia o horizontal por custo. É uma sequência defensável, desde que seja consciente. Adiar a micro-segmentação sem a documentar como risco assumido é diferente de não saber que ela existe.

O caso específico do calçado: linhas sazonais e reconfiguração

Em Felgueiras e S. João da Madeira, a rede OT tem uma característica que as fábricas contínuas não têm: reconfigura-se por coleção. Uma linha de montagem que fez sapato de homem em agosto passa a fazer sapato de mulher em fevereiro, com máquinas diferentes, sensores diferentes, layout diferente. Uma segmentação rígida por porta física morre à primeira mudança de coleção. Aqui a topologia tem de assentar em VLANs lógicas e políticas por perfil de dispositivo, não por localização de cabo. O inventário de ativos deixa de ser um documento estático e passa a ser um processo — cada dispositivo que entra numa linha nova tem de herdar automaticamente a política da célula onde é ligado.

2: Parâmetros, métricas e thresholds

Números que separam um projeto real de um slide. Em 2024 o CERT.PT registou 2.758 incidentes de cibersegurança em Portugal, mais 36% do que em 2023, e cerca de 78% em entidades privadas (Fonte: CNCS, 2024). A indústria não está fora do radar — está no centro.

O threshold operacional que os manuais não referem: acima de ~200 endpoints em rede, o agente leve de EDR deixa de chegar. A partir dessa dimensão precisa de correlação centralizada (SIEM) e de segmentação por firewall dedicada, não de regras num router de PME. Abaixo disso, uma firewall industrial de gama média e VLANs bem desenhadas resolvem 90% do risco.

Latência: onde a segurança colide com a produção

O número que quebra projetos é a latência. Um técnico de IT sem experiência de OT desenha uma segmentação limpa, mete inspeção profunda em todo o tráfego, e descobre que o controlo de movimento de uma máquina de bordado passou a ter jitter. A regra prática: quanto mais baixo o nível Purdue, mais determinística tem de ser a rede. O tráfego de controlo em tempo real (Nível 0-1) não pode passar por inspeção profunda — inspeciona-se na fronteira das zonas, não dentro da célula OT. Uma firewall que introduz 15 ms de latência é irrelevante entre IT e DMZ, e catastrófica entre um drive e o seu PLC.

A firewall mais segura do mundo, mal colocada, transforma-se numa causa de defeitos de produção que ninguém consegue explicar durante semanas.

O ponto cego do NTP

Sem relógios sincronizados, os logs são inúteis num incidente. Se o PLC diz 14:03 e a firewall diz 14:11, ninguém reconstrói a cadeia de eventos. Force um servidor NTP interno na DMZ e proíba os dispositivos de sincronizar com relógios externos aleatórios.

O NTP tem uma segunda consequência que a maioria ignora: sem tempo sincronizado, o cálculo de OEE mente. Se o terminal de recolha regista o início de uma paragem com o relógio errado, o tempo de disponibilidade fica distorcido, e a métrica que devia orientar o Lean vira ficção. Segurança e produtividade partilham a mesma dependência — o que é raro e conveniente, porque justifica o investimento em NTP perante quem só se importa com produção.

Dimensionar a retenção de logs sem falir

Doze meses de logs parecem simples até calcular o volume. Uma fábrica de 150 endpoints com logging razoável gera gigabytes por dia. A tentação é reduzir o que se regista — e é aí que se perde a capacidade de investigar. A abordagem defensável: logging completo com retenção curta em armazenamento rápido, mais retenção longa comprimida e barata para conformidade. O que a NIS2 e a ISO 27001 exigem é que os logs existam e estejam íntegros quando forem precisos, não que estejam todos numa base de dados quente.

3: Configuração prática

Snippets ilustrativos. A lógica importa mais do que a sintaxe do seu fornecedor específico.

Definição de VLANs por zona num switch gerido — separação de célula produtiva, supervisão e DMZ:

# VLAN 10 - OT célula tinturaria (PLCs + drives)
VLAN 20 - OT célula malhas
VLAN 30 - Supervisão (SCADA/HMI)
VLAN 50 - DMZ industrial (brokers, réplica historian)
VLAN 100 - IT escritório

vlan 10
 name OT_TINTURARIA
vlan 20
 name OT_MALHAS
vlan 30
 name SUPERVISAO
vlan 50
 name DMZ_IND
vlan 100
 name IT_ESCRITORIO

Porta do PLC: acesso puro, sem trunk, sem DHCP dinâmico
interface GigabitEthernet0/5
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 # bloqueia negociação — evita VLAN hopping
 switchport nonegotiate

Regra de firewall na fronteira: default deny, e só o fluxo estritamente necessário do ERP para a réplica na DMZ (nunca para o historian real):

# Política base: negar tudo entre zonas
Só o ERP (IT) fala com o broker OPC-UA na DMZ, porta 4840

PERMITIR: IT -> DMZ (leitura de produção via broker)
allow src 100.0.0.0/24 dst 50.0.0.10 port 4840 proto tcp

PERMITIR: DMZ -> OT supervisão (pull do historian, unidirecional)
allow src 50.0.0.10 dst 30.0.0.5 port 4840 proto tcp

NEGAR EXPLICITAMENTE: IT nunca toca no OT diretamente
deny src 100.0.0.0/24 dst 10.0.0.0/22 proto any
deny src 100.0.0.0/24 dst 30.0.0.0/24 proto any

NEGAR: OT nunca inicia sessão para a Internet
deny src 10.0.0.0/22 dst 0.0.0.0/0 proto any
log deny all

Porquê default deny e não default allow

A diferença entre default deny e default allow com exceções é a diferença entre uma rede que sabe o que faz e uma que reza para que nada corra mal. Com default allow, cada ameaça nova exige uma regra nova para a bloquear — está sempre atrasado. Com default deny, tudo o que não foi explicitamente autorizado está bloqueado por defeito, e a única forma de um fluxo existir é alguém tê-lo pensado e escrito. É mais trabalho no início e infinitamente menos trabalho depois. O custo real do default deny não é técnico — é o mapeamento prévio de todos os fluxos legítimos, que a secção 4 detalha e que a maioria das fábricas nunca fez.

O direccionamento do fluxo importa tanto como a porta

Repare, no snippet acima, que a regra DMZ → OT é pull unidirecional: é a DMZ que puxa do historian, nunca o OT que empurra para a DMZ. Esta distinção parece pedante e é fundamental. Se for o OT a iniciar a ligação, um PLC comprometido pode usar essa ligação para exfiltrar ou para pedir instruções. Se for a DMZ a puxar, o PLC nunca inicia nada — responde apenas a pedidos legítimos de uma zona de confiança superior. Nos casos de segurança mais exigente usa-se um data diode, hardware que fisicamente só deixa passar dados numa direção. Para a maioria das fábricas têxteis, uma regra de firewall unidirecional bem escrita é suficiente e muito mais barata.

Acesso remoto do técnico da assistência — o vetor mais perigoso e mais ignorado. Nada de TeamViewer permanente. Um jump server na DMZ, acesso por VPN com MFA, e a sessão só existe quando é aberta:

# Fluxo de acesso do fornecedor externo:
1. VPN com MFA -> DMZ apenas (nunca direto ao OT)
2. Jump server regista sessão (gravação de ecrã)
3. Acesso à máquina só na janela autorizada, depois revoga

Regra: fornecedor entra na DMZ, salta para 1 PLC específico
allow src VPN_FORNECEDOR dst 50.0.0.20 port 22 proto tcp
allow src 50.0.0.20 dst 10.0.0.15 port 102 proto tcp  # só este PLC
Tudo o resto: negado + log

O problema político do acesso do fornecedor

Tecnicamente, o jump server com janela e gravação resolve o acesso remoto. Politicamente, é onde os projetos morrem. O fornecedor da máquina de tinturaria alemã ou italiana vai resistir — o contrato de assistência dele assume acesso permanente, a garantia depende de ele poder entrar quando quiser, e a fábrica tem medo de perder o suporte. A resposta é contratual, não técnica: renegociar o SLA de assistência para incluir o procedimento de acesso via jump server. O que se ganha em troca é gravação de sessão — prova documental de tudo o que o fornecedor fez na sua máquina, útil quando há uma avaria e a discussão é sobre quem mexeu no quê. Vender o jump server ao fornecedor como proteção mútua costuma desbloquear a resistência.

4: Integrações e dependências

O erro clássico da segmentação é fazê-la e descobrir que partiu integrações que ninguém documentou. Antes de cortar, mapeie todos os fluxos. O que liga onde, numa fábrica têxtil típica:

O inventário de fluxos que ninguém tem

A tabela acima parece óbvia depois de escrita. O problema é que quase nenhuma fábrica portuguesa a tem antes de começar a segmentação. Os fluxos existem na cabeça do técnico que os configurou — muitas vezes um fornecedor que já não trabalha com a empresa — e em nenhum documento. A fase de mapeamento é a mais aborrecida e a mais importante do projeto todo. Fá-lo com captura de tráfego real durante um ciclo produtivo completo, não com o que as pessoas dizem que a rede faz. Numa fábrica de confeção, descobrimos um fluxo entre o software de corte automático e uma partilha de ficheiros que ninguém mencionou porque "sempre funcionou assim" — e que, cortado sem aviso, teria parado o corte de toda a coleção.

Numa fábrica com 15 anos de crescimento orgânico, a rede real e a rede que as pessoas descrevem são dois mapas de dois países diferentes.

A dependência do relógio que arrasta o BI

A dependência que se esquece sempre: a captura de OEE do KORA Productivity depende do relógio sincronizado. Se segmentar e cortar o acesso ao NTP, os dados de cycle time ficam desalinhados e o BI mente. Para quem faz Lean Manufacturing a sério, um historian dessincronizado é pior do que não ter historian.

Esta é a razão pela qual a segmentação não pode ser um projeto de IT isolado. Quem desenha a rede tem de perceber o que corre em cima dela. Cortar o acesso ao NTP para "endurecer" o OT parece prudente até o diretor de produção descobrir, três semanas depois, que os relatórios de eficiência que usa para negociar com a casa-mãe deixaram de bater certo. A segmentação bem feita preserva todas as dependências legítimas — e a única forma de as preservar é conhecê-las.

Replicação entre unidades: túneis dedicados, não partilhados

Para fábricas com múltiplas unidades, a replicação entre filiais via Multi Connect tem de passar por túneis dedicados, não pela mesma VPN dos técnicos externos. Misturar os dois é convite a movimento lateral. Uma empresa têxtil com fiação num concelho e acabamentos noutro tem tráfego legítimo, constante e de confiança elevada a atravessar entre unidades. Esse tráfego merece o seu próprio túnel, com as suas próprias regras, separado do acesso pontual e de menor confiança dos fornecedores externos. Colapsar tudo numa VPN única é conveniente de configurar e desastroso de defender — porque significa que comprometer o acesso de um fornecedor abre caminho à rede inter-filiais inteira.

5: Armadilhas operacionais

O que vimos rebentar em produção, anonimizado.

• VLAN plana com "só um dispositivo temporário". A câmara IP de 2016 nunca é temporária. Numa distribuidora do corredor Lousada/Paços, uma câmara com firmware vulnerável foi a porta de entrada. Regra: inventário obrigatório, e nada entra na rede OT sem VLAN atribuída.
• Patching agressivo no OT. Uma equipa de IT aplicou um update de Windows a um HMI a meio do turno. Linha parada 4 horas. O OT faz patching em janela programada, testado primeiro, nunca automático.
• Firewall sem inspeção de protocolos industriais. Uma firewall "enterprise" comum vê Modbus e S7comm como tráfego opaco. Deixa passar comandos de escrita para um PLC como se fossem bytes inócuos. Precisa de DPI industrial na fronteira.
• Acesso remoto do fornecedor sempre ligado. O TeamViewer permanente da tinturaria. O contrato de assistência exige acesso — o que não exige é que esteja aberto 24/7. Jump server, janela, gravação, revogação.
• Documentação de fluxos inexistente. Segmentaram uma fábrica de calçado em Felgueiras e o planeamento de produção deixou de puxar dados. Ninguém sabia que o MES lia diretamente de uma partilha de ficheiros no PLC. Mapeie antes de cortar.
• NTP ignorado. Já descrito. Sem tempo sincronizado, o SIEM é decorativo e o relatório das 72h da NIS2 é ficção.
• Wi-Fi de chão-de-fábrica ligado à VLAN de escritório. Os terminais móveis de armazém do KORA Inventory num SSID que também serve o telemóvel pessoal de quem passa. Separe SSIDs por VLAN, com autenticação por certificado nos terminais.
• Chief de armazém tirado do rádio. Não é técnico, é humano — mas mata rollouts. Qualquer reconfiguração de rede que corte a comunicação dos terminais de picking mais de duas horas gera revolta e sabotagem passiva. Faça a migração de VLAN dos terminais fora do horário de operação.

A armadilha do "dispositivo desconhecido" que ninguém pode desligar

Quando finalmente monta a monitorização de rede, vai encontrar dispositivos que ninguém identifica. Um IP que responde, gera tráfego, e nenhuma pessoa na fábrica sabe o que é. A tentação de desligar "para ver quem se queixa" é forte e perigosa — pode ser o controlador de uma balança de expedição, o sensor de temperatura de uma câmara, ou o PLC de uma máquina que só corre uma vez por mês. A regra: nunca desligue um dispositivo desconhecido em produção. Isole-o numa VLAN de quarentena com logging total, observe o que tenta comunicar, e reconstrua a sua função a partir do tráfego. A paciência aqui evita a paragem que a pressa provoca.

A armadilha humana: o rollout que a fábrica sabota

A última armadilha da lista merece expansão porque é a que subestimamos mais. O chief de armazém no corredor Lousada/Paços, o operador de tinturaria com 30 anos de casa, a costureira que sabe que "aquele terminal demora sempre um bocadinho a arrancar de manhã" — estas pessoas não vão ler o seu diagrama Purdue. Vão sentir a diferença no dia em que o terminal deixa de responder ou a rede fica lenta durante o turno. E a resposta delas não é abrir um ticket — é contornar. Voltar ao papel, usar o telemóvel pessoal, pedir ao fornecedor para "arranjar uma maneira mais rápida". A segmentação tecnicamente perfeita que ignora a operação real é sabotada em silêncio até deixar de proteger o que quer que seja.

Nenhuma arquitetura de rede sobrevive ao contacto com um turno de produção que não foi avisado. Migre fora de horas, comunique antes, e tenha um plano de recuo pronto para as 6h da manhã seguinte.

6: Decisão técnica final

Sem hedging. A escolha de arquitetura conforme a dimensão e o setor:

O erro de sobredimensionar tanto quanto o de subdimensionar

Há uma tentação, sobretudo depois de um susto, de comprar tudo: SIEM, SOC gerido, micro-segmentação total, para uma confeção de 40 pessoas. É deitar dinheiro que faz falta na produção a um problema que VLANs bem desenhadas e uma firewall industrial resolvem. O SIEM que ninguém tem competência para operar é pior do que não ter SIEM — gera alertas que ninguém lê e uma falsa sensação de segurança. Dimensione a arquitetura ao risco real e à capacidade real de a operar, não ao medo. Uma fábrica que segmenta bem com meios modestos está mais segura do que uma que comprou ferramentas caras que não sabe usar.

O financiamento que muda o cálculo

A dimensão que a tabela não captura é o financiamento. Investimentos em cibersegurança e digitalização industrial encaixam frequentemente nos instrumentos do PT2030, do PRR e do COMPETE 2030 — o que altera o cálculo de retorno. Uma DMZ industrial e a reconfiguração de rede que num orçamento próprio são adiadas "para o ano que vem" tornam-se viáveis quando entram num projeto de digitalização candidatado a comparticipação. O que trava estas candidaturas não costuma ser a elegibilidade — é o relatório técnico. Uma memória descritiva que fundamente a arquitetura em IEC 62443 e nas obrigações da NIS2 passa o crivo técnico com muito menos atrito do que uma que peça "melhorar a segurança" sem topologia definida.

Se tem mais de 50 colaboradores num setor crítico e ainda não tem DMZ industrial, não está atrasado na NIS2 — está exposto. São coisas diferentes, e a segunda custa mais.

Sequência de implementação recomendada

Para quem tem de fazer isto sem parar a fábrica, a ordem que funciona:

1. Inventário de ativos e captura de tráfego durante um ciclo produtivo completo. Nunca corte antes de mapear.
2. Desenho lógico das zonas e do inventário de fluxos legítimos, validado com produção e com os fornecedores de máquinas.
3. Montagem da DMZ e das réplicas, em paralelo com a rede existente, sem cortar nada ainda.
4. Migração de VLANs fora do horário de operação, célula a célula, com plano de recuo por cada passo.
5. Substituição do acesso remoto permanente por jump server, renegociando SLAs com os fornecedores.
6. Ativação do default deny na fronteira só depois de todos os fluxos legítimos estarem confirmados a funcionar.
7. Logging, NTP e retenção — a base da conformidade e da capacidade de investigação.

Para o rigor documental que a auditoria ISO 27001 exige, cruze esta arquitetura com consultoria certificada em ISO 27001 e RGPD. E se está a avaliar isto no contexto de uma operação de M&A, a auditoria prévia tecnológica deve validar a segmentação como critério de risco, não como detalhe.

7: Como a INFOS implementa

Trabalhamos a partir do dentro: conhecemos como o ERP MULTI, o KORA Productivity e o Qlik Sense falam com o chão-de-fábrica, portanto desenhamos a segmentação sem partir integrações — a réplica na DMZ, os fluxos OPC-UA, a sincronização de tempo, tudo mapeado antes de cortar. A nossa equipa de cibersegurança e rede cruza a arquitetura Purdue/IEC 62443 com as obrigações concretas da NIS2 e da ISO 27001, e valida a topologia contra o guia de infraestrutura de TI industrial. Software vertical e rede desenhados pela mesma casa — porque quem não sabe onde flui o dado de produção não devia estar a decidir onde passa a firewall.

A diferença que sentimos no terreno é esta: um integrador de rede generalista desenha uma topologia limpa e depois descobre, tarde demais, que partiu a captura de OEE ou a replicação entre filiais, porque não sabia que existiam. Nós começámos pelo outro lado — sabemos onde flui cada dado de produção porque escrevemos o software que o gera. Essa ordem inverte o risco. Em vez de segmentar e rezar para não partir nada, segmentamos preservando conscientemente cada dependência legítima, porque as conhecemos uma a uma antes de tocar numa única regra de firewall.

Fontes

• Diretiva (UE) 2022/2555 (NIS2), Jornal Oficial da União Europeia; transposição nacional pelo Decreto-Lei n.º 125/2025, Diário da República.
• Centro Nacional de Cibersegurança (CNCS) / CERT.PT — Relatório de incidentes 2024.
• IBM Security — Cost of a Data Breach Report 2024.
• Verizon — Data Breach Investigations Report (DBIR) 2025.
• ISC2 — Cybersecurity Workforce Study 2024.
• IEC 62443 — Security for industrial automation and control systems; Purdue Enterprise Reference Architecture.

Perguntas frequentes

O que é a arquitetura Purdue e por que é importante para a NIS2?

A arquitetura Purdue é um modelo de referência que organiza a rede industrial em zonas hierárquicas, da produção (Nível 0-1) até à empresa (Nível 4-5). É a linguagem que o auditor NIS2 utiliza para avaliar a segmentação da rede. O artigo refere que este modelo está consolidado na norma IEC 62443 e é essencial para demonstrar conformidade regulatória.

Qual é a diferença entre segmentação vertical e horizontal?

A segmentação vertical separa os níveis IT, DMZ e OT para bloquear ataques que descem do escritório. A horizontal isola células produtivas entre si, impedindo propagação lateral de ransomware. O artigo indica que a maioria das fábricas portuguesas começa pela vertical, mas adiar a horizontal sem documentar o risco é uma falha de governança.

Por que motivo uma rede de escritório não funciona no chão-de-fábrica?

A rede de escritório otimiza para conveniência (tudo acessível, DHCP dinâmico), enquanto a OT exige determinismo e disponibilidade. Um PLC não precisa de aceder à Internet, e uma máquina de tinturaria não pode fazer updates automáticos durante um banho. Aplicar a lógica do escritório causa crescimento descontrolado da rede, como exemplificado na malharia de Guimarães.

O que é a DMZ industrial e por que é crítica?

A DMZ industrial é uma zona-tampão (Nível 3.5) onde vive tudo que precisa de atravessar a fronteira OT/IT — replicação de historian, brokers, jump servers. Nenhum fluxo deve ir diretamente do IT para o OT. O artigo alerta que sem DMZ, um ransomware que entra pelo escritório pode comprometer toda a produção em vez de apenas a faturação.

É necessário comprar novo hardware para segmentar a rede?

Não. O artigo afirma que a maioria das fábricas portuguesas não precisa de comprar mais firewalls — o hardware existente chega se for reconfigurado com disciplina. Segmentação é uma decisão de topologia que se paga em VLANs, conduítes e reconfiguração, não em novos produtos.

Como se propaga o ransomware numa rede plana como a da malharia de Guimarães?

Numa VLAN plana com 28 dispositivos, um portátil comprometido varre todos os equipamentos em segundos, sem encontrar barreiras. O artigo exemplifica que um técnico de assistência com TeamViewer permanente pode ser o ponto de entrada. A micro-segmentação horizontal obriga o tráfego inter-célula a passar pela firewall, travando a propagação.

Qual é o argumento para convencer o CFO a investir em DMZ industrial?

A DMZ industrial não é um custo de segurança abstrato — é um seguro contra paragem de linha. O artigo refere que quando ransomware entra pela rede de escritório, a DMZ é a diferença entre perder o servidor de faturação e perder a produção inteira. Uma fábrica que falha uma janela de entrega perde a posição na cadeia de subcontratação, que demora anos a reconquistar.