Plataforma NinjaOne Relay

Tema

Este artículo describe NinjaOne Relay para entornos desconectados y aislados.

Entorno

Plataforma NinjaOne

Descripción

NinjaOne Relay ofrece funciones de gestión de terminales para entornos totalmente desconectados y aislados físicamente. Relay permite un control ampliado para la gestión de inventarios, la aplicación de parches, la generación de informes y el análisis de terminales que, de otro modo, quedarían sin gestionar. Haz clic en las secciones siguientes para obtener más información.

• Servidor NinjaOne Relay
• Modos de funcionamiento
• Escuchas y superficies de red
• Interfaz de usuario (UI)
• Seguridad
• Flujos de trabajo
• Durabilidad de los datos
• Cumplimiento normativo
• Recursos adicionales

Servidor NinjaOne Relay

El servidor NinjaOne Relay amplía la cobertura de NinjaOne a los terminales que no pueden conectarse directamente a la plataforma SaaS de NinjaOne. NinjaOne Relay se ejecuta como un servicio en un host gestionado y actúa como intermediario de confianza. Un pequeño agente específico para cada plataforma en cada terminal envía información al relé. Desde allí, los datos se envían a NinjaOne (modo A) o permanecen en el entorno local y se muestran a través de la interfaz de usuario (UI) del operador en los modos B, C o D. Varios relés pueden compartir una única autoridad de certificación mediante una configuración de confianza entre pares, lo que permite que las implementaciones más grandes o redundantes distribuyan los agentes entre varios relés que confían entre sí.

Modos de funcionamiento

La clave de configuración `operating_mode`, establecida en el momento de la instalación, determina qué subsistemas se inician y qué superficies de red se abren. Todos los modos utilizan el mismo transporte mTLS del agente. Lo que varía entre ellos es lo que fluye por encima de esa capa y en qué dirección. Consulte la siguiente tabla para obtener más detalles sobre los modos de funcionamiento. Haga clic en el nombre del modo para obtener más detalles.

Modo A: Puente

Para clientes cuyo host de relé pueda conectarse a NinjaOne y que prefieran controlar los terminales desde la plataforma NinjaOne que ya utilizan. El acceso a la API de NinjaOne solo es necesario durante la instalación, pero se pueden revocar los permisos posteriormente, y el relé sigue sincronizándose a partir de sus asignaciones de roles almacenadas en caché.

Modo B: Unidireccional: par protegido por diodo

Para entornos que necesitan que NinjaOne envíe archivos y tareas a través de un límite de confianza sin que nada vuelva. NinjaOne empareja dos relés a través de un diodo de datos de hardware (Guard); el relé aislado se comunica con sus terminales, pero no puede volver a conectarse con NinjaOne ni con el relé conectado.

Modo C: Aislamiento físico: totalmente autónomo

Para enclaves que no tienen ninguna ruta de acceso a NinjaOne. El relé constituye toda la superficie de gestión, controlada a través de la interfaz de usuario local. 

Modo D: Par «Sneakernet»: conectado ↔ aislamiento físico ↔ aislado

Para un verdadero aislamiento físico (air-gap), puenteado mediante soportes sellados, un operador transporta los paquetes entre dos relés emparejados: el lado conectado empaqueta los paquetes, el lado aislado los reproduce y devuelve los resultados de la misma manera.

Escuchas y superficies de red

El relé de NinjaOne se ejecuta en Windows Server 2019 o superior, macOS 12 o superior y versiones modernas de Linux, con una variante FIPS disponible para implementaciones reguladas. Expone hasta tres escuchas TLS entrantes, dependiendo del modo. Los agentes siempre se conectan al relé en el puerto 8443; las otras dos dependen del modo. La única conexión saliente que establece un relé es una conexión HTTPS con la API de NinjaOne, y solo desde el relé que está conectado a NinjaOne (modo A), además del lado conectado de los pares de los modos B y D. El relé con aislamiento físico (modo C) y los relés aislados no establecen ninguna conexión saliente. La siguiente tabla describe cada opción de escucha.

Interfaz de usuario (UI)

Los modos B, C y D cuentan con una consola de operador optimizada integrada directamente en el binario del relé. Hay cinco espacios de trabajo de nivel superior: 

Estado: estado delos trabajadores , profundidad de las colas, verificación de la cadena de auditoría.

Inventario: historial de hardware, software y red por punto final.

Biblioteca: paquetes , parches, contenido SCAP, líneas de base de cumplimiento, archivos preparados y paquetes.

Configuración: usuarios y roles, autenticadores, TLS y PKI externa.

Selección de objetivos: elige un conjunto de objetivos y una acción, y observa a continuación una cuadrícula de tareas en tiempo real.

Seguridad

NinjaOne Relay incluye las siguientes funciones de seguridad:

Transporte e identidad

TLS mutuo entre cada agente y el Relay, utilizando una autoridad de certificación ECDSA P-256 integrada generada en el primer inicio. Cada agente recibe un certificado de cliente válido durante 90 días a través de un token de inscripción de un solo uso. Los certificados se renuevan automáticamente 30 días antes de su caducidad. NinjaOne Relay admite la revocación mediante CRL y un respondedor OCSP conforme a RFC 6960 con AIA integrado. Los agentes fijan la huella digital de la CA de Relay durante la primera inscripción (TOFU) y rechazan cualquier discrepancia posterior con la CA.

Autenticación del operador

La interfaz de usuario del operador admite cuentas locales con almacenamiento de contraseñas Argon2id, autenticación multifactorial (MFA) TOTP con recuperación en tres niveles (códigos por usuario, restablecimiento por parte del administrador con la firma conjunta de dos administradores y una clave de emergencia generada durante la instalación). La autenticación CAC/PIV opcional valida la cadena completa de certificados frente a los anclajes de confianza importados por el operador con revocación OCSP y CRL en tiempo real (fallo duro por defecto; se ofrecen opciones de fallo blando y anulación mediante un respondedor OCSP interno para entornos aislados).

Defensa en profundidad

Listas de permisos y denegaciones de IP, filtrado de países por GeoIP y limitación de tasa mediante «token bucket» por terminal y a nivel global. Las direcciones de origen IPv6 se agregan a /64 por defecto (límite de host según RFC 4291), por lo que un par hostil con un prefijo enrutado no puede agotar el límite del «token bucket» por clave. El campo «X-Forwarded-For» solo se tiene en cuenta cuando el par figura en la lista de proxies de confianza. Los datos de inventario proporcionados por el agente se someten a un proceso de escape HTML antes de mostrarse en los campos WYSIWYG de NinjaOne, lo que elimina la vulnerabilidad de XSS almacenado.

Auditoría a prueba de manipulaciones

NinjaOne Relay registra cada inscripción, emisión de certificados, revocación, envío de tareas, cambio de configuración y acción administrativa en un registro de auditoría respaldado por SQLite con una cadena de hash paralela (SHA-256(canonical(row) ‖ prev_hash)). Un punto final de verificación recorre la cadena y detecta la primera ruptura, lo que resulta adecuado para el análisis forense de la respuesta a incidentes y la certificación entre relés en el Modo D.

Credenciales en reposo

NinjaOne Relay almacena los tokens de inscripción como hash SHA-256, y tanto la clave de la API de comandos como el token de inscripción se renuevan automáticamente según una programación configurable. NinjaOne Relay almacena la clave en un campo personalizado seguro de tipo TEXT_ENCRYPTED con permiso de automatización READ_ONLY. Los secretos a nivel de columna (claves privadas de paquetes, secretos de MFA) se envuelven con una clave de cifrado de claves generada durante la instalación y se almacenan en un archivo con chmod 0600 junto a la base de datos. Todos los secretos en disco tienen permisos 0600; el servicio de Linux se ejecuta como un usuario dedicado bajo el refuerzo de seguridad de systemd.

Opción FIPS 140-3

Un modo de compilación FIPS opcional restringe los conjuntos de cifrado TLS y valida los tipos de clave para implementaciones reguladas. El sobre del paquete admite tanto las suites Ed25519/X25519 (por defecto) como ECDSA-P256/ECDH-P256 (conforme a FIPS); en modo FIPS, el hash de la contraseña cambia de Argon2id a PBKDF2-HMAC-SHA512 con 600 000 iteraciones.

Flujos de trabajo

Más allá del inventario original y las primitivas de comando, los modos B, C y D añaden los siguientes flujos de trabajo para las tareas diarias de los operadores que antes requerían automatizaciones personalizadas de NinjaOne: 

• Parches: importar paquetes de parches, implementarlos en los destinos, realizar un seguimiento del estado de instalación por terminal y mostrar la línea de base de parches instalados en el inventario. 
• Paquetes de software: instalar, desinstalar y verificar mediante comandos específicos para cada plataforma; lista de paquetes como inventario. 
• Análisis SCAP: gestionar el contenido, los motores y las personalizaciones de los análisis; activar análisis; incorporar resultados ARF/XCCDF; los hallazgos por regla se muestran en la interfaz de usuario. 
• Líneas de base de cumplimiento: paquetes denominados de parches y paquetes obligatorios, además de un perfil SCAP; asignación a los terminales; una tabla de terminales × línea de base muestra de un vistazo si están en cumplimiento, fuera de cumplimiento o en estado desconocido. 
• Transporte de paquetes (Modo D): el lado del productor empaqueta todo lo anterior como operaciones de paquete firmadas; el lado del consumidor las reproduce.

Durabilidad de los datos

A prueba de fallos por defecto. Todos los estados autoritativos persisten en una base de datos SQLite en modo WAL con confirmaciones sincrónicas y permisos 0600, incluyendo certificados emitidos, registros de terminales, instantáneas de inventario, el registro de auditoría, tokens de inscripción, archivos en fase de preparación, la caché de roles de NinjaOne, colas de paquetes, cuentas de usuario y sesiones, resultados SCAP y líneas de base de cumplimiento. Un reinicio repentino del host solo hace que se pierda, como mucho, lo que se estuviera en medio de una confirmación; SQLite revierte esos cambios al volver a abrirse. No se requiere ningún procedimiento especial de apagado. El estado en memoria es efímero y se puede perder sin problema al reiniciar, y las tareas periódicas de limpieza (retención, poda de instantáneas, caducidad de tokens y archivos) se ejecutan automáticamente sin intervención del operador.

Cumplimiento normativo

El producto incluye tres documentos de cumplimiento: una certificación STIG de Seguridad y Desarrollo de Aplicaciones (ASD), una matriz de controles NIST SP 800-53 (rev. 5) y una guía de refuerzo de seguridad para operadores. El registro de auditoría se conserva durante 90 días de forma predeterminada y se puede exportar. NinjaOne Relay no almacena datos de los clientes más allá del inventario de terminales y el historial de tareas; todo ello permanece en la infraestructura del cliente a menos que se sincronice explícitamente con NinjaOne (Modo A).

Recursos adicionales

Para obtener más información sobre NinjaOne Relay, consulta «NinjaOne Endpoint Management: Requisitos del sistema y compatibilidad».