Ya cubrimos cómo un actuador LoRaWAN enciende un motor a distancia: la clase de dispositivo, el downlink confirmado, el fail-safe ante pérdida de señal. Ese problema es de radiofrecuencia. Hay uno distinto, y más fácil de pasar por alto, que aparece en cuanto ese control queda accesible desde un dashboard: ¿quién tiene permiso para presionar el botón? Una motobomba de riego o un aireador de camaronera no son un foco que se enciende por error sin consecuencia —un accionamiento indebido puede vaciar un tanque de combustible, inundar una parcela o dejar sin oxígeno una piscina en la hora que menos conviene—, y esa pregunta de acceso, permisos y trazabilidad es tan de ingeniería como la del downlink.
El riesgo no es solo que alguien externo entre: es que cualquiera con acceso pueda accionar cualquier cosa
El error de diseño más común en sistemas de control remoto pequeños no es una brecha externa espectacular, sino la ausencia total de granularidad interna: una sola cuenta compartida, con la misma contraseña para todos, que puede ver los datos de los sensores y accionar cualquier relé del sitio. Con esa arquitectura, un operador de turno que solo necesita consultar el nivel de oxígeno disuelto tiene, sin quererlo, la misma capacidad de apagar el aireador principal que el gerente de la camaronera. El principio de mínimo privilegio —cada cuenta con exactamente los permisos que su función requiere, ni uno más— es la primera línea de defensa, y es aplicable antes de pensar en cifrado o en firewalls: no importa qué tan segura sea la conexión si la cuenta que la usa puede hacer más de lo que su rol amerita.
Roles diferenciados: quién ve, quién acciona, quién administra
En la práctica de campo conviene separar al menos tres niveles de acceso:
- Solo lectura (visualización): ve gráficas históricas, alarmas y el estado actual de sensores y actuadores, pero no puede enviar ningún comando. Es el nivel adecuado para un cliente, un consultor externo o un operario que solo necesita reportar condiciones.
- Operador: puede accionar los actuadores para los que tiene permiso explícito —encender la bomba de la parcela 3, no la de la parcela 7— dentro de límites definidos (por ejemplo, sin poder cambiar el fail-safe ni el umbral de una alarma).
- Administrador: gestiona usuarios, permisos, umbrales de alarma y la configuración de los dispositivos, incluyendo qué actuador queda expuesto a qué rol.
Esta segmentación no es una particularidad de Yubox: ChirpStack, el network server open source que describimos en la nota sobre ChirpStack y TTN, organiza el acceso por tenants (organizaciones o equipos que administran sus propias aplicaciones y, opcionalmente, sus propios gateways) y expone claves de API separadas por tenant específicamente para que un integrador no tenga que compartir credenciales de administrador solo para enviar un downlink de prueba. La capa de aplicación —el dashboard que ve el cliente final— es la que normalmente añade el control de roles más granular (lectura, operación, administración) sobre esa base de tenants.
Autenticación: la puerta antes de la puerta
Separar roles no sirve de nada si cualquiera puede autenticarse como cualquier usuario. Tres controles concretos reducen ese riesgo de forma desproporcionada respecto a su costo de implementación:
- Contraseñas individuales, nunca compartidas por sitio. Una cuenta genérica “operador-camaronera” que usan cinco personas hace imposible saber después quién accionó qué.
- Autenticación de dos factores (2FA) para cualquier cuenta con permiso de accionamiento, no solo para el administrador. Un segundo factor —código temporal o notificación push— convierte el robo de una contraseña filtrada en un incidente contenido en vez de un acceso directo al relé.
- Expiración de sesión y cierre automático en dashboards que se dejan abiertos en una computadora compartida de la oficina de campo, un vector de acceso indebido más común de lo que parece en instalaciones agrícolas y acuícolas.
Bitácora de auditoría: quién accionó qué, cuándo y con qué resultado
Cuando un actuador tiene múltiples usuarios con permiso de accionamiento, la pregunta después de cualquier incidente —una bomba que se quedó encendida toda la noche, un aireador que se apagó en el peor momento— es siempre la misma: ¿quién dio la orden? Un registro de auditoría útil no es solo “se accionó el relé 2”; debe capturar, como mínimo:
- Usuario que emitió el comando (no la cuenta compartida, el usuario individual).
- Marca de tiempo del comando y, por separado, del ACK de confirmación (o su ausencia, si el downlink confirmado que describimos en la nota de actuadores nunca llegó).
- Estado anterior y estado solicitado (de apagado a encendido, o viceversa).
- Origen del comando: accionamiento manual desde el dashboard o regla automática (por ejemplo, un umbral de oxígeno disuelto que dispara el aireador sin intervención humana).
Ese registro debe ser de solo anexado (append-only): nadie, ni siquiera un administrador, debería poder borrar o editar una entrada ya escrita, porque el valor de la bitácora está precisamente en que sea la fuente confiable cuando hay que reconstruir qué pasó. La norma ISA/IEC 62443, el marco de referencia para ciberseguridad en sistemas de control industrial, formaliza este tipo de exigencia dentro de sus siete “requisitos fundamentales” (Foundational Requirements): identificación y autenticación de cada entidad que accede al sistema, control de uso según el rol ya autenticado, y respuesta oportuna a eventos —que un accionamiento o un intento fallido genere una alerta verificable, no solo una línea silenciosa en un log que nadie revisa—.
Alertas: qué merece despertar a alguien y qué no
No todo evento de accionamiento necesita una notificación push a las 3 de la mañana, pero ciertos patrones sí ameritan una alerta activa (correo, SMS o push, según la criticidad):
- Comando enviado sin confirmación (ACK) en el tiempo esperado: el operador cree que la bomba encendió, pero el nodo nunca confirmó. Sin esta alerta, el primer indicio del problema es el cultivo sin regar horas después.
- Accionamiento fuera del horario o del patrón habitual: un relé que se activa a las 2 a.m. cuando el histórico de esa bomba muestra uso exclusivamente diurno es una señal —de una regla mal configurada o de un acceso no autorizado— que vale la pena revisar, no ignorar.
- Intentos de accionamiento sin permiso o con credenciales fallidas repetidas: tan relevante como saber qué se accionó es saber qué se intentó accionar sin éxito.
- Actuador que permanece encendido más allá de un límite razonable: un aireador o bomba que sigue activo mucho después de lo que el patrón operativo normal sugiere, típicamente por una regla que nunca evaluó apagarlo o por un fail-safe que no se disparó como se esperaba.
El diseño de estas alarmas sigue el mismo principio que ya tratamos en la nota sobre cómo configurar alarmas de energía sin ruido operativo: demasiadas notificaciones de bajo valor entrenan al equipo a ignorarlas, así que cada alerta de accionamiento debe representar una condición que de verdad requiera una decisión humana.
Cómo se ve en una instalación real
En una finca con riego automatizado, el flujo típico combina un Sensor HUB que reporta humedad de suelo, un actuador que abre la electroválvula o el contactor de la motobomba, y un gateway LoRaWAN que conecta ambos a la plataforma. La capa de permisos determina que el agrónomo de campo pueda abrir manualmente el riego de su parcela desde el celular, pero no reconfigurar el umbral de humedad que dispara el riego automático —eso queda para el administrador del sistema—. En una camaronera con varios aireadores por piscina controlados desde una tarjeta de riel DIN como Yubox Industrial o desde relés Yubox Air Control, la bitácora de auditoría es la que permite reconstruir, después de una mortandad, si el aireador de la piscina 4 se apagó por una regla automática, por una orden manual, o si simplemente nunca llegó el ACK del comando de encendido.
Conclusión
El control remoto de un motor no termina en la ingeniería de radio: exige la misma disciplina que cualquier sistema de control industrial expuesto a más de una persona —mínimo privilegio, roles diferenciados entre ver y accionar, autenticación robusta con segundo factor, una bitácora de auditoría inmutable y alertas que distingan lo urgente de lo rutinario—. Omitir cualquiera de esos cinco elementos no vuelve el sistema inútil, pero sí lo vuelve imposible de auditar cuando algo sale mal, y en una bomba o un aireador eso casi siempre se traduce en pérdida real. ¿Necesita definir roles, alertas y bitácora de auditoría para el control remoto de su operación? Conversemos sobre cómo configurar los permisos correctos para su equipo.