Categoría: Seguridad
Centralización de logs con Graylog u OpenSearch: registros consultables y conservados
Los registros de servidores, aplicaciones, cortafuegos y nubes en un único sitio, con campos normalizados, búsquedas rápidas y una retención que podéis justificar ante una auditoría.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Graylog Open: SSPL. OpenSearch: Apache 2.0
En resumen
Centralizar logs es llevar los registros de todos vuestros sistemas a un único sitio donde se pueden buscar, conservar y vigilar. Lo montamos con Graylog, que añade flujos, reglas de procesado y alertas sobre OpenSearch, o con OpenSearch y sus paneles directamente. Nos encargamos de la recogida, la normalización, la retención, las copias, la monitorización de la ingesta y las actualizaciones, en vuestra cuenta.
¿Qué nos encargamos de mantener?
Tener los registros repartidos por cada servidor funciona hasta el día en que hay que reconstruir qué pasó: el servidor ya rotó sus archivos, el de la nube guardaba siete días o el atacante borró lo que le delataba. Un sistema central evita eso, siempre que alguien lo mantenga:
Recogida
Agentes y entradas syslog cifradas desde servidores, contenedores, red y nube.
Normalización
Reglas que extraen los mismos campos de fuentes distintas para buscar de una vez.
Almacenamiento
Índices de OpenSearch dimensionados, con rotación y retención por tipo de registro.
Ingesta vigilada
Alertas cuando una fuente calla, cuando se dispara el volumen o cuando la cola de entrada crece.
Copias y archivo
Snapshots a almacenamiento de objetos y restauración de prueba de índices antiguos.
Accesos
Inicio de sesión único, roles por equipo y registro de las consultas.
¿Qué arquitectura recomendamos?
En Graylog, la pieza que recibe y procesa es el servidor de Graylog, que guarda su configuración en MongoDB, y la que almacena es OpenSearch, que el Data Node de Graylog instala y gestiona por vosotros. Sin Graylog, los agentes envían a OpenSearch y el procesado se hace en ellos o en una capa intermedia. En ambos casos, la ingesta pasa por un punto con cola para no perder registros si el almacenamiento va lento.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Decenas de servidores y un equipo pequeño | Graylog y Data Node en un nodo, con snapshots fuera | Todo en un producto, sencillo de operar |
| Volumen alto o retención larga | Graylog en dos nodos y OpenSearch en tres o más | El almacenamiento es lo que más crece |
| Ya tenéis OpenSearch o un servicio gestionado | Fluent Bit o Vector hacia OpenSearch y sus paneles | Aprovecha lo que hay, sin otra capa |
La operación del clúster de búsqueda en sí, con memoria, shards y actualizaciones, la contamos en Elasticsearch y OpenSearch gestionados.
¿Qué problemas encontramos más a menudo?
- Fuentes que dejaron de enviar hace semanas sin que nadie lo notara.
- Todo en un índice: registros de depuración y de auditoría con la misma retención y los mismos permisos.
- Campos distintos para lo mismo: la IP de origen se llama de cinco maneras y ninguna búsqueda las junta.
- Disco lleno: sin retención, el almacén deja de aceptar registros justo en el peor momento.
- Syslog sin cifrar ni autenticar atravesando redes que no son vuestras.
- Datos personales o secretos en los registros que nadie revisó antes de guardarlos durante meses.
¿Cómo hacemos las copias y las actualizaciones?
La configuración de Graylog vive en MongoDB, que copiamos aparte; las reglas y los flujos también quedan exportados en vuestro repositorio. Los índices se copian con snapshots a un almacenamiento de objetos, y de vez en cuando restauramos uno antiguo en un entorno aparte para comprobar que se puede consultar. Para actualizar, seguimos el orden y las versiones compatibles que publica Graylog entre servidor, MongoDB y OpenSearch, ensayamos antes en pruebas y revisamos que las reglas de procesado siguen produciendo los mismos campos.
¿Para quién tiene sentido?
- Una empresa que prepara una auditoría y necesita demostrar que conserva y protege los registros de acceso y de cambios.
- Un equipo técnico con muchos servidores y servicios que pierde tiempo entrando por SSH en cada máquina para leer registros.
- Quien ya tiene un SIEM y quiere guardar el contexto completo durante más tiempo y a menor coste.
Para la detección de amenazas sobre esos mismos sistemas, mirad Wazuh gestionado. Si lo que necesitáis son registros de aplicación junto a las métricas, encaja mejor la monitorización con Grafana y Prometheus, con Loki.
¿Cómo protegemos los propios registros?
Un sistema de logs guarda justo lo que un atacante querría borrar o leer. Los agentes envían por TLS, el panel no se expone a internet y se entra con inicio de sesión único. Cada equipo ve solo sus flujos o índices, y las consultas quedan registradas. Los snapshots van a un almacenamiento de objetos en otra cuenta, con bloqueo de objetos si el proveedor lo ofrece, para que no se puedan borrar desde la plataforma. Antes de guardar nada, revisamos con vuestro equipo qué campos llevan datos personales o secretos y los filtramos o enmascaramos en la entrada.
- FuentesServidores, red, nube
- AgentesFluent Bit, Vector o syslog TLS
- GraylogEntradas, reglas y flujos
- OpenSearchÍndices con retención
- ArchivoSnapshots en S3
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores cloud o dedicados para Graylog y los nodos de datos, con discos NVMe y snapshots en Object Storage de Hetzner. | Mucho disco por poco coste, que es lo que más pide un sistema de logs. |
| AWS | Graylog en EC2 o Amazon OpenSearch Service como almacén, con lectura de CloudTrail, VPC Flow Logs y CloudWatch Logs. | Si solo hay registros de AWS, a veces basta con CloudWatch Logs bien organizado; lo valoramos antes. |
| Google Cloud | Compute Engine con Graylog u OpenSearch y exportación de Cloud Logging mediante Pub/Sub. | |
| Azure | Máquinas virtuales con Graylog u OpenSearch y lectura de los registros de actividad y de Microsoft Entra ID a través de Event Hubs. | |
| OVH | Instancias de Public Cloud o dedicados con Graylog y OpenSearch, o el OpenSearch gestionado de OVHcloud como almacén. | |
| Servidor propio | Graylog y OpenSearch en vuestros servidores o máquinas virtuales, recibiendo de toda la red interna. | El sistema de logs no debería vivir en la misma máquina que vigila: si la comprometen, se pierde la evidencia. |
Qué incluye
- Graylog con su Data Node, o OpenSearch con OpenSearch Dashboards, en vuestra cuenta y dimensionado para vuestro volumen diario.
- Recogida desde servidores Linux y Windows, contenedores, equipos de red y registros de vuestra nube, con agentes o syslog sobre TLS.
- Normalización de campos (origen, usuario, IP, acción, resultado) para buscar igual en registros de fuentes distintas.
- Flujos o índices separados por tipo de registro, con su retención y sus permisos.
- Retención pactada por escrito: unos meses consultables y más tiempo archivado en almacenamiento de objetos.
- Alertas sobre la propia ingesta: fuentes que dejan de enviar, picos anómalos, disco y colas de entrada.
- Copias de la configuración y snapshots de los índices, con restauración probada.
- Acceso por inicio de sesión único, roles por equipo y registro de quién consulta qué.
Preguntas frecuentes
¿Esto es lo mismo que Wazuh?
No. Wazuh es un SIEM: sus agentes buscan amenazas, revisan configuraciones y vigilan la integridad de archivos. Un sistema de logs centralizado guarda y permite buscar todos los registros, también los que no son de seguridad, como los de aplicación o los de red. Muchas veces conviven: Wazuh detecta y Graylog u OpenSearch conservan el contexto completo.
¿Graylog u OpenSearch con sus paneles?
Graylog aporta lo que hace falta para operar los registros a diario: entradas para casi cualquier formato, reglas de procesado, flujos con permisos y alertas. OpenSearch con OpenSearch Dashboards es más flexible y totalmente Apache 2.0, pero el procesado lo tenéis que resolver antes, en los agentes. Si queréis un producto listo para el equipo, Graylog; si ya trabajáis con OpenSearch, sus paneles.
¿Qué pasa con la licencia de Graylog?
Graylog Open se publica con la licencia SSPL, que no está aprobada por la OSI como código abierto. Para usarlo dentro de vuestra empresa no supone un problema; su restricción afecta a quien ofrece Graylog como servicio a terceros. Algunas funciones, como el archivado integrado, son de las ediciones de pago, y os decimos antes si alguna os haría falta.
¿Cuánto tiempo hay que guardar los logs?
Depende de vuestras obligaciones legales, contractuales y de vuestro sector, y no lo decidimos nosotros. Lo habitual es separar un periodo corto consultable al momento y otro más largo en almacenamiento de objetos, más barato. Lo que pactemos queda escrito y aplicado con políticas de índices, para que el disco no decida por vosotros.
¿No sería más sencillo Loki?
Para registros de aplicación que se consultan junto a las métricas, muchas veces sí. Loki indexa solo etiquetas, ocupa poco y encaja con Grafana. Para búsquedas libres por cualquier campo, informes de auditoría o permisos por tipo de registro, Graylog u OpenSearch responden mejor.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el