Dokumentation

Audit-Log

Revisionsfähige, manipulationssensitive Dokumentation relevanter Ereignisse zur Nachvollziehbarkeit, Integrität und Compliance.

1. Audit-Log System

Das Audit-Log-System ist ein zentraler Bestandteil der digitalen Meldestellen-Plattform und dient der lückenlosen, manipulationssensitiven beziehungsweise manipulationsgeschützten und revisionsfähigen Dokumentation aller system- und fallrelevanten Ereignisse.

Ziel des Systems ist es, technische, organisatorische und rechtliche Anforderungen in einer einheitlichen Architektur zusammenzuführen. Im Vordergrund stehen insbesondere Nachvollziehbarkeit, Integrität, Transparenz, Mandantentrennung und die belastbare Dokumentation sensibler Vorgänge innerhalb eines Hinweisgebersystems.

2. Zielsetzung des Audit-Systems

Nachvollziehbarkeit

Relevante Aktionen werden lückenlos dokumentiert und in einen zeitlichen Kontext gesetzt.

Manipulationsschutz

Die Integrität des Audit-Logs wird kryptografisch abgesichert und regelmäßig geprüft.

Revisionsfähigkeit

Bearbeitungsschritte, Löschprozesse und Sicherheitsereignisse bleiben nachvollziehbar dokumentiert.

Compliance-Unterstützung

Das System unterstützt Anforderungen aus DSGVO, HinSchG sowie ISO-orientierten Kontrollsystemen.

3. Systemübersicht

Das Audit-System dokumentiert sämtliche relevanten Vorgänge innerhalb eines Tenant-Systems und bildet daraus eine forensisch nachvollziehbare Ereigniskette. Es ist so aufgebaut, dass sowohl technische Sicherheitsereignisse als auch fallbezogene Bearbeitungsschritte protokolliert werden.

Zentrales Audit-Log pro Tenant
Strukturierte, maschinenlesbare Event-Daten
Standardisierte Event-Namen
Hash-Chain zur Integritätsprüfung
Append-Only-Prinzip auf Anwendungsebene
Vollständig nachvollziehbare Löschprozesse
Sichtbarer Immutability-Status
Multi-Tenant- und Hosting-Kompatibilität

4. Architektur und Funktionsweise

4.1 Zentrales Audit-Log

Für jeden Tenant existiert ein eigenständiges Audit-Log. Dadurch wird eine konsequente Mandantentrennung umgesetzt. Das Audit-Log speichert sicherheitsrelevante und fallbezogene Ereignisse in strukturierter Form.

4.2 Strukturierte Event-Daten

Jeder Log-Eintrag enthält insbesondere folgende Informationen:

  • Zeitstempel
  • Benutzer oder Systemakteur
  • Aktion, zum Beispiel auth.login_success oder case.created
  • Bereich, zum Beispiel auth, case oder system
  • Payload im JSON-Format mit Detailinformationen

Diese Struktur stellt sicher, dass das Audit-Log sowohl für Menschen lesbar als auch maschinell auswertbar bleibt.

4.3 Zentraler Audit Writer

Alle Audit-Einträge werden über eine zentrale Logging-Komponente geschrieben. Dadurch werden uneinheitliche Log-Mechanismen vermieden und eine konsistente Event-Struktur sichergestellt.

4.4 Standardisierte Event-Namen

Zu den protokollierten Standard-Events gehören unter anderem:

  • auth.login_success
  • auth.login_failed
  • case.created
  • case.updated
  • case.delete_request_created
  • case.delete_request_approved
  • case.deleted
  • audit.integrity_check

5. Tenant-Isolation und Mandantentrennung

Das System ist vollständig mandantenfähig aufgebaut. Jeder Tenant verfügt über ein eigenes Audit-Log. Eine Vermischung von Daten zwischen Kundeninstanzen findet nicht statt.

Dies ist insbesondere relevant für:

  • DSGVO-konforme Trennung von Datenbeständen
  • saubere organisatorische und technische Abgrenzung von Verantwortungsbereichen
  • sichere Skalierung in einer SaaS-Architektur

6. Erfasste Ereignisse

Das Audit-System protokolliert unter anderem folgende Ereignisse und Bearbeitungsschritte:

Authentifizierung

Login-Erfolge, Login-Fehler, Authentifizierungsprobleme und sicherheitsrelevante Zugriffsversuche.

Fallbearbeitung

Erstellung von Fällen, Statusänderungen, interne Notizen, Rückfragen, Kommunikation und prozessrelevante Änderungen.

Löschprozesse

Antrag, Freigabe und Durchführung von Löschungen inklusive Umfang und beteiligter Verantwortlicher.

Systemereignisse

Integritätsprüfungen, technische Prüfzustände und Informationen zum aktiven Schutzmodus.

7. Löschprozesse und DSGVO-Nachweis

Ein besonderer Schwerpunkt liegt auf der vollständigen Auditierbarkeit von Löschvorgängen. Das System dokumentiert nicht nur, dass eine Löschung stattgefunden hat, sondern auch den Ablauf, die Freigabe und den Umfang.

Beispiel für eine strukturierte Payload:

{ "attachments_deleted": 3, "messages_deleted": 5, "notes_deleted": 2 }

Damit ist unter anderem nachvollziehbar:

  • wer einen Löschprozess beantragt hat
  • wer ihn freigegeben hat
  • wann die Löschung erfolgt ist
  • welche Datenelemente betroffen waren

8. Integrität und Manipulationsschutz

8.1 Hash-Chain

Die Audit-Einträge sind kryptografisch miteinander verkettet. Jede nachträgliche Veränderung würde die Kette beschädigen und damit unmittelbar sichtbar werden. Die Integritätsprüfung erkennt beispielsweise Sequenzlücken, doppelte Sequenznummern oder Hash-Abweichungen.

8.2 Integrity Engine

Das System führt Integritätsprüfungen durch und protokolliert diese selbst wieder als Audit-Ereignis. Dadurch entsteht ein Meta-Level der Nachweisbarkeit: Es wird nicht nur protokolliert, was geschieht, sondern auch, dass die Korrektheit der Protokollierung regelmäßig geprüft wird.

8.3 Immutability Layer

Das Audit-System dokumentiert transparent, in welchem Schutzmodus es betrieben wird. In eingeschränkten Hosting-Umgebungen, in denen keine Datenbank-Trigger verfügbar sind, erfolgt die Schutzlogik auf Anwendungsebene.

8.4 Hard Audit Guard

Mit dem Hard Audit Guard wird das Audit-Log auf Anwendungsebene effektiv als Append-Only-System behandelt. Neue Einträge dürfen geschrieben werden, Änderungen oder Löschungen bestehender Audit-Einträge werden im regulären Betrieb aktiv blockiert.

8.5 Verifikation im System

Die Integrität des Audit-Logs kann im Tenant-System aktiv geprüft werden. Die Prüfung analysiert den aktuellen Zustand der Hash-Kette, erkennt Legacy-Einträge ohne Hash sowie potenzielle Bruchstellen und schreibt die ausgelöste Integritätsprüfung wiederum selbst als Audit-Ereignis mit.

  • manuell auslösbare Integritätsprüfung im Backoffice
  • sichtbarer Status mit Ergebnis, geprüftem Umfang und eventuellen Legacy-Einträgen
  • separater Verify-Bereich für Prüf- und Nachweiszwecke

8.6 Export- und Nachweisformate

Für interne Prüfungen, Datenschutznachweise oder externe Prüfkommunikation können Audit-Daten in mehreren Formaten exportiert werden. Neben einem strukturierten JSON-Export steht auch ein lesbarer TXT-Export zur Verfügung. Beide Exporte enthalten zusätzliche Integritäts- und Signaturinformationen zum exportierten Datenstand.

  • TXT-Export für lesbare Prüf- und Freigabeprozesse
  • JSON-Export für technische Weiterverarbeitung und Archivierung
  • Integritätsstatus, Hash-Informationen und Signaturmetadaten im Export enthalten

9. Sicherheitsmodell

Das Audit-System basiert auf einem mehrstufigen Sicherheitsansatz:

Ebene Beschreibung
Write Protection Änderungen am Audit-Log werden auf Anwendungsebene blockiert.
Hash-Chain Nachträgliche Manipulationen zerstören die Integritätskette und werden erkennbar.
Integrity Engine Regelmäßige Prüfungen analysieren den Zustand der Audit-Kette und dokumentieren das Ergebnis.
Immutability-Status Der aktive Schutzmodus wird systemseitig dokumentiert und transparent ausgewiesen.

10. Rechtliche Einordnung

10.1 DSGVO

Das Audit-System unterstützt insbesondere folgende datenschutzrechtliche Anforderungen:

  • Nachvollziehbarkeit von Zugriffen und Verarbeitungsschritten
  • Integrität und Vertraulichkeit der Verarbeitung
  • Dokumentierte und überprüfbare Löschprozesse
  • Rechenschaftspflicht und Transparenz technischer Maßnahmen

10.2 Hinweisgeberschutzgesetz (HinSchG)

Für interne Meldestellen ist die nachvollziehbare, vertrauliche und manipulationsgeschützte Bearbeitung von Hinweisen wesentlich. Das Audit-System unterstützt diese Anforderungen durch die lückenlose Dokumentation von Bearbeitungsschritten und sicherheitsrelevanten Vorgängen.

10.3 Revisionsfähigkeit und GoBD-nahe Anforderungen

Das System orientiert sich an wesentlichen Prinzipien revisionsfähiger Dokumentation: Nachvollziehbarkeit, Prüfbarkeit, transparente Löschprozesse und weitgehende Unveränderbarkeit innerhalb der gegebenen Infrastruktur.

10.4 ISO-orientierte Nachweisbarkeit

Das Audit-System kann als Bestandteil eines Informationssicherheits- und Kontrollsystems verwendet werden. Es unterstützt unter anderem Logging, Monitoring, Incident-Nachverfolgung, Kontrollnachweise und technische Integritätsprüfungen.

11. Transparenz zu technischen Rahmenbedingungen

In Hosting-Umgebungen mit eingeschränkten Datenbankrechten können Datenbank-Trigger oder tiefergehende DB-Schutzmechanismen nicht immer eingesetzt werden. Das System kompensiert dies durch eine Kombination aus Anwendungsschutz, Hash-Chain und Integritätsprüfung.

Direkte Datenbankzugriffe außerhalb der Anwendung könnten theoretisch Änderungen vornehmen. Solche Änderungen bleiben jedoch nicht unbemerkt, da sie im Rahmen der Integritätsprüfung sichtbar werden.

12. Entwicklungsreife des Systems

Patch Schwerpunkt Reifegrad
Patch 01 Audit Foundation Fundament
Patch 02 Audit Writer & Event Integration Vollständigkeit
Patch 03 Security, Deletion Tracking & Audit Depth Rechtssicherheit
Patch 04 Audit Integrity Engine Integrität
Patch 05 Audit Immutability Layer Transparenz
Patch 06 Hard Audit Guard Manipulationsschutz

13. Gesamtbewertung

Das Audit-System stellt eine hochentwickelte, compliance-orientierte und technisch belastbare Lösung für digitale Meldestellen dar. Es verbindet nachvollziehbare Protokollierung, dokumentierte Löschprozesse, Integritätsprüfung und anwendungsseitigen Manipulationsschutz in einer mandantenfähigen Architektur.

Vollständig auditierbar
Mandantentrennung je Tenant
Strukturierte, auswertbare Event-Daten
Lückenlose Dokumentation sensibler Vorgänge
Manipulationsschutz im Regelbetrieb
Manipulationsnachweis durch Integritätsprüfung
Geeignet für Datenschutz- und Compliance-Dokumentation
Einsetzbar als Grundlage für Behörden- und Prüferkommunikation