Servicio remoto para máquinas: acceso remoto seguro sin puertos abiertos

Una máquina se detiene, el cliente llama — y el técnico de servicio más cercano está a cientos de kilómetros. Para los fabricantes de maquinaria y los equipos de mantenimiento, el servicio remoto hace tiempo que dejó de ser una opción: es la condición para un servicio rentable. La pregunta no es si, sino cómo: ¿cómo llega usted a una máquina en la red de su cliente sin comprometer la seguridad informática de este — y sin iniciar un proyecto de VPN propio para cada instalación?

Esta guía muestra cómo funciona el servicio remoto con IronFlock: mediante conexiones salientes y cifradas, sin un solo puerto abierto en la máquina.

Por qué el servicio remoto clásico llega a sus límites

Los enfoques establecidos traen consigo problemas recurrentes:

• Las VPN site-to-site son proyectos, no soluciones. Cada conexión con un cliente exige coordinación entre dos departamentos de TI, reglas de firewall, conceptos de direccionamiento IP y mantenimiento continuo. Eso no escala a cientos de sitios.
• Los puertos entrantes abiertos son superficie de ataque. Cada servicio accesible desde el exterior en una máquina — SSH, HTTP, VNC — es una puerta de entrada potencial y, en muchas redes OT, sencillamente no es autorizable.
• Los routers de telemantenimiento crean soluciones aisladas. Un módulo de mantenimiento por máquina significa hardware propio, administración propia, accesos propios — y ninguna vista común de la flota.
• Falta trazabilidad. ¿Quién accedió, cuándo y a qué instalación? Sin un registro exhaustivo, esa pregunta apenas puede responderse ante clientes y auditores.

El principio: conexiones de dentro hacia fuera

IronFlock invierte la dirección. En la máquina — o en un dispositivo edge junto a ella — se ejecuta el agente del dispositivo de IronFlock. Este inicia todas las conexiones de forma saliente hacia la plataforma, cifradas mediante TLS. Esto tiene consecuencias inmediatas:

• Ningún puerto abierto en el dispositivo. La máquina no es descubrible desde internet ni directamente direccionable. No existe ningún servicio que un atacante pudiera escanear.
• Ninguna regla de firewall entrante en el cliente. Basta una conexión saliente HTTPS/WSS — el mismo tipo de conexión que utiliza cualquier navegador. También se soporta el funcionamiento detrás de proxys corporativos.
• Acceso remoto mediante túneles inversos. Cuando accede a una interfaz web local o a un servicio, la plataforma establece la conexión mediante una arquitectura de proxy inverso gestionado a través del canal existente — la dirección de la conexión original sigue siendo saliente.

Esta arquitectura de confianza cero se describe en detalle en la documentación de seguridad.

Qué puede alcanzar de forma remota

El Acceso remoto no está limitado a un protocolo. Por app y dispositivo pueden activarse túneles para distintos servicios:

Además, existen dos vías de acceso a nivel de sistema:

• Acceso al host — un terminal basado en navegador sobre el sistema operativo host del dispositivo, para diagnóstico del sistema, depuración de red y administración de Docker. Sin intervención local, sin desplazamiento in situ.
• Acceso SSH — para depuración avanzada con autenticación por clave; el inicio de sesión con contraseña está deshabilitado de forma predeterminada.

Los túneles también pueden integrarse mediante un widget de inserción directamente en un board: su equipo de servicio supervisa los datos de la flota e interactúa con la interfaz web de una máquina concreta — en el mismo dashboard.

Cómo funciona en la práctica

El servicio remoto con IronFlock se configura en tres pasos:

1. Declarar los puertos. El desarrollador de la app describe en la port-template.yml qué puertos y protocolos ofrece la app — por ejemplo, el HMI en el puerto 8080. Esto se hace una sola vez, en la app, no por máquina.
2. Activar el túnel. Un usuario autorizado activa el túnel en la configuración de la app del dispositivo — con un interruptor, sin configuración de red.
3. Usar la URL segura. La plataforma genera una URL protegida detrás de la cual queda accesible el servicio local — solo para usuarios autenticados y autorizados.

Si la conexión de red se interrumpe, el agente y el túnel se reconectan automáticamente — el agente está diseñado para la conectividad y la resiliencia y reintenta la reconexión de forma indefinida.

Un caso de servicio típico

Cómo se vive esto lo muestra un recorrido como el que ocurre a diario en el equipo de servicio de un fabricante de maquinaria:

1. Aviso. Una alarma o una llamada del cliente informa de una avería en una instalación en Francia. En el proyecto, el técnico lo ve de inmediato: el dispositivo está en línea, la app se está ejecutando.
2. Primer diagnóstico en el board. En el board de la máquina, los datos en vivo y los gráficos de historial muestran cuándo comenzó el comportamiento — a menudo, con eso la causa ya queda acotada.
3. Acceso al HMI. El técnico activa el túnel HTTPS y abre la interfaz de la máquina en el navegador — la misma vista que ve el operador in situ.
4. Profundizar si es necesario. Si no basta, sigue el túnel TCP hacia el controlador para el entorno de programación del PLC — o el acceso al host para revisar contenedores, red y carga del sistema.
5. Cerrar con todo documentado. Cada paso queda en el registro de auditoría. El cliente puede comprobar en todo momento quién accedió a su instalación y cuándo.

Sin cliente VPN, sin guardias de la TI del cliente, sin desplazamientos — y, en el mejor de los casos, la instalación vuelve a producir antes de que una intervención in situ siquiera se hubiera planificado.

Seguridad y control: ¿quién puede hacer qué — y quién hizo qué?

El acceso remoto es una cuestión de confianza. IronFlock lo hace controlable y trazable:

• Permisos granulares. Solo puede activar túneles quien posee al menos el permiso de actualización sobre el dispositivo. El modelo de privilegios trabaja con permisos específicos por recurso en lugar de roles de administrador genéricos.
• Pista de auditoría completa. Cada activación y cada uso de un túnel se registra en el registro de auditoría del dispositivo — quién, cuándo, qué puerto, incluidas las conexiones de proxy reales.
• Cifrado de extremo a extremo. Desde el navegador hasta el dispositivo, todos los componentes se comunican por canales protegidos con TLS; el inicio de sesión se realiza mediante OpenID Connect con autenticación de dos factores opcional.
• Acceso revocable en cualquier momento. Los permisos para socios de servicio externos se otorgan de forma granular y pueden retirarse en cualquier momento — el propietario del proyecto conserva la soberanía de los datos.

Para fabricantes de maquinaria: el servicio remoto como parte del producto

Quien entrega máquinas no quiere reinventar el servicio para cada sitio. Con IronFlock, el servicio remoto se convierte en parte de la propia máquina:

• Una app, toda la flota. La app de servicio se instala a nivel de proyecto y se asigna a los dispositivos — con diez o con mil máquinas, la vía de acceso es la misma.
• Despliegue flexible. Ya sea IronFlock Cloud, un Appliance en la red local del cliente o una nube privada — el alcance funcional, también para el acceso remoto, es idéntico.
• Usted aporta el conocimiento de la máquina, no la infraestructura. La gestión de túneles, el cifrado, la gestión de usuarios y el registro de auditoría los aporta la plataforma.

Preguntas frecuentes

¿Tiene que abrir puertos en el firewall la TI de mi cliente?

No. El agente del dispositivo establece exclusivamente conexiones salientes cifradas con TLS — comparable a un navegador que abre un sitio web. No se requieren reglas de firewall entrantes, redirecciones de puertos ni direcciones IP fijas. También se soportan entornos con proxy corporativo.

¿Puedo programar mi PLC de forma remota?

Sí. A través de túneles TCP llega a su controlador con las herramientas de ingeniería habituales — por ejemplo, Siemens TIA Portal, CODESYS o TwinCAT — como si estuviera en la red local. Los puertos se declaran una sola vez en la app y se habilitan de forma selectiva por dispositivo.

¿Cómo se registra y controla el acceso remoto?

Solo puede activar túneles quien posee el permiso correspondiente sobre el dispositivo. Cada activación y cada uso quedan en el registro de auditoría inmutable del dispositivo — incluidos el usuario, el momento y el puerto. Así puede demostrar en todo momento ante clientes y auditores quién tuvo acceso y cuándo.

¿Qué ocurre si la máquina está sin conexión o la conexión se interrumpe?

El agente del dispositivo reintenta la reconexión de forma indefinida y restablece automáticamente los túneles de acceso remoto tras una interrupción de red. Incluso bajo presión de memoria o de disco, el agente mantiene la accesibilidad remota como máxima prioridad — el dispositivo sigue siendo administrable de forma remota.

Próximos pasos

El camino más rápido hacia su primer acceso remoto: cree un proyecto con la guía de Primeros pasos, conecte un dispositivo y active un túnel — lleva pocos minutos y es gratuito en la nube. Los detalles técnicos los encontrará en la documentación de Acceso remoto y Seguridad.