Log-Weiterleitung

NomOS sendet die Audit-Ereignisse deines Mandanten an ein SIEM wie Splunk, oder ein SIEM holt sie selbst ab. Einrichten können das nur Plattform-Admins.

Was weitergeleitet wird

Jedes Ereignis ist ein governter Lauf oder ein Resource-Lesezugriff, nur mit Metadaten: event_id, record_source, class, kind, occurred_at, tenant, room, actor, agent, outcome, Governance-Akte (Verb, Gegenstandstyp, Gegenstandskennung), die gelesene Resource-URI, run_id, ob das Beleg-Bundle signiert ist, und ein Link auf das Bundle in NomOS. Fragen, Antworten, Begründungen, Entscheid-Titel und Dokumenttexte verlassen die Plattform nie.

Push an Splunk

Lege in Splunk ein HTTP-Event-Collector-Token an und wähle einen Index. Lege in NomOS ein Ziel mit HEC-URL und Token an, sende das Testereignis und aktiviere es. Etwa jede Minute sendet der Shipper neue Ereignisse mit dem Source Type ainomos:audit. Der Cursor rückt erst vor, wenn Splunk einen Block angenommen hat; die Zustellung erfolgt also mindestens einmal: Doppelte entfernst du in einer Suche mit dedup event_id. Der Status zeigt die letzte Zustellung, den letzten Fehler und den Rückstand: gelb ab 15 Minuten, rot ab 60.

Pull über die API

Lege auf der Seite Log-Weiterleitung einen Reader-Client an; sein Secret wird einmal angezeigt. Das SIEM holt ein Token mit dem Client-Credentials-Grant und ruft GET /api/platform/audit-events mit limit, class und format auf, danach gibt es next_cursor als cursor zurück. Der erste Aufruf kann mit since ältere Historie überspringen. Jede Seite mit Ereignissen schreibt einen eigenen Audit-Eintrag. Ein widerrufener Reader ist sofort gesperrt.

Formate

Das Format wählst du pro Ziel und beim Abruf. Standard ist das NomOS-JSON mit den Feldern oben. OCSF bildet jedes Ereignis auf OCSF 1.9.0, Klasse API Activity (6003), ab; Felder ohne OCSF-Gegenstück landen unter unmapped. Ein Ziel kann ausserdem nur ausgewählte Ereignisklassen senden und statt ab jetzt ab einem früheren Datum beginnen.

Sicherheit

Ziele müssen HTTPS mit einem Zertifikat verwenden, dem NomOS vertraut: einem öffentlich gültigen, einem von einer Firmen-CA oder einem, das ein Admin gepinnt hat. Eine Firmen-CA kann der Betrieb für die ganze Installation hinterlegen oder ein Plattform-Admin für ein einzelnes Ziel; sie ergänzt die öffentlichen Zertifizierungsstellen, und der Hostname wird weiterhin geprüft. Pinning vertraut genau einem Zertifikat für ein Ziel, nachdem der Admin seinen SHA-256-Fingerabdruck verglichen hat; es passt für ein Splunk mit selbst signiertem oder Standard-Zertifikat. Beides ist nie ein Weg, die Prüfung abzuschalten. Adressen in privaten Netzen werden abgelehnt, und Weiterleitungen werden nicht befolgt. Das HEC-Token wird verschlüsselt gespeichert und nur mit den letzten vier Zeichen angezeigt. Jede Änderung an einem Ziel, Reader, einer CA oder einem gepinnten Zertifikat braucht eine Begründung und wird als Beleg festgehalten.

Eigenes Kubernetes

Bei einer selbst betriebenen Installation läuft die Log-Weiterleitung im Chart und braucht keinen Cloud-Dienst. Stammt das Zertifikat deines Splunk von einer Firmen-CA, hinterlegt der Betrieb diese CA als Secret (logShipping.caBundleSecret); die Zertifikatsprüfung bleibt eingeschaltet. Ein Splunk an einer privaten Adresse ist nur erlaubt, wenn der Betrieb seinen Hostnamen in logShipping.allowedPrivateHosts einträgt. Ziel-Tokens brauchen ein Keyring-Secret (logShipping.keyringSecret); bleibt es leer, nutzt das Chart den Keyring der E-Mail-Zugangsdaten. Das funktioniert unabhängig davon, ob E-Mail über SMTP oder eine API läuft. Sperrt der Cluster ausgehenden Verkehr standardmässig, gib HTTPS von brain-core und log-shipper zum Splunk-Port frei.

Grenzen

Weitergeleitet werden nur Audit-Ereignisse, keine technischen Logs von Anwendung, Gateway oder Anmeldung. Die Indexer-Bestätigung von Splunk wird nicht genutzt: HTTP 200 gilt als angenommen. Neue Ereignisse kommen mit ein bis zwei Minuten Verzögerung an.