NIS2 em profundidade: controlos técnicos para a fábrica portuguesa

O diagnóstico está feito. O plano técnico está aprovado pelo trio CEO + CFO + IT. Sabe que a sua fábrica cai debaixo da NIS2 e sabe, em linhas gerais, como a rede OT/IT deve ser segmentada. Falta a parte que ninguém quer escrever num slide: os controlos concretos. Que regra de firewall, que política de retenção de logs, que MFA em que sistema, que RTO para o servidor do MES. Neste artigo, o nível operacional da NIS2 é resolvido em detalhe técnico — parâmetros, snippets, thresholds e as armadilhas que já vimos rebentar em produção.

A tese, e vou pagá-la ao longo do texto: a maioria das fábricas portuguesas falha a NIS2 não por falta de tecnologia, mas por falta de evidência auditável. Tem antivírus, tem backups, tem VPN. O que não tem é a prova, com data e hora, de que aquilo funciona, foi testado e alguém é responsável por ele. A NIS2 não pergunta se tem controlos. Pergunta se os consegue demonstrar quando o CNCS bater à porta depois de um incidente. E aqui a diferença entre o seu nome numa lista de incidentes e o silêncio é a qualidade dos seus registos, não a marca da sua firewall.

Convém pôr números na mesa antes de continuar. O Centro Nacional de Cibersegurança, através do CERT.PT, registou 2.758 incidentes em 2024 — mais 36% do que no ano anterior, com a esmagadora maioria (78%) a incidir sobre entidades privadas. Não é um problema de bancos nem de operadoras de telecomunicações. É um problema da confecção de Barcelos, do armazém de Lousada, da metalomecânica de Águeda. E é sobre esses que a NIS2 e a sua transposição nacional, o Decreto-Lei n.º 65/2025, vão exercer pressão regulatória real — com coimas que, na versão europeia da diretiva, podem chegar a 10 milhões de euros ou 2% do volume de negócios global anual para entidades essenciais.

1. Arquitetura recomendada

Assumo que já leu o diagnóstico e o plano técnico e que a arquitetura de rede OT/IT já está desenhada. O que falta é a camada de controlos que assenta sobre essa segmentação. Pense em três anéis concêntricos, do exterior para o coração da fábrica. Não é uma metáfora bonita para consumo de slide — é a forma como se distribui orçamento, responsabilidade e prioridade de implementação.

Anel 1 — Perímetro e identidade

Firewall de próxima geração na fronteira, MFA obrigatório em tudo o que é acesso remoto e num diretório de identidade central. O erro clássico é ter MFA no e-mail e deixar o acesso ao ERP com utilizador e password partilhados entre três pessoas do armazém. A identidade é o novo perímetro — inclusive para o chefe de armazém que odeia teclar códigos e que vai lutar contra qualquer controlo que o tire do rádio por mais de dois minutos.

O perímetro tradicional — aquele muro entre "dentro" e "fora" da rede — morreu no dia em que o comercial começou a aceder ao ERP do telemóvel na feira de Milão e o integrador da máquina de corte pediu VPN para dar assistência de Itália. Hoje há dezenas de pontos de entrada legítimos. Cada um deles é uma porta. O que muda a segurança não é o número de portas, é saber quem passa por cada uma, quando, e com que autorização. Isso chama-se identidade, e é onde a maioria das fábricas gasta menos e devia gastar mais.

Anel 2 — Rede segmentada e monitorizada

A célula OT (autómatos, terminais de KORA Productivity, balanças, leitores) vive numa VLAN sem saída direta para a Internet. Todo o tráfego OT↔IT passa por um ponto de inspeção. Aqui não há VPN genérica: há túneis específicos, por serviço, com registo. Se um terminal de captura de produção precisa de falar com o ERP, abre-se essa porta e só essa.

Numa fábrica de calçado de Felgueiras, o chão-de-fábrica pode ter facilmente 40 a 60 dispositivos ligados à rede: terminais de picotagem, máquinas de costura computorizadas, balanças de cola, leitores de código de barras nas linhas de montagem, os postos de MES. Cada um destes dispositivos foi comprado numa data diferente, corre software diferente e tem um ciclo de vida diferente do PC de escritório. Metê-los todos na mesma VLAN que o servidor de ficheiros do departamento financeiro é convidar o desastre. A segmentação não é purismo de arquitetura — é contenção de danos. Quando algo entra, e algo vai entrar, a pergunta é: até onde consegue chegar?

Anel 3 — Dados, backup e recuperação

O coração: base de dados do ERP, servidor de ficheiros, imagens dos servidores. Backup 3-2-1, com a cópia imutável fora do domínio. Um ataque de ransomware que apanha o Active Directory apanha, quase sempre, os backups que estão no mesmo domínio. A cópia offline ou imutável é o que separa "restaurámos em 6 horas" de "pagámos".

A regra 3-2-1 é simples de recitar e difícil de cumprir: três cópias dos dados, em dois tipos de suporte diferentes, com uma cópia fora das instalações. A versão moderna acrescenta o "1" imutável — uma cópia que, uma vez escrita, não pode ser alterada nem apagada durante um período definido, nem por um administrador com credenciais válidas. É esta a defesa contra o cenário em que o atacante entra com privilégios de administrador e, antes de cifrar, apaga os backups para forçar o pagamento. Já vimos acontecer. A cópia imutável é o único controlo que resiste a um administrador comprometido.

Uma firewall cara sem logs retidos é um extintor pendurado na parede sem carga. Fica bonito na auditoria visual. Não apaga nada.

A tabela de decisão por anel

Para o trio de decisão CEO + CFO + IT, ajuda ter o esforço e o retorno mapeados por anel antes de aprovar orçamento. Não gaste no anel 3 se o anel 1 está aberto de par em par — mas também não deixe o anel 3 para "a fase 2" que nunca chega.

2. Parâmetros, métricas e thresholds

Aqui está a tabela que devia estar colada ao monitor do seu IT lead. Números defensáveis, alinhados com a lógica da NIS2 e com o que a ISO 27001 espera em termos de controlo operacional. Ajuste ao seu contexto — mas não afrouxe os que estão marcados como críticos.

Os prazos de 24 e 72 horas não são recomendação nossa — são obrigação da Diretiva (UE) 2022/2555, transposta em Portugal pelo Decreto-Lei n.º 65/2025. Falhar a janela de 24 horas de early warning é, por si só, uma falha de conformidade, mesmo que o incidente venha a ser controlado. A diretiva prevê ainda um terceiro momento: o relatório final, até um mês após a notificação inicial, com a descrição completa do incidente, causa raiz e medidas de mitigação aplicadas.

Porquê 15 dias para patches?

Porque abaixo disso a fábrica não consegue testar e agendar paragem sem partir linhas; acima disso, a janela de exposição a exploits conhecidos torna-se indefensável numa auditoria. Quinze dias é o compromisso operacional entre disponibilidade e risco. Para OT com paragem só programável, documente a exceção com compensação (isolamento, monitorização reforçada) — a NIS2 tolera o risco gerido, não o risco ignorado.

Há uma nuance que separa o IT de escritório do OT de chão-de-fábrica. Um servidor de e-mail aplica um patch e reinicia numa madrugada de domingo sem que ninguém repare. Uma máquina de injeção plástica na indústria metal/plástico a meio de uma série de 40.000 peças não se reinicia porque saiu um patch. A paragem tem custo direto — molde a arrefecer, ciclo interrompido, refugo. Por isso o OT vive por outra lógica: quando não pode aplicar o patch no prazo, isole o dispositivo de forma agressiva e monitorize-o como se já estivesse comprometido. É a diferença entre risco ignorado e risco gerido, e a NIS2 vive dessa distinção.

RTO e RPO: traduzir para linguagem de negócio

RTO — Recovery Time Objective — é o tempo máximo que aceita ter o sistema em baixo. RPO — Recovery Point Objective — é a quantidade máxima de dados que aceita perder, medida em tempo. Um RPO de uma hora significa que, no pior cenário, perde a última hora de trabalho registado. Traduza isto para o fim de mês numa confecção perto de Famalicão: se o ERP cai às 16h de dia 30 e o último backup é das 15h, perdeu uma hora de lançamentos de produção numa altura em que meia dúzia de pessoas está a fechar horas, quantidades e faturação de subcontratação para a casa-mãe. Uma hora nesse dia não é uma hora qualquer.

Definir RTO e RPO não é um exercício técnico — é uma decisão de negócio disfarçada de decisão técnica. Quanto mais curtos, mais caros. Um RPO de um minuto exige replicação síncrona; um RPO de 24 horas basta um backup nocturno. A pergunta certa não é "quanto tempo demora a recuperar", é "quanto custa cada hora parada" — e essa pergunta responde-a o CFO, não o administrador de sistemas.

Definir o RTO é uma decisão do CFO travestida de decisão do IT. Quem assina o custo de cada hora de paragem é quem deve assinar o objetivo de recuperação.

3. Configuração prática

Snippets ilustrativos. Sem credenciais, sem IPs reais. Adapte à sua infraestrutura e nunca copie-cole para produção sem revisão.

Segmentação OT: regra de firewall restritiva

# Política por omissão: negar tudo entre VLAN OT e IT.
Só se abre o estritamente necessário, por serviço e destino.

VLAN_OT = 10.20.0.0/24   (terminais chão-de-fábrica)
SRV_ERP = 10.10.5.30     (servidor aplicacional ERP MULTI)

Permitir apenas captura de produção terminal -> ERP (porta app)
allow from VLAN_OT to SRV_ERP port 8443 proto tcp   # HTTPS interno
Negar qualquer saída OT para a Internet
deny  from VLAN_OT to any port any                   # regra final catch-all
Logar tudo o que bate no catch-all (evidência de tentativa)
log   deny VLAN_OT

O princípio operacional aqui chama-se default deny: nega tudo, abre o mínimo. É o inverso da prática comum de "abre tudo e vai fechando o que der problemas", que produz sempre uma rede cheia de portas esquecidas. A regra final que loga o que bate no catch-all não serve só para segurança — serve como diagnóstico. Se um dispositivo legítimo estiver a tentar comunicar e a falhar, aparece no log e você descobre uma dependência que não sabia que existia.

Retenção e centralização de logs (rsyslog para SIEM)

# Reencaminhar logs de autenticação e firewall para o coletor central.
Sem centralização, cada máquina apaga a sua própria prova.

/etc/rsyslog.d/60-nis2.conf
auth,authpriv.*   @@10.10.9.15:6514   # TLS para o coletor SIEM
Reter localmente 90 dias antes de rotação
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
(rotação e retenção de 12 meses geridas no coletor central)

A centralização de logs é o controlo mais subvalorizado e o que mais frequentemente falta. A razão é aborrecida: não impede nada. Um SIEM não bloqueia um ataque — regista-o. Mas sem esse registo centralizado, no dia do incidente, você anda a saltar de máquina em máquina a copiar ficheiros de texto que se contradizem nos fusos horários, enquanto o CNCS espera pela notificação de 24 horas. O log centralizado é a diferença entre reconstruir o que aconteceu em duas horas ou em duas semanas.

Verificação automática de restauro (esqueleto de job)

# Restaurar o último backup da BD do ERP para ambiente isolado
e validar integridade. Correr trimestralmente, guardar log com data.

restore_db --source /backup/erp/latest.bak --target sandbox_erp
Validar que a tabela de faturação tem registos do último mês
check_row_count sandbox_erp faturas --min 1 --since -30d
Registar resultado como evidência de auditoria (com timestamp)
echo "$(date -Is) restore OK" >> /var/log/nis2/restore-evidence.log

Repare no último passo de cada snippet: o registo com data. A NIS2 não vive dos comandos. Vive da prova de que os comandos correram. O segundo passo — validar que a tabela de faturação tem registos recentes — é o que distingue um teste de restauro a sério de um teatro. Copiar um ficheiro e dizer "restaurado" não prova nada. Restaurar e depois abrir a base de dados e confirmar que os dados estão lá e fazem sentido: isso é evidência auditável.

A hierarquia da evidência

Nem toda a evidência tem o mesmo valor numa auditoria pós-incidente. Um administrador a dizer "sim, testamos os backups" vale zero. Um relatório automático semanal que diz "sucesso" vale pouco, porque não prova que o ficheiro era restaurável. Um log com timestamp de um restauro real para ambiente isolado, com validação de conteúdo, vale tudo. Construa os seus controlos a pensar em qual destes três níveis vai poder mostrar ao auditor.

4. Integrações e dependências

Nenhum destes controlos vive isolado. O mapa de dependências é onde as implementações reais tropeçam — porque a fábrica esquece-se de que o servidor do ERP depende do Active Directory, que depende do DNS, que depende de um switch que ninguém sabe onde está fisicamente.

• Identidade → tudo: o diretório central autentica ERP, MES, WMS e correio. Se cair, cai o acesso a tudo. Precisa de redundância própria e de um procedimento de acesso de emergência (break-glass) documentado.
• ERP MULTI → base de dados → backup imutável: o ERP MULTI é o repositório da Bill of Materials, das encomendas e da certificação AT. A cadeia de backup tem de cobrir a BD completa, não só os ficheiros.
• KORA Productivity → ERP: a captura de produção alimenta o OEE e o planeamento. O túnel OT↔IT desta ligação é o mais crítico — e o mais tentado por atacantes que já entraram no chão-de-fábrica.
• SIEM / coletor de logs → todos os sistemas: sem centralização, não há correlação de eventos. Um login falhado no ERP e um login falhado no e-mail, isolados, não dizem nada. Correlacionados, são um ataque em curso.
• BI → logs de auditoria: com Qlik Sense a ler os logs de acesso via ETL, monta um dashboard de Business Intelligence de segurança que o CISO consulta em 30 segundos em vez de escavar ficheiros de texto.

O procedimento break-glass que ninguém tem

O acesso de emergência — break-glass — é o conjunto de credenciais seladas que só se usam quando tudo o resto falha. Deve estar documentado, guardado fisicamente em cofre ou em cofre digital com múltipla aprovação, e o seu uso deve disparar um alerta imediato. A maioria das fábricas não tem isto. Tem, em vez disso, a password de administrador do domínio na cabeça de uma pessoa. No dia em que essa pessoa está de férias no Algarve sem rede e o AD cai, descobre-se que o plano de continuidade era uma pessoa. Formalize o break-glass: quem pode aceder, como se autoriza, e como se regista o uso.

A pergunta que separa o plano do teatro: se o Active Directory cair às 3 da manhã de sábado, quem entra no sistema e como? Se a resposta é "o João sabe a password de admin", não tem plano. Tem o João.

A cadeia de fornecedores como dependência oculta

A NIS2 estende explicitamente a responsabilidade à cadeia de fornecedores. Não basta ter a sua casa arrumada — precisa de saber que o integrador que mantém a sua máquina de corte, o fornecedor de cloud que aloja o seu backup e o consultor que acede ao ERP têm práticas mínimas de segurança. Isto é uma mudança cultural difícil para a PME industrial portuguesa, habituada a relações de confiança pessoal com fornecedores de décadas. A diretiva exige que essa confiança passe a ter contrato, cláusula e prova. Comece pelos fornecedores com acesso remoto aos seus sistemas — são o vetor mais direto.

5. Armadilhas operacionais

O que vimos rebentar em fábricas reais — anonimizado, mas verdadeiro na sua natureza.

1. Backups no mesmo domínio

Numa unidade de metalomecânica, o ransomware cifrou os servidores e, na mesma corrida, os backups em rede — porque estavam no mesmo domínio Windows. Restauro impossível. Solução: pelo menos uma cópia imutável ou offline, fora do controlo do domínio comprometível. A regra prática: se um administrador de domínio comprometido consegue apagar o backup, esse backup não conta como cópia de segurança para efeitos de recuperação de ransomware.

2. MFA com exceções "temporárias" permanentes

A exceção de MFA para o diretor comercial "só esta semana porque está em feira" que dura três anos. É sempre a conta com exceção que é comprometida. Solução: exceções de MFA com data de expiração automática. Sem exceção sem prazo. E monitorize a lista de exceções mensalmente — a entropia natural de qualquer organização acumula exceções como o armazém acumula paletes órfãs.

3. Logs que ninguém lê e que se apagam sozinhos

Firewall a registar tudo — e a rotacionar os logs a cada 7 dias por falta de disco. Quando houve incidente, a evidência tinha desaparecido há um mês. Solução: centralização em SIEM com retenção de 12 meses, dimensionada no orçamento desde o início. O custo de armazenamento de logs é ridículo comparado com o custo de não conseguir provar o que aconteceu numa notificação ao regulador.

4. O terminal de chão-de-fábrica com Windows fora de suporte

O terminal que controla uma máquina cara corre um sistema que já não recebe patches, porque "o fornecedor da máquina não certifica versões mais novas". Ponto de entrada perfeito. Solução: isolamento agressivo em VLAN sem Internet, monitorização dedicada, e pressão contratual sobre o fabricante da máquina. Este é um problema estrutural do têxtil e da metalomecânica, onde máquinas de 15 anos com controlos de Windows XP embebido ainda produzem valor todos os dias. Não as vai deitar fora — vai isolá-las.

5. Restauro nunca testado

Backups a correr há anos, verdes no relatório. No dia do desastre, descobre-se que o backup da BD estava corrompido há oito meses. O relatório dizia "sucesso" porque copiava um ficheiro — não porque o ficheiro fosse restaurável. Solução: teste de restauro trimestral real, como detalhamos no disaster recovery em fábrica. Sem restauro testado, não tem backup. Tem esperança.

6. Credenciais partilhadas no armazém

Um login "armazem1" que 12 pessoas usam. Quando algo corre mal, ninguém sabe quem foi. E quando alguém sai da empresa, a password fica. Solução: identidade individual, mesmo no terminal de KORA Inventory Suite — leitura de crachá é mais rápida do que teclar e é auditável. No corredor distribuição de Lousada/Paços, onde o chefe de armazém não quer perder tempo, o crachá resolve os dois problemas: velocidade para ele, rastreabilidade para a auditoria.

7. Fornecedores com acesso permanente por VPN

O integrador da máquina de corte tem VPN aberta 24/7 "para dar assistência". Um dos maiores vetores de ataque é a cadeia de fornecedores. Solução: acesso de fornecedor sob pedido, com janela temporal, gravação de sessão e revogação automática. Isto liga diretamente à lógica de zero trust em redes OT.

8. A conta de quem já saiu

O colaborador saiu há oito meses. A conta continua ativa, com acesso ao ERP, porque o RH avisou o IT por e-mail que ninguém leu. Contas fantasma são o presente perfeito para um atacante: privilégios legítimos sem ninguém a monitorizar o comportamento. Solução: ligar o processo de saída do RH à desativação automática de acessos. Quando o offboarding no sistema de pessoas dispara a revogação no diretório, a lacuna fecha-se sozinha.

A tabela das armadilhas por probabilidade

Se tiver de priorizar — e vai ter — ataque primeiro o que é mais provável e mais barato de corrigir. Esta é a ordem que recomendamos numa PME industrial típica.

6. Decisão técnica final

Sem hedging. A escolha de controlos escala com a dimensão e o perfil de risco. As pequenas fábricas são o alvo desproporcionado, não a exceção — precisamente porque assumem que são pequenas demais para interessar a alguém. Um operador de ransomware não escolhe alvos pela dimensão; escolhe pela facilidade de entrada e pela probabilidade de pagamento. Uma fábrica familiar sem SOC, com backups no domínio e a produção parada a custar milhares por hora, é o alvo ideal: fraca defesa, forte incentivo a pagar.

A PME que se acha demasiado pequena

Há uma tentação, no escalão até 50 PCs, de dizer "isto é para os grandes". Não é. É verdade que uma confecção com 30 colaboradores não vai montar um SOC. Mas o EDR num agente leve, os backups imutáveis na cloud e o MFA no diretório são acessíveis, comprováveis e cobrem a esmagadora maioria dos vetores reais. A NIS2, na transposição nacional, define âmbitos por dimensão e criticidade — e mesmo quem cai fora do âmbito direto é frequentemente arrastado por via da cadeia de fornecimento, quando a casa-mãe (Inditex, Decathlon, Tom Tailor) exige provas de segurança ao subcontratado do vestuário. A conformidade deixou de ser opcional no dia em que virou requisito de compra.

O escalão intermédio: o mais desconfortável

O escalão de 50 a 200 PCs com OT é o mais difícil de resolver. É grande demais para se safar com o mínimo, mas pequeno demais para justificar um SOC interno a tempo inteiro. A resposta racional é o modelo híbrido: capacidade própria para o dia-a-dia (EDR, coletor de logs, gestão de identidade) e serviço gerido externo para a monitorização 24/7 e a resposta a incidentes. O défice global de profissionais de cibersegurança torna a contratação interna de uma equipa de resposta a incidentes praticamente impossível para uma fábrica desta dimensão — o mercado de talento não existe ao preço que a empresa pode pagar.

Acima de 200 PCs: sem atalhos

Regra dura: acima de 200 PCs, o agente leve não chega — implemente SIEM com correlação e uma capacidade de resposta 24/7, própria ou contratada. Nesta dimensão, com múltiplas instalações e OT extensa, a superfície de ataque é grande demais para vigilância manual. A correlação de eventos automática — ligar o login falhado no ERP ao login falhado no e-mail à transferência de dados anómala às 4 da manhã — é o que transforma centenas de milhares de linhas de log por dia em três alertas que valem a pena investigar.

Há uma poupança mensurável em automatizar a deteção. As organizações que usaram IA e automação de forma extensiva na prevenção pouparam, em média, valores significativos por violação, segundo os relatórios anuais de custo de violação da IBM — num contexto em que o custo médio global de uma violação se manteve na ordem dos milhões de dólares. A automação de deteção não é luxo — é matemática de contenção de perdas.

Se ainda está a decidir a solução por preço de licença, está a comparar a coisa errada. Compare o custo de 8 horas de linha parada num pico de coleção com o custo do controlo que as evita.

O calendário de financiamento não espera pela auditoria

Uma nota prática de quem já viu candidaturas a arrastar-se. Investimentos em cibersegurança e infraestrutura enquadram-se frequentemente nos instrumentos do PT2030, do COMPETE 2030 e do Norte 2030, e há linhas específicas de digitalização e resiliência. O que trava as candidaturas raramente é o mérito — é o relatório técnico mal instruído, a ausência de orçamentos comparáveis, a falta de ligação clara entre o investimento e uma obrigação regulatória concreta. A NIS2 dá-lhe, ironicamente, o melhor argumento de candidatura que já teve: um investimento que não é discricionário, é imposto por diretiva europeia transposta. Use isso na memória descritiva.

7. Como a INFOS implementa

Trabalhamos a NIS2 na fábrica de dentro para fora: o ERP MULTI e o KORA Productivity assentam sobre infraestrutura que desenhamos com segmentação OT/IT, identidade central e backup imutável, e ligamos os logs de acesso a dashboards de Qlik Sense para que a evidência de conformidade esteja a um clique — não escondida em ficheiros de texto que ninguém abre. Os serviços de cibersegurança e datacenter fecham o ciclo com monitorização e recuperação testada. Para quem gere também as pessoas por trás dos acessos, o cruzamento entre RH e acessos — com o pplPortal — remove uma das maiores lacunas: contas de quem já saiu da empresa.

Porquê de dentro para fora e não o contrário

A abordagem mais comum no mercado é vender segurança como camada colada por cima do que já existe: instale este produto, contrate este serviço, feche a auditoria. Funciona no papel e falha na fábrica, porque a segurança colada por cima é sempre a primeira coisa a ser contornada quando incomoda a produção. Quando os controlos nascem da forma como o ERP, o MES e o WMS já trabalham — quando a identidade individual no terminal de armazém é ao mesmo tempo mais rápida e mais segura — a conformidade deixa de ser um imposto e passa a ser um subproduto. É essa a diferença que 35 anos a implementar software vertical para indústria nos ensinaram: o controlo que atrapalha o operador acaba desligado; o controlo que o ajuda fica.

A NIS2 vai obrigar muita fábrica portuguesa a fazer o que devia fazer há anos. A diferença entre quem sofre a diretiva e quem a usa é simples: os primeiros gastam em auditorias para provar que estão em conformidade; os segundos configuram os sistemas para que a conformidade seja um subproduto automático de como já trabalham. A pergunta que fica não é se vai ter um incidente — é se, quando o tiver, terá a data e a hora a provar que fez tudo o que devia. É essa prova, e não a marca da firewall, que decide o resto.

Fontes

• Diretiva (UE) 2022/2555 (NIS2), Jornal Oficial da União Europeia; transposição nacional pelo Decreto-Lei n.º 65/2025, Diário da República.
• Centro Nacional de Cibersegurança (CNCS) / CERT.PT — Relatório de incidentes 2024.
• IBM — Cost of a Data Breach Report (edições anuais).
• Verizon — Data Breach Investigations Report (DBIR).
• ISC2 — Cybersecurity Workforce Study.
• ISO/IEC 27001 — Sistema de gestão de segurança da informação.

Perguntas frequentes

O que significa a regra 3-2-1 para backups e como a implemento?

A regra 3-2-1 exige três cópias dos dados, em dois tipos de suporte diferentes, com uma cópia fora das instalações. A versão moderna acrescenta uma cópia imutável — que não pode ser alterada nem apagada durante um período definido, nem por um administrador. Esta cópia imutável protege contra ataques de ransomware onde o atacante entra com privilégios de administrador e apaga os backups.

Por que motivo a identidade é mais importante do que a firewall?

A identidade é o novo perímetro porque há dezenas de pontos de entrada legítimos na sua fábrica: telemóvel do comercial, VPN do integrador, acesso remoto. O que muda a segurança não é o número de portas, é saber quem passa por cada uma, quando e com que autorização. Uma firewall cara sem registos auditáveis não o protege em auditoria.

O que é uma VLAN OT e por que preciso dela?

Uma VLAN OT é uma rede isolada para dispositivos de chão-de-fábrica (terminais, máquinas, balanças, leitores). Numa fábrica podem existir 40 a 60 dispositivos comprados em datas diferentes com software diferente. Isolá-los numa VLAN sem saída direta para a Internet é contenção de danos: quando algo entra, limita até onde consegue chegar.

O MFA é obrigatório em todos os acessos?

Sim. O erro clássico é ter MFA no e-mail e deixar o acesso ao ERP com utilizador e password partilhados. A identidade é o novo perímetro — inclusive para o chefe de armazém. Cada acesso remoto, cada serviço crítico, deve exigir autenticação multifator através de um diretório de identidade central.

Como faço a inspeção de tráfego entre OT e IT?

Todo o tráfego OT↔IT passa por um ponto de inspeção central. Não há VPN genérica: há túneis específicos por serviço, com registo. Se um terminal de captura de produção precisa de falar com o ERP, abre-se apenas essa porta e nenhuma outra. Cada ligação fica documentada com data e hora.

Qual é o risco de não ter uma cópia de backup fora das instalações?

Um ataque de ransomware que apanha o Active Directory apanha, quase sempre, os backups no mesmo domínio. Sem uma cópia offline ou imutável, a diferença é entre "restaurámos em 6 horas" e "pagámos resgate". A cópia fora das instalações é a defesa contra o cenário em que o atacante entra com privilégios de administrador.

O que é uma cópia imutável de backup?

Uma cópia que, uma vez escrita, não pode ser alterada nem apagada durante um período definido, nem por um administrador com credenciais válidas. É a única defesa que resiste a um administrador comprometido. Protege contra atacantes que entram com privilégios elevados e tentam apagar os backups antes de cifrar os dados.

Por que razão a maioria das fábricas portuguesas falha a NIS2?

Não por falta de tecnologia, mas por falta de evidência auditável. Têm antivírus, backups, VPN. O que não têm é a prova com data e hora de que aquilo funciona, foi testado e alguém é responsável. A NIS2 não pergunta se tem controlos — pergunta se os consegue demonstrar quando o CNCS bater à porta após um incidente.