¿Qué es el software RMM y para qué sirve?

Teletransportémonos un instante hasta la Nostromo para este tema. Observemos cómo la tripulación de la película de Alien viaja hibernada, pero la nave no vaga a la deriva en la oscuridad. El ordenador central, Madre, vigila los sistemas y solo despierta a sus tripulantes cuando algo pide ojos humanos. Pero un momento, ¿esta no es la película donde (casi) todos mueren horriblemente por un xenomorfo? Bueno, sí, pero quedémonos con la idea de una máquina que vigila y gestiona mientras nadie mira, avisando solo cuando hace falta. Bajado a nuestra órbita IT y multiplicado por cientos de equipos, eso es lo que hace un RMM en esencia.
Así que analicemos ese software a fondo para comprenderlo y, de paso, evitar que se vuelva contra nosotros, como Madre en la obra maestra de Ridley Scott.
Como veremos, un RMM (Remote Monitoring and Management, o monitorización y gestión remota) es el software que permite vigilar y administrar equipos a distancia desde una única consola. Para proveedores de servicios gestionados (MSP) y departamentos IT con la infraestructura desparramada por todas partes, esa es la forma óptima de gobierno: concentrar Mando y Control en un punto.

¿Qué es el software RMM?

El inevitable trámite de la definición nos enfocará correctamente si sabemos leer el concepto en dos tiempos.
Un software RMM (Remote Monitoring and Management o Monitorización y Gestión Remota) es una plataforma que permite ver qué le pasa a un equipo y hacer algo al respecto sin tenerlo delante.
Ese primer tiempo de lectura, monitoring, implica capacidades de supervisión, de ver estado, disponibilidad, métricas de rendimiento y qué falla en el sistema.
La segunda parte de management implica acción sobre dicho equipo, como ejecutar un script, reiniciar, instalar paquetes, parchear o reconfigurar.
La clave es el término restante, remote. El hecho de poder extender nuestros hilos manejando desde un solo punto estaciones de trabajo de una sucursal lejana, servidores en un centro de datos, endpoints de teletrabajadores… O en el caso de un MSP, equipos que ni siquiera son nuestros, sino de diferentes clientes desperdigados por todas partes.
Un RMM debe cumplir todo eso, porque sin la primera mitad de monitorización seremos ciegos, sin la segunda de gestión seremos inútiles y sin el remoto necesitaremos un poder de bilocación que no se nos va a conceder.
En resumen, un único trono y un poder sobre muchos, que podemos extender hasta el último rincón.

¿Cómo funciona una herramienta RMM?

Que nadie se lo diga a marketing, pero casi todos los RMM se parecen más por dentro de lo que su publicidad quiere admitir.
Por eso, el flujo de trabajo típico de un RMM es, en realidad, una rueda que gira (casi) sola:

• Se despliega un agente o mecanismo de gestión en cada equipo a controlar y monitorizar.
• Estos reportan información a una plataforma central, nuestro Trono de Hierro.
• La consola muestra el estado y las métricas de cada dispositivo.
• Las alertas configuradas se disparan cuando se cumplen ciertas condiciones.
• Los técnicos pueden ejecutar acciones remotas desde esa misma consola de monitorización (de ahí el «casi» del principio, porque en este trabajo algo requerirá que Madre despierte a un humano tarde o temprano).
• Las tareas repetitivas se pueden automatizar.

La arquitectura concreta es lo que sí cambia según el fabricante.
Así, hay RMM que empujan órdenes desde el servidor y otros que prefieren que sea el agente quien las recoja.
En Pandora RMM, por ejemplo, nuestro sistema funciona así: el agent se conecta al servidor buscando ejecuciones programadas y, si las encuentra, las lleva a cabo en local y después reporta su estado. Así la consola no llama a la puerta del equipo remoto, sino que este acude a recoger el encargo.
Durante esos viajes la comunicación circula cifrada y el agente consulta (por defecto) cada treinta segundos, quedando la respuesta acotada por ese intervalo y el tiempo de ejecución de la tarea.

Funciones principales de un software RMM

Cuando se trata de RMM, con las prestaciones ocurre un poco como con el funcionamiento, que las diversas opciones tienden a proporcionarnos poderes similares, aunque siempre varían según marca y precio que podamos pagar, claro.
Esas funciones que nos debe permitir un buen RMM son:

• Monitorizar endpoints: desde disponibilidad hasta rendimiento, pasando por métricas y sin necesidad de estar pendientes de preguntarles «cómo están».
• Inventariar hardware y software: sabiendo exactamente qué tenemos, dónde y por qué versión van en el baile constante de números.
• Configurar y recibir alertas: que avisan cuando la Nostromo se desvía de rumbo, algo se rompe o, mejor aún, antes de que ese algo se rompa.
• Ejecutar comandos y scripts remotamente: como actualizar o correr código en una, varias o todas las máquinas a la vez.
• Automatizar tareas: para que la máquina haga lo que un humano repite mil veces al día.
• Instalar y actualizar software: sin necesidad de abrir sesión por equipo, que es la esencia del despliegue automatizado de software.
• Gestión de parches (patch management): aplicando a escala los remiendos necesarios.
• Acceso y control remoto: el RMM debe ahorrar viajes, pero no la capacidad de usar el equipo como si lo tuviéramos delante.
• Gestionar procesos y servicios: como arrancar, parar o reiniciar.
• Programar tareas: para que las cosas sucedan a la hora prevista y no cuando nuestra neurona saturada se acuerde.
• Generar informes: convirtiendo datos brutos en algo más sencillo y visual, que jefes y clientes puedan fingir que entienden.
• Dashboards: teniendo una pantalla que cuente la historia de un vistazo a quienes no tienen tiempo de leer.

Obviamente, lo anterior es lo ideal, pero en la vida real algunas funciones vienen de serie en algunas aplicaciones RMM, pero otras pueden llegar vía integración, mientras otras más, simplemente, pueden no estar.
Por eso, cuando leamos «un RMM hace X» en la lista anterior, es mejor traducir mentalmente a «un RMM puede hacer X si el producto concreto lo soporta». Ese «puede» es el matiz que nos recordará no comprar a ciegas.
Aumentemos ahora el zoom sobre el tema y analicemos algunos cometidos clave que el RMM puede facilitar en nuestro día a día en IT.

Los RMM y la gestión de parches

Como el parche que no se aplica a tiempo muta en vulnerabilidad que explota esa misma noche, el patch management es una de las funciones más demandadas, y útiles, en un RMM, ya que esa tarea es candidata perfecta para una ejecución remota.
Dicha gestión de parches en un buen RMM debería incluir:

• Detección de las actualizaciones que haya disponibles.
• Despliegue centralizado de las mismas.
• Programación por ventanas para no ponernos con ella en hora punta de trabajo.
• Selección de qué dispositivos entran en cada ventana y la validación posterior de que el parche tapó el agujero sin abrir diez nuevos.

La gestión de parches es tan fundamental como cambiarle el aceite a la Nostromo, higiene básica más que prestación moderna. De hecho, NIST la encuadra como mantenimiento preventivo dentro de su guía de gestión empresarial de parches (SP 800-40 Rev. 4).
Para quienes quieran profundizar, hablamos en su día con detalle en nuestra guía de gestión efectiva de parches.

Los RMM y la automatización

Si el parcheado es higiene, la automatización de tareas IT es ahorro, tanto de tiempo, como de cordura y esfuerzo.
En las situaciones donde se puede delegar la tarea a una máquina, un RMM brilla porque ya pone en su sitio la palanca adecuada, un agente en cada máquina, capaz de ejecutar lo que le ordenemos.
Ahora, es importante recordar que antes he resaltado «cordura» y, si queremos conservarla, hemos de entender que no todas las tareas son buenas candidatas a la automatización. Las que sí tienen papeletas son:

• Ejecución de scripts.
• Instalación de paquetes y apps.
• Reinicio de servicios y aplicación de cambios de configuración.
• Limpieza de temporales acumulados.
• Lanzamiento de otras tareas programadas…

Pero donde obtenemos valor de verdad es en reaccionar sin intervención humana ante eventos conocidos.
Por ejemplo, si el sistema detecta que el servicio de impresión (siempre es la impresora) se ha colgado y sabe que el remedio es reiniciarlo, poco sentido tiene que técnicos que cobran como seniors dejen el café y el Genshin Impact para ir a darle a un botón.
Con la automatización conseguimos:

• Menos trabajo manual.
• Menos errores no forzados.
• Técnicos que dejan el café y el Genshin para dedicarse a tareas de mayor valor, como Clair Obscur.

En entornos IT multicliente, como el de un proveedor de servicios gestionados (MSP), esa automatización puede ser la ventaja en productividad que buscamos. En esos casos, recordemos estandarizar servicios MSP primero, porque es el requisito imprescindible para la automatización bien hecha.
Y hablando de proveedores de servicios…

Por qué los MSP utilizan herramientas RMM

Gestionar un MSP viene con un problema de fábrica, manejar mil equipos de mil clientes distintos y hacerlo con un margen que no acabe devorado por desplazamientos en carretera y horas de trabajo técnico.
En un escenario de gestión como ese, el RMM se vuelve imprescindible y de ahí su uso habitual por MSP que cosechan beneficios como:

• Centralización de la gestión: traducida en «muchos clientes, una única consola».
• Monitorización proactiva de problemas: enterándonos antes de que el cliente lo tuitee o, mejor aún, antes de que se produzca.
• Menos desplazamientos: de modo que cada visita que no hacemos es margen que conservamos.
• Estandarización: que, en la medida de lo posible, se plasma de nuevo en «muchos clientes, una única configuración» similar en todas partes. Esa es la llave para poder escalar nuestras operaciones.
• Automatización: y que el trabajo repetitivo lo haga quien no cobra por hora.
• Tiempos de respuesta menores: que no se dan necesariamente porque corremos más, sino porque la monitorización en un MSP nos ahorra esas carreras.
• Mejor control del SLA: porque nos permite medir y esa es la primera pieza del cumplimiento.
• Una gestión multicliente: pudiendo hacer malabarismos con varias organizaciones, una plataforma y datos segregados, sin que se nos caiga nada al suelo.

Hoy, un MSP sin RMM que intente microgestionar doscientos endpoints a golpe de clic difícilmente ganará la partida por volumen.

RMM para equipos IT internos

Cualquier departamento IT que tenga una infraestructura repartida entre nubes varias, aplicaciones de terceros, sistemas on-premise y virtualizaciones (¿queda alguien que no viva así?) se encuentra con idéntico problema de base que un MSP: máquinas desperdigadas «por ahí fuera» que alguien tiene que cuidar.
Teletrabajo, sedes en otros países, endpoints distribuidos o entornos híbridos a medio terminar… La llave del RMM encaja igual de bien en esta cerradura, solo que aquí el «cliente» es nuestra propia organización y el SLA nuestra propia paciencia.

RMM vs acceso remoto

Hay confusiones que conviene despejar, porque los dos conceptos del título no son lo mismo.
El acceso remoto es lo que permite conectarnos a un equipo y operarlo a distancia. Vemos la pantalla, movemos el ratón de forma que parezca magia a los no técnicos, arreglamos lo que toca y nos vamos.
Esto es extremadamente útil y también reactivo y de uno en uno.
Así, el acceso remoto seguro es la casilla inicial del juego, pero el RMM añade otras capas de barniz: monitorización continua, automatización, alertas… y gestión centralizada simultánea de muchos equipos.

RMM vs NMS

Esta es otra confusión habitual que trae más miga técnica, así que saquemos la lupa y examinemos de cerca.
Un NMS (Network Management System) posa sus ojos en la red, en los routers, switches, protocolos, disponibilidad y rendimiento de nuestra infraestructura de comunicaciones. Y ese es su terreno natural, los caminos por los que viaja todo.
Por otra parte, un RMM mira hacia los sistemas y endpoints, como estaciones de trabajo o servidores, que operamos y administramos de forma remota. Si el NMS examina los caminos, el RMM examina los destinos de esa comunicación y lo que corre dentro de ellos.
Por eso no son lo mismo y tampoco se sustituyen, sino que pueden coexistir perfectamente en sus terrenos, complementándose para cumplir nuestro viejo sueño de control total con puño de hierro.
En Pandora, de hecho, existen licencias diferenciadas para RMM y NMS, aunque ambas pueden integrarse dentro de la misma plataforma, porque la idea no es elegir entre ver la red o ver los equipos, sino cambiar esa «o» por una «y» sin levantar un castillo de Frankenstein de herramientas.

RMM vs PSA

He aquí dos términos que se mencionan juntos, ya que RMM y PSA trabajan en tándem, pero repartiéndose tareas diferentes.
Así, el RMM actúa sobre los sistemas, como ya hemos visto, y detecta, monitoriza y ejecuta, mientras que el PSA (Professional Services Automation) gestiona el negocio del servicio, en forma de tickets, tiempos, contratos, facturación y todo el papeleo que existe entre «lo arreglé» y «lo cobré».
La integración de ambas herramientas permite, por ejemplo, que una alerta técnica se convierta en una incidencia gestionable con su responsable asignado, tiempo y cierre.
Sin embargo, no todo RMM trae PSA de serie. Algunos lo incluyen de forma nativa, pero otros se limitan a exponer la información técnica y dejan que el PSA la recoja vía integración.
Si esta funciona bien, el salto de la alerta por «disco lleno» al «ticket abierto y asignado» sucede automáticamente sin que nadie tenga que pulsar teclas, que es justo donde está el ahorro real.

Beneficios del software RMM

Hemos echado un vistazo a bastantes ya cuando hablábamos de RMM y MSP, pero lo cierto es que son extensibles a la gestión moderna de casi cualquier departamento IT pues, como comentaba también, estos sufren la necesidad de gestionar de forma homogénea infraestructuras cada vez más heterogéneas.
Por eso, los beneficios globales de un RMM se pueden resumir en:

• Mantenimiento proactivo: actuando guiados por tendencias que nos permiten intervenir antes de que el umbral estalle.
• Ahorros de tiempo: gracias a menos clics repetidos, menos túneles carpianos y menos sesiones manuales.
• Menos desplazamientos también: porque cada visita evitada es dinero que se queda en el bolsillo.
• Estandarización: desplegando lo mismo por igual en todas partes, lo que ahorra horas de soporte a nuestro yo futuro.
• Reducción del trabajo repetitivo: de forma que la rutina sea responsabilidad del sistema y no de la persona.
• Menor tiempo de respuesta: porque cuando saltó la alerta de posible incendio ya estábamos mirando la chispa.
• Mayor visibilidad: sabiendo qué tenemos en nuestro inventario y en qué lamentable estado se encuentra de un solo vistazo.
• Potencial de escalabilidad: haciendo crecer nuestra iniciativa en número de máquinas sin crecer proporcionalmente en personas que las atiendan manualmente.
• Soporte al SLA: de modo que, gracias al RMM, podemos medir para cumplir y cumplir para cobrar.

En definitiva, las ventajas que sostienen las estrategias para reducir horas de soporte sin perder SLA y minimizar el soporte reactivo que nos devora el margen.

Los riesgos y seguridad de un RMM

Siempre que escribo suelo llegar a la parte que menos gente quiere leer y que, a la vez, es la que más se debería considerar, la seguridad, porque, ¿qué necesita un RMM para funcionar bien y hacer todo eso tan maravilloso que hemos visto?
Privilegios elevados, y además, con capacidad de actuar sobre muchos equipos a la vez. Eso significa que si nos comprometen la plataforma, consiguen las llaves del parque entero y la sangría de la Nostromo palidecerá frente a la que nos harán a nosotros.
Por eso hemos de blindar el juguete y he aquí buenas prácticas para ello, que podemos usar como lista de chequeo a la hora de revisar nuestro RMM.

• Autenticación multifactor: la consola RMM es la llave maestra de todas las puertas y, sin MFA, una contraseña filtrada abre todo nuestro cielo a los actores maliciosos.
• Privilegios mínimos y control férreo de accesos: la regla es la de siempre, cada técnico ve y toquetea solamente lo que necesita y ni una cosa más.
• Auditoría y registro de sesiones: que nos chive en todo momento quién entró, qué hizo y en qué momento, para cuando algo pase y haya que hacer de Sherlock Holmes.
• Gestión segura de credenciales: que no sean contraseñas en un post-it pegado al monitor, como me he encontrado más de dos veces en demasiadas oficinas.
• Segmentación clara: separando clientes y entornos para que si un hacker nos abre una brecha, la grieta no se propague a todos en cascada.
• Actualización de la propia plataforma: porque, irónicamente, la herramienta que parchea también debe ser parcheada.
• Control de scripts: con inventario y revisión habitual de lo que se ejecuta en masa, ya que hemos de recordar que correrán en muchos sitios a la vez.
• Revisión de cuentas inactivas: dado que permisos zombis y credenciales olvidadas son los agujeros de entrada favoritos de los hackers.

La pesadilla de nuestro Equipo Azul de ciberseguridad con un RMM es la de los Borg de Star Trek, la asimilación completa y de golpe de toda nuestra flota IT… porque nosotros mismos entregamos el control centralizado.
Al final, un punto único de control y mando también es un punto único de fallo y riesgo, por eso la CISA no trata las plataformas RMM como una nota a pie de página.
En su plan de ciberdefensa para RMM advierte de que los actores de ransomware las usan precisamente para saltar desde un MSP a las redes de sus clientes, multiplicando el alcance de un solo compromiso.
En resumen, lo que nos hace eficientes en la gestión también hace muy eficientes a los adversarios en sus labores.

Qué mirar a la hora de elegir un software RMM

Creo que todos sabemos cómo va este tema, que las demos siempre funcionan bien, pero el día a día es otra cosa. Por eso, para distinguir valor real de teatro de producto conviene de nuevo que consideremos lo siguiente como una lista de chequeo durante nuestra elección y miremos bien:
Sistemas operativos compatibles: cubriendo lo que tenemos de verdad, no lo que el comercial suponga.

• Despliegue: para ver cómo se instalan los agentes y a qué velocidad se replica todo.
• Escalabilidad y multitenancy: para que crecer en clientes no nos obligue a rehacer todo el telar constantemente, como Penélope mientras esperaba a Odiseo.
• Automatización y scripting: averiguando cómo de fácil es codificar tareas y reutilizarlas en las herramientas que estamos valorando.
• Gestión de parches: con su alcance real y no solo el que insinúa el marketing.
• Inventario de activos: para saber qué profundidad y frescura de datos obtendremos sobre los elementos de nuestra infraestructura.
• Control remoto: integrado, seguro y sin licencia sorpresa para algo tan crítico.
• Alertas e informes: que sean realmente útiles y no queden en ruido bonito solamente.
• Seguridad y auditoría: el multifactor que hemos visto, registros de actividad, segmentación… todo lo comentado en el epígrafe anterior.
• API e integraciones (PSA/ITSM): porque un RMM aislado e incapaz de comunicarse bien es media solución.
• Modelo de licencia y despliegue: ¿on-premise o SaaS? ¿Por agente o por nodo?… Y ojo a los topes ocultos.
• Soporte: porque cuando algo explota a las tres de la mañana, el nivel de respuesta se paga caro si escatimamos.

Cómo encaja Pandora RMM

Todo lo anterior son más que datos y prestaciones, es lo que hemos vivido en Pandora. Por eso más de veinte años, cientos de clientes y miles de equipos y necesidades diferentes han cristalizado en Pandora RMM, nuestra solución especializada en las necesidades reales de monitorización y gestión remota.
Ella nos permite:

• Controlar remotamente equipos Windows, Linux o Mac (y sin licencia adicional).
• Instalar, actualizar y parchear selectivamente, para mantener los equipos afinados y seguros.
• Inventariar hardware y software.
• Correr scripts con precondición y post-ejecución.
• Ejecutar el arranque y parada de procesos y servicios.
• Informes y dashboards a medida…

Es decir, todo lo realmente útil, gestionado de forma centralizada.
Y para entornos MSP, eso vive dentro de una misma plataforma común, pero con gestión diferenciada por cliente.
En definitiva, que no hemos puesto todas esas listas de chequeo porque son lo que toca en un contenido, sino porque las hemos destilado de nuestros errores y aciertos en este tiempo.
Pero seamos honestos donde corresponde. Las funciones de seguridad y compliance de Pandora RMM (auditorías, recogida centralizada de logs o alertas) contribuyen al blindaje del entorno, pero no la convierten en un EDR o un SIEM.
Obviamente, esa es una conversación distinta, pero siempre queremos dejar claro hasta dónde llegamos, sin motos que vender.

Preguntas frecuentes

Sócrates pensaba que la manera de aprender era hacerse las preguntas adecuadas y tenía razón, así que recapitulemos lo más importante que hemos visto de esa forma.

¿Qué significa RMM?

Remote Monitoring and Management (monitorización y gestión remota), término que hace referencia al software que nos permite supervisar y administrar equipos a distancia desde una única consola central de mando.

¿Para qué sirve un software RMM?

Para gestionar muchos equipos remotos desde un punto único de mando que haga que no tengamos que desplazarnos para labores de monitorización, inventario, parcheo, ejecución de scripts, automatización o control del dispositivo.

¿Quién utiliza herramientas RMM?

Sobre todo, los Proveedores de Servicios Gestionados (MSP), pero también departamentos IT internos que manejan un contexto similar de infraestructura distribuida entre teletrabajo, sucursales, sedes repartidas por todas partes y entornos híbridos.

¿Cuál es la diferencia entre RMM y acceso remoto?

Uno es la parte y otro es el todo, porque el acceso remoto nos conecta a un equipo para operarlo, pero el RMM va mucho más allá y añade monitorización continua, automatización, alertas o gestión centralizada sobre muchos equipos a la vez.
Un RMM puede y suele incluir control remoto, pero es importante comprender que no son lo mismo.

¿Cuál es la diferencia entre RMM y PSA?

Que el RMM actúa sobre sistemas detectando, monitorizando y ejecutando en ellos, mientras el PSA gestiona el negocio del servicio, como la creación de tickets, el control de tiempos, contratos, facturación…
En un mundo IT ideal, RMM y PSA se integran para convertir alertas técnicas en incidencias gestionables, pero es importante comprender que no todo RMM incluye PSA y no debemos esperarlo por defecto.

¿Un RMM sirve para gestionar parches?

Sí. La mayoría de soluciones RMM incluyen patch management porque es básico y un caso de uso ideal.
Así, podemos detectar necesidades de parcheo, desplegar desde central, programar y verificar ese despliegue a las horas óptimas y en dispositivos seleccionados…
Eso sí, como todo en esta vida, el alcance y la madurez varían entre productos y presupuestos.

¿Un RMM es una herramienta de seguridad?

Por sí solo no. Es cierto que complementa la seguridad con el parcheado, inventario, políticas o acceso controlado, pero no sustituye a un EDR ni a un SIEM.

¿Puede utilizar un RMM una empresa que no sea MSP?

Sí, por supuesto. Cualquier organización con endpoints distribuidos puede aprovecharlo y, de hecho, muchas infraestructuras IT se parecen a un MSP en el sentido de tener muchas máquinas y no todas en proximidad física.

Conclusión

La operación IT ha cambiado mucho en poco tiempo y también lo ha hecho de sitio. Antes, intervenir era sinónimo de aparecer, de abrir el ticket, coger el coche, sentarse ante el equipo, arreglar y volver a nuestra Batcueva. Pero la escala de las operaciones actuales y su dispersión han hecho inviable este modelo.
Hoy, el RMM es la pieza que permite graduarnos de una actuación equipo por equipo a gobernar infraestructuras completas desde una única consola que combina monitorización, automatización y acción remota.
El mejor amigo de nuestra obsesión de control.
Para un MSP especialmente, el valor de un RMM es lo que libera, es poder ampliar su cartera de dispositivos y clientes sin que la carga operativa crezca igual. Eso gana margen sin perder control, que al final es el juego real del MSP.
Aquella Nostromo del principio se vigilaba sola mientras la tripulación dormía, ahora, podemos conseguir lo mismo en nuestra infraestructura… Y con menos aliens acechando por sus pasillos.

Isaac García

Siempre con un teclado entre manos, desde el primer ZX Spectrum que abrí de par en par para ver cómo funcionaba, la tecnología ha sido mi pasión y trabajo, de lo que hablo y lo que escribo.

Always with a keyboard in my hands, ever since I opened up my first ZX Spectrum wide to see how it worked, technology has been my passion and my work, what I speak about and what I write about.