Audit-Trail & System-Log
Zwei getrennte Protokolle: was fachlich geändert wurde – und was technisch passiert ist.
SimpleAct führt zwei Protokolle, die oft verwechselt werden. Der Audit-Trail beantwortet die Frage „wer hat wann welchen Datensatz wie geändert" und ist Beweismittel. Das System-Log beantwortet „was ist im Betrieb passiert" und ist Diagnosewerkzeug. Der Unterschied ist nicht kosmetisch: Nur der Audit-Trail ist gegen nachträgliche Veränderung geschützt.
Auf einen Blick
- Enthalten ab
- Alle Pläne
- Wo in der App
- Administration → Audit-Log bzw. System-Log
- Ergebnis
- Änderungshistorie mit Integritätsnachweis, System-Log-Export für SIEM
- API
- /api/v1/admin/audit-logs · /api/v1/admin/system-logs
Warum der Audit-Trail eine Hash-Kette ist
Ein Änderungsprotokoll ist als Nachweis nur so viel wert wie die Antwort auf die Frage: „Woher wissen wir, dass daran nachträglich nichts geändert wurde?" Deshalb trägt jeder Audit-Eintrag einen Hash über seinen eigenen Inhalt und zusätzlich den Hash seines Vorgängers. Jeder Eintrag versiegelt damit die gesamte Kette vor ihm.
Wird ein Eintrag nachträglich verändert oder entfernt, passt sein Hash nicht mehr zu dem, was der nächste Eintrag erwartet – die Kette bricht an einer nachweisbaren Stelle. Diese Prüfung können Sie selbst auslösen: für die Historie eines einzelnen Datensatzes oder in einem Durchlauf für alle Ketten Ihrer Organisation. Das Ergebnis ist die Aussage, die in einer Prüfung zählt: unverändert oder nicht, und wenn nicht, ab wo.
Was ein Audit-Eintrag enthält
| Feld | Bedeutung |
|---|---|
| Akteur | Wer die Änderung ausgelöst hat – mit Rolle. Bei einem API-Zugriff wird der API-Key als Akteur geführt, mit Name und Kennung des Keys; die Benutzer-ID bleibt dabei leer. |
| Quelle der Aktion | Ob die Änderung aus der Oberfläche, aus der API oder aus einem Systemprozess kam. Ein API-Key wird immer als „api" geführt – das lässt sich nicht per Header überschreiben. |
| Aktion und Ereignistyp | Was gemacht wurde – anlegen, ändern, löschen, exportieren, freigeben. |
| Entität und Datensatz-ID | Woran es passiert ist. Darüber läuft auch die Kettenprüfung für einen einzelnen Datensatz. |
| Alter und neuer Wert | Der Zustand vor und nach der Änderung – bei Bedarf feldgenau. Das ist der Unterschied zwischen „wurde geändert" und „wurde so geändert". |
| Status und Fehlermeldung | Auch fehlgeschlagene Versuche werden protokolliert. Ein Protokoll, das nur Erfolge kennt, verschweigt genau die interessanten Fälle. |
| IP-Adresse, User-Agent, Sprache | Der technische Kontext des Zugriffs. |
| Hash und Vorgänger-Hash | Die Verkettung, die die Integritätsprüfung möglich macht. |
System-Log
Das System-Log ist die Betriebssicht. Es lässt sich filtern und exportieren – typischerweise, um es in ein SIEM zu übernehmen.
| Merkmal | Werte |
|---|---|
| Stufen | ERROR, WARNING, INFO, DEBUG, TRACE |
| Quellen | API, UI, SYSTEM, DATABASE, AUTH, MIDDLEWARE |
| Filter | Stufe, Quelle, Benutzer, Zeitraum und weitere Kriterien. Ein unbekannter Filterwert wird abgelehnt statt stillschweigend ignoriert. |
| Export | JSON oder CSV, bis zu 10.000 Einträge, neueste zuerst. Die Antwort ist immer JSON: Bei CSV steht der Text im Datenfeld – kein Datei-Download. |
| Zusätzliche Felder | Anfrage-ID, Endpunkt, HTTP-Methode, Statuscode und Antwortzeit – genug, um einen Fehlerbericht ohne Rückfrage zu bearbeiten. |
API-Schreibzugriffe tragen keinen Personennamen
Datensätze, die per API-Key geändert wurden, führen als Ersteller bzw. Bearbeiter eine feste technische Kennung – nicht die Person, die den Key angelegt hat. Das ist Absicht: Ein Key ist keine Person, und eine maschinelle Änderung unter einem Personennamen zu führen, würde den Audit-Trail etwas behaupten lassen, was nicht stattgefunden hat. Welcher Key es war, steht im Audit-Trail.
Zeitstempel sind UTC
Alle Zeitstempel werden in UTC geführt und im ISO-8601-Format mit abschließendem Z ausgeliefert. Wenn Sie Protokolle mit anderen Systemen abgleichen, rechnen Sie beim Import um – nicht beim Export.