Zum Inhalt

ADR-019: Objektspeicher und Schlüsselverwaltung

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

Datum, Uhrzeit Version Änderung Autor
09.08.2026 11:52 1.1 Getrennten Falkenstein-Backupstandort und Wiederherstellungsentscheid ADR-020 verknüpft Codex
09.08.2026 11:33 1.0 Hetzner Object Storage in Nürnberg und AWS KMS in Frankfurt als bevorzugte V1-Lösung festgelegt Codex

Kontext

ADR-013 verlangt einen privaten, versionierten Objektspeicher für Vertragsdokumente. ADR-018 legt tägliche kryptografische Sammelnachweise im getrennten Objektspeicher fest. Hetzner Object Storage verschlüsselt Objekte nicht standardmässig im Ruhezustand, unterstützt aber Server-Side Encryption with Customer-provided Keys (SSE-C), also serverseitige Verschlüsselung mit kundenseitig bereitgestellten Schlüsseln. Hetzner speichert den bereitgestellten Schlüssel nicht.

DiveLogix360 benötigt deshalb eine getrennte, wartungsarme und kostengünstige Schlüsselverwaltung. Ein selbst betriebener Secrets-Manager würde zusätzliche Hochverfügbarkeits-, Backup-, Entsiegelungs-, Aktualisierungs- und Notfallprozesse erfordern.

Entscheidung für V1

  1. Hetzner Object Storage am Standort Nürnberg (nbg1) ist der bevorzugte V1-Objektspeicher.
  2. AWS Key Management Service (AWS KMS) in Frankfurt (eu-central-1) ist die bevorzugte V1-Schlüsselverwaltung.
  3. Es wird ein symmetrischer kundenseitig verwalteter AWS-KMS-Schlüssel verwendet.
  4. Jeder schutzbedürftige Upload erhält über GenerateDataKey einen zufälligen Datenschlüssel. Der Klartextschlüssel wird über Transport Layer Security (TLS) als SSE-C-Schlüssel an Hetzner übermittelt und unmittelbar nach Gebrauch aus dem Anwendungsspeicher entfernt.
  5. Die SQL-Datenbank speichert nur den von AWS KMS verschlüsselten Datenschlüssel, die AWS-KMS-Schlüsselreferenz, den Algorithmus und die interne Objektreferenz. Klartextschlüssel werden weder persistiert noch protokolliert.
  6. Beim Download entschlüsselt AWS KMS den gespeicherten Datenschlüssel. Das Backend übermittelt ihn als SSE-C-Schlüssel an Hetzner und streamt die Datei nach eigener Autorisierungsprüfung an den Benutzer.
  7. SSE-C-Schlüssel oder AWS-Zugangsdaten werden nie an Browser oder andere Clients ausgegeben. Direkte S3-Download-URLs sind für SSE-C-geschützte Objekte ausgeschlossen; Downloads werden ausschliesslich durch das Backend vermittelt.
  8. Der AWS-KMS-Verschlüsselungskontext enthält nur nicht personenbezogene technische Kennungen oder Hashwerte. Er enthält keine Namen, E-Mail-Adressen, Tenant-Bezeichnungen oder Dokumentinhalte.
  9. Vertragsdokumente, Audit-Sammelnachweise, Offboarding-Exporte und andere Schutz- beziehungsweise Aufbewahrungsklassen werden in getrennten privaten Buckets oder gleichwertig getrennten Bereichen geführt. Objektversionierung, Object Lock und Lifecycle-Regeln werden je Klasse festgelegt.
  10. Objektpfade und Metadaten enthalten keine direkt lesbaren personenbezogenen Angaben.

Berechtigungen und Schlüsselbetrieb

  • Das Backend verwendet eine eigene technische AWS-Identität mit Zugriff ausschliesslich auf den vorgesehenen Schlüssel und den minimal erforderlichen Aktionen kms:GenerateDataKey, kms:Decrypt und kms:DescribeKey.
  • AWS-Zugangsdaten liegen nicht in Git, SQL oder ungeschützten .env-Dateien. Der initiale V1-Nachweis darf über geschützte systemd-Credentials oder eine gleichwertige Deployment-Geheimnisablage erfolgen.
  • Schlüsseladministration und Schlüsselnutzung werden getrennt berechtigt. Administratorkonten verwenden Mehrfaktor-Authentifizierung.
  • AWS CloudTrail protokolliert Schlüsseloperationen. Protokolle dürfen weder Klartextschlüssel noch vertrauliche Inhaltsdaten enthalten.
  • Schlüssellöschung ist gegen versehentliche Ausführung geschützt und nur kontrolliert mit Wartefrist zulässig.
  • Wiederherstellung, Berechtigungsentzug, Zugangsdatenrotation und der Ausfall von AWS KMS werden vor Produktivbetrieb getestet.

Datenschutz- und Produktivsperre

Die Architekturentscheidung allein ist keine datenschutzrechtliche Freigabe. Hetzner und AWS bleiben im Provider- und Unterauftragnehmerregister under_review. Vor Verarbeitung produktiver personenbezogener Daten müssen mindestens folgende Nachweise vorliegen:

  • konkrete juristische Vertragspartei und verwendete Dienste;
  • Auftragsverarbeitungsvertrag beziehungsweise Auftragsbearbeitungsvereinbarung;
  • Primär-, Replikations-, Protokoll-, Support- und Fernzugriffsländer;
  • vollständige dienstbezogene Unterauftragnehmerketten;
  • technische und organisatorische Massnahmen;
  • Aufbewahrungs-, Rückgabe-, Lösch- und Vertragsendprozess;
  • Übermittlungsgrundlage und erforderliche Transferprüfung für mögliche Drittlandzugriffe;
  • dokumentierter Schlüssel-, Berechtigungs-, Wiederherstellungs- und Notfalltest.

AWS verarbeitet die zufälligen Datenschlüssel, erhält über diese Architektur aber keine Vertragsdokumente oder sonstigen Objektdaten. Die vertragliche und datenschutzrechtliche Bewertung von AWS bleibt dennoch erforderlich.

Konsequenzen und offene Umsetzung

  • Hetzner-SSE-C und AWS-KMS-Envelope-Encryption werden in einem zentralen Speicherdienst implementiert.
  • Fehler zwischen Objektspeicherung und Metadatenpersistierung benötigen idempotente Kompensation und Alarmierung.
  • Upload, Download, Rotation, Berechtigungsentzug, Manipulation, Object Lock, Lifecycle, Restore und kontrollierte Löschung werden automatisiert getestet.
  • Kosten und Anzahl der AWS-KMS-Operationen werden überwacht. Ein Upload benötigt typischerweise eine GenerateDataKey-Operation, ein Download eine Decrypt-Operation.
  • Backup und Wiederherstellung sind in ADR-020 entschieden. Monitoring bleibt eine eigene Providerentscheidung innerhalb von UC00-07-09.

Quellen

Verknüpfte Dokumente