Protocolos e serviços de rede em automação: arquitetura e critérios de uso
Organize diagnóstico, acesso remoto, transferência, gestão, logs e serviços web de uma rede OT com função, risco, fluxo permitido e evidência de teste.
Mapa funcional dos serviços de rede em automação
| Função | Serviços típicos | Evidência principal |
|---|---|---|
| Diagnóstico | ICMP, traceroute, ARP/ND, DNS | captura, rota, cache e tempos |
| Administração | SSH, HTTPS | identidade, sessão e log de ação |
| Transferência | SFTP, FTPS, FTP/TFTP legado | hash, arquivo e autorização |
| Gestão | SNMP, LLDP | OID, contador, trap e vizinho |
| Registros | Syslog | timestamp, severity, origem e retenção |
| Identidade | RADIUS, TACACS+, LDAP | autenticação, autorização e accounting |
A matriz de firewall deve derivar dessas funções e dos endpoints aprovados, não de uma lista genérica de portas.
Serviço auxiliar também faz parte do sistema de automação
Ping, DNS, SSH, SNMP, Syslog e HTTPS não comandam diretamente um disjuntor, mas sustentam diagnóstico, engenharia, supervisão e manutenção. Quando entram sem arquitetura, viram dependências invisíveis: o IED continua processando proteção local, porém a equipe perde acesso, nomes deixam de resolver, alarmes não chegam ou backups falham. O primeiro passo é registrar qual função operacional cada serviço cumpre e quem depende dela.
A classificação deve separar plano de processo, plano de controle e plano de gestão. DNP3, IEC 104 ou MMS transportam dados de automação; SSH e HTTPS administram equipamentos; SNMP e Syslog observam a infraestrutura. Essa diferença define prioridade, origem autorizada, zona, retenção e resposta a falhas. Compartilhar a mesma rede física não torna todos os fluxos equivalentes.
Organize por função antes de olhar portas
Diagnóstico inclui ICMP, traceroute, ARP e consultas DNS. Acesso remoto usa preferencialmente SSH ou HTTPS. Transferência pode empregar SFTP, FTPS ou mecanismos específicos do fabricante. Gestão usa SNMP e descoberta LLDP; registros usam Syslog; autenticação central pode usar RADIUS, TACACS+ ou LDAP. A porta ajuda o firewall, mas não descreve o propósito nem garante que o processo do outro lado seja legítimo.
Uma matriz de serviços deve associar origem, destino, protocolo de transporte, porta, direção de início, autenticação, criticidade e proprietário. Para protocolos com canais dinâmicos, como FTP, a regra precisa considerar o mecanismo completo. Para aplicações web, o endereço IP e a porta 443 não explicam hostname, certificado, proxy ou caminho da API.
Disponibilidade não significa permitir tudo
Em OT, é comum manter serviços inseguros por medo de indisponibilidade. O resultado é uma superfície maior e pouca previsibilidade. O caminho correto é provar quais serviços o equipamento realmente suporta, desabilitar o que não tem uso, restringir administração a estações ou jump servers definidos e prever acesso local de contingência. Segurança e continuidade devem ser testadas juntas.
Um serviço central também precisa de comportamento de falha declarado. Se DNS cair, os clientes usam cache, endereço IP ou deixam de operar? Se AAA ficar indisponível, existe conta local de emergência protegida e auditada? Se o coletor Syslog parar, o equipamento mantém fila? A arquitetura deve responder antes do comissionamento, não durante uma ocorrência.
Autenticação, sigilo e integridade são propriedades diferentes
Criptografar o canal protege conteúdo em trânsito, mas não substitui controle de identidade ou autorização. SSH com senha compartilhada continua com atribuição fraca; HTTPS com certificado expirado ou hostname divergente pode levar a exceções permanentes; SNMPv3 sem visão restrita pode conceder leitura ou escrita excessiva. Cada serviço deve declarar quem autentica quem, quais ações são permitidas e como as credenciais são renovadas.
Telnet, FTP, TFTP, HTTP e SNMPv1/v2c possuem limitações importantes de proteção nativa. Em equipamento legado, a decisão pode ser compensar com zona restrita, ACL, jump server e janela controlada, mas isso precisa ser explícito. Chamar um protocolo de “interno” não remove a possibilidade de captura, alteração, uso indevido ou propagação a partir de um host comprometido.
Observabilidade precisa de horário e contexto
SNMP fornece estado e contadores; Syslog relata eventos; LLDP descreve vizinhança; a captura mostra pacotes. Nenhuma fonte isolada fecha a causa. Um link flap pode aparecer como mudança operacional no SNMP, evento no Syslog, alteração de vizinho e retransmissões na aplicação. Correlacionar exige relógios coerentes, identificação única de ativos e retenção suficiente.
O baseline deve registrar taxas normais, contadores que crescem, vizinhos esperados, certificados, versões e destinos de log. Alertar apenas “equipamento offline” perde sinais anteriores como CRC crescente, autenticação recusada ou lease prestes a expirar. A observabilidade útil aponta a primeira divergência e preserva evidência para reteste.
Ciclo de vida inclui versão, credencial e certificado
Serviços de rede não terminam quando o ping responde. Chaves SSH precisam de inventário e revogação; certificados TLS expiram; contas mudam de função; comunidades SNMP devem ser eliminadas ou protegidas; OIDs e mensagens Syslog podem mudar com firmware. O pacote de engenharia deve incluir responsáveis, periodicidade de revisão e procedimento de rollback.
Antes de atualizar firmware ou substituir um equipamento, exporte configuração, lista de usuários, chaves confiáveis, certificados, MIBs, destinos Syslog e dependências DNS/DHCP. O novo ativo pode responder no mesmo IP e ainda romper automações por algoritmo SSH, cadeia de certificado, nome de interface, OID ou formato de log diferente.
Teste o caso normal, a falha e a recuperação
O aceite começa comprovando resolução, sessão, autenticação, autorização, ação e registro. Depois interrompa de forma controlada DNS, servidor AAA, coletor, rota ou certificado; observe timeout, alarme, fallback e impacto no processo. Restaure o componente e confirme retorno sem duplicidade, tempestade de reconexão ou credencial residual indevida.
Cada teste precisa de horário, configuração, origem, destino e resultado esperado. “Funcionou” é insuficiente: uma conexão SSH pode abrir com algoritmo proibido; um GET SNMP pode responder sem traps; HTTPS pode carregar com alerta ignorado. O critério deve medir a propriedade que o serviço deveria entregar.
Diagnóstico segue a primeira fronteira que divergiu
Comece por enlace e endereço local, avance por ARP ou Neighbor Discovery, rota, DNS, TCP ou UDP, segurança do transporte e protocolo de aplicação. Compare um caso bom e um ruim. Se TCP não completa, não altere certificado; se TLS falha depois do TCP, não culpe VLAN sem evidência; se HTTP retorna 403, a rede entregou a solicitação e o foco passa a ser autorização.
Preserve tabela ARP, rota, consulta DNS, captura, logs dos dois lados e estado do firewall antes de reiniciar. O relatório final deve ligar sintoma, primeira divergência, mecanismo, causa, correção e reteste. Esse método evita transformar ping em veredito universal e reduz mudanças simultâneas que apagam a causa.
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.
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.