Comissionamento de serviços de rede OT: matriz de fluxos e evidências
Valide DNS, ICMP, SSH, transferência, SNMP, Syslog, HTTPS, AAA e LLDP com matriz de fluxos, caso normal, falhas controladas, captura e critérios de aceite.
Matriz mínima de aceite dos serviços
| Serviço | Caso normal | Falha e recuperação |
|---|---|---|
| ICMP/rota | alcance conforme política | bloqueio interpretado sem afetar aplicação |
| SSH/AAA | identidade e privilégio corretos | servidor secundário e break-glass |
| Transferência | arquivo, hash e permissão | interrupção, espaço e rollback |
| SNMP/Syslog | dado, evento e horário | manager/coletor fora e retorno |
| HTTPS/TLS | nome, cadeia, método e efeito | certificado/credencial inválidos |
| LLDP | vizinhança esperada | age-out, retorno e inventário |
Todos os casos devem ter resultado esperado definido antes da execução.
O objeto do teste é uma função, não uma porta aberta
A matriz começa no uso: estação de engenharia administra switch por SSH; NMS consulta SNMP; equipamento envia Syslog; aplicação acessa API HTTPS. Para cada fluxo, registre endpoints, direção de início, transporte, porta, nome, identidade, frequência, criticidade e responsável. Uma varredura de portas não prova autenticação, conteúdo ou efeito.
Separe fluxos permanentes, temporários de manutenção e contingência. Regras abertas para comissionamento precisam de prazo e remoção. Serviços desabilitados também entram no aceite: a evidência deve mostrar que Telnet, HTTP ou FTP não estão escutando quando a arquitetura determinou alternativas seguras.
Congele baseline e versões antes de testar
Exporte configuração de switches, firewalls, servidores e ativos; registre firmware, IP, VLAN, rota, DNS, certificados, host keys, usuários, MIBs, destinos de log e horário. Sem baseline, uma correção durante o teste pode criar estado não documentado. Identifique a revisão comum do pacote.
Mapeie dependências centrais e locais. Um teste HTTPS pode depender de DNS, NTP, CA, proxy e AAA. Se falhar, a ordem de verificação deve seguir essas fronteiras. Defina janela e contato operacional para qualquer ação que possa afetar processo.
Validação por camadas reduz mudanças aleatórias
Confirme enlace, VLAN e contadores; depois endereço, ARP/ND e rota; resolução DNS; transporte TCP/UDP; TLS ou SSH; protocolo e função. Pare na primeira divergência. Ping não é pré-requisito universal: o serviço pode estar permitido mesmo com Echo bloqueado. GOOSE e outros fluxos camada 2 exigem método diferente.
Use captura na origem e, quando necessário, em ponto espelhado aprovado. Preserve clocks e filtros. Combine PCAP com logs do firewall, servidor, cliente e equipamento. Uma captura isolada mostra pacote, não explica necessariamente decisão interna.
Caso normal precisa provar identidade e efeito
Para SSH, valide host key, usuário e comando. Para SFTP/FTPS, valide arquivo e hash. Para SNMP, OID, unidade e contador. Para Syslog, mensagem, timestamp e normalização. Para HTTPS, certificado, método, status e estado resultante. Para AAA, perfil e accounting. Para LLDP, vizinho e porta.
Registre também tempos e volumes. Um serviço pode funcionar e exceder timeout do sistema consumidor. Polling agressivo pode prejudicar enlace. A amostra deve representar rota principal e, quando houver, caminho de contingência.
Falhas controladas revelam o comportamento real
Teste credencial incorreta, certificado inválido, servidor secundário, coletor indisponível, perda de rota, arquivo interrompido e lease ou cache conforme o serviço. Determine timeout, retry, alarme, fallback, fila e impacto. Faça isso em ativo de teste ou janela autorizada, nunca improvisando sobre função crítica.
A expectativa precisa ser escrita antes: um reject AAA não deve cair para conta local; perda de Syslog não deve travar IED; ausência de DNS pode manter sessão existente e impedir nova; perda do manager SNMP não deve alterar processo. Resultado diferente exige correção ou aceitação formal de risco.
Recuperação é etapa independente
Restaurar o componente não encerra o teste. Confirme reconexão, limpeza de alarmes, drenagem de fila, ausência de duplicidade, retorno ao servidor preferido e renovação de estado. Um serviço pode permanecer preso em backoff ou continuar usando cache antigo depois que a causa sumiu.
Em redundância, meça failover e failback. Verifique mudança de certificado, host key, rota, vizinho e contadores. A recuperação deve ocorrer sem reinício manual não previsto; se o reboot for necessário, documente impacto e procedimento.
Evidência deve permitir repetição e auditoria
Cada caso precisa de ID, pré-condição, ação, esperado, observado, horário, responsável e anexos. Nomeie arquivos com revisão e proteja credenciais. Captura deve conter o recorte suficiente; logs devem preservar original. Screenshots sem texto pesquisável e horário claro são complemento, não fonte única.
O relatório diferencia sintoma, mecanismo e causa. “Firewall bloqueou” só é causa quando regra, origem, destino e intenção demonstram divergência. Se a regra estava correta e o cliente usou IP errado por DNS, o bloqueio foi consequência.
Encerramento remove exceções e cria baseline operacional
Revise regras temporárias, contas de teste, comunidades, arquivos, certificados e acessos. Atualize matriz as-built, inventário, diagramas, MIBs e calendário de renovação. Gere baseline de latência, contadores, vizinhos, mensagens e certificados para comparação futura.
A aprovação requer todos os fluxos legítimos funcionando, fluxos proibidos negados, modos de falha conhecidos e recuperação demonstrada. O pacote final deve permitir que outra equipe repita o teste sem depender da memória de quem comissionou. Pendências precisam de responsável, risco, prazo e condição operacional explícitos; não podem desaparecer em observações genéricas.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- IEC 62443-3-3:2013 — System security requirements and security levels — IEC. Requisitos técnicos de segurança para sistemas de automação e controle industrial.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security — NIST. Arquiteturas, ameaças e controles aplicáveis a ambientes OT.
- RFC 1122 — Requirements for Internet Hosts — Communication Layers — RFC Editor / IETF. Requisitos de IP, ICMP e camadas de comunicação em hosts.
- RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification — RFC Editor / IETF. Especificação vigente do IPv6.
- RFC 9110 — HTTP Semantics — RFC Editor / IETF. Semântica atual de métodos, campos e códigos HTTP.
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — RFC Editor / IETF. TLS 1.3, handshake, autenticação e proteção do transporte.
- RFC 9325 — Recommendations for Secure Use of TLS and DTLS — RFC Editor / IETF. Recomendações atuais para versões, algoritmos e configuração TLS.
- RFC 4251 — The Secure Shell (SSH) Protocol Architecture — RFC Editor / IETF. Arquitetura SSH e separação entre transporte, autenticação e conexão.
- RFC 5424 — The Syslog Protocol — RFC Editor / IETF. Formato, facility, severity, timestamp e dados estruturados de Syslog.
- RFC 3411 — Architecture for Describing SNMP Management Frameworks — RFC Editor / IETF. Arquitetura do framework SNMP.
- RFC 3414 — User-based Security Model (USM) for SNMPv3 — RFC Editor / IETF. Autenticação e privacidade do SNMPv3 USM.
- IEEE 802.1AB-2016 — Station and Media Access Control Connectivity Discovery — IEEE Standards Association. LLDP e descoberta de conectividade em camada 2.
- Wireshark User’s Guide — Wireshark Foundation. Documentação oficial de captura, filtros, estatísticas e interpretação da interface do analisador.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.