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.
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_successodercase.created - Bereich, zum Beispiel
auth,caseodersystem - 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_successauth.login_failedcase.createdcase.updatedcase.delete_request_createdcase.delete_request_approvedcase.deletedaudit.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:
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.