Claude Platform Docs
AmministrazioneSecurity posture

Inviare gli eventi di Security posture al tuo SIEM

Richiedi le attività di Security posture dall’Activity Feed della Compliance API, leggine una campo per campo e mantieni aggiornato il tuo SIEM con una lettura pianificata che intercetta le attività in ritardo.

Questa pagina ti guida da una Compliance Access Key fino alle attività di Security posture che arrivano come eventi nel tuo sistema di “security information and event management” (gestione delle informazioni e degli eventi di sicurezza), o SIEM, secondo una pianificazione. La panoramica indica quali organizzazioni dispongono di queste attività. Ti serve una Compliance Access Key che copra l’organizzazione, con lo scope read:compliance_activities o read:org_audit.

Richiedere le attività

Per leggere solo queste attività, filtra il feed con activity_types[]. In questa richiesta, created_at.gte imposta il created_at più vecchio da leggere e order=asc restituisce prima le attività più vecchie:

cURL
curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  -H "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  -H "anthropic-version: 2026-10-21" \
  --data-urlencode "activity_types[]=org_security_control_attestation_updated" \
  --data-urlencode "created_at.gte=2026-10-20T00:00:00Z" \
  --data-urlencode "order=asc" \
  --data-urlencode "limit=5000"

Il riferimento APIAnteprima disponibile con link al riferimento API (premi Tab finché il focus non entra nella scheda, Esc per tornare indietro) descrive ciascun parametro.

Leggere un’attività

Ogni elemento dell’array data della risposta è un’attività come questa.

{
  "id": "activity_01Hq7ZtYc4Vb2NmKx8RsPd3W",
  "type": "org_security_control_attestation_updated",
  "created_at": "2026-10-20T15:04:00.220114Z",
  "organization_id": "org_01JuY4bkwkH1x4PodBJaWmh2",
  "organization_uuid": "91012d09-e48b-438e-a489-1bebfd8fa6f9",
  "actor": {
    "type": "user_actor",
    "email_address": "jane.doe@example.com",
    "user_id": "user_01WxYzAbCdEfGhJkMnPqRsTu",
    "ip_address": "192.0.2.34",
    "user_agent": "Mozilla/5.0..."
  },
  "control": "directory_sync_enabled",
  "action": "attested",
  "status": "accepted_risk"
}
  • control indica il controllo di sicurezza, un’impostazione o pratica consigliata.
  • action indica cosa è successo all’attestazione del controllo, ovvero la dichiarazione registrata da una persona sul controllo. Qui attested significa che ne è stata registrata una per un controllo che non ne aveva.
  • status è il valore dell’attestazione. Qui è Rischio accettato (accepted_risk): il controllo non è in atto e l’organizzazione accetta il rischio.
  • actor qui identifica la persona che ha attestato, tramite ID utente e indirizzo email.
  • created_at qui è il momento in cui ha attestato.

Il Riferimento per gli eventi di Security posture elenca altri campi e valori.

Se la risposta è vuota

Un array data vuoto è valido. Il feed contiene solo le modifiche apportate da quando ha iniziato a registrare queste attività per l’organizzazione. Resta vuoto finché non viene effettuata o modificata un’attestazione.

Verifica che l’organizzazione disponga di queste attività. Poi chiedi a qualcuno di attestare un controllo. Dopo un po’ di tempo, ripeti la richiesta.

Eseguirlo secondo una pianificazione

Qualsiasi di queste attività può diventare interrogabile più tardi rispetto al consueto ritardo di indicizzazione di 1 minuto dell’Activity Feed, con un created_at che è già nel passato. Quindi un’integrazione che procede solo in avanti, da un cursore o da un created_at.gte che avanza, non vede mai un’attività del genere. Rileggi una finestra temporale a ritroso fissa di 4 ore a ogni esecuzione e scarta le attività che hai già archiviato:

query = activity_types[]=org_security_control_attestation_updated
      & created_at.gte={now - 4 hours}
      & order=asc
      & limit=5000
cursor = null
loop:
  if cursor is null:
    page = GET /v1/compliance/activities?{query}
  else:
    page = GET /v1/compliance/activities?{query}&after_id={cursor}
  for activity in page.data:
    if activity.id is not in stored_ids:
      store(activity)
      add activity.id to stored_ids
  if not page.has_more: break
  cursor = page.last_id
  • Esegui spesso: esegui il ciclo con la frequenza richiesta dai tuoi alert, ad esempio ogni 5 minuti.
  • Mantieni la stessa query per l’intera esecuzione: calcola created_at.gte, in UTC e con codifica URL, all’inizio di ogni esecuzione. Invia gli stessi filtri e lo stesso order su ogni pagina. Con order=asc, passare last_id come after_id restituisce la pagina successiva di attività più recenti. Impaginare i risultati spiega after_id e last_id.
  • Deduplica in base a id: questo passaggio è obbligatorio, perché le esecuzioni consecutive si sovrappongono.
  • Gestisci le esecuzioni non riuscite: se una richiesta non riesce dopo i tentativi descritti in Gestire gli errori della Compliance API, termina l’esecuzione. L’esecuzione successiva rilegge di nuovo l’intera finestra. Se le esecuzioni non riescono o si interrompono per più di 4 ore, la successiva rilettura giornaliera legge le attività perse da tali esecuzioni.

Rileggere 15 giorni una volta al giorno

Una volta al giorno, esegui lo stesso ciclo con una finestra temporale a ritroso di 15 giorni al posto di 4 ore. Questa rilettura giornaliera legge anche un’attività che diventa interrogabile fino a 14 giorni dopo il suo created_at.

  • Registra l’ora di inizio di ogni rilettura giornaliera completata.
  • Elimina un id archiviato solo se lo hai archiviato più di 16 giorni prima dell’ultimo inizio registrato.
  • Se non è registrato alcun inizio, imposta created_at.gte tanto indietro quanto ti serve; il feed conserva le attività per 6 anni.
  • Se è trascorso più di un giorno dall’ultimo inizio registrato, esegui la rilettura giornaliera successiva con created_at.gte impostato a 15 giorni prima di quell’inizio.

Se acquisisci già l’intero feed

Un’integrazione che legge l’intero Activity Feed, senza un filtro activity_types[] che escluda queste attività, le riceve già. Verifica due cose:

Verificare che funzioni

Dopo che qualcuno ha attestato un controllo, esegui il ciclo finché non archivia la nuova attività. Poi eseguilo di nuovo: non archivia quell’attività una seconda volta.

Passaggi successivi

Per generare alert in base al momento in cui hai archiviato un’attività, anziché in base al suo created_at, consulta Rilevare le modifiche in Security posture. Per l’“Open Cybersecurity Schema Framework”, o OCSF, consulta Mappare gli eventi di Security posture su OCSF. Per i risultati attuali, consulta Riferimento per i risultati di Security posture.

Questa pagina ti è stata utile?