Arquitectura de Wazuh: el camino del evento desde el agente hasta el dashboard
Cómo se conectan agente, manager, indexer y dashboard en Wazuh: el camino del evento, puntos de fallo y señales para operar la arquitectura.
Cuando una organización despliega Wazuh, el valor no está en instalar los cuatro componentes por separado, sino en entender cómo se relacionan entre sí. Sin esa comprensión, es común terminar con un SIEM que recibe datos pero no entrega correlación útil, o con un dashboard que muestra alertas que nadie sabe interpretar.
El problema operacional de fondo es conocido: eventos dispersos en servidores, cambios de configuración no autorizados, logs que se acumulan sin contexto y una visibilidad de seguridad fragmentada. La arquitectura de Wazuh —agentes, manager, indexer y dashboard— existe precisamente para resolver ese desorden, pero solo si se entiende el flujo completo de la información.
El problema que resuelve la arquitectura de Wazuh
En una operación típica, cada servidor genera eventos de seguridad: intentos de acceso fallidos, modificaciones de archivos críticos, ejecución de comandos sospechosos, cambios en políticas locales. Sin una capa central que los recopile y correlacione, esos eventos quedan aislados.
El resultado es una visibilidad fragmentada. El equipo de infraestructura revisa logs por separado, el equipo de seguridad no tiene contexto global y los cambios no autorizados pasan desapercibidos hasta que generan un incidente mayor. La arquitectura de Wazuh aborda esto estableciendo un flujo claro: los agentes recolectan, el manager procesa y correlaciona, el indexer almacena y el dashboard visualiza.
No se trata de una herramienta mágica, sino de un pipeline bien definido. Como todo pipeline, su eficacia depende de que cada etapa cumpla su función y de que las dependencias entre ellas estén controladas.
Componentes y flujo técnico de punta a punta
Agente: la capa de recolección
El agente es el componente que se instala en los servidores que se desea monitorear. Su función principal es recolectar eventos locales y enviarlos al manager. Dependiendo de la configuración, puede capturar logs del sistema, eventos de autenticación, cambios en archivos (FIM), inventario de software y hardware, y detectar procesos o conexiones anómalas.
El agente mantiene una comunicación activa con el manager. No es un proceso pasivo que espera consultas: envía eventos de forma continua y también recibe instrucciones de configuración. Esto permite actualizar políticas de detección sin intervenir manualmente en cada servidor.
Manager: procesamiento y correlación
El manager es el cerebro de la operación. Recibe los eventos de los agentes y aplica reglas de correlación para identificar comportamientos relevantes. Es aquí donde los eventos dispersos se convierten en alertas con contexto.
El manager también gestiona las políticas de los agentes, centraliza la configuración de los grupos de servidores y mantiene las bases de reglas que definen qué se considera sospechoso. En despliegues más grandes, puede escalarse en clúster para distribuir la carga y garantizar disponibilidad.
Un punto importante: el manager no almacena los eventos de forma indefinida. Su rol es procesar y decidir qué es relevante. El almacenamiento a largo plazo corresponde al indexer.
Indexer: almacenamiento y búsqueda
El indexer recibe los eventos ya procesados y los almacena de forma indexada para permitir búsquedas rápidas. Es la capa que hace posible responder preguntas como "¿qué ocurrió en este servidor entre las 14:00 y las 15:00?" o "¿este hash de archivo apareció antes en otro equipo?".
En arquitecturas distribuidas, el indexer puede desplegarse en varios nodos para escalar horizontalmente. Esto es relevante cuando el volumen de eventos crece: la capacidad de retención y consulta depende directamente de cómo esté dimensionado este componente.
Dashboard: visualización y operación
El dashboard es la interfaz que consume la información del indexer. Permite visualizar alertas, construir paneles personalizados, explorar eventos y generar reportes. Es la capa que usan los equipos de seguridad y operaciones para tomar decisiones.
El dashboard no tiene lógica de correlación propia: consulta al indexer y presenta los resultados. Esto significa que si el indexer está mal configurado o el volumen de datos es excesivo, la experiencia en el dashboard se degrada aunque el componente en sí funcione.
El flujo completo
Un evento típico recorre este camino:
- El agente detecta un cambio en un archivo crítico o recibe un log de autenticación fallida.
- Envía el evento al manager mediante comunicación cifrada.
- El manager aplica reglas, correlaciona con otros eventos y determina si genera una alerta.
- El evento y la alerta se envían al indexer para almacenamiento.
- El dashboard consulta el indexer y muestra la alerta al operador.
Cada salto en esta cadena es una dependencia. Si el agente no envía, el manager no procesa. Si el manager no procesa, el indexer no almacena. Si el indexer no almacena, el dashboard no muestra nada.
Puntos de fallo, dependencias y señales que conviene observar
Operar Wazuh no es solo instalarlo. Hay puntos específicos donde la arquitectura suele fallar y que conviene monitorear de forma proactiva:
Pérdida de conectividad agente-manager. Si un agente pierde comunicación con el manager, los eventos de ese servidor quedan fuera del análisis. La señal temprana es la ausencia de eventos recientes de un agente en el dashboard, no una alerta explícita. Conviene revisar periódicamente el estado de los agentes activos y configurar notificaciones cuando un agente deje de reportar.
Saturación del manager. Cuando el volumen de eventos supera la capacidad de procesamiento del manager, se generan colas y los eventos se procesan con retraso. Esto se manifiesta como alertas que llegan tarde o correlaciones incompletas. Monitorear el uso de CPU, memoria y el tamaño de las colas internas del manager es esencial.
Crecimiento descontrolado del indexer. El almacenamiento indexado crece rápido si no hay políticas de retención claras. Un indexer sin espacio disponible deja de aceptar eventos nuevos, lo que rompe silenciosamente la cadena: el dashboard sigue funcionando, pero con datos desactualizados. Definir políticas de retención y monitorear el uso de disco es crítico.
Configuración inconsistente entre agentes. Si los agentes tienen versiones o configuraciones distintas, los eventos llegan con formatos diferentes y las reglas de correlación pueden no aplicar correctamente. La señal es una alta tasa de eventos "sin clasificar" o alertas que no tienen contexto.
Dependencia del reloj y la sincronización. La correlación de eventos depende de timestamps confiables. Si los servidores no están sincronizados con NTP, los eventos pueden ordenarse mal y las correlaciones temporales pierden sentido.
Criterios para evaluar esta arquitectura dentro de Wazuh como Servicio
Entender la arquitectura es el primer paso para decidir cómo operarla. La pregunta práctica es si tu equipo tiene la capacidad de mantener cada capa funcionando de forma consistente: actualizar agentes, ajustar reglas, dimensionar el indexer, monitorear colas y responder ante fallos de conectividad.
Para muchas organizaciones, la operación de Wazuh compite con otras prioridades de infraestructura y seguridad. Evaluar un modelo de Wazuh como Servicio implica revisar cómo se gestionan las dependencias críticas que describimos antes: quién monitorea la salud de los agentes, quién ajusta la capacidad del indexer cuando el volumen crece y quién responde cuando un componente deja de reportar.
No se trata de externalizar por externalizar, sino de reconocer que la arquitectura de Wazuh exige mantenimiento continuo. Un despliegue bien diseñado puede degradarse en semanas si no se supervisan las señales correctas.
Preguntas frecuentes sobre la arquitectura de Wazuh
¿Es obligatorio usar los cuatro componentes?
En una implementación estándar, sí. El agente recolecta, el manager procesa, el indexer almacena y el dashboard visualiza. Pueden existir variantes, pero esa es la arquitectura de referencia.
¿Puede el manager funcionar sin indexer?
Técnicamente puede procesar eventos, pero sin indexer no hay almacenamiento consultable ni dashboard funcional. El valor operativo se pierde.
¿Qué pasa si un agente se desconecta temporalmente?
Depende de la configuración. En algunos casos los eventos se almacenan localmente y se reenvían al reconectar; en otros se pierden. Es una decisión de diseño que conviene tomar explícitamente.
¿El dashboard reemplaza al manager para tomar decisiones?
No. El dashboard es una interfaz de consulta. La lógica de correlación y las políticas viven en el manager.
La arquitectura de Wazuh es sólida cuando se entiende como un sistema con dependencias claras. El camino del evento —del agente al dashboard— define qué tan útil será la plataforma para tu operación. Si cada capa está dimensionada y monitoreada, la visibilidad de seguridad deja de ser un problema y se convierte en una capacidad real.
Conversemos sobre cómo evaluar Wazuh como Servicio en tu operación.
