Um switch Ethernet gerenciável em uma rede SCADA ou DCS é mais do que um multiplicador de portas. Ele controla os caminhos do tráfego, disponibiliza diagnósticos e pode limitar ou ampliar o impacto de um erro de configuração.

O objetivo de engenharia não é usar o máximo de recursos. É garantir comunicações previsíveis, acesso restrito ao gerenciamento e evidências suficientes para diagnosticar falhas sem perturbar o processo.

Um projeto em camadas separa o controle de campo, os sistemas supervisórios, as operações da unidade e a troca de dados corporativos.

Comece pelo tráfego e pelas consequências

Documente cada controlador, IHM, historiador, estação de engenharia, gateway e caminho de acesso remoto antes de alterar as configurações do switch. Registre os protocolos necessários, os pares de comunicação, as taxas de atualização, o comportamento de multicast e as expectativas de recuperação.

Esse inventário transforma a segmentação em uma decisão de engenharia. Uma VLAN, por si só, não é um limite de segurança, a menos que as regras de roteamento e firewall imponham os caminhos de comunicação pretendidos.

A NIST SP 800-82 Rev. 3 descreve a segurança de OT no contexto de desempenho, confiabilidade e segurança operacional. As orientações da CISA também enfatizam a segmentação e a troca controlada de dados entre sistemas críticos e serviços corporativos.

Separe o gerenciamento do tráfego de processo

Coloque as interfaces de gerenciamento dos switches em uma rede de gerenciamento dedicada. Permita o acesso somente a partir de hosts de administração autorizados, por meio de firewalls ou listas de controle de acesso definidos.

Desative os serviços de gerenciamento não utilizados. Prefira SSH e HTTPS quando o switch oferecer suporte a eles. Evite Telnet e HTTP não criptografado, pois as credenciais e as sessões podem ficar expostas.

Altere as credenciais padrão, use contas nominais e aplique permissões baseadas em funções. A autenticação centralizada pode melhorar a responsabilização, mas a planta também precisa de um método de recuperação documentado para quando o serviço de autenticação estiver indisponível.

Proteja o acesso local

O acesso pelo console continua sendo valioso durante o comissionamento e em caso de falha da rede. Portanto, o acesso físico deve ser controlado, e as credenciais locais não devem ser compartilhadas de maneira casual.

Uma configuração salva não deve conter senhas de demonstração nem padrões do fabricante. Armazene as credenciais de recuperação de acordo com o processo de acesso aprovado pela unidade.

Use uma segmentação compatível com as operações

Agrupe os dispositivos por função, consequência e necessidade de comunicação. Exemplos incluem células de controladores, sistemas de proteção, servidores supervisórios, equipamentos relacionados à segurança e acesso de manutenção.

Não crie uma VLAN plana para a planta simplesmente porque todos os dispositivos usam Ethernet industrial. Uma estação de trabalho comprometida ou uma tempestade de broadcast poderá então alcançar equipamentos que nunca precisaram de comunicação direta.

Uma VLAN de gerenciamento deve ser acessível somente por caminhos de administração aprovados.

Quando houver protocolos multicast, verifique o snooping de IGMP, a posição do querier e o comportamento da redundância. Um projeto multicast incorreto pode sobrecarregar as portas ou interromper a E/S, mesmo quando os testes comuns de unicast forem aprovados.

Interfaces e gateways relevantes podem ser consultados na coleção Comunicação e Redes. As plataformas de controladores estão agrupadas em Sistemas PLC e PAC.

Projete a redundância como um sistema

Links redundantes exigem um protocolo documentado e um tempo de convergência testado. Adicionar cabos paralelos sem proteção contra loops pode criar uma tempestade de broadcast em vez de resiliência.

Verifique se a rede usa Rapid Spanning Tree, um protocolo de anel do fabricante, o Media Redundancy Protocol ou outro método. Confirme a compatibilidade entre todos os switches participantes.

Teste a falha de cabos, a perda de energia do switch, a recuperação de portas bloqueadas e a restauração. Registre a perda de pacotes e o comportamento dos controladores, não apenas o tempo de convergência informado pelo switch.

O registro de eventos e a sincronização de tempo ajudam no diagnóstico

Envie os eventos do switch para um sistema de registro protegido quando for viável. Eventos úteis incluem alterações de link, falhas de autenticação, alterações de configuração, transições de topologia e alarmes de energia.

Um horário consistente é essencial. Sem relógios sincronizados, um operador não consegue correlacionar de forma confiável uma transição do switch com falhas de PLC, alarmes de IHM ou eventos do firewall.

O SNMP deve ser configurado de forma planejada. Restrinja as estações de gerenciamento e use versões autenticadas e criptografadas quando houver suporte. Evite expor acesso amplo de gravação.

Implemente alterações sem criar riscos ocultos

Faça backup da configuração em execução antes do trabalho. Registre o modelo do switch, o firmware, a configuração ativa, as portas conectadas e o método de reversão.

Aplique as alterações durante uma janela aprovada. Valide as comunicações do processo, a entrega de alarmes, as atualizações do historiador, a redundância, o acesso remoto e a sincronização de tempo após cada etapa importante.

As atualizações de firmware exigem a mesma disciplina que as alterações em controladores. Analise os avisos do fabricante, teste a versão-alvo em laboratório e confirme que uma imagem de recuperação está disponível.

Opinião do autor: switches gerenciáveis geram valor quando sua configuração é compreensível e recuperável. Um projeto complicado sem responsáveis definidos, backups e comportamento de falha testado é mais difícil de operar do que uma rede mais simples e documentada.