Ereignisse aus Security posture an dein SIEM senden

Diese Seite führt dich von einem Compliance Access Key bis zu Aktivitäten aus Security posture, die nach Zeitplan als Ereignisse in deinem System für Security Information and Event Management (SIEM) ankommen. Die Übersicht nennt, welche Organisationen diese Aktivitäten haben. Du brauchst einen Compliance Access Key, der die Organisation abdeckt, mit dem Scope read:compliance_activities oder read:org_audit.

Die Aktivitäten anfordern

Um nur diese Aktivitäten zu lesen, filtere den Feed mit activity_types[]. In dieser Anfrage legt created_at.gte den frühesten zu lesenden created_at fest, und order=asc gibt die ältesten Aktivitäten zuerst zurück:

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"

Die API-ReferenzVorschau mit Links zur API-Referenz verfügbar – drücke Tab, bis der Fokus in die Karte wechselt, und Escape, um zurückzukehren. beschreibt jeden Parameter.

Eine Aktivität lesen

Jedes Element des Arrays data in der Antwort ist eine Aktivität wie diese.

{
  "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 benennt die Sicherheitskontrolle, eine empfohlene Einstellung oder Vorgehensweise.
• action gibt an, was mit der Bestätigung der Kontrolle geschehen ist, der festgehaltenen Aussage einer Person über die Kontrolle. Hier bedeutet attested, dass eine Bestätigung für eine Kontrolle erfasst wurde, die noch keine hatte.
• status ist der Wert der Bestätigung. Hier ist es Akzeptiertes Risiko (accepted_risk): Die Kontrolle ist nicht eingerichtet, und die Organisation akzeptiert das Risiko.
• actor identifiziert hier die Person, die bestätigt hat, anhand von Benutzer-ID und E-Mail-Adresse.
• created_at ist hier der Zeitpunkt, zu dem sie bestätigt hat.

Die Referenz zu Ereignissen aus Security posture listet weitere Felder und Werte auf.

Wenn die Antwort leer ist

Ein leeres Array data ist gültig. Der Feed enthält nur Änderungen, die vorgenommen wurden, seit er begonnen hat, diese Aktivitäten für die Organisation aufzuzeichnen. Er bleibt leer, bis eine Bestätigung abgegeben oder geändert wird.

Prüfe, ob die Organisation diese Aktivitäten hat. Lass dann jemanden eine Kontrolle bestätigen. Wiederhole die Anfrage nach einer Weile.

Nach Zeitplan ausführen

Jede dieser Aktivitäten kann später abfragbar werden als nach der üblichen Indexierungsverzögerung des Activity Feed von 1 Minute, mit einem created_at, das bereits in der Vergangenheit liegt. Eine Integration, die sich nur vorwärts bewegt, ausgehend von einem Cursor oder einem fortschreitenden created_at.gte, sieht eine solche Aktivität daher nie. Lies bei jedem Durchlauf einen festen Rückblickzeitraum von 4 Stunden erneut ein, und verwirf die Aktivitäten, die du bereits gespeichert hast:

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

• Häufig ausführen: Führe die Schleife so oft aus, wie deine Alarme es erfordern, zum Beispiel alle 5 Minuten.
• Für den gesamten Durchlauf dieselbe Abfrage beibehalten: Berechne created_at.gte zu Beginn jedes Durchlaufs, in UTC und URL-kodiert. Sende auf jeder Seite dieselben Filter und dieselbe order. Mit order=asc gibt die Übergabe von last_id als after_id die nächste Seite jüngerer Aktivitäten zurück. Ergebnisse paginieren erklärt after_id und last_id.
• Anhand von id deduplizieren: Dieser Schritt ist erforderlich, weil sich aufeinanderfolgende Durchläufe überschneiden.
• Fehlgeschlagene Durchläufe behandeln: Wenn eine Anfrage nach den Wiederholungsversuchen aus Compliance-API-Fehler behandeln fehlschlägt, beende den Durchlauf. Der nächste Durchlauf liest sein gesamtes Zeitfenster erneut. Wenn Durchläufe länger als 4 Stunden fehlschlagen oder ausbleiben, liest das nächste tägliche erneute Einlesen die Aktivitäten, die sie verpasst haben.

Einmal täglich 15 Tage erneut einlesen

Führe einmal am Tag dieselbe Schleife mit einem Rückblickzeitraum von 15 Tagen statt 4 Stunden aus. Dieses tägliche erneute Einlesen liest auch eine Aktivität, die bis zu 14 Tage nach ihrem created_at abfragbar wird.

• Halte die Startzeit jedes täglichen erneuten Einlesens fest, das abgeschlossen wird.
• Entferne eine gespeicherte id nur, wenn du sie mehr als 16 Tage vor dem letzten festgehaltenen Start gespeichert hast.
• Wenn kein Start festgehalten ist, setze created_at.gte so weit zurück, wie du es brauchst; der Feed bewahrt Aktivitäten 6 Jahre lang auf.
• Wenn seit dem letzten festgehaltenen Start mehr als ein Tag vergangen ist, führe das nächste tägliche erneute Einlesen mit created_at.gte auf 15 Tage vor diesem Start gesetzt aus.

Wenn du bereits den gesamten Feed einliest

Eine Integration, die den gesamten Activity Feed liest, ohne einen Filter activity_types[], der diese Aktivitäten ausschließt, erhält sie bereits. Prüfe zwei Dinge:

• Unbekannte Werte: Dein Handler gibt irgendeinen type oder Feldwert, den er nicht erkennt, unverändert weiter. Siehe Das Activity-Objekt verstehen.
• Verspätete Aktivitäten: Eine Integration, die nur nach jüngeren Aktivitäten fragt, verpasst eine, die erst verspätet abfragbar wird. Ergänze die Integration um das erneute Einlesen über 4 Stunden und das tägliche erneute Einlesen über 15 Tage.

Prüfen, ob es funktioniert

Nachdem jemand eine Kontrolle bestätigt hat, führe die Schleife aus, bis sie die neue Aktivität speichert. Führe sie dann erneut aus: Sie speichert diese Aktivität kein zweites Mal.

Nächste Schritte

Um Alarme an dem Zeitpunkt auszurichten, zu dem du eine Aktivität gespeichert hast, und nicht an ihrem created_at, siehe Änderungen in Security posture erkennen. Für das Open Cybersecurity Schema Framework (OCSF) siehe Ereignisse aus Security posture auf OCSF abbilden. Für aktuelle Ergebnisse siehe Referenz zu Ergebnissen aus Security posture.