RMM autohospedado vs. administrado: guía para MSP pequeños

Respuesta corta: Elige entre RMM autohospedado y administrado decidiendo quién puede operar el plano de control de forma segura cada semana. Compara costo total, riesgo de acceso privilegiado, uptime, actualizaciones, backups, monitoreo, integraciones, soporte, migración y rollback. Una licencia más barata solo ayuda cuando el MSP puede financiar y demostrar las responsabilidades que pasan a su equipo.

La licencia no es la decisión real

Un MSP pequeño puede estar satisfecho con su RMM actual y aun así necesitar reducir gastos. Eso crea una pregunta atractiva: si el equipo ya hospeda documentación, monitoreo o administración de red, ¿por qué no hospedar también el RMM?

Una discusión reciente en r/SmallMSP sobre cambiar a un RMM open source expuso el tradeoff real. Los operadores hablaron de ahorro en licencias, tiempo de mantenimiento, backups, monitoreo, actualizaciones, certificados, seguridad, seguros, integraciones y el riesgo de colocar a todos los clientes detrás de infraestructura que ahora debe defender el MSP.

Esta guía no califica productos RMM. Ayuda a un MSP pequeño a decidir si el plano de control debe operarlo un vendor, el propio MSP o una combinación híbrida en etapa de prueba.

Usa el framework de selección de stack para comparar el RMM contra el resto de las herramientas. Usa esta guía cuando la decisión específica sea quién será dueño de la infraestructura RMM y sus modos de falla.

Separa el modelo de licencia del modelo operativo

Open source y autohospedado no son sinónimos. Responden preguntas distintas.

• Open source: el código fuente y la licencia permiten un nivel definido de inspección, modificación o redistribución.
• Propietario: el editor del software controla el código fuente y los derechos de licencia.
• Autohospedado: el MSP o su proveedor de infraestructura opera la aplicación y sus dependencias.
• Administrado o SaaS: un vendor opera el servicio y lo entrega bajo una suscripción o acuerdo de servicio.

Eso crea al menos cuatro modelos posibles:

1. Software open source operado por el MSP.
2. Software open source hospedado y soportado por un vendor.
3. Software propietario entregado como servicio administrado.
4. Software propietario licenciado para que el MSP lo hospede.

No uses “open source” como sinónimo de gratuito, autohospedado, sin soporte o inseguro. No uses “SaaS” como sinónimo de mantenido, recuperable o seguro. Registra el modelo real de licencia, hosting, soporte, actualizaciones, datos y responsabilidades.

Define el trabajo del RMM antes de cambiarlo

Escribe qué carga realmente el RMM actual antes de comparar reemplazos:

• Enrollment e inventario de endpoints.
• Aprobación, despliegue, excepciones y evidencia de parches.
• Acceso remoto por escritorio, shell y transferencia de archivos.
• Almacenamiento, aprobación, ejecución y resultados de scripts.
• Políticas de monitoreo, enrutamiento de alertas, supresión y escalación.
• Roles técnicos, separación de clientes e historial de auditoría.
• Creación de tickets y propiedad dentro de la mesa de servicio.
• Integraciones con documentación, PSA, facturación, reportes y APIs.
• Reportes para clientes y evidencia de revisión mensual.
• Acceso de emergencia cuando otra herramienta o sistema de identidad no esté disponible.

También registra lo que no hace. Una utilidad de acceso remoto no es automáticamente un RMM completo. Una herramienta de parches no incluye necesariamente monitoreo, scripts, propiedad de alertas y reportes para clientes. Reemplazar un producto por tres utilidades puede ser válido, pero el modelo operativo debe mostrar quién es dueño de los huecos.

Trata el RMM como infraestructura privilegiada compartida

Un RMM no es una aplicación web interna cualquiera. Puede ejecutar comandos, desplegar software, cambiar configuración, transferir archivos y alcanzar endpoints de varios clientes.

La guía conjunta de CISA para MSP y sus clientes destaca que los MSP normalmente mantienen acceso privilegiado y conectividad de confianza hacia los entornos de sus clientes. Un proveedor comprometido puede convertirse en una ruta de acceso inicial hacia varias organizaciones.

El límite de decisión es sencillo:

Si comprometer este plano de control puede afectar a varios clientes al mismo tiempo, opéralo como infraestructura crítica para la entrega del servicio, no como otro servidor económico.

Define el radio de impacto:

• ¿Cuántos clientes y endpoints puede alcanzar una sola cuenta técnica?
• ¿Una política, script, actualización o credencial puede cruzar límites entre clientes?
• ¿El RMM depende del tenant de identidad principal del MSP?
• ¿La misma identidad puede eliminar logs, backups y el servicio activo?
• ¿Qué acción de emergencia puede detener la ejecución remota sin destruir evidencia?
• ¿Cómo notificará y apoyará el MSP a los clientes afectados si se compromete la plataforma?

La respuesta no es que las plataformas administradas sean seguras y las autohospedadas peligrosas. La respuesta es que el acceso privilegiado crea riesgo en ambos modelos y alguien debe tener la capacidad, responsabilidad y presupuesto para operar los controles.

Construye un mapa de responsabilidades

Para cada tarea nombra responsable, evidencia, ruta de escalación y respaldo humano.

En un modelo administrado, verifica que el vendor sea dueño de

• Disponibilidad, capacidad y recuperación de la plataforma.
• Parches de infraestructura y aplicación.
• Monitoreo de la plataforma y respuesta a incidentes.
• Entrega segura de software y notificación de cambios.
• Backups del servicio y restores probados.
• Aislamiento entre tenants y capacidad de auditoría.
• Escalación de soporte y notificación de seguridad.
• Retención, exportación y eliminación de datos al terminar.

El MSP todavía es dueño de las identidades técnicas, roles, políticas de endpoint, atención de alertas, scripts, autorización del cliente, integraciones y promesas contractuales. SaaS no transfiere esas tareas.

En un modelo autohospedado, el MSP debe ser dueño de

• Sistema operativo, runtime, base de datos, proxy, DNS, certificados y dependencias.
• Diseño de red, exposición, reglas de firewall y acceso administrativo.
• Upgrades de aplicación, correcciones de seguridad, validación de releases y rollback.
• Capacidad, uptime, monitoreo, respuesta on-call y escalación con vendor o comunidad.
• Backups de datos, configuración, scripts, secretos y documentación de recuperación.
• Pruebas de restore dentro de un entorno limpio.
• Logs centralizados protegidos contra el mismo dominio de falla.
• Contención de incidentes, preservación de evidencia, comunicación al cliente y recuperación.

Si una responsabilidad no tiene dueño porque “el equipo lo atenderá”, en la práctica será responsabilidad de la persona más ocupada durante la caída.

Calcula el costo mensual total de entrega

Compara el mismo límite operativo en ambos modelos.

```text

Licencia o suscripción

+ cómputo, base de datos, almacenamiento, tráfico, DNS, certificados y backup

+ monitoreo, logging, escaneo de seguridad y entrega de alertas

+ labor de mantenimiento y upgrades rutinarios

+ pruebas de restore y ejercicios de continuidad

+ capacitación técnica y migración de flujos

+ tiempo esperado de incidentes y soporte

+ cobertura fuera de horario o soporte externo

+ depreciación o reemplazo de infraestructura on-premises

+ preparación de salida, exportación y rollback

= costo mensual total de entrega del RMM

```

Convierte el tiempo de la persona dueña en una tarifa cargada real. Dos horas de mantenimiento no son gratuitas porque ocurran después del trabajo de clientes. Agrega los ingresos o tareas de entrega que se desplazan cuando la persona más experimentada mantiene la plataforma.

Usa la guía de precios de servicios administrados para comprobar si el plan del cliente puede financiar este costo. Si el RMM ahorra 300 dólares en licencias, pero agrega 500 en labor recurrente y trabajo de riesgo, el ahorro no existe.

También modela el mes malo:

• Un upgrade falla y requiere rollback.
• La base de datos se llena o corrompe.
• Un certificado vence.
• El acceso remoto falla durante una caída del cliente.
• Una corrección de seguridad exige un cambio de emergencia.
• La única persona que entiende el despliegue no está disponible.

El mes normal demuestra viabilidad económica. El mes malo demuestra supervivencia.

Aplica una puerta mínima de seguridad

No pruebes un RMM autohospedado sobre endpoints de clientes hasta que existan estos controles:

• Cuentas técnicas nominativas; ningún administrador compartido.
• MFA resistente a phishing cuando la plataforma lo permita.
• Roles de mínimo privilegio separados por cliente y función.
• Una cuenta de emergencia separada con uso controlado y revisado.
• Acceso administrativo separado de navegación y correo técnico ordinarios.
• Exposición pública mínima, entrada y salida controladas, y puertos documentados.
• Secretos, tokens de API, llaves de firma, credenciales de base de datos y backup protegidos.
• Fuente de release verificada, integridad de actualizaciones, inventario de dependencias y paquete de rollback.
• Logs centralizados de autenticación, políticas, scripts, sesiones remotas y administración.
• Alertas que se conviertan en tickets con dueño, no en otra bandeja.
• Backup probado y restore dentro de un entorno limpio.
• Una ruta de aislamiento o apagado que detenga comandos remotos y preserve evidencia.
• Un runbook de incidentes escrito con responsable de notificación a clientes.

CISA, NSA y MS-ISAC advierten que el software RMM legítimo puede usarse para persistencia y comando y control. Sus mitigaciones incluyen auditar herramientas remotas autorizadas, revisar logs de ejecución, controlar la ejecución de software y restringir el acceso remoto a rutas aprobadas.

Aplica esa guía en ambos sentidos: protege tu RMM contra compromiso y ayuda a los clientes a distinguir tu agente autorizado de software remoto no permitido.

Diseña la continuidad antes de la primera caída

Define el objetivo de recuperación del propio RMM:

• ¿Cuánto tiempo pueden operar los técnicos sin la consola?
• ¿Qué soporte puede continuar mediante una ruta alterna?
• ¿Qué pérdida de configuración y datos es aceptable?
• ¿Dónde vive el backup y qué identidad puede restaurarlo?
• ¿Puede recuperarse el servicio si la cuenta cloud, sitio, dominio o tenant de identidad principal no está disponible?
• ¿Quién tiene el runbook y la autoridad de recuperación cuando la persona dueña está desconectada?

La guía de NIST sobre seguridad de acceso remoto recomienda tratar los componentes remotos mediante modelos de amenazas, controles de seguridad y políticas documentadas. Para un RMM autohospedado, la recuperación no puede limitarse a “la VM tiene backup”. El MSP debe probar que aplicación, base de datos, certificados, secretos, red, conectividad de agentes y acceso técnico pueden restaurarse juntos.

Ejecuta al menos estos ejercicios:

1. Restaura aplicación y base de datos dentro de un entorno aislado.
2. Recupera acceso administrativo sin depender del operador principal.
3. Reemite o restaura certificados y confianza de agentes de forma segura.
4. Confirma que los logs sobreviven a la pérdida o compromiso del servidor activo.
5. Deshabilita o aísla el plano de control sin desinstalar todos los agentes.
6. Soporta un endpoint mediante la ruta alterna documentada.

Conecta la evidencia con la checklist de pruebas de restore. Un snapshot exitoso no es un RMM recuperado.

Prueba el flujo, no solo la consola

El RMM está listo cuando el trabajo normal sobrevive al cambio.

Prueba:

• Un endpoint nuevo entra al cliente y política correctos.
• Un endpoint no administrado o desactualizado se vuelve visible.
• Una falla de parches produce un ticket con dueño y evidencia.
• Un técnico inicia una sesión autorizada sin credenciales compartidas.
• Un script requiere la aprobación prevista y registra operador, objetivo, resultado y hora.
• Las alertas conservan contexto del cliente y evitan ruido duplicado.
• Los datos de equipos y clientes siguen visibles en documentación.
• El trabajo incluido y los proyectos permanecen distinguibles para facturación.
• Los reportes mensuales se producen sin reconstrucción manual.
• El offboarding permite exportar datos, remover agentes y revocar accesos limpiamente.

Usa el modelo de mesa de servicio para MSP pequeños como recorrido de aceptación. Si las alertas no se convierten en trabajo con dueño, el nuevo RMM solo cambió el dashboard.

Ejecuta un piloto paralelo de 60 a 90 días

Comienza con equipos internos. Después agrega un grupo pequeño y autorizado de endpoints no críticos. No conviertas la primera prueba de recuperación en el día que se cancela la plataforma anterior.

Antes del piloto

• Registra un inventario de políticas, scripts, monitores, reportes, integraciones, roles y excepciones actuales.
• Define puertas obligatorias y criterios de aceptación medibles.
• Prepara runbooks de backup, restore, upgrade, caída y rollback.
• Define qué datos de clientes pueden entrar a la plataforma nueva y dónde residirán.
• Registra reglas de cancelación, exportación y eliminación de agentes del servicio anterior.

Durante el piloto

• Opera ambas plataformas solo donde sea seguro duplicar agentes y políticas.
• Evita jobs de parches, scripts, reinicios y configuraciones remotas que compitan.
• Mide setup, mantenimiento, revisión de alertas, limpieza de tickets y soporte.
• Completa al menos un upgrade normal y un ejercicio de rollback.
• Restaura la plataforma desde backup dentro de un entorno aislado.
• Prueba pérdida de un operador, credencial, certificado y nodo de servicio.
• Valida eliminación de endpoints y exportación de datos.
• Registra cada paso manual que el demo no mostró.

Detén el piloto si

• MFA, separación de roles, logs o aislamiento de clientes no cumplen la puerta.
• Las actualizaciones no pueden validarse o revertirse de manera predecible.
• El restore depende del conocimiento no documentado de la persona dueña.
• El acceso remoto no es confiable para la promesa de soporte.
• Las alertas crean más trabajo sin dueño que la plataforma actual.
• El costo operativo medido elimina el ahorro esperado.

Un piloto puede terminar con “conservar el RMM actual”. Evitar una mala migración es un resultado válido.

Usa puertas obligatorias antes de puntajes ponderados

No permitas que un precio bajo compense una falla de seguridad o recuperación.

Puertas obligatorias

• MFA y cuentas nominativas.
• Separación de clientes y mínimo privilegio.
• Acciones privilegiadas auditables.
• Acceso remoto confiable para los sistemas soportados.
• Backup y restore probados.
• Upgrades y rollback controlados.
• Ruta definida de incidentes y notificación a clientes.
• Datos de clientes y endpoints exportables.

Si un finalista falla una puerta, detén la evaluación o documenta una excepción temporal con responsable, fecha límite y control compensatorio.

Criterios ponderados

Califica a los finalistas contra la misma evidencia:

• Costo mensual total de entrega.
• Tiempo técnico semanal.
• Calidad de alertas y flujo de tickets.
• Control de parches y scripts.
• Esfuerzo de integración.
• Calidad de reportes.
• Soporte y escalación.
• Disponibilidad y recuperación.
• Esfuerzo de migración y costo de salida.
• Ajuste a las capacidades del equipo actual.

Conserva la evidencia junto al puntaje. Un “5” sin resultado de prueba es impulso de ventas escrito como número.

Planea migración y rollback juntos

El plan de migración debe incluir:

• Conciliación de inventario de endpoints y responsables.
• Aprobación del cliente cuando lo exija el contrato o alcance de seguridad.
• Mapeo de políticas, scripts, monitores, roles e integraciones.
• Rotación de credenciales y secretos.
• Reglas de convivencia de agentes y orden de eliminación.
• Ventanas de mantenimiento y controles de reinicio.
• Medidas de éxito por grupo de clientes.
• Punto de congelamiento para cambios riesgosos.
• Criterios de activación y autoridad de rollback.
• Exportación y retención desde la plataforma anterior.
• Evidencia final de que accesos y agentes anteriores fueron eliminados.

No asumas que desinstalar el agente anterior completa la migración. Confirma tareas programadas, servicios, módulos de control remoto, tokens de API, cuentas técnicas, webhooks, scripts y acceso del vendor.

Conecta la salida con la checklist de offboarding y recuperación de accesos, aunque el “offboarding” sea de una herramienta y no de un cliente.

Documenta la decisión para clientes y aseguradora

El registro útil no dice “open source es más seguro” o “el vendor grande es responsable”. Documenta:

• Razón de negocio para el cambio.
• Modelos y alternativas evaluadas.
• Puertas de seguridad y recuperación.
• Resultados de pruebas y excepciones conocidas.
• Ubicaciones de hosting y datos.
• Diseño de acceso privilegiado y separación de clientes.
• Responsables de actualizaciones, vulnerabilidades, incidentes y notificación.
• Evidencia de backup y restore.
• Acuerdo de soporte y escalación.
• Plan de migración, rollback y salida.
• Responsable de aprobación y próxima fecha de revisión.

La guía de CISA para MSP recomienda que los contratos entre MSP y cliente identifiquen claramente la propiedad de los roles y responsabilidades de seguridad. Un diseño autohospedado crea más responsabilidades que nombrar; no hace que desaparezcan del contrato.

Errores comunes

El error más común es comparar la factura SaaS contra la licencia autohospedada y llamar ahorro a la diferencia.

Otros fallos incluyen:

• Tratar open source y autohospedaje como la misma decisión.
• Llamar reemplazo completo de RMM al acceso remoto o parcheo aislado.
• Hospedar infraestructura crítica de control en un servidor sobrante sin monitoreo.
• Usar un administrador para todos los clientes y todas las capas de plataforma.
• Guardar logs y backups en la misma cuenta y dominio de falla que producción.
• Aplicar actualizaciones directamente en producción sin staging ni rollback.
• Ignorar mantenimiento de certificados, base de datos, dependencias y almacenamiento.
• Migrar scripts sin revisar privilegio y seguridad.
• Ejecutar dos agentes sin controlar políticas y reinicios duplicados.
• Cancelar el servicio anterior antes de aprobar exportación, recuperación y rollback.
• Contar noches y fines de semana de la persona dueña como labor sin costo.

Elige el modelo operativo que el equipo pueda sostener

El autohospedaje puede encajar cuando el equipo ya opera servicios seguros de producción, tiene más de una persona capaz, puede entregar monitoreo y respuesta, puede probar recuperación y el ahorro medido permanece después de sumar labor y riesgo reales.

Un RMM administrado puede encajar cuando el equipo necesita disponibilidad y actualizaciones operadas por un vendor, no quiere ser dueño de otra plataforma privilegiada, valora soporte contractual o todavía no puede cumplir internamente la puerta de seguridad y continuidad.

Un modelo híbrido puede encajar cuando el MSP prueba una plataforma autohospedada para uso interno o aislado mientras conserva la administrada para la cartera amplia. El híbrido solo ayuda cuando las herramientas duplicadas no crean deuda oculta de políticas, seguridad, facturación o capacitación.

Cuándo cambiar de nivel

Revisa la decisión cuando el contrato actual ya no corresponda al número de endpoints o flujo de efectivo, el soporte del vendor se convierta en riesgo de entrega, el autohospedaje consuma más margen del esperado, una sola persona continúe como dependencia crítica, la plataforma no alcance las puertas de seguridad o recuperación, o las integraciones impidan un servicio limpio.

El RMM correcto no se define por quién posee el servidor. Es el modelo que tu MSP puede asegurar, operar, recuperar, explicar y abandonar sin apostar la cartera de clientes.