Protegendo switches gerenciáveis para redes SCADA e DCS

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, expõe diagnósticos e pode limitar ou ampliar o efeito 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 acesso somente a partir de hosts de administração autorizados, por meio de firewalls ou listas de controle de acesso definidas.

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 ser 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 unidade 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 valioso durante o comissionamento e as falhas de rede. Portanto, o acesso físico deve ser controlado, e as credenciais locais não devem ser compartilhadas de maneira informal.

Uma configuração salva não deve conter senhas de demonstração nem padrões do fornecedor. 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. Os exemplos incluem células de controladores, sistemas de proteção, servidores supervisórios, equipamentos relacionados à segurança e acesso para manutenção.

Não crie uma VLAN de planta plana simplesmente porque todos os dispositivos usam Ethernet industrial. Uma estação de trabalho comprometida ou uma tempestade de broadcast poderia 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, o posicionamento do querier e o comportamento da redundância. Um projeto multicast incorreto pode sobrecarregar 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 fornecedor, 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 dos switches 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.

O 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 deliberada. Restrinja as estações de gerenciamento e use versões autenticadas e criptografadas quando houver suporte. Evite expor amplo acesso de gravação.

Comissione as 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 fornecedor, teste a versão de destino em laboratório e confirme a disponibilidade de uma imagem de recuperação.

Opinião do autor: os 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.