Reenvío a SIEM / XDR
Para qué sirve esta pantalla
Reenvío a SIEM / XDR es donde declaras las herramientas de seguridad que reciben los eventos de auditoría de la plataforma. Es una de las tres tarjetas de Observabilidad y Auditoría que no contienen ningún valor de configuración: administra destinos, y cada uno es un registro con nombre, formato de salida, transporte, filtros, credencial y un estado activo o inactivo.
La entrega la realiza un servicio interno aparte. Consume el flujo unificado de eventos de auditoría de la plataforma en su propio grupo de consumidores, así que el reenvío nunca compite con el consumidor del registro de auditoría y un destino que falla no puede frenarlo. Ese servicio es solo interno y no publica ningún puerto de host.
Existen dos planos, en una sola lista. Un destino de despliegue lo heredan todos los tenants. Un destino de tenant pertenece a un tenant y se suma a lo que hereda. Un tenant no puede retirar un destino de despliegue heredado: todo destino de despliegue recibe los eventos de todos los tenants, y el conjunto efectivo de un tenant es los destinos de despliegue más los suyos.
La pestaña Por tenant se comporta de forma distinta a sus hermanas. Desde el plano de plataforma aquí no hay listado de tenants ni selector: un destino propio de un tenant se alcanza desde el propio contexto operativo de ese tenant, y la pestaña lo dice en lugar de mostrarte un plano vacío.
Qué debe existir antes
Es una pantalla de plataforma: se alcanza en el contexto de plataforma y solo se sirve al tenant de plataforma. Los permisos son propios de este subsistema, y tener la lectura de la configuración de plataforma no los incluye:
- El permiso de lectura de destinos de reenvío, que lista el plano de despliegue.
- El permiso de gestión de destinos de reenvío, para crear, editar, activar, desactivar o eliminar uno en el plano de despliegue.
- Para un destino propio de un tenant, los permisos de lectura y de anulación del plano de tenant. Son permisos distintos, no los mismos aplicados a un tenant.
Decisiones que tomas aquí
Declarar un destino
Añadir destino empieza por una tarjeta de transporte, y el transporte fija después la forma del formulario. Se ofrecen cuatro: Syslog, Splunk HEC, Microsoft Sentinel y un webhook firmado según Standard Webhooks. De forma independiente, el formato de salida es CEF u OCSF — el formato decide qué aspecto tiene el registro, el transporte decide cómo viaja, y se eligen por separado.
Un nombre es único dentro de su plano, así que un tenant puede reutilizar el nombre de un destino de despliegue. Cada transporte HTTP pide un endpoint; Syslog pide un host, un puerto y una elección de transporte entre UDP, TCP o TLS sobre TCP.
Credenciales, y el transporte que no tiene
Tres transportes llevan una credencial de solo escritura: un token HEC, un secreto de cliente de Sentinel o un secreto de firma del webhook de al menos 32 caracteres. La plataforma la sella y devuelve una máscara en cada lectura, así que la consola nunca tiene una copia.
Después de guardar un secreto de webhook, la consola muestra una sola vez su forma whsec_, la que usa la biblioteca Standard Webhooks de tu receptor; cópiala en ese momento. Dejar el campo vacío al editar significa sin cambios; escribir un valor real la rota. La credencial de un destino de despliegue se sella bajo la clave del despliegue y la de un tenant bajo la clave de ese tenant.
Syslog solo lleva credencial para TLS mutuo. Con TLS sobre TCP, a un colector que exige un certificado de cliente se le presenta uno: pega la cadena del certificado, la hoja primero, y su clave privada en PEM sin cifrar. La clave es la única credencial del destino: se sella, no se vuelve a mostrar y solo se reemplaza pegando otra; en su lugar la pantalla muestra la huella de su clave pública.
Un certificado renovado para la misma clave se guarda sin la clave, mientras que cambiar el host, el puerto o las anclas de confianza exige volver a introducirla, y la pantalla lo indica antes de guardar. Guardar el destino con UDP o TCP sin cifrar elimina el certificado y su clave.
Todos los transportes, Syslog incluido, pueden llevar además material de confianza: hasta cinco autoridades de certificación en formato PEM, que son material público, se almacenan y se devuelven sin enmascarar, y no llevan contraseña; si se deja vacío, el destino conserva la confianza por omisión.
Filtrado, y cuál es realmente el valor por omisión
Todo destino reenvía todos los eventos por omisión, en los cuatro planos, incluidos el plano de autenticación y los eventos que llevan datos personales. Los filtros son un mecanismo de exclusión y nada más, así que dejarlos vacíos es una decisión y no un olvido.
Se combinan cuatro filtros. Una severidad mínima descarta lo que quede por debajo del umbral. Una lista de tipos admitidos, cuando no está vacía, admite solo los tipos que coinciden. Una lista de tipos excluidos descarta los que coinciden. Una lista de identificadores de clave admitidos, cuando no está vacía, admite solo los eventos que referencian una de esas claves — incluido un intento denegado contra una clave vigilada. Un evento filtrado para un destino sigue llegando a todos los demás destinos que lo admitan.
Una operación fallida o rechazada se califica al menos como Media, sea cual sea su tipo de evento, así que un umbral Medio sigue entregando cada rechazo y descarta los éxitos rutinarios.
La coincidencia de tipos acepta un tipo completo, un nombre de plano o un prefijo. Cada elemento se prueba como coincidencia exacta y después como prefijo con punto, hayas escrito o no un comodín final, así que auth.login y auth.login.* se comportan igual aquí.
Cuándo llega un cambio al reenviador
El reenviador nunca lee la tabla de destinos. Guardar uno vuelve a proyectar la lista efectiva resuelta en una entrada de caché firmada y permanente, y la anuncia en un canal al que el reenviador está suscrito, que es lo que hace que un cambio surta efecto sin reiniciar nada. Una escritura de despliegue vuelve a proyectar el conjunto de despliegue y solo los tenants realmente afectados; una escritura de tenant vuelve a proyectar ese tenant solo.
Qué ocurre cuando un destino es inalcanzable
No se descarta nada, y ese es el contrato. Un fallo reintentable se reintenta hasta cuatro intentos en total, con una espera que empieza en medio segundo y se duplica hasta un techo de treinta segundos. Cuando se agotan los intentos — o el fallo es permanente — el evento y el destino se escriben en un tema de mensajes fallidos con un envío bloqueante y confirmado, y un evento de auditoría firmado registra el fallo de entrega, de modo que el propio registro lleva la evidencia.
Si ni siquiera esa escritura puede confirmarse, o el destino está saturado de trabajo, el evento no se confirma y se vuelve a entregar más tarde en lugar de perderse. Se preserva el orden y la posición nunca rebasa un destino que no se haya tratado de forma duradera.
Leer con precisión las vistas de Estado y de Fallidos
La vista Estado lista cada destino de despliegue y su estado configurado, activo o desactivado. No es telemetría de entrega en vivo: aquí todavía no se miden la latencia ni la tasa de error, y la propia vista lo indica. La vista Fallidos explica el comportamiento de la cola de mensajes fallidos y no muestra una profundidad en vivo. Ninguna de las dos es prueba de que la entrega esté funcionando ahora mismo — para eso, consulta el registro de auditoría.
En esta superficie no hay acción de prueba.
Cómo se relaciona con otras pantallas
Esta superficie vive dentro del grupo Observabilidad y Auditoría, junto a los otros dos subsistemas que administran registros en lugar de valores:
Los eventos que se reenvían aquí son los mismos que consultan las pantallas de auditoría, y su destino se dibuja en el mapa de integraciones.