Tilslut dit SIEM til Uniqkeys auditlog-feed

Uniqkey kan streame din organisations sikkerhedshændelser til dit SIEM (Microsoft Sentinel, Splunk, Elastic, Wazuh eller ethvert værktøj, der kan forespørge et REST API). Denne artikel forklarer, hvordan du aktiverer integrationen i Admin Portal, hvordan events-API'et fungerer, og hvad du kan forvente af dataene.

Hvem kan bruge dette

• Integrationen aktiveres pr. organisation af en organisationsadministrator i Admin Portal.
• Dit SIEM skal have udgående HTTPS-adgang til Uniqkeys events-endpoint.
• Events er de samme auditlogposter, som du allerede kan se under Audit logs i Admin Portal. Intet, der ikke er synligt dér, eksporteres, og vault-hemmeligheder, adgangskoder eller nøgler inkluderes aldrig.

Trin 1: Aktivér integrationen og generér et token

1. Log ind på Admin Portal som administrator.
2. Gå til Integrations og åbn fanen SIEM.
3. Kopiér det API endpoint der vises øverst i widgetten. Dette er den URL, som dit SIEM vil forespørge.
4. Slå SIEM til, eller klik på Generate Token. En dialogboks viser dit nye token.
5. Kopiér tokenet, og gem det i dit SIEMs secret store. Tokenet vises kun én gang. Når du lukker dialogboksen, kan det ikke vises igen.

Administration af tokenet efterfølgende:

• Regenerate Token udsteder et nyt token og ugyldiggør straks det gamle. Opdatér dit SIEM før eller umiddelbart efter regenereringen, ellers stopper polling.
• Hvis du slår SIEM fra, slettes tokenet, og integrationen deaktiveres. Dit SIEM vil modtage 403 Forbidden until a new token is generated.
• Der er ét token pr. organisation. Hvis flere værktøjer skal bruge feedet, deler de tokenet.
• Generering eller sletning af et token registreres også i auditloggen.

Trin 2: Konfigurér dit SIEM

Alle SIEM-connectors har brug for de samme tre ting:

Polling hvert 5. minut er et godt udgangspunkt. Events bliver tilgængelige cirka 2 minutter efter, de sker (se "Hvad du kan forvente af dataene" nedenfor), så der er ingen fordel ved at polle oftere end hvert 2. minut.

Hurtig test med curl

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

En fungerende opsætning returnerer HTTP 200 med en JSON-body som den i afsnittet "Svar". 401 betyder, at Authorization-headeren mangler eller ikke er et Bearer-token. 403 betyder, at tokenet er ukendt, er blevet regenereret, eller at integrationen er deaktiveret.

API-reference

Anmodning

GET /api/v1/events

En anmodning uden parametre er gyldig og returnerer din organisations historik fra begyndelsen, én side ad gangen.

Cursoren er opaque. Du må ikke konstruere, parse eller ændre den. Formatet kan ændres uden varsel, men en cursor, du har modtaget, vil fortsat fungere.

Svar

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

• Events returneres med de ældste først.
• has_more fortæller, om du straks skal anmode om næste side. Loop på has_more, ikke på et tomt events-array: En side kan være tom, selvom der stadig er flere data.
• cursor er altid til stede, også på tomme sider og når has_more er false. Gem den som dit checkpoint efter hvert svar.

Fejl returnerer HTTP 400 med en maskinlæsbar kode:

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

Newline-delimited JSON

Hvis din collector foretrækker én event pr. linje (Splunk generic REST inputs, Elastic, log shippers), skal du sende Accept: application/x-ndjson. Body'en indeholder derefter én JSON-event pr. linje uden envelope, og pagineringsfelterne flyttes til response headers:

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

Headerne giver de samme garantier som JSON-body'en: Cursoren er altid til stede, også på en tom side.

Event-format

{
  "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" }
}

Kategorier

Da hver event har en kategori, kan du pege flere connectors mod det samme endpoint med forskellige category-filtre, for eksempel for at sende credential_access til et billigere storage tier og beholde resten i dit analytics tier.

Hvad du kan forvente af dataene

• Levering sker mindst én gang. Under visse forhold kan en event leveres to gange. Deduplikér på id.
• Events vises cirka 2 minutter efter, de sker. Feedet tilbageholder bevidst de nyeste 2 minutter, så ingen events springes over, mens skrivninger stadig færdiggøres. Derfor bør dit SIEM ikke polle oftere end hvert 2. minut.
• Historikken er begrænset af opbevaringsperioden for din auditlog. Feedet leverer det, som din organisation opbevarer. Kontrollér Data Cleanup & Retention under organisationens indstillinger. Hvis din collector er nede længere end opbevaringsperioden, kan udløbne events ikke gendannes. Hold collectoren kørende kontinuerligt.
• outcome er ikke et signal om mislykket login. Uniqkey registrerer i øjeblikket ikke mislykkede loginforsøg, så hver authentication-event er en vellykket event. failure bruges kun til handlinger, hvis formål er at registrere en afvisning, for eksempel en godkendelsesanmodning, der afvises i mobilappen. Byg ikke brute-force-detektioner på dette feed.
• client.ip er ikke altid til stede. Events, der skrives af baggrundsprocesser, SCIM eller visse klientflows, indeholder ingen IP. Værdien tages fra den modtagne anmodning og bør betragtes som rapporteret af klienten frem for verificeret af infrastrukturen.
• Følsomme data inkluderes aldrig. Adgangskoder, sikre noter, kortnumre, nøgler og andet krypteret vault-indhold forlader aldrig zero-knowledge-grænsen. Feedet indeholder kun de metadata, der er synlige i auditloggen i Admin Portal.

Bemærkninger pr. SIEM

Uniqkey leverer endnu ikke færdigbyggede connector-pakker. Endpointet følger de samme konventioner som andre leverandører af identitets- og password manager-løsninger, så standardmekanismen til REST-polling i hvert SIEM fungerer.

• Microsoft Sentinel: brug en Codeless Connector eller en Logic App med API key authentication (Authorization-header, præfiks Bearer ). Konfigurér paginering på cursor-responsefeltet, som sendes tilbage som cursor-queryparameteren, og brug has_more som loop-betingelse. API'et accepterer start og cursor sammen, hvilket er den måde, Codeless Connector Framework sender sin anden side på.
• Splunk: et REST modular input eller Add-on Builder input fungerer. Send Accept: application/x-ndjson så hver event indekseres som sin egen post, og læs X-Next-Cursor og X-Has-More til checkpointing.
• Elastic: Elastic Agent eller Filebeat HTTP JSON / CEL input kan polle endpointet, gemme cursor som sin cursor-state og loope på has_more. NDJSON-tilstand understøttes også.
• Wazuh: Wazuh har ingen indbygget REST-poller. Kør et lille planlagt script, der poller endpointet, gemmer cursor i en state-fil og skriver events som JSON-linjer til en logfil, som en Wazuh-agent overvåger med log_format: json.

Fejlfinding

Når du kontakter support, skal du inkludere din organisations-id, den præcise request-URL uden tokenet, HTTP-statussen og response body'en.