Observabilidad
Se transmite cada evento a su SIEM, firmado y verificable.
Los eventos de auditoría y seguridad se envían en tiempo real a Splunk, Datadog, Elastic, Microsoft Sentinel, S3 WORM, syslog estándar o un webhook HTTPS genérico (plan Enterprise). Cada evento lleva la firma Ed25519 de la fila de auditoría y el id de la clave que la produjo; la clave pública de su empresa se publica en /audit/pubkey/:company_id. Los envíos fallidos se reintentan con backoff hasta un día y después pasan a una cola de mensajes fallidos (dead-letter) que puede reproducir.
Caldyr
Splunk
Datadog
Elastic
Sentinel
S3 WORM
Syslog
Cómo funciona
1
Se emite el evento
Una fila de auditoría se firma y se difunde al emisor de SIEM.
2
Bloque de firma adjunto
El sobre es la fila de auditoría más su bloque de firma: sig, key_id, pubkey_fp, prev_hash, payload_hash. Una clave de firma por empresa, no por destino.
3
Enviado a su destino
Seis modos de autenticación por destino - none, bearer, mTLS, signed JWT, Sentinel OAuth2 y Sentinel shared key - y un destino que no indica ninguno se queda en none. mTLS y signed JWT no envían ningún secreto compartido; bearer envía el propio token del destino en cada envío, Sentinel OAuth2 un token de acceso de Azure AD, Sentinel shared key un HMAC calculado con la clave del espacio de trabajo, y Splunk o Datadog siguen enviando su token incluso con mTLS. Los destinos HTTP exigen https:// y syslog por TCP exige TLS, pero syslog por UDP va sin cifrar.
4
Reenvío al reconectar
Los envíos fallidos se reintentan con backoff hasta 24 horas y después pasan a una cola de mensajes fallidos (dead-letter) que puede reproducir.
Análisis a fondo
Sobres firmados
El bloque es una firma Ed25519 sobre la fila de auditoría tal como está almacenada, encadenada a la fila anterior: sig, key_id, pubkey_fp, prev_hash, payload_hash. raw_json, ECS, OCSF y syslog llevan los cinco campos; CEF y LEEF llevan solo la firma y el id de clave. La clave pública de su empresa se publica en /audit/pubkey/:company_id, y no entregamos ningún verificador para su lado: comprobar el bloque es tarea de su SIEM. En un destino con transformaciones de filtro, la firma cubre la fila tal como estaba antes de la transformación.
Garantías de entrega
Al menos una vez con IDs idempotentes. Los lotes fallidos se reintentan con backoff; tras el último reintento, o ante un rechazo permanente, pasan a una cola de mensajes fallidos (dead-letter) que usted reproduce a mano.
Destinos WORM / de cumplimiento
S3 Object Lock en modo gobernanza o cumplimiento para almacenamiento inmutable: los auditores obtienen prueba de retención sin configuración adicional.
Configurar un destino
shell · curl
# 1. store each credential, get back a handle (company admin)
$ curl -X POST $CALDYR_URL/api/siem/secret-bindings \
-H "Authorization: Bearer $CALDYR_TOKEN" -H "Content-Type: application/json" \
-d '{"team_id": "<your-team-uuid>",
"field": "mtls_cert_ref",
"value": '"$(jq -Rs . < client.pem)"'}'
# → 201 {"handle": "<32 hex>", "ref": "vault-ref://h/<32 hex>", …}
# value is a PEM file, JSON-escaped by jq; repeat with field mtls_key_ref (key PEM) and mtls_bearer_ref (Splunk HEC token)
# 2. create the destination, referencing the returned refs
$ curl -X POST $CALDYR_URL/api/siem/destinations \
-H "Authorization: Bearer $CALDYR_TOKEN" -H "Content-Type: application/json" \
-d '{"name": "splunk-prod",
"kind": "splunk_hec",
"url": "https://splunk.example.com:8088",
"format": "ecs",
"batch_size": 100,
"auth_kind": "mtls",
"config": {
"mtls_cert_ref": "vault-ref://h/<cert handle>",
"mtls_key_ref": "vault-ref://h/<key handle>",
"mtls_bearer_ref": "vault-ref://h/<token handle>"}}'
Su SIEM es la fuente de verdad: nosotros solo lo alimentamos, firmado.
Cuando llega la investigación de una vulneración, el auditor usa sus registros firmados, no los nuestros. Nosotros somos el mensajero.
Comparativa
| Caldyr | Webhooks (sin firmar) | Exportación manual de registros | |
|---|---|---|---|
| Entrega en tiempo real | envío · none, bearer, mTLS, JWT o Sentinel | POST sin firmar | solo por lotes |
| Sobres firmados | bloque Ed25519 · clave de empresa | no | no |
| Reenvío al reconectar | búfer duradero | se descarta al fallar | N/D |
| Múltiples destinos | todos a la vez | una sola URL | manual |
| Cumplimiento WORM | S3 Object Lock | no | no |
Preguntas frecuentes
Los envíos fallidos se reintentan con backoff y después pasan a una cola de mensajes fallidos (dead-letter) que puede reproducir. El plano de control sigue funcionando.
Sí. Una configuración habitual es Splunk para el SOC + S3 WORM para cumplimiento + Datadog para ingeniería, todo desde el mismo flujo de eventos con reglas de filtro independientes.
raw_json por defecto; las variantes ECS, CEF, LEEF, syslog y OCSF están disponibles por destino, además de asignaciones de campos personalizadas mediante una transformación YAML.
Las reglas de filtro por destino admiten jsonpath → ocultar. Los campos de PII se pueden eliminar antes de que lleguen a destinos de menor confianza.
¿Listo para gobernar su infraestructura de IA?
Solicite acceso en minutos, o hable con nosotros sobre su despliegue aislado de la red.