Conecte su SIEM al feed del registro de auditoría de Uniqkey

Uniqkey puede transmitir los eventos de seguridad de su organización a su SIEM (Microsoft Sentinel, Splunk, Elastic, Wazuh o cualquier herramienta que pueda consultar una API REST). Este artículo explica cómo activar la integración en el Admin Portal, cómo funciona la API de eventos y qué puede esperar de los datos.

Quién puede utilizarlo

• La integración se activa para cada organización por un administrador de la organización en el Admin Portal.
• Su SIEM necesita acceso HTTPS saliente al endpoint de eventos de Uniqkey.
• Los eventos son las mismas entradas del registro de auditoría que ya puede ver en Audit logs en el Admin Portal. No se exporta nada que no sea visible allí y nunca se incluyen secretos del vault, contraseñas ni claves.

Paso 1: Activar la integración y generar un token

1. Inicie sesión en el Admin Portal como administrador.
2. Vaya a Integrations y abra la pestaña SIEM.
3. Copie el API endpoint que aparece en la parte superior del widget. Esta es la URL que consultará su SIEM.
4. Switch the SIEM toggle on, or click Generate Token. A dialog shows your new token.
5. Copie el token and store it in your SIEM's secret store. El token solo se muestra una vez. Después de cerrar el cuadro de diálogo, no podrá volver a mostrarse.

Gestionar el token posteriormente:

• Regenerate Token issues a new token and immediately invalidates the old one. Update your SIEM before or right after regenerating, otherwise polling stops.
• Al desactivar SIEM se elimina el token y se desactiva la integración. Su SIEM recibirá 403 Forbidden until a new token is generated.
• Hay un token por organización. Si varias herramientas necesitan el feed, comparten el mismo token.
• La generación o eliminación de un token también queda registrada en el registro de auditoría.

Paso 2: Configurar su SIEM

Todos los conectores SIEM necesitan las mismas tres cosas:

Una consulta cada 5 minutos es una buena configuración predeterminada. Los eventos están disponibles aproximadamente 2 minutos después de producirse (consulte «Qué esperar de los datos» más abajo), por lo que consultar con una frecuencia superior a cada 2 minutos no aporta ninguna ventaja.

Prueba rápida con curl

curl -s "https://<endpoint>/api/v1/events?limit=5" \
  -H "Authorization: Bearer <your token>"

A working setup returns HTTP 200 with a JSON body like the one in the "Response" section. 401 means the Authorization header is missing or not a Bearer token. 403 means the token is unknown, was regenerated, or the integration is disabled.

Referencia de la API

Solicitud

GET /api/v1/events

Una solicitud sin parámetros es válida y devuelve el historial de su organización desde el principio, página por página.

El cursor es opaco. No lo construya, analice ni modifique. Su formato puede cambiar sin previo aviso, pero un cursor recibido seguirá funcionando.

Respuesta

{
  "events": [ ... ],
  "has_more": true,
  "cursor": "eyJUIjoiMjAyNi0wOS0wMVQwOToxNDoyMi4xMTdaIiwiSSI6Ijlh..."
}

• Los eventos se devuelven empezando por los más antiguos.
• has_more tells you whether to request the next page right away. Loop on has_more, not on an empty events array: a page can be empty while more data remains.
• cursor is always present, including on empty pages and when has_more is false. Store it as your checkpoint after every response.

Los errores devuelven HTTP 400 con un código legible por máquina:

{ "error": { "code": "invalid_cursor", "message": "Cursor is not valid. Submit the cursor from a previous response verbatim." } }

JSON delimitado por líneas

Si su collector prefiere un evento por línea (entradas REST genéricas de Splunk, Elastic, log shippers), envíe Accept: application/x-ndjson. El cuerpo contendrá un evento JSON por línea sin envoltorio y los campos de paginación pasarán a los headers de respuesta:

Content-Type: application/x-ndjson
X-Next-Cursor: eyJUIjoi...
X-Has-More: true

Los headers ofrecen las mismas garantías que el cuerpo JSON: el cursor siempre está presente, incluso en una página vacía.

Formato del evento

{
  "id": "9a1c7f2e-4b13-4a8e-9f21-0c2b7d5e8a44",
  "timestamp": "2026-09-01T09:14:22.117Z",
  "category": "credential_access",
  "action": "get_vault_password_details",
  "action_id": "daf12269-a58f-4e3a-ab01-05b1293a7cac",
  "action_source": "extension",
  "outcome": "success",
  "organization_id": "d5ecd732-4a67-418c-9dea-38a097fba1f6",
  "actor": { "id": "3f2a...", "email": "jane.doe@example.com", "type": "user" },
  "client": { "system": "extension", "ip": "185.23.44.9" },
  "target": { "type": "vault", "id": "7c9d...", "name": "GitHub build account" }
}

Categorías

Como cada evento incluye una categoría, puede dirigir varios conectores al mismo endpoint con diferentes category filtros, por ejemplo para enviar credential_access a un nivel de almacenamiento más económico y mantener el resto en su nivel de análisis.

Qué esperar de los datos

• La entrega se realiza al menos una vez. En determinadas condiciones, un evento puede entregarse dos veces. Elimine duplicados mediante id.
• Los eventos aparecen aproximadamente 2 minutos después de producirse. El feed retiene deliberadamente los 2 minutos más recientes para que no se omita ningún evento mientras aún se completan las escrituras. Por este motivo, su SIEM no debe consultar con una frecuencia superior a cada 2 minutos.
• El historial está limitado por el período de retención del registro de auditoría. El feed proporciona lo que conserva su organización. Consulte Data Cleanup & Retention en la configuración de la organización. Si su collector permanece inactivo durante más tiempo que el período de retención, los eventos caducados no podrán recuperarse. Mantenga el collector en ejecución continua.
• outcome no es una señal de inicio de sesión fallido. Uniqkey no registra actualmente los intentos de inicio de sesión fallidos, por lo que cada evento authentication es correcto. failure solo se utiliza para acciones cuyo propósito es registrar una denegación, por ejemplo una solicitud de aprobación rechazada en la aplicación móvil. No cree detecciones de fuerza bruta basadas en este feed.
• client.ip no siempre está presente. Los eventos generados por procesos en segundo plano, SCIM o algunos flujos de cliente no incluyen IP. El valor se obtiene de la solicitud recibida y debe considerarse como informado por el cliente, no verificado por la infraestructura.
• Nunca se incluyen datos confidenciales. Las contraseñas, notas seguras, números de tarjeta, claves y otros contenidos cifrados del vault nunca salen del límite de conocimiento cero. El feed solo contiene los metadatos visibles en el registro de auditoría del Admin Portal.

Notas por SIEM

Uniqkey todavía no proporciona paquetes de conectores preconfigurados. El endpoint sigue las mismas convenciones que otros proveedores de identidad y gestores de contraseñas, por lo que funciona el mecanismo estándar de consulta REST de cada SIEM.

• Microsoft Sentinel: use a Codeless Connector or a Logic App with API key authentication (Authorization header, prefix Bearer ). Configure paging on the cursor response field, sent back as the cursor query parameter, and use has_more as the loop condition. The API accepts start and cursor together, which is how the Codeless Connector Framework sends its second page.
• Splunk: a REST modular input or an Add-on Builder input works. Send Accept: application/x-ndjson so each event is indexed as its own record, and read X-Next-Cursor and X-Has-More for checkpointing.
• Elastic: the Elastic Agent or Filebeat HTTP JSON / CEL input can poll the endpoint, persist cursor as its cursor state, and loop on has_more. NDJSON mode is also supported.
• Wazuh: Wazuh has no native REST poller. Run a small scheduled script that polls the endpoint, keeps the cursor in a state file, and writes events as JSON lines to a log file that a Wazuh agent monitors with log_format: json.

Solución de problemas

Cuando contacte con soporte, incluya el ID de su organización, la URL exacta de la solicitud sin el token, el estado HTTP y el cuerpo de la respuesta.