Skip to content

Logging der Änderungshistorie von Clients

User Story

Als Nutzer möchte ich die Änderungshistorie von Clients protokollieren, um alle Änderungen transparent nachverfolgen zu können.

Warum

Eine Änderungshistorie von Clients bewirkt eine transparente Nachverfolgung aller Änderungen, was die Rückverfolgbarkeit und Verantwortlichkeiten sicherstellt. Sie hilft bei der Diagnose von Problemen und der Bewertung des Einflusses früherer Änderungen auf aktuelle Herausforderungen.

Links, Hinweise, Bemerkungen

Audit-Log (unveränderbar, manipulationssicher)

  • Zweck: Nachvollziehbarkeit sicherheitsrelevanter und administrativer Aktionen
  • Inhalt:
    • Zeitstempel (UTC, inkl. Millisekunden)
    • Benutzer-ID bzw. Authentifizierungskennung (z. B. Elster-Zertifikat-ID)
    • Aktionstyp (create/update/delete)
    • Betroffener Client (Name, ID)
    • Änderungskontext (z. B. API vs. GUI)
    • Altdaten und Neudaten (diff oder Snapshot)
  • Speicherort: Zentraler, geschützter Audit-Log-Speicher (z. B. Elasticsearch, SIEM-System)
  • Aufbewahrung: mind. 1 Jahr, abhängig von Datenschutz und Sicherheitsanforderungen
  1. Systemlog (technische Verarbeitung)
  • Zweck: Unterstützung bei Support, Debugging, Performance-Monitoring
  • Inhalt: - Technische Ausführung (z. B. „PUT /clients/{id}“) - Response-Code - ggf. Fehlerdetails oder Validierungswarnungen
  • Ort: im Applikationslog (z. B. über Logback, Winston oder Fluentd)
  1. Change-Log im UI/SSP
  • Zweck: Sichtbarkeit für Nutzer:innen direkt im Frontend
  • Inhalt: Änderungszeitpunkt und Wer hat was geändert (z. B. „Zustellpunkte hinzugefügt“)
  • Technik: Abfrage über ein Audit-Log-API-Endpoint oder eigene History-Tabelle

Akzeptanzkriterien

  • Alle Änderungen an den Clients werden protokolliert
  • Die Protokolle können nicht bearbeitet oder manuell gelöscht werden
  • Alle CRUD-Operationen an Clients werden zentral protokolliert
  • Logs sind unveränderbar und nicht durch Nutzer editierbar
  • Einsicht über UI oder dedizierten API-Endpunkt möglich
  • Logeinträge enthalten Autor, Zeitstempel und Datendifferenzen
  • Logging ist dokumentiert (z. B. in der Betriebsdokumentation)
  • Unveränderbarkeit: Logs müssen schreibgeschützt und revisionssicher gespeichert werden.
  • Zugriffsrechte: Nur lesender Zugriff für berechtigte Personen/Prozesse (z. B. Betreiber, Support).
  • Protokollierungspflichtig: Alle Änderungen, auch über interne APIs oder automatische Jobs.
  • Schnittstelle für Prüfung/Export: Möglichkeit zur Einsicht durch Admins bzw. Audit-Verantwortliche.
  • Datensparsamkeit beachten: Keine sensiblen Nutzdaten (z. B. Antragsinhalte), nur Metadaten.

Durchführungsplan (von dem Entwickler auszufüllen)

Edited by Laura Elges