Logging estructurado y SIEM
El logging estructurado centraliza los eventos compatibles de Opfield y de los daemons con campos buscables y una política de retención. Dimensiona el almacenamiento para la ingesta y la retención, supervisa el estado de ClickHouse y planifica las actualizaciones del motor antes de que las imágenes antiguas dejen de tener soporte.
El logging estructurado da a las aplicaciones un único almacén de logs con búsqueda, con campos, esquemas, retención y acceso por entorno, en lugar de archivos de texto repartidos por los servidores. La exportación a SIEM envía un flujo de auditoría reducido al colector externo de tu equipo de seguridad. Ambos cumplen funciones distintas: los logs sirven para el diagnóstico operativo, y el SIEM transporta eventos de auditoría con la privacidad reducida para el análisis de seguridad. Ninguno es una copia de seguridad del otro.
El responsable de la plataforma proporciona la capacidad de ClickHouse y los límites de retención, los responsables de los servicios definen los campos útiles y la clasificación de los datos, y el responsable de seguridad aprueba los destinos SIEM y su autenticación. El éxito significa que un evento conocido se puede ingerir, encontrar, conservar durante el periodo previsto y correlacionar sin secretos y, cuando sea necesario, entregar una vez y de forma segura al colector externo.
Los destinos SIEM entregan eventos centrados en la auditoría a través de una outbox duradera. Desactivar SIEM pausa las nuevas entregas sin eliminar la configuración de los destinos ni los registros históricos finalizados. Prueba las firmas, los reintentos, la idempotencia y la capacidad del receptor.
Los logs y los payloads de SIEM no deben contener contraseñas, tokens, claves privadas, URI de conexión a bases de datos, prompts, salidas de modelos ni credenciales de vinculaciones en bruto. Usa ID de petición e identificadores de recursos estables para la correlación.
Decisiones antes de incorporar datos
Sección titulada «Decisiones antes de incorporar datos»Define qué servicios pueden escribir, qué campos se permiten, cuánto tiempo se conservan los datos, quién puede buscarlos y qué eventos requieren exportación externa. Calcula el volumen a partir de los eventos por segundo, el tamaño medio de los eventos y la retención en lugar de elegir un TTL arbitrario. Un periodo de retención más largo aumenta el historial disponible para los incidentes, pero también el coste de almacenamiento y el impacto de recopilar datos sensibles.
Elige un modo de esquema de forma deliberada:
| Modo | Úsalo cuando | Contrapartida |
|---|---|---|
reject |
La calidad de los campos debe garantizarse en la ingesta | Los productores deben gestionar correctamente los eventos rechazados |
strip |
Importan los campos conocidos y los datos personalizados desconocidos deben descartarse | Se elimina el contexto de diagnóstico inesperado |
loose |
Los equipos necesitan campos personalizados saneados y flexibles | La gobernanza y la coherencia de las búsquedas requieren más disciplina |
Crea un entorno de logging por aplicación o por límite de confianza significativo. No uses un único token de ingesta compartido entre equipos sin relación; los tokens son secretos de solo escritura y deben poder revocarse de forma independiente.
Flujo de trabajo del logging estructurado
Sección titulada «Flujo de trabajo del logging estructurado»- Activa la función y verifica el estado de ClickHouse.
- Crea un entorno de logging para una aplicación o un límite de confianza.
- Asocia un esquema cuando se requiera validación de campos, o usa el modo loose de forma deliberada.
- Fija la retención y los presupuestos de peticiones y eventos adecuados al tráfico esperado.
- Crea un token de ingesta de solo escritura y guárdalo en el gestor de secretos de la aplicación.
- Envía un evento sintético con campos y un ID de petición conocidos.
- Busca el evento y verifica la marca de tiempo, la severidad, las etiquetas y el estado de retención.
Los límites de peticiones y de eventos son independientes. La ingesta por lotes puede aceptar los eventos válidos y rechazar los miembros no válidos, por lo que los clientes deben inspeccionar la respuesta estructurada en lugar de suponer que todo el lote se ha aceptado.
El SDK oficial de TypeScript puede agrupar, reintentar, vaciar y transportar contexto de trazas o de peticiones para servicios Node.js. Sea cual sea el cliente, define una alternativa para cuando Opfield no esté disponible temporalmente y limita el búfer local para que un fallo del logging no agote la memoria o el disco de la aplicación.
Retención y capacidad
Sección titulada «Retención y capacidad»El TTL por entorno es solo un límite. Las tareas de mantenimiento de Opfield también aplican presupuestos globales de filas y de disco aproximado. Supervisa la disponibilidad de ClickHouse, la presión de las fusiones, el crecimiento del disco, la ingesta rechazada y la antigüedad del evento más reciente. Planifica la retención a partir de los requisitos de incidentes y de cumplimiento en lugar de dejarla ilimitada.
Desactivar el logging estructurado oculta las superficies normales del producto y rechaza la nueva ingesta, pero conserva los datos almacenados y la configuración. Vuelve a activarlo solo cuando entiendas la condición subyacente de estado o de derechos del plan.
Que la capacidad esté bien no es simplemente que el proceso de ClickHouse esté en buen estado. Confirma que la marca de tiempo del evento más reciente avanza, que las búsquedas devuelven los datos recientes esperados, que la retención elimina las particiones antiguas y que se entienden los rechazos de ingesta. Opfield puede pausar la ingesta cuando se agota la capacidad configurada mientras la búsqueda existente sigue disponible; configura una alerta antes de llegar a ese límite.
Entrega a SIEM
Sección titulada «Entrega a SIEM»Configura cada colector HTTPS con el método de autenticación compatible más restrictivo. Valida la confianza en el certificado, la firma de las peticiones, la idempotencia del receptor, el tamaño de lote aceptado, el comportamiento de reintentos y el historial de entregas duradero. La outbox registra el progreso de las entregas para que una caída temporal del colector no obligue a los operadores a recrear eventos a mano.
Si SIEM está desactivado, se conservan la configuración de los destinos y los registros históricos finalizados. Cuando termina el periodo de gracia de una licencia, el reenvío a SIEM se pausa: se conservan la configuración, el historial de entregas y los registros ya en cola, pero los eventos de auditoría que se producen mientras el reenvío está pausado no se ponen en cola; el reenvío se reanuda al renovar sin necesidad de reconfigurar. La ingesta de logs estructurados sigue funcionando tras el periodo de gracia. Consulta Bajada de plan y caducidad. Confirma el último evento aceptado por el receptor y la antigüedad de la cola de Opfield antes de reanudar la operación normal.
Detalles para operadores: contrato de entrega a SIEM
Sección titulada «Detalles para operadores: contrato de entrega a SIEM»Los destinos SIEM deben usar HTTPS y pueden autenticarse con un token bearer, HMAC-SHA256 o una cabecera personalizada validada. Las peticiones HMAC incluyen una marca de tiempo y una firma sobre el cuerpo JSON en bruto exacto; los receptores deben comparar las firmas en tiempo constante y rechazar las marcas de tiempo antiguas. No pongas credenciales en la URL, la cadena de consulta, los logs ni los tickets de prueba.
Opfield entrega a través de una outbox duradera y reintenta los errores de red transitorios, los tiempos de espera agotados, los límites de peticiones y los fallos del servidor. Otros errores del cliente pueden convertirse en fallos definitivos. Usa Send test event para validar un destino; la prueba sintética no crea un evento de auditoría ni una entrega en cola. Eliminar un destino descarta las filas pendientes, mientras que desactivarlo pausa la entrega para reanudarla más tarde.
Reglas de tratamiento de datos
Sección titulada «Reglas de tratamiento de datos»Define una lista de campos permitidos que las aplicaciones pueden enviar. Oculta los datos en el origen, porque la retención y la exportación posteriores multiplican el impacto de un secreto filtrado. Usa ID de recursos, ID de petición, ID de trazas y categorías de error acotadas en lugar de credenciales en bruto, prompts, volcados del entorno o cuerpos de petición arbitrarios.
Si un secreto llega al logging, detén las emisiones posteriores, revoca o rota el secreto en su origen, restringe el acceso al entorno afectado y sigue el proceso de eliminación de datos y de incidentes de la organización. Eliminar un resultado de búsqueda de la vista no demuestra que se hayan saneado todas las particiones conservadas, las exportaciones ni las copias externas en el SIEM.