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 |
user_id |
wer hat es gemacht (NULL bei System-Aktionen) |
action |
host.create, alert_rule.update, dashboard.delete, … |
target_kind |
host, alert_rule, dashboard, … |
target_id |
UUID der betroffenen Resource |
old_values |
JSONB mit Werten vor der Änderung |
new_values |
JSONB mit Werten nach der Änderung |
created_at |
Zeit |
ip |
IP des Users |
old_values und new_values werden via track_change befüllt — eine kleine Helper-Funktion, die SQLAlchemy-Models in Dicts konvertiert und sensible Felder maskiert.
Instrumentierte Routen¶
Folgende Routes schreiben Audit-Einträge:
- Hosts (Create, Update, Delete)
- Host-Services (Create, Update, Delete, ACK, Downtime-Set)
- Tenants
- Alert-Rules
- Notification-Channels
- Dashboards
- Monitoring-Scripts
- Profile + Profile-Checks
- Users + Roles
Login / Logout / Failed-Login werden ebenfalls geloggt, mit action = auth.login_success / auth.login_failed.
Redacted Felder¶
AUDIT_FIELD_BLACKLIST (in api/app/audit.py):
password_hashtwo_fa_secrettoken_hashkey_hashsnmp_communityssh_passwordprivate_key
Diese Felder erscheinen im Audit-Log als "***" — auch wenn sie sich geändert haben, nicht als Klartext.
Diff-Ansicht¶
/audit-log → klappbare Zeilen mit Diff-Highlight:
- alert_rule_threshold_warn: 80
+ alert_rule_threshold_warn: 50
- alert_rule_channels: ["ops-email"]
+ alert_rule_channels: ["ops-email", "ops-push"]
Rot/grün gefärbt, alte/neue Werte gegenübergestellt.
Filter¶
| Filter | Beispiel |
|---|---|
| Action | nur delete-Aktionen |
| Target-Kind | nur host |
| Target-ID | nur Änderungen an einem bestimmten Host |
| User | wer war es |
| Zeitraum | letzte 24 h, last 30 d, custom |
Filter werden in URL persistiert: /audit-log?action=delete&target_kind=host.
Audit auf der Host-Detail-Seite¶
Pro Host: Audit-Tab zeigt nur die Einträge mit target_id = <hostId>. Nützlich um „was ist mit diesem Host passiert?" auf einer Seite zu sehen.
Retention¶
| Tier | Default-Retention |
|---|---|
| Community | 30 Tage |
| Pro | 90 Tage |
| Enterprise | konfigurierbar bis unlimited |
Auto-Purge läuft täglich. Wenn länger gebraucht: Audit-Export (CSV / JSON) regelmäßig in externen Storage.
Export¶
curl -H "Authorization: Bearer <JWT>" \
"https://deine-domain.tld/api/v1/audit-log/export?from=2026-04-01&format=csv" \
> audit-april.csv
Format: CSV oder JSON, mit allen Feldern.
Sicherheit¶
- Audit-Log ist read-only über die UI — keine Edit/Delete-Endpoints
- DB-Side-Constraint:
audit_loghat keineUPDATE-Trigger (außer System-Migrations) - Backups beinhalten den Audit-Log — bei Restore aus altem Backup gehen jüngere Einträge verloren
Permissions¶
| Permission | Wirkung |
|---|---|
audit.view |
Audit-Log einsehen |
audit.export |
CSV/JSON-Export |
audit.purge |
manuell älter-als-X löschen (nur Super-Admin) |
Compliance¶
Wenn ein Auditor fragt „Wer hat den Threshold von Service X am Datum Y geändert?":
/audit-log?target_id=<service-uuid>&action=update- Sortiert nach Datum, einzeln aufklappen
- Diff zeigt alte und neue Werte
- Author und IP sichtbar
Reicht für die meisten ISO-27001-Audits.
Anschluss¶
- Soft-Delete & Papierkorb — was passiert bei Delete
- PDF-Reports — Audit als formaler Bericht