Audit-Log¶
Jede schreibende Operation (Create, Update, Delete) auf relevanten Tabellen landet im audit_log. Mit Diff zwischen alt und neu, mit Author, mit Zeitstempel.
Was ist drin¶
| Feld | Bedeutung |
|---|---|
id |
UUID des Eintrags |
tenant_id |
Tenant-Scope (NULL bei tenantübergreifenden Aktionen) |
actor_id / actor_email |
wer hat es gemacht |
action |
z. B. host_create, dashboard_update, dashboard_soft_delete, auth.login_success |
target_type |
z. B. host, dashboard |
target_id |
UUID der betroffenen Ressource |
detail |
JSONB mit Zusatzinfos (z. B. geänderte Feldnamen) |
old_values / new_values |
JSONB mit Werten vor/nach der Änderung |
admin_action_category |
automatisch aus der Aktion abgeleitete Kategorie für die Quick-Filter |
created_at |
Zeit |
Ein eigenes IP-Adressfeld gibt es nicht — bei Anmeldungen (auch Fehlversuchen) steht die Absender-IP aber in den Details. Jeder Eintrag mit Inhalt lässt sich aufklappen und zeigt die Details vollständig, dazu den Vorher/Nachher-Vergleich. Protokolliert werden ab v1.9.437 auch Änderungen an den SMTP-Einstellungen (Passwort nur als „geändert: ja/nein"), Lizenzwechsel (nur die ersten sechs Zeichen des Schlüssels) und erzeugte Offline-Bundles für Agent/Collector.
Redigierte Felder¶
Folgende Felder erscheinen im Audit-Log immer als [REDACTED], auch wenn sie sich geändert haben — nie als Klartext:
password_hashtwo_fa_secrettwo_fa_email_code_hash/two_fa_email_codetoken_hashkey_hashsnmp_communityfield_encryption_key
Diff-Ansicht¶
/audit → klappbare Zeilen mit Diff-Highlight zwischen old_values und new_values, rot/grün gefärbt.
Filter¶
| Filter | Beispiel |
|---|---|
| Aktion | z. B. nur dashboard_soft_delete |
| Ziel-Typ | nur host |
| Ziel-ID | nur Änderungen an einer bestimmten Ressource |
| Suche | Teilstring über Akteur, Aktion und Detail-Inhalte |
| Kategorie | Quick-Filter-Kategorie |
| Zeitraum | created_from / created_to |
| Geringfügige Aktionen | standardmäßig ausgeblendet (Präferenz-Updates, gespeicherte Filter, Token-Refresh) — per Schalter einblendbar |
Quick-Filter¶
Drei vorgefertigte Abfragen sparen das manuelle Zusammensetzen: Login-Versuche, Destruktive Aktionen (Delete/Purge/Restore/Import der letzten Tage) und Modus-Wechsel.
Sichtbarkeits-Stufen¶
Drei Permissions steuern, wie viel ein User sieht:
| Permission | Wirkung |
|---|---|
audit_log.view_own |
nur eigene Aktionen |
audit_log.view_tenant |
alle Aktionen im eigenen Tenant-Scope |
audit_log.view_global |
alle Aktionen, tenantübergreifend (Super-Admin automatisch) |
Im User-Portal (nicht im Admin-Bereich) ist die Sicht unabhängig von der Permission-Stufe immer auf „eigene Aktionen" begrenzt — auch für Super-Admins.
Audit auf der Host-Detail-Seite¶
Der Reiter Verlauf & Analyse einer Host-Detail-Seite enthält einen Abschnitt „Änderungsverlauf" — dieselbe Audit-Ansicht, aber fest auf target_type=host und die ID dieses Hosts gefiltert.
Retention¶
Automatische Bereinigung löscht Audit-Einträge, die älter als 730 Tage (2 Jahre) sind, im täglichen Hintergrundlauf. Es gibt keine nach Lizenzstufe gestaffelte Aufbewahrungsdauer.
Sicherheit¶
- Audit-Log ist read-only über die UI — keine Edit-Endpunkte
- Es gibt aktuell keinen CSV/JSON-Export-Endpunkt und keinen manuellen Purge-Endpunkt für das Audit-Log — Bereinigung läuft ausschließlich automatisch über die 730-Tage-Regel
Compliance¶
Wenn ein Auditor fragt „Wer hat Dashboard X am Datum Y geändert?":
/audit?target_type=dashboard&target_id=<uuid>- Sortiert nach Datum, einzeln aufklappen
- Diff zeigt alte und neue Werte
- Autor (E-Mail) sichtbar
Anschluss¶
- Soft-Delete & Papierkorb — was beim Delete passiert
- PDF-Reports — für formale Berichte (Audit ist davon unabhängig)