ADR-013: Vertragsdokumente im privaten Objektspeicher¶

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

Datum, Uhrzeit	Version	Änderung	Autor
09.08.2026 11:33	1.5	Hetzner Object Storage und getrennte AWS-KMS-Schlüsselverwaltung nach ADR-019 verknüpft	Codex
08.08.2026 13:28	1.4	Akzeptierte Providerentscheidung ADR-016 verknüpft	Codex
08.08.2026 11:57	1.3	Zehnjährige Frist für akzeptierte Vertragsnachweise und 35-tägiges Auslaufen gelöschter Primärdaten aus Backups verknüpft	Codex
07.08.2026 18:57	1.2	SHA-256 als Integritätsverfahren und PDF-Objektspeicherung für beide Abschlusswege präzisiert	Codex
07.08.2026 18:38	1.1	Schweizer Schreibweise durchgängig bereinigt	Codex
07.08.2026 18:11	1.0	Private und versionierte Ablage digitaler Vertragskopien im Objektspeicher festgelegt	Codex

Kontext¶

ADR-015 erlaubt für den Auftragsverarbeitungsvertrag (AVV) sowohl den elektronischen Abschluss in DiveLogix360 als auch den kontrollierten Upload eines ausserhalb der Anwendung unterzeichneten Dokuments. Für beide Wege muss ein unveränderlicher und tenantbezogener Vertragsnachweis gespeichert werden.

Die eigentliche Vertragsdatei kann als Binärdaten in der relationalen SQL-Datenbank, im lokalen Dateisystem des Anwendungsservers oder in einem spezialisierten Objektspeicher abgelegt werden.

Geprüfte Varianten¶

Variante A: Binärdaten in der SQL-Datenbank¶

Transaktionale Zuordnung ist einfach.
Datenbankgrösse, Sicherungen und Wiederherstellung werden durch grosse Dokumente belastet.
Dokumentzugriffe und Datenbankzugriffe lassen sich schwerer getrennt absichern.

Variante B: Lokales Dateisystem des Anwendungsservers¶

Technisch einfach für eine einzelne Instanz.
Nicht zuverlässig für mehrere Instanzen, Containerwechsel oder horizontale Skalierung.
Backup, Replikation und unveränderliche Versionierung müssen separat gelöst werden.

Variante C: Privater Objektspeicher¶

Dateien und relationale Metadaten werden ihrem Zweck entsprechend getrennt gespeichert.
Zugriff, Versionierung, Verschlüsselung, Lebenszyklus und Backups können gezielt konfiguriert werden.
Die Anwendung kann zeitlich begrenzte signierte Zugriffs-URLs erzeugen.
Der Speicheranbieter muss datenschutzrechtlich und vertraglich geprüft werden.

Entscheidung¶

Variante C wird für V1 akzeptiert.

Die digitale Vertragskopie wird in einem privaten Objektspeicher abgelegt.
Das lokale Dateisystem des Anwendungsservers ist keine dauerhafte Vertragsablage.
Die SQL-Datenbank speichert nur den internen Objektschlüssel, Integritäts-Hash, Dateimetadaten, Tenant- und Vertragszuordnung, Version, Abschluss- und Prüfmetadaten.
Es wird keine dauerhaft öffentlich erreichbare URL gespeichert.
Ein berechtigter Abruf erfolgt wegen der SSE-C-Schlüsselübergabe ausschliesslich über einen geschützten Anwendungsstream; der Browser erhält weder Speicherdienst- noch Schlüsselzugriff.
Vertragsversionen werden nicht überschrieben. Eine neue Version erhält ein neues Vertragsobjekt und einen neuen Datenbankdatensatz.
Online abgeschlossene Verträge und hochgeladene externe Vertragskopien verwenden dieselbe Speicher-, Integritäts- und Zugriffslogik.
Auch beim elektronischen Abschluss wird die unveränderliche PDF-Kopie im Objektspeicher abgelegt; vollständige Vertragsinhalte werden nicht in SQL gespeichert.
Für den Integritätsnachweis wird in V1 SHA-256 verwendet und die Verfahrenskennung zusammen mit dem Hash gespeichert.
Für V1 ist PDF das verbindliche Archiv- und Uploadformat. Ein physisches Papieroriginal bleibt ausserhalb von DiveLogix360; verarbeitet wird ausschliesslich dessen digitale Kopie.

Ein beispielhafter interner Objektschlüssel lautet:

tenants/{tenant-id}/contracts/{contract-id}/signed-original.pdf

Der Schlüssel ist nicht als Autorisierungsmechanismus zu behandeln und darf allein keinen Zugriff ermöglichen.

Sicherheits- und Datenschutzanforderungen¶

privater Bucket ohne anonymen oder öffentlichen Lesezugriff;
Verschlüsselung bei Übertragung und Speicherung;
strikte Tenant- und Rollenprüfung vor jedem Abruf;
höchstens fünf Minuten gültige, signierte Anwendungslinks und ausschliesslich backendvermittelte Downloads;
Prüfung auf MIME-Typ, PDF-Signatur, Dateigrösse und Schadsoftware vor endgültiger Freigabe;
kryptografischer Hash zur Integritätskontrolle;
Protokollierung von Upload, Prüfung, Abruf, Versionswechsel und administrativem Zugriff;
keine Vertragsinhalte, Anwendungslinks oder Schlüssel in Anwendungs- und System-Logs;
Anbieter, Speicherregion, Unterauftragsverarbeiter und Vertragsgrundlagen müssen vor Produktivbetrieb geprüft sein;
Akzeptierte, ersetzte und beendete Vertragsnachweise werden gemäss Fristenmatrix zehn Jahre ab Ende des Kalenderjahres des Vertragsendes aufbewahrt; die juristische Länderprüfung bleibt Go-live-Pflicht.

SQL-Metadaten¶

Mindestens folgende Informationen werden relational gespeichert:

tenant_id und contract_id;
Vertragsversion und Abschlussart;
interner storage_object_key;
ursprünglicher Dateiname;
MIME-Typ und Dateigrösse;
kryptografischer Dokument-Hash;
Upload-Zeitpunkt und hochladender Benutzer;
Abschlusszeitpunkt, Unterzeichner und Funktion;
Prüfstatus, prüfender Benutzer und Prüfzeitpunkt;
Verweis auf die vorherige beziehungsweise ersetzte Vertragsversion.

Konsequenzen und offene Umsetzung¶

Das Prisma-Datenmodell benötigt Vertrags- und Dokumentmetadatenmodelle.
Hetzner Object Storage in Nürnberg und AWS KMS in Frankfurt sind gemäss ADR-019 ausgewählt; Konfiguration und Produktivnachweise bleiben offen.
Upload-, Prüf-, Abruf- und Versionierungsendpunkte müssen implementiert werden.
Das festgelegte Grössenlimit, die Schadsoftwareprüfung und die maximale Gültigkeit backendvermittelter Anwendungslinks müssen technisch umgesetzt werden.
Backup, Wiederherstellung, Aufbewahrung und kontrollierte Löschung müssen Objektspeicher und SQL-Metadaten gemeinsam behandeln. Gelöschte Primärdaten laufen innerhalb von höchstens 35 Tagen aus rollierenden Backups aus.
Automatisierte Tests müssen unberechtigten Cross-Tenant-Zugriff, abgelaufene URLs, manipulierte Dateien und Versionsüberschreibung abweisen.