Claude Platform Docs
AdministrationSecurity posture

Envoyer les événements de Security posture vers votre SIEM

Demandez les activités de Security posture au flux d’activité de la Compliance API, lisez-en une champ par champ et maintenez votre SIEM à jour grâce à une lecture planifiée qui rattrape les activités tardives.

Cette page vous guide depuis une Compliance Access Key jusqu’à l’arrivée planifiée des activités de Security posture sous forme d’événements dans votre système « security information and event management » (gestion des informations et des événements de sécurité), ou SIEM. La page Aperçu indique quelles organisations disposent de ces activités. Vous avez besoin d’une Compliance Access Key qui couvre l’organisation, avec la portée read:compliance_activities ou read:org_audit.

Demander les activités

Pour ne lire que ces activités, filtrez le flux avec activity_types[]. Dans cette requête, created_at.gte définit le created_at le plus ancien à lire, et order=asc renvoie les activités les plus anciennes en premier :

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"

La référence de l’APIAperçu disponible avec des liens vers la référence de l’API, appuyez sur Tab jusqu’à ce que le focus entre dans la carte, et sur Échap pour revenir. décrit chaque paramètre.

Lire une activité

Chaque élément du tableau data de la réponse est une activité comme celle-ci.

{
  "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 nomme le contrôle de sécurité, un paramètre ou une pratique recommandé(e).
  • action indique ce qui est arrivé à l’attestation du contrôle, la déclaration enregistrée d’une personne au sujet du contrôle. Ici, attested signifie qu’une attestation a été enregistrée pour un contrôle qui n’en avait aucune.
  • status est la valeur de l’attestation. Ici, il s’agit de Risque accepté (accepted_risk) : le contrôle n’est pas en place, et l’organisation accepte le risque.
  • actor identifie ici la personne qui a effectué l’attestation, par identifiant d’utilisateur et adresse e-mail.
  • created_at indique ici le moment où cette personne a effectué l’attestation.

La Référence des événements de Security posture répertorie davantage de champs et de valeurs.

Si la réponse est vide

Un tableau data vide est valide. Le flux ne contient que les changements effectués depuis qu’il a commencé à enregistrer ces activités pour l’organisation. Il reste vide tant qu’aucune attestation n’a été effectuée ou modifiée.

Vérifiez que l’organisation dispose de ces activités. Demandez ensuite à quelqu’un d’effectuer une attestation pour un contrôle. Après un certain temps, répétez la requête.

L’exécuter de façon planifiée

N’importe laquelle de ces activités peut devenir interrogeable plus tard que le délai d’indexation habituel d’une minute du flux d’activité, avec un created_at déjà passé. Ainsi, une intégration qui ne fait qu’avancer, à partir d’un curseur ou d’un created_at.gte qui progresse, ne voit jamais une telle activité. Relisez une fenêtre rétrospective fixe de 4 heures à chaque exécution, et écartez les activités que vous avez déjà stockées :

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
  • Exécuter souvent : Exécutez la boucle aussi souvent que vos alertes l’exigent, par exemple toutes les 5 minutes.
  • Conservez la même requête pendant toute l’exécution : Calculez created_at.gte, en UTC et encodé pour l’URL, au début de chaque exécution. Envoyez les mêmes filtres et le même order sur chaque page. Avec order=asc, transmettre last_id comme after_id renvoie la page suivante d’activités plus récentes. Paginer les résultats explique after_id et last_id.
  • Dédupliquer par id : Cette étape est obligatoire, car les exécutions consécutives se chevauchent.
  • Gérer les exécutions en échec : Si une requête échoue après les nouvelles tentatives décrites dans Gérer les erreurs de la Compliance API, mettez fin à l’exécution. L’exécution suivante relit l’intégralité de sa fenêtre. Si les exécutions échouent ou s’interrompent pendant plus de 4 heures, la relecture quotidienne suivante lit les activités qu’elles ont manquées.

Relire 15 jours une fois par jour

Une fois par jour, exécutez la même boucle avec une fenêtre rétrospective de 15 jours au lieu de 4 heures. Cette relecture quotidienne lit également une activité qui devient interrogeable jusqu’à 14 jours après son created_at.

  • Enregistrez l’heure de début de chaque relecture quotidienne qui se termine.
  • Ne supprimez un id stocké que si vous l’avez stocké plus de 16 jours avant le dernier début enregistré.
  • Si aucun début n’est enregistré, définissez created_at.gte aussi loin dans le passé que nécessaire ; le flux conserve les activités pendant 6 ans.
  • S’il s’est écoulé plus d’un jour depuis le dernier début enregistré, exécutez la relecture quotidienne suivante avec created_at.gte défini à 15 jours avant ce début.

Si vous ingérez déjà le flux complet

Une intégration qui lit l’intégralité du flux d’activité, sans filtre activity_types[] qui exclut ces activités, les reçoit déjà. Vérifiez deux points :

Vérifier que cela fonctionne

Après qu’une personne a attesté un contrôle, exécutez la boucle jusqu’à ce qu’elle stocke la nouvelle activité. Exécutez-la ensuite de nouveau : elle ne stocke pas cette activité une deuxième fois.

Étapes suivantes

Pour déclencher une alerte sur l’heure à laquelle vous avez stocké une activité, et non sur son created_at, consultez Détecter les changements dans Security posture. Pour le « Open Cybersecurity Schema Framework » (cadre ouvert de schéma de cybersécurité), ou OCSF, consultez Mapper les événements de Security posture vers OCSF. Pour les résultats actuels, consultez Référence des résultats de Security posture.

Cette page vous a-t-elle été utile ?