Un switch Ethernet administrable en una red SCADA o DCS es más que un multiplicador de puertos. Controla las rutas del tráfico, expone diagnósticos y puede limitar o ampliar el efecto de un error de configuración.

El objetivo de ingeniería no es utilizar el máximo de funciones. Es lograr comunicaciones predecibles, restringir el acceso de administración y contar con suficiente evidencia para diagnosticar fallos sin alterar el proceso.

Un diseño en capas separa el control de campo, los sistemas de supervisión, las operaciones del sitio y el intercambio de datos empresariales.

Comience por el tráfico y las consecuencias

Documente cada controlador, HMI, historiador, estación de ingeniería, pasarela y ruta de acceso remoto antes de cambiar la configuración del switch. Registre los protocolos necesarios, los pares de comunicación, las tasas de actualización, el comportamiento de multidifusión y las expectativas de recuperación.

Este inventario convierte la segmentación en una decisión de ingeniería. Una VLAN por sí sola no es un límite de seguridad, a menos que las reglas de enrutamiento y del firewall impongan las rutas de comunicación previstas.

NIST SP 800-82 Rev. 3 describe la seguridad de OT en el contexto del rendimiento, la fiabilidad y la seguridad funcional. Las directrices de CISA también hacen hincapié en la segmentación y el intercambio controlado de datos entre sistemas críticos y servicios empresariales.

Separe la administración del tráfico de proceso

Coloque las interfaces de administración de los switches en una red de administración dedicada. Permita el acceso únicamente desde hosts de administración autorizados a través de firewalls o listas de control de acceso definidas.

Desactive los servicios de administración que no utilice. Prefiera SSH y HTTPS cuando el switch los admita. Evite Telnet y HTTP sin cifrado, ya que las credenciales y las sesiones pueden quedar expuestas.

Cambie las credenciales predeterminadas, utilice cuentas con nombre y aplique permisos basados en roles. La autenticación centralizada puede mejorar la trazabilidad, pero la planta también necesita un método de recuperación documentado para cuando el servicio de autenticación no esté disponible.

Proteja el acceso local

El acceso por consola sigue siendo valioso durante la puesta en marcha y las fallas de red. Por lo tanto, el acceso físico debe estar controlado y las credenciales locales no deben compartirse de manera informal.

Una configuración guardada no debe contener contraseñas de demostración ni valores predeterminados del proveedor. Almacene las credenciales de recuperación conforme al proceso de acceso aprobado del sitio.

Utilice una segmentación que se ajuste a las operaciones

Agrupe los dispositivos por función, consecuencias y necesidades de comunicación. Algunos ejemplos son las celdas de controladores, los sistemas de protección, los servidores de supervisión, los equipos relacionados con la seguridad funcional y el acceso de mantenimiento.

No cree una VLAN de planta plana simplemente porque todos los dispositivos utilicen Ethernet industrial. De hacerlo, una estación de trabajo comprometida o una tormenta de difusión podría alcanzar equipos que nunca necesitaron comunicarse directamente.

Una VLAN de administración solo debe ser accesible a través de rutas de administración aprobadas.

Cuando haya protocolos de multidifusión, verifique la inspección IGMP, la ubicación del consultador y el comportamiento de redundancia. Un diseño incorrecto de multidifusión puede sobrecargar los puertos o interrumpir las E/S incluso cuando las pruebas habituales de unidifusión sean satisfactorias.

El hardware de interfaz y pasarela pertinente puede consultarse en la colección Comunicación y redes. Las plataformas de controladores están agrupadas en Sistemas PLC y PAC.

Diseñe la redundancia como un sistema

Los enlaces redundantes requieren un protocolo documentado y un tiempo de convergencia probado. Añadir cables paralelos sin protección contra bucles puede crear una tormenta de difusión en lugar de resiliencia.

Compruebe si la red utiliza Rapid Spanning Tree, un protocolo de anillo del proveedor, Media Redundancy Protocol u otro método. Confirme la compatibilidad entre todos los switches participantes.

Pruebe la falla de un cable, la pérdida de alimentación de un switch, la recuperación de un puerto bloqueado y el restablecimiento. Registre la pérdida de paquetes y el comportamiento del controlador, no solo el tiempo de convergencia indicado por el switch.

El registro y la sincronización horaria ayudan al diagnóstico

Envíe los eventos de los switches a un sistema de registro protegido cuando sea práctico. Entre los eventos útiles se incluyen los cambios de enlace, los fallos de autenticación, los cambios de configuración, las transiciones de topología y las alarmas de alimentación.

La coherencia horaria es esencial. Sin relojes sincronizados, un operador no puede correlacionar de forma fiable una transición del switch con fallos del PLC, alarmas de la HMI o eventos del firewall.

SNMP debe configurarse deliberadamente. Restrinja las estaciones de administración y utilice versiones autenticadas y cifradas cuando sea posible. Evite exponer un acceso amplio de escritura.

Ponga en marcha los cambios sin crear riesgos ocultos

Realice una copia de seguridad de la configuración en ejecución antes de trabajar. Registre el modelo del switch, el firmware, la configuración activa, los puertos conectados y el método de reversión.

Aplique los cambios durante una ventana aprobada. Valide las comunicaciones del proceso, la entrega de alarmas, las actualizaciones del historiador, la redundancia, el acceso remoto y la sincronización horaria después de cada paso importante.

Las actualizaciones de firmware requieren la misma disciplina que los cambios en los controladores. Revise los avisos del proveedor, pruebe en laboratorio la versión objetivo y confirme que haya una imagen de recuperación disponible.

Opinión del autor: los switches administrables aportan valor cuando su configuración es comprensible y recuperable. Un diseño complicado sin responsables, copias de seguridad ni un comportamiento ante fallas probado es más difícil de operar que una red más sencilla y documentada.