Guía técnica · Planta conectada
El gateway IIoT también necesita mantenimiento
Qué identificar, respaldar y comprobar para actualizar o reemplazar un gateway industrial sin perder la configuración que conecta la máquina con sus datos.
Una máquina sigue produciendo, pero el histórico dejó de recibir datos. El gateway responde al encendido y sus indicadores parecen normales. Para recuperar la conexión, mantenimiento necesita conocer la configuración de red, el destino de los mensajes y las credenciales utilizadas. Si esa información quedó solamente en la computadora del integrador, reemplazar una caja puede convertirse en una intervención extensa.
En esta situación conceptual, el problema supera al hardware averiado. El equipo concentra decisiones de integración que deben conservarse durante actualizaciones, cambios de personal y reemplazos.
Un aviso que exige identificar el equipo exacto
Según el aviso MPSA-262560 de Moxa, publicado el 16 de octubre de 2026, el AIG-302 con firmware 1.4.0 y anteriores presenta dos vulnerabilidades: autorización insuficiente para acceder a secretos internos y una clave privada raíz incorporada. El fabricante publicó el parche 1.4.1. Las condiciones de ataque incluyen acceso a la red adyacente; una de las fallas requiere además una cuenta autenticada.
El aviso permite actuar sobre un producto y versiones determinados. No demuestra que todos los gateways tengan esas fallas. Para una instalación, la primera tarea es comparar referencia y firmware con el alcance del boletín y seguir las indicaciones vigentes del fabricante.
La identificación debe quedar asociada al activo físico: ubicación, número de serie, función, interfaces utilizadas y responsable. Una lista que sólo dice “gateway de producción” difícilmente permita decidir qué actualizar ni a quién avisar.
El respaldo debe permitir reconstruir la conexión
La guía NIST SP 800-82, revisión 3, trata la seguridad OT considerando requisitos de funcionamiento, confiabilidad y seguridad del proceso. Su enfoque incluye gestión de cambios, pruebas de parches y preparación de respaldos y recuperación. Para aplicarlo a un gateway conviene convertir cada dependencia en un elemento verificable.
Un respaldo útil debe acompañarse con un inventario de lo que incluye y de lo que queda fuera. Según el equipo, habrá que conservar configuración de red, mapas de señales, escalados, tópicos, certificados, aplicaciones y versiones. También se necesita el procedimiento para obtener o restituir credenciales mediante un repositorio protegido. Esos secretos no deberían aparecer en planillas de acceso general.
La posibilidad de exportar una configuración no garantiza que un repuesto la acepte. Hay que comprobar modelo, revisión de hardware, firmware y licencias requeridas. Si la restauración exige acceso a un portal o a una cuenta que ya no está disponible, esa dependencia debe resolverse antes de necesitarla durante una falla.
Actualizar sin perder el recorrido del dato
Antes de una actualización se define qué servicio se interrumpe y durante cuánto tiempo puede hacerlo. En una arquitectura con control local independiente, la pérdida de telemetría no debería introducir por sí misma una orden sobre la máquina. Esta separación debe verificarse en la instalación concreta.
El plan de intervención necesita una copia previa identificada, el paquete oficial compatible, criterios de aceptación y una alternativa de recuperación soportada. Volver a una versión anterior no siempre es posible ni conveniente; el fabricante debe confirmar las condiciones. En presencia de claves comprometidas también corresponde verificar si exige regenerar certificados o renovar credenciales.
Después de reiniciar, comprobar solamente que abre el dashboard deja preguntas sin resolver. Conviene seguir una señal desde su origen: nombre del activo, unidad, escala, marca de tiempo y destino. Luego revisar alarmas de comunicación, suscripciones, almacenamiento durante cortes y tratamiento de mensajes acumulados. Un valor visible puede estar desactualizado o pertenecer a una configuración anterior.
Recuperación y soporte después de la entrega
La prueba de restauración debe registrar qué se recuperó, qué se completó manualmente y cuánto tardó cada etapa. Una copia guardada y una recuperación comprobada son evidencias diferentes. Cuando cambian señales, certificados o aplicaciones, el registro de versiones debe indicar qué respaldo corresponde al sistema entregado.
También se define quién recibe avisos de seguridad, evalúa su aplicabilidad y coordina la intervención con producción. El soporte necesita conocer disponibilidad de repuesto, plazo de reposición y acceso a las herramientas necesarias. El cliente debe conservar documentación suficiente para continuar operando si cambia el proveedor de asistencia.
En Nodira relevamos esas dependencias junto con el recorrido de las señales y definimos las comprobaciones de entrega y recuperación. Así, la conexión IIoT queda vinculada con una configuración identificable y un procedimiento de mantenimiento. Para comenzar, alcanza con seleccionar un gateway y comprobar si su documentación permite reconstruir el servicio en un equipo compatible.