Zum Inhalt

ADR-018: Revisionsfähige Auditierung

Stand: 09.08.2026 11:33 Branch: main Status: Akzeptiert

Datum, Uhrzeit Version Änderung Autor
09.08.2026 11:33 1.1 Hetzner Object Storage und AWS-KMS-Schlüsselverwaltung nach ADR-019 verknüpft Codex
08.08.2026 14:48 1.0 V1-Auditmodell mit täglichen kryptografischen Sammelnachweisen festgelegt Codex

Kontext

Vertragsabschlüsse, Freigaben, Rollen- und Statusänderungen, sensible Zugriffe, Aufbewahrungssperren und Löschungen müssen nachvollziehbar sein. Das vorhandene Prisma-Schema enthält mehrere Protokolltabellen, bildet Verantwortlichkeitskontext, standardisierte Ereignisse und Manipulationsnachweise jedoch noch nicht vollständig ab.

Revisionsfähig bedeutet für DiveLogix360 nachvollziehbar, vollständig, zugriffsgeschützt, manipulationsüberwacht und fristgerecht aufbewahrt. Der Begriff behauptet keine automatische rechtliche Beweiskraft.

Entscheidung für V1

  1. audit_log, access_log, auth_log, deletion_log, system_log und notification_log bleiben nach ihrem jeweiligen Zweck getrennt.
  2. Vertrags- und Datenschutzaktionen verwenden verbindliche Ereignis- und Grundcodes statt freien Texts.
  3. Jeder fachliche Auditnachweis enthält mindestens Verantwortlichkeitskontext, Akteurtyp, optionale Akteur-ID, Tenant-ID soweit anwendbar, Objektart, Objektreferenz, Ereignis, Ergebnis, Grundcode, serverseitigen UTC-Zeitpunkt und geheimnisfreie Korrelations-ID.
  4. Vertragsereignisse referenzieren zusätzlich Vertragsinstanz, Vertragsversion und Dokument-Hash.
  5. Unterstützte Akteurtypen sind mindestens user, system, provider und anonymous. Fehlende Benutzerreferenzen dürfen den Nachweis nicht verhindern.
  6. Alt- und Neuwerte werden ausschliesslich über feldbezogene Positivlisten aufgenommen. Passwörter, Hashes, Token, Authentifizierungsgeheimnisse, Wiederherstellungscodes, vollständige Dokumente und Nachrichteninhalte sind ausgeschlossen.
  7. DeletionLog.dataSnapshot wird entfernt. Löschungsnachweise enthalten keine gelöschten Inhaltsdaten.
  8. Anwendungsrollen dürfen Protokolle weder verändern noch direkt löschen. Fristgerechte Löschung erfolgt ausschliesslich über den kontrollierten Retention-Prozess.
  9. Kritische Änderung und Auditnachweis werden in einer gemeinsamen Transaktion gespeichert. Ohne Auditnachweis wird die Änderung abgebrochen.
  10. Zugriffe auf und Exporte von Audit-, Vertrags-, Löschungs- und Sicherheitsnachweisen werden im Access-Protokoll selbst nachgewiesen.
  11. Ein verpflichtendes Vier-Augen-Prinzip besteht für die Protokollerzeugung in V1 nicht.

Täglicher kryptografischer Sammelnachweis

Für jeden UTC-Kalendertag wird je Verantwortlichkeitskontext ein kanonisch sortierter Sammelnachweis der neuen vertrags- und datenschutzrelevanten Ereignisse erzeugt.

Er enthält mindestens:

  • Zeitraum und Kontext;
  • Anzahl Ereignisse;
  • erste und letzte Ereignis-ID;
  • verwendete Kanonisierung und Hash-Algorithmus;
  • SHA-256-Prüfwert;
  • serverseitigen Erstellungszeitpunkt;
  • Ergebnis und Referenz des vorherigen Sammelnachweises.

Der Sammelnachweis enthält keine fachlichen Inhaltsdaten. Er wird gemäss ADR-019 verschlüsselt und getrennt von der Protokolldatenbank unveränderlich in Hetzner Object Storage am Standort Nürnberg abgelegt. Objektversionierung und Löschschutz richten sich nach der jeweiligen Protokollfrist. Ein fehlender, verspäteter oder abweichender Nachweis löst einen Alarm aus.

Technische Konsequenzen

  • tenantId muss bei plattformweiten Ereignissen optional sein; scope = platform oder scope = tenant ist verpflichtend.
  • Das Schema benötigt Ereignis, Ergebnis, Grundcode, Akteurtyp, Korrelations-ID und kontrollierte Metadatenfelder.
  • Freie JSON-Alt- und Neuwerte werden durch Positivlisten und zentrale Filterung begrenzt.
  • Datenbankrechte oder Trigger müssen Append-only für Anwendungsrollen erzwingen.
  • Ein täglicher idempotenter Versiegelungsjob erzeugt, speichert und verifiziert die Sammelnachweise.
  • Prüfung, Alarmierung, Wiederholung, Retention, Restore-Verhalten und Objektspeicherzugriffe werden automatisiert getestet.

Aufbewahrung

Es gelten die Kategorien RF-11 bis RF-17 der zentralen Fristenmatrix. Sammelnachweise werden so lange wie die dadurch belegte längste Ereigniskategorie aufbewahrt und danach kontrolliert gelöscht. Ein dokumentierter legal_hold kann die Löschung begründet aussetzen.

Verknüpfte Dokumente