Arquitectura del Agente

Cada agente de Moftgate se comunica con el servidor en un programa regular llamado heartbeat. En cada heartbeat el servidor decide qué debe hacer el agente: qué ajustes aplicar, qué políticas DLP hacer cumplir, qué módulos ejecutar y qué campos personalizados o exclusiones de actualización respetar. Esta guía explica esas decisiones desde la perspectiva de un administrador para que pueda configurar los agentes con confianza.

La configuración se entrega a través de tres capas que se ejecutan en orden en cada heartbeat: primero el servidor elige el perfil activo para ese endpoint, luego filtra las políticas DLP por ámbito de destino y, finalmente, combina el perfil elegido con los predeterminados del tenant. Las verificaciones de licencia se ejecutan junto con este flujo, de modo que las funciones sin licencia nunca se envían al agente.

Un perfil de agente es un paquete reutilizable de ajustes: interruptores DLP, reglas USB, opciones del gateway de contenido web, rutas de monitoreo de integridad de archivos y más. En lugar de configurar cada endpoint individualmente, crea un puñado de perfiles que coincidan con los roles de sus dispositivos (por ejemplo "Laptops de finanzas", "Terminales kiosk", "Estaciones de trabajo de desarrolladores") y asigna un perfil a cada endpoint.

Cuando un agente se registra por primera vez, se le asigna automáticamente el perfil predeterminado. Si ha marcado un perfil como predeterminado, se usa ese; de lo contrario se usa el perfil más antiguo como respaldo. Puede reasignar el perfil en cualquier momento desde la página de detalle del endpoint.

1. 1
   Abra la página de detalle del endpoint

   Vaya a Fleet Intelligence, abra el endpoint que desea configurar y localice el selector de Agent Profile.

2. 2
   Elija un perfil

   Seleccione el perfil de agente que coincida con el rol del dispositivo (p. ej. "Laptops de finanzas", "Terminales kiosk"). El cambio surte efecto en el próximo heartbeat.

3. 3
   Verifique en la caché del agente

   En el endpoint, ejecute "agent --profile" para confirmar que los ajustes en caché, las políticas DLP y los módulos activos coinciden con lo que configuró.

Cerrar imagen

El ámbito de destino decide a qué endpoints se aplica un perfil o política. Cuando el servidor selecciona el perfil activo para un endpoint, recorre una escalera de prioridad de lo más específico a lo menos específico. El primer ámbito que coincide gana, y los ámbitos de menor prioridad se ignoran para esa decisión.

El orden de prioridad, de mayor a menor, es: endpoints, luego users, luego groups, luego profiles, luego all. En términos simples: una regla dirigida a un único dispositivo vence a una dirigida a una persona; una persona vence a un grupo; un grupo vence a un perfil; y un perfil vence a una regla general para "todos".

Los grupos le permiten dirigir políticas y perfiles a colecciones de dispositivos o personas. Moftgate mantiene dos tipos independientes de membresía de grupo: grupos de endpoints (qué dispositivos pertenecen juntos, p. ej. "Servidores IT", "Estaciones de trabajo de contabilidad") y grupos de usuarios (qué personas pertenecen juntas, p. ej. "Contratistas", "Directivos").

Cuando una política usa el ámbito "groups", el servidor verifica ambos tipos de membresía: si el endpoint o su usuario actualmente conectado pertenece a al menos uno de los grupos seleccionados, la política se aplica. Esta lógica OR significa que puede dirigir una política a "cualquiera en el grupo de Finanzas o cualquier dispositivo en el grupo de Finanzas" con una sola regla.

• Los grupos de endpoints son ideales para políticas por rol de dispositivo (p. ej. aplicar bloqueo USB estricto en terminales kiosk).
• Los grupos de usuarios son ideales para políticas basadas en personas (p. ej. permitir transferencia de portapapeles para directivos independientemente del laptop que usen).
• Un único endpoint puede pertenecer a muchos grupos, y un único usuario puede pertenecer a muchos grupos.

Las políticas DLP se filtran por ámbito de destino en cada heartbeat, de modo que cada agente recibe solo las políticas relevantes para él. Se usan los mismos cinco ámbitos, con un detalle importante para el ámbito "groups": coincide si el endpoint pertenece a un grupo seleccionado O el usuario conectado pertenece a un grupo seleccionado.

Lo que un agente realmente hace está controlado por dos cosas: si su licencia incluye el módulo y si el módulo está activado en el perfil activo del endpoint. Ambas deben ser verdaderas para que la función se ejecute. Esta verificación de dos capas evita que se envíen funciones sin licencia al agente y le permite desactivar un módulo por perfil incluso cuando está licenciado.

En cada heartbeat el servidor envía al agente una lista corta de módulos activos. El agente solo inicia las tareas en segundo plano para los módulos de esa lista: no rastreará el portapapeles ni el USB para DLP si DLP está inactivo, no vigilará archivos para monitoreo de integridad si visibility está inactivo, etc. Esto mantiene a los agentes inactivos ligeros.

• Heartbeat siempre funciona, incluso sin licencia, por lo que el agente permanece visible en el panel.
• Si no existe archivo de licencia, todos los módulos se cierran y el agente no hace nada más allá del heartbeat.
• Un módulo desactivado en el perfil no se envía al agente, ahorrando CPU, memoria y red.
• Cuando la licencia cambia, la lista de módulos activos se actualiza en el próximo heartbeat.

Los campos personalizados y las exclusiones KB (knowledge base) se entregan a los agentes con la misma lógica de coincidencia de destino que las políticas. Cada campo personalizado o exclusión puede tener como ámbito todos los endpoints, un grupo, un perfil, una tag o un único endpoint, de modo que los agentes solo reciben lo que les aplica.

Los campos personalizados le permiten recopilar metadatos adicionales de cada endpoint (por ejemplo "Centro de Costos", "Departamento", "Tag de Activo"). El agente recopila automáticamente valores conocidos como hostname, OS y nombre de usuario, usa el valor predeterminado para todo lo demás y luego reporta los valores al servidor en cada heartbeat.

Las exclusiones KB le indican al agente qué actualizaciones de OS omitir. Cuando el agente está a punto de instalar una actualización, primero verifica la lista de exclusiones; cualquier actualización excluida se omite y se registra. Las exclusiones también se pueden filtrar por tipo de sistema operativo, de modo que una exclusión solo para Windows nunca afecta a un agente macOS.

Para usuarios avanzados e ingenieros de soporte, el agente incluye un pequeño conjunto de banderas de línea de comandos. Son útiles para diagnosticar lo que un endpoint está haciendo realmente y para probar reglas DLP contra un archivo antes de desplegar una política.