Acceso Remoto Asistido y Desatendido: Cómo Elegir y Protegerlo
October 15, 2026
Son las 6:40 de la tarde de un lunes y una gerente de finanzas está a punto de cerrar el mes. Su laptop no abre el sistema contable. Llama a la mesa de ayuda, un técnico se conecta y en un minuto ya está moviendo su mouse. Nadie le preguntó si estaba de acuerdo, nadie anotó por qué hacía falta y la grabación, si existe, queda guardada en la laptop del técnico. Dos horas después, ese mismo técnico se conecta a un servidor de sucursal que nadie está usando y reinicia un servicio. Misma herramienta, mismo hábito, un riesgo completamente distinto.
El acceso remoto es la capacidad más usada y menos examinada en la mayoría de los departamentos de TI. Un técnico abre sesiones decenas de veces al día, casi siempre con prisa, y rara vez se detiene a preguntar si la conexión fue aprobada, quedó registrada o era realmente necesaria. Esa misma capacidad, en manos equivocadas, es también la puerta por la que entran los atacantes. Por esa tensión, elegir entre acceso remoto asistido y desatendido merece una política escrita y no un hábito.
Lo escribimos como asesores. Las primeras secciones aplican a cualquier herramienta de soporte remoto. Las siguientes muestran cómo NinjaOne Remote, uno de nuestros partners, lleva estos controles a la práctica y qué significa eso para los equipos de Latinoamérica.
En el lenguaje del sector, la diferencia entre los dos modos no es de sofisticación técnica. Es si hay una persona frente al dispositivo cuando el técnico se conecta. En una sesión asistida, el usuario está presente y enterado: pidió ayuda, ve lo que hace el técnico y puede detenerlo. En una sesión desatendida, el técnico se conecta a un dispositivo que nadie está usando en ese momento: una computadora durante la noche, un quiosco, un servidor, una laptop olvidada sobre el escritorio.
La distinción importa porque cambia tres cosas a la vez. La primera es el consentimiento. En una sesión asistida, la presencia del usuario es el consentimiento. En una desatendida, el consentimiento debe establecerse de antemano, por política, porque nadie puede hacer clic en permitir en el momento de la conexión. La segunda es la visibilidad. Un usuario presente puede notar una acción inesperada y decirlo. Una sesión desatendida no tiene testigos humanos, así que el registro y la grabación son los únicos testigos. La tercera es el alcance del daño. Un error en una sesión asistida suele afectar a un usuario. Un error, o una credencial robada, en un contexto desatendido puede alcanzar todos los dispositivos a los que llega el grupo de técnicos.
La mayoría de los equipos usa ambos modos y los mezcla sin darse cuenta. Ese es el verdadero punto de partida: rara vez el problema es que un modo sea peligroso, sino que nadie decidió qué modo aplica a qué trabajo, quién lo aprueba y qué evidencia queda después.
Las sesiones asistidas sirven para trabajo que requiere a una persona en el circuito: diagnosticar un problema que el usuario puede describir, guiar a alguien en una aplicación nueva, resolver algo que depende de lo que se ve en pantalla en ese momento o capacitar. El usuario ve el trabajo, lo que genera confianza en TI. El costo es la interrupción: el técnico necesita que el usuario esté disponible y el usuario no puede usar su dispositivo con normalidad durante la sesión.
Las sesiones desatendidas sirven para trabajo que no necesita al usuario: aplicar actualizaciones, instalar software, ejecutar un diagnóstico, recuperar una máquina que dejó de responder o dar soporte a dispositivos que no tienen un usuario habitual, como terminales de punto de venta, pantallas de señalización, equipos de laboratorio y servidores. Para equipos distribuidos y para proveedores de servicios gestionados, el acceso desatendido es lo que hace posible el soporte fuera del horario laboral y entre husos horarios. Abordamos el lado de la visibilidad de esa realidad en nuestro artículo sobre visibilidad de endpoints para equipos remotos.
Una regla sencilla funciona bien. Si el trabajo depende de lo que el usuario sabe o ve, usa acceso asistido. Si depende solo del estado del dispositivo, usa acceso desatendido. Cuando una tarea empieza de una forma y termina de la otra, por ejemplo una sesión asistida que necesita un reinicio y una instalación larga, cierra la sesión asistida, avisa al usuario y continúa bajo las reglas del acceso desatendido. Cambiar de modo en silencio es donde aparecen los huecos de política.
Toda vía legítima de acceso remoto es también una vía de ataque si está expuesta o mal controlada. Los datos de respuesta a incidentes coinciden en esto. El Active Adversary Report de Sophos del primer semestre de 2024 analizó casos de respuesta a incidentes atendidos por el equipo X-Ops de Sophos durante 2023. Los atacantes abusaron del protocolo de escritorio remoto (RDP) en 90% de los ataques. RDP y servicios remotos externos similares fueron el método de acceso inicial en 65% de los casos. En 43% de los casos, la autenticación multifactor no estaba configurada.
De ahí salen dos lecciones. Primero, el problema rara vez es la idea de acceso remoto. Es el acceso remoto alcanzable desde internet, protegido solo con una contraseña y sin monitoreo. Segundo, los adversarios no necesitan herramientas exóticas cuando ya hay una legítima instalada y de confianza. Una herramienta de soporte remoto mal gobernada es un regalo para ellos.
Nada de esto significa que debas evitar el acceso desatendido. Significa tratarlo como una capacidad privilegiada, con la misma disciplina que aplicas a las cuentas de administrador. Para el negocio, el resultado que importa es simple: el soporte sigue siendo ágil y ningún técnico, contratista o atacante llega a un dispositivo sin que alguien haya decidido que puede hacerlo.
El acceso desatendido conlleva más riesgo porque nadie está presente para notar un uso indebido. Estos son los controles que pedimos a nuestros clientes antes de habilitarlo de forma amplia. Limita quién puede conectarse: crea grupos de técnicos con permiso explícito, mantenlos pequeños y evita que todos los roles de la mesa de ayuda puedan llegar a todos los dispositivos. Exige autenticación multifactor a cada técnico que pueda abrir una sesión, porque una contraseña compartida en una herramienta remota es justo la debilidad que señalan los datos de Sophos.
Vincula cada conexión a un registro de quién se conectó, a qué dispositivo, cuándo, por cuánto tiempo y bajo qué ticket. Una conexión que no pueda asociarse a un ticket debe ser excepcional y revisarse. Usa aprobaciones con límite de tiempo para el acceso eventual, de modo que un técnico que necesita un grupo sensible de dispositivos para una tarea específica lo reciba por una ventana definida y no de forma permanente. Revisa la membresía de los grupos cada mes, porque las personas cambian de rol, los contratistas se van y el acceso sobrevive a la razón que lo originó. Una revisión mensual lo detecta antes que una auditoría.
Por último, decide de antemano qué se graba, quién puede ver las grabaciones, dónde se guardan y por cuánto tiempo, y fija reglas para la transferencia de archivos: propósitos limitados, una referencia de ticket en cada transferencia y un lugar claro donde viven los archivos transferidos. Ninguno de estos controles frena a un técnico competente. Frenan el error y el abuso, que es justamente la idea.
Las sesiones asistidas conllevan menos riesgo, pero también es donde vive la ingeniería social. Los atacantes se hacen pasar por personal de soporte, llaman a los usuarios y les piden aprobar una conexión. El hábito del usuario de hacer clic en permitir es la vulnerabilidad. La contramedida es sobre todo de conducta: obtén consentimiento explícito al inicio, explica al usuario lo que piensas hacer antes de tomar el control, narra las acciones que tocan datos, credenciales o configuraciones, y confirma con el usuario el problema, el alcance y la solución antes de cerrar, dejando constancia de esa confirmación en el ticket.
Los usuarios también necesitan saber cómo los contacta el soporte legítimo, para que una llamada inesperada que pide un código o una conexión llame la atención. Una nota interna breve con el proceso oficial, enviada por tu canal habitual, suele ser suficiente. Estos hábitos además mejoran la calidad. Un técnico que explica lo que hace suele detectar sus propios errores y deja al usuario mejor informado para la próxima vez.
Una política que vive en la cabeza de una persona no es una política. Deja por escrito cuándo aplica cada modo, con dos o tres ejemplos reales de tickets anteriores, el texto de consentimiento para sesiones asistidas, la ruta de aprobación para las desatendidas y qué se registra en el ticket después de cada sesión. Después, mídelo: resolución en el primer contacto, tiempo medio de resolución, tasa de visitas repetidas y la proporción entre sesiones asistidas y desatendidas. Esa proporción es especialmente reveladora. Un equipo que descubre que la mayoría de sus sesiones son desatendidas debería verificar si sus controles corresponden a esa realidad.
La laptop de un empleado remoto. El empleado reporta que una aplicación de negocio falla después de reiniciar. El problema depende de lo que el usuario ve, así que el acceso asistido es la elección correcta, con consentimiento solicitado al inicio. Si la solución implica una instalación larga, acuerda una hora y termina el trabajo de forma desatendida. El empleado trabaja desde casa, posiblemente en una red compartida, así que importa más la ruta de conexión que la ubicación física: sin reglas de entrada, grupos de técnicos controlados y un ticket como registro.
Un servidor o un quiosco sin usuario habitual. Las terminales de punto de venta, los quioscos de sucursal, las pantallas de señalización y los servidores rara vez tienen a alguien cerca para aprobar una conexión. El acceso desatendido es la única opción práctica, y por eso necesita los controles más fuertes: un grupo pequeño y aprobado, autenticación multifactor, aprobaciones con límite de tiempo para todo lo que salga del mantenimiento rutinario y una revisión mensual de quién pertenece al grupo.
Un contratista o un dispositivo que no es tuyo. Un proveedor necesita revisar un dispositivo que no está inscrito en tu plataforma de administración. No instales un agente permanente para una tarea puntual. Usa un método temporal basado en invitación, define una fecha de vencimiento y registra quién invitó a quién y por qué.
NinjaOne es partner de GB Advisors y lo implementamos para clientes en Latinoamérica y el Caribe. El técnico inicia una sesión remota desde el panel del dispositivo y el equipo final recibe una solicitud de conexión. NinjaOne Remote ofrece control remoto completo y, en Windows, también el Modo Background. Los usuarios pueden tomar el control de sus propias computadoras cuando están lejos mediante el Portal del Usuario Final, y pueden correr hasta tres conexiones simultáneas contra un mismo dispositivo, ya sea de los mismos técnicos o usuarios o de otros.
El consentimiento es un ajuste y no un hábito. Un ajuste global hace que NinjaOne Remote pida confirmación al usuario final antes de conectarse. A nivel de organización, el ajuste agrega un tiempo de espera para la confirmación y una opción para permitir el acceso si ese tiempo vence, algo que no aplica a dispositivos móviles. A nivel de dispositivo, los administradores pueden deshabilitar NinjaOne Remote en un dispositivo, o exigir un aviso de aprobación con un tiempo de espera opcional. Así puedes escribir tu política dentro de la herramienta: las estaciones con usuario exigen aprobación, mientras que los servidores y quioscos se manejan distinto, con la excepción como una decisión deliberada y revisable.
El acceso de los técnicos está controlado por permisos, asignados por rol o por usuario, y el Modo Background exige un permiso aparte. Una lista de IP permitidas admite hasta 10 direcciones IP WAN de origen y bloquea las demás, y una sesión ya establecida sigue permitida si la IP WAN cambia. Durante la sesión, una pequeña ventana de notificación en el dispositivo avisa al usuario que el equipo está controlado y muestra una marca configurable. El usuario final puede ocultar esa ventana, y ocultarla no termina la sesión, así que confirma que esto coincide con tus expectativas de transparencia antes del despliegue.
Los técnicos pueden usar control completo, enviar combinaciones de teclas como Ctrl-Alt-Del y F12, imprimir de forma remota, transferir archivos, chatear con el usuario final, ajustar la calidad de video, grabar la sesión y terminarla. Los ajustes de sesión concentran buena parte de la política. Puedes definir un tiempo de inactividad con una acción que no haga nada, bloquee la estación o cierre la sesión del usuario, elegir una acción al cerrar con esas mismas tres opciones, sincronizar el portapapeles en ambos sentidos y limpiarlo al cerrar, deshabilitar el fondo de pantalla remoto, grabar automáticamente y bloquear el teclado y el mouse del técnico para una sesión de solo visualización. Las grabaciones se guardan por defecto en la computadora del técnico y el directorio puede cambiarse. Eso cambia tu estrategia de evidencia: una grabación en una laptop es tan duradera y está tan protegida como la laptop, así que define cómo se recolectan las grabaciones y quién puede acceder a ellas.
El Modo Background es la respuesta práctica al mantenimiento mientras alguien trabaja. Corre bajo la cuenta SYSTEM de Windows en un escritorio separado, y el usuario no ve ninguna sesión remota. El técnico dispone de Explorador de archivos, Editor del Registro, Administrador de servicios y PowerShell, además de Visor de eventos, Administración de discos y CMD. Permite aplicar parches, desplegar software, ejecutar scripts, cambiar configuraciones, recolectar registros y reiniciar servicios sin reiniciar el equipo. Para usarlo, el rol necesita el permiso Background Mode for NinjaOne Remote en Allowed, la función debe estar habilitada en Administration, Apps, Installed, NinjaOne Remote, y el dispositivo debe estar administrado por NinjaOne. El inicio y el fin de la sesión se registran con el nombre del técnico, y las sesiones del Modo Background también se graban.
El Modo Background tiene límites que conviene conocer. Las aplicaciones que dependen de la sesión interactiva del usuario, de gráficos o de tokens de perfil pueden no funcionar ahí. Los reinicios interrumpen la sesión del usuario, así que prográmalos fuera del horario laboral o usa una sesión estándar. Esto se conecta directamente con los parches, tema que tratamos en nuestro artículo sobre gestión automatizada de parches: un técnico puede pasar de una actualización fallida a la corrección sin cambiar de herramienta.
Para dispositivos que no están inscritos en NinjaOne, Quick Connect ofrece acceso de una sola vez sin agente preinstalado. Las invitaciones se crean para destinatarios específicos, con nombre, descripción opcional, organización opcional, vencimiento y confirmación opcional del usuario final, y se envían por enlace, código o correo. Quick Connect también puede desplegar el agente de NinjaOne, conectarse con credenciales de administrador guardadas o de un solo uso mediante Connect As, y compartir pantalla desde la aplicación móvil NinjaOne Assist con un código de invitación. Las invitaciones, los despliegues de agente y otros eventos quedan registrados en la pestaña Activities. Primero debe habilitarse en Administration, Apps, Installed, NinjaOne Remote, y no puede conectarse a un dispositivo sin conexión. Encaja con el escenario del contratista que vimos arriba.
En la red, NinjaOne Remote usa el puerto TCP 443 como vía principal, el puerto TCP 7075 como alternativa y admite proxies SOCKS 5. Los dispositivos no necesitan reglas de entrada, porque ambos lados se conectan hacia afuera a la nube de NinjaOne. Los proxies o la inspección SSL pueden romper las sesiones, así que ese tráfico debe incluirse en una lista de permitidos o excluirse de la inspección. Los dispositivos compatibles son Windows, macOS, Android, iOS e iPadOS, con límites en móviles: los Android totalmente administrados permiten control completo si el usuario final lo autoriza, los Android con perfil de trabajo o personales son de solo visualización, y todos los dispositivos Apple son de solo visualización. En macOS, el control remoto requiere los permisos de Grabación de pantalla y Accesibilidad, con Acceso total al disco como opcional, y todos pueden aprobarse de antemano mediante MDM. El streamer se despliega de forma silenciosa junto con el agente de NinjaOne, mientras que el reproductor se instala manualmente desde la biblioteca.
Cuando el acceso remoto vive en la misma plataforma que el monitoreo, los parches y la automatización, hay menos lugares donde puede esconderse una vía de acceso sin gobierno. Analizamos esa lógica en el costo oculto de la dispersión de herramientas de TI, y la guía de RMM explica por qué el acceso remoto pertenece junto a esas funciones.
Las organizaciones de la región suelen operar con equipos de TI reducidos que cubren varios países, sedes y husos horarios, y muchas dependen de proveedores externos para parte de su soporte. Eso hace más común el acceso desatendido y vuelve más importante el gobierno de los técnicos de terceros que en una empresa de una sola oficina. Una cadena regional con cien sucursales, cada una con una terminal de punto de venta y una computadora de trastienda, no puede enviar a una persona a cada sitio. Necesita mantenimiento nocturno y necesita la certeza de que quien se conecta es quien la política dice que es.
De ahí salen tres puntos prácticos. Deja por escrito qué grupo de técnicos pertenece a cada proveedor y retira el acceso el día en que termina el contrato, no en la próxima revisión. Revisa las expectativas de manejo de datos que aplican en cada país donde operas e involucra a los equipos legales o de cumplimiento cuando las grabaciones o las transferencias de archivos puedan incluir datos personales. Y prueba la calidad de la conexión desde los lugares donde tus usuarios realmente trabajan, porque las redes de la región varían mucho. Los proxies corporativos y la inspección SSL son comunes en organizaciones grandes, lo que convierte la lista de permitidos mencionada antes en una tarea real para tu equipo de redes y no en una nota al pie.
Lo mismo aplica a los proveedores de servicios gestionados que atienden a muchos clientes desde un solo equipo. Los límites de acceso son lo que impide que el grupo de técnicos de un cliente vea los dispositivos de otro, un tema que desarrollamos en cómo los MSP gestionan entornos multi-cliente.
Antes de asumir que tu esquema actual está bien porque nada ha fallado a simple vista, responde con honestidad estas cinco preguntas.
Si dudas en dos o más de estas respuestas, las puertas abiertas ya existen. El siguiente paso es un inventario y una política de una página, seguidos de un piloto con un grupo de técnicos antes de ampliarlo.
El acceso desatendido es demasiado riesgoso para permitirlo. Conlleva más riesgo, pero prohibirlo empuja a los técnicos hacia herramientas no aprobadas que quedan fuera de cualquier registro. Un acceso gobernado, con grupos pequeños, reglas de consentimiento y revisión, es más seguro que un acceso que nadie ve.
No necesitamos grabar todas las sesiones. Es correcto. Graba donde los datos, la obligación de cumplimiento o el riesgo lo justifiquen, y define almacenamiento, retención y acceso antes de activar la grabación. Un montón de grabaciones sin reglas es un pasivo.
Una segunda herramienta remota no nos cuesta nada. Cuesta un conjunto adicional de credenciales, una bitácora adicional y una vía de acceso que puede quedar fuera de tus revisiones. Operar más de una herramienta sin una razón es uno de los errores más comunes que vemos.
Nuestro firewall bloqueará esto. NinjaOne Remote no necesita reglas de entrada en los dispositivos, porque ambos lados se conectan hacia afuera por el puerto TCP 443, con el puerto 7075 como alternativa. Lo que tu equipo de redes debe hacer es incluir en la lista de permitidos, o excluir de la inspección, los proxies y la inspección SSL para ese tráfico.
La pregunta correcta no es qué modo usar. Es si tu organización puede demostrar, en cualquier momento, quién tiene acceso a qué dispositivos, por qué lo tiene y qué hizo con él. Si la respuesta es sí tanto para el acceso asistido como para el desatendido, tu soporte remoto es un activo. Si es no, es un riesgo que además resulta cómodo.
Empieza con el inventario y la política de una página, y luego haz un piloto de los controles con un equipo. Mide primero tu línea base, por ejemplo el tiempo medio de resolución de los tickets remotos, para que la mejora pueda demostrarse y no solo suponerse. En GB Advisors ayudamos a equipos de TI y proveedores de servicios gestionados de Latinoamérica y el Caribe a evaluar, diseñar e implementar controles de administración remota y seguridad, con un análisis independiente primero y una recomendación después. Conversa con nuestro equipo sobre una revisión breve de tus vías de acceso remoto y te mostraremos dónde están las puertas abiertas.
