Okta System Log exportieren (API, CSV, SIEM)

TL;DR. Für eine Untersuchung holen Sie die gesamte Organisation über die vollen 90 Tage Aufbewahrung mit GET /api/v1/logs, einem begrenzten Fenster since/until und limit=1000, und folgen dem Header Link: rel="next", bis er verschwindet. Paginieren Sie nie, indem Sie since selbst verschieben. Nutzen Sie den CSV-Export der Admin Console nur für einen schnellen Blick und SIEM- oder Log-Streaming-Daten, wenn Sie mehr als 90 Tage brauchen. Behalten Sie das rohe JSON: Alle anderen Formate verlieren Felder.

Beim Export gehen die meisten Okta-Untersuchungen unbemerkt schief. Nicht weil er schwierig wäre, sondern weil die naheliegende Abkürzung (nach dem verdächtigen Benutzer suchen, auf Herunterladen klicken) eine Datei erzeugt, die vollständig aussieht und es nicht ist. Dieser Artikel ist die ausführliche Fassung der Checkliste auf der Startseite des Tools.

Was Sie exportieren

Das Okta System Log ist ein Strom von LogEvent-Objekten. Jedes hat einen eventType, einen actor, ein target-Array, client (IP, User-Agent, Geolokalisierung), securityContext (ASN, AS-Organisation, ISP, Proxy-Kennzeichen), authenticationContext (mit der Sitzungskennung), outcome, debugContext.debugData und eine eindeutige uuid. Das Schema ist in der Referenz der System-Log-API dokumentiert.

Zwei Eigenschaften der Daten bestimmen alles Weitere:

Die Aufbewahrung beträgt 90 Tage. Okta gibt an, dass ältere Daten nicht zurückgegeben werden (System-Log-Abfrageleitfaden). Kann der Vorfall älter sein, bleibt nur, was vorher gestreamt oder gesammelt wurde.
Korrelationen brauchen die Ereignisse anderer. Ein Zurücksetzen durch den Helpdesk wird mit dem Helpdesk-Mitarbeiter als Akteur und Ihrem Opfer als Ziel protokolliert. Eine Rollenvergabe mit dem Angreifer als Akteur und dem neuen Admin als Ziel. Filtern Sie auf einen Benutzer, verlieren Sie die halbe Geschichte.

Option 1: die System-Log-API (empfohlen)

Sie liefert das Original-JSON, alle Felder und ein reproduzierbares Verfahren.

Zugangsdaten

Nutzen Sie einen Lesezugang: ein API-Token, das ein Read-only-Administrator erstellt hat, oder eine OAuth-2.0-Service-App mit dem Scope okta.logs.read. Ein Okta-API-Token trägt die Rechte des Admins, der es erstellt hat (Okta Help Center: API-Tokens), also erstellen Sie es für diese Aufgabe nicht als Super Administrator und widerrufen Sie es nach dem Export. Stellen Sie während eines aktiven Vorfalls außerdem sicher, dass das verwendete Konto keines ist, das der Angreifer kontrollieren könnte.

Begrenzte Abfragen und Paginierung

Der Abfrageleitfaden unterscheidet zwei Arten von Abfragen:

	Begrenzte Abfrage	Polling-Abfrage
Parameter	`since` und `until` gesetzt	kein `until`, `sortOrder=ASCENDING`
Zweck	festen Zeitraum exportieren	neuen Ereignissen laufend folgen
Ende	letzte Seite hat keinen `next`-Link	liefert immer einen `next`-Link
Reihenfolge	nach `published`	kann ungeordnet sein

Für die Forensik brauchen Sie eine begrenzte Abfrage. Der Leitfaden ist in zwei wichtigen Punkten eindeutig: Folgen Sie den next-Links, statt manuell mit since und until zu paginieren (das kann Ereignisse überspringen oder doppeln), und manche Ereignisse eines jüngeren Zeitraums können verspätet eintreffen. Exportieren Sie bis „jetzt minus ein paar Minuten“ und holen Sie die letzten Stunden bei einem laufenden Vorfall später erneut.

Eine minimale Shell-Schleife:

url="https://${OKTA_DOMAIN}/api/v1/logs?since=2026-06-15T00:00:00Z&until=2026-09-13T00:00:00Z&limit=1000"
n=0
while [ -n "$url" ]; do
  n=$((n+1))
  curl -sS -D headers.txt \
    -H "Authorization: SSWS ${OKTA_API_TOKEN}" \
    -H "Accept: application/json" \
    "$url" > "okta-system-log-$(printf %04d $n).json"
  url=$(tr -d '\r' < headers.txt | grep -i '^link:.*rel="next"' \
        | sed -E 's/^[Ll]ink: <([^>]+)>.*/\1/')
  sleep 1   # deutlich unter dem Rate Limit bleiben
done
gzip okta-system-log-*.json

Jede Seite ist ein JSON-Array. Zusammenführen ist unnötig: Der Analyzer nimmt viele Dateien auf einmal an, ebenso Arrays, die hintereinander in einer Datei stehen. Ereignisse werden per uuid dedupliziert, überlappende Seiten oder ein erneuter Lauf schaden also nicht.

limit erlaubt bis zu 1.000 Ereignisse pro Seite. Abfragen unterliegen Rate Limits und einem Timeout von 30 Sekunden pro Abfrage; eine sehr aktive Organisation über 90 Tage bedeutet viele Seiten, lassen Sie es laufen.

Serverseitig filtern: nur zur Triage

Die API unterstützt einen filter-Ausdruck wie eventType eq "user.mfa.factor.reset_all" und einen Stichwortparameter q (Abfrageleitfaden). Beides hilft, eine schnelle Frage zu beantworten. Für den Beweisexport lassen Sie beides weg.

Option 2: CSV aus der Admin Console

In der Admin Console unter Reports › System Log den Zeitraum setzen, die Suche leer lassen und Download CSV verwenden (Okta Help Center: System Log). Das braucht kein Token und ist für kurze Zeiträume schnell.

Der Preis ist die Genauigkeit: Eine CSV flacht verschachtelte Objekte ab, und die genaue Spaltenliste des Konsolen-Downloads konnte ich in der öffentlichen Dokumentation nicht verifizieren. Der Analyzer liest CSV-Dateien, deren Kopfzeilen LogEvent-Pfade sind (actor.alternateId, client.ipAddress, target[0].displayName, securityContext.asNumber usw.), oder eine _raw-Spalte mit dem Original-JSON. Liefert eine Konsolen-CSV weniger Befunde als erwartet, exportieren Sie erneut über die API, bevor Sie Schlüsse ziehen.

Option 3: Log Streaming (EventBridge, Splunk Cloud)

Okta kann System-Log-Ereignisse nahezu in Echtzeit an Amazon EventBridge oder Splunk Cloud streamen; ein Super Admin richtet das unter Reports › Log Streaming ein (Okta Help Center: Log Streaming). Ein Stream leitet nur künftige Ereignisse weiter: Er ist eine Aufbewahrungsstrategie, kein Werkzeug zur Wiederherstellung.

Wenn bereits ein Stream existiert, exportieren Sie den Zeitraum aus dessen Ziel:

EventBridge-Archive (S3, CloudWatch Logs) enthalten jedes LogEvent im Feld detail des EventBridge-Umschlags. JSON oder JSON Lines, mit oder ohne gzip, können unverändert abgelegt werden.
Splunk: Suchen Sie den Okta-Sourcetype und exportieren Sie die Ergebnisse als JSON oder CSV. Das Feld _raw enthält das Original-Ereignis und wird verwendet, wenn vorhanden; result-Umschläge werden entpackt.

Option 4: andere SIEMs

Die Regel ist überall dieselbe: Exportieren Sie die Rohereignisse mit den originalen Feldnamen.

Elastic: Dokumente werden automatisch aus _source entpackt.
Generisches JSON Lines mit einem LogEvent pro Zeile funktioniert direkt, ebenso Zeilen mit Syslog-Präfix, die mit dem JSON-Ereignis enden.
Microsoft Sentinel: Die klassische benutzerdefinierte Tabelle Okta_CL flacht Felder in Spalten mit Suffix wie actor_alternateId_s ab; der Analyzer bildet diese noch nicht ab. Wenn das Original-JSON verfügbar ist, exportieren Sie lieber das.

Checkliste vor der Analyse

Bevor Sie den Export an irgendjemanden oder an den Analyzer übergeben:

Der Zeitraum reicht mindestens mehrere Tage vor das erste verdächtige Ereignis zurück (Baselines brauchen Historie).
Es wurde kein Filter und keine Suche angewendet.
Erster und letzter published-Zeitstempel entsprechen dem angefragten Fenster.
Die Dateien werden unverändert und mit Hashwerten dort aufbewahrt, wo der Angreifer sie nicht erreicht.
Das Token oder die Service-App für den Export ist widerrufen oder deaktiviert.

Der nächste Schritt ist die Analyse des Exports. Wenn Sie noch nicht wissen, wonach Sie suchen, beginnen Sie mit dem Leitfaden zur Untersuchung einer Okta-Kompromittierung.

Weiterführende Links

Okta Developer: System-Log-Abfrageleitfaden (begrenzte und Polling-Abfragen, Filter, Aufbewahrung)
Okta Developer: Referenz der System-Log-API
Okta Help Center: Log Streaming
Okta Help Center: Verwaltung von API-Tokens