MFA y hashing de contraseñas
TOTP con apps de autenticador y códigos de recuperación. Contraseñas con Argon2id; cuentas antiguas migradas en el primer login. Política de MFA configurable como obligatoria por tenant.
Seguridad de la plataforma
Lunixar está diseñado para que el acceso sea verificado, el aislamiento entre tenants sea total, y la ejecución remota tenga controles explícitos. MFA, Argon2id, política de contenido, niveles de confianza y auditoría completa — sin excepciones en las capas críticas.
Aplicable a backend, WebSocket, agente y viewer. Sin excepciones en aislamiento de tenant ni RBAC.
Modelo de 3 capas
Controles implementados
Cada control está verificado en código. No hay funciones prometidas ni en roadmap en esta lista.
TOTP con apps de autenticador y códigos de recuperación. Contraseñas con Argon2id; cuentas antiguas migradas en el primer login. Política de MFA configurable como obligatoria por tenant.
Aislamiento completo en backend, WebSocket, agente y viewer. RBAC en cada endpoint — sin acceso cruzado posible entre tenants.
Tenants sin confianza verificada no pueden combinar descarga y ejecución. Confianza extendida con TTL de 30 días. Reglas de destinos bloqueados aplican en registro y terminal.
Refuerzos transversales
Fuerza bruta bloqueada por Redis, detección de reutilización de refresh tokens y MFA step-up. CSRF double-submit, security headers y sesiones revocables.
Binarios obfuscados sin .pdb, actualizaciones verificadas con SHA-256 y allowlist de URL. Enroll tokens con expiración y límite de usos; los instaladores de agente no pueden renombrarse desde la plataforma.
Ejecuciónes bloqueadas en script_logs con el motivo exacto. Cambios de nivel de confianza con timestamp, usuário y motivo.
Modelo de seguridad en 3 capas
Las tres capas de seguridad aplican en orden. Sin identidad verificada no hay acceso; sin acceso con permisos no hay operación; sin confianza verificada no hay ejecución remota sensible.
1
Login protegido con Argon2id, protección contra fuerza bruta por Redis, y TOTP MFA configurable como obligatorio por tenant. Las acciones sensibles requieren step-up MFA reciente aunque la sesión esté activa.
2
RBAC verifica permisos en cada capa. El aislamiento de tenant impide cualquier acceso cruzado entre cuentas. Cada request al backend, al WebSocket y al viewer pasa por validación de tenant y rol.
3
La política de contenido bloquea combinaciones de descarga y ejecución para tenants no verificados. Las reglas de destinos bloqueados aplican a terminal, scripts, schedules y registro de cuentas. Todo lo bloqueado queda en el log de auditoría.
Preguntas frecuentes
TOTP con apps de autenticador como Google Authenticator, Authy o cualquier app compatible. Al activar MFA se generan códigos de recuperación de un solo uso. Los tenants pueden configurar MFA como obligatorio para todos sus usuários.
El aislamiento de tenant está implementado en todas las capas: backend, WebSocket, agente y viewer. Cada request valida el tenant del usuário antes de acceder a cualquier dato. No hay rutas de acceso cruzado ni por error de configuración.
Para tenants sin confianza verificada, el script se bloquea antes de llegar al agente. Se guarda con IsMalicious=true en la plataforma y la ejecución queda registrada en script_logs con WasBlockedBySecurityPolicy y el motivo exacto.
Sí. La plataforma expone las sesiones activas desde la configuración de cuenta. Puedes ver cada sesión activa y revocarla individualmente sin necesidad de cambiar la contraseña.
Prevención de abuso RMM
La página de seguridad explica el modelo de plataforma; la página de prevención de abuso se enfoca en política de ejecución remota, instaladores no renombrables, restricción por tenant, auditoría y reporte.