AES-256-GCM-Feldverschlüsselung, LUKS-Volume, TLS 1.3.

Drei Ebenen: (1) Volume-Verschlüsselung: Das gesamte Datenbank-Volume (Hetzner Cloud Volume) ist mit LUKS und AES-256 verschlüsselt und schützt vor physischem Zugriff. (2) Feld-Verschlüsselung: Bankdaten (IBAN, BIC, Bankname) werden vor dem Schreiben in die SQLite-Datenbank zusätzlich mit AES-256-GCM auf Feldebene verschlüsselt (lib/crypto/field.ts). (3) Transport: alle Verbindungen mit TLS 1.3, nur Cipher Suites mit Forward Secrecy.

AES-256-GCM ist ein anerkannter Verschlüsselungs-Standard nach NIST SP 800-38D. AES (Advanced Encryption Standard) mit 256-Bit-Schlüssellänge ist die stärkste Variante; GCM (Galois/Counter Mode) ist ein moderner Modus, der gleichzeitig verschlüsselt und Integrität sichert (kein nachträgliches Manipulieren des Chiffrats möglich). Wird vom BSI (TR-02102-1) explizit empfohlen.

Der AES-256-GCM Master-Key liegt in der Server-Env-Variable FIELD_ENCRYPTION_KEY (base64-encodiert, 32 Bytes), außerhalb des Anwendungs-Repos. Eine Off-Host-Sicherung in einem Password Manager ist Bestandteil des Betriebs. Bei Verlust des Keys werden die verschlüsselten Bankdaten-Felder kryptographisch wertlos.

Authentifizierung läuft über Better-Auth mit httpOnly+Secure+SameSite-Lax-Cookies, 30 Tage Sitzungsdauer. Login per Google OAuth oder optional als anonyme Demo-Session. Magic-Link-Tokens für das Mieterportal werden nur gehasht in der Datenbank gespeichert; der Klartext-Token existiert ausschließlich in der E-Mail und in der angeklickten URL.

Drei Szenarien: (1) Datenträger-Diebstahl: LUKS-Volume-Verschlüsselung schützt. Festplatten-Inhalt ist Chiffrat. (2) Lesezugriff auf die SQLite-Datei: Bankdaten weiterhin durch die zusätzliche AES-256-GCM-Feldverschlüsselung geschützt, solange der Master-Key separat gesichert ist. (3) Kompromittierter App-Server mit Zugriff auf die Env-Variable: dann sind auch die Bankdaten-Felder lesbar. Im Notfall greift der Incident-Response-Plan (docs/breach-runbook.md) mit 72-Stunden-Meldepflicht nach Art. 33 DSGVO.

Alle Verbindungen zwischen Browser und Server laufen über TLS 1.3 (RFC 8446, 2018), den modernsten TLS-Standard. Forward Secrecy ist Pflicht (DHE/ECDHE Key Exchange): selbst bei späterer Kompromittierung des Server-Schlüssels können vergangene Sessions nicht entschlüsselt werden.

OCR-Texte werden vor Übergabe an Google Gemini lokal pseudonymisiert (siehe /sicherheit/anonymisierung-ki). Die pseudonymisierte Anfrage wird mit TLS 1.3 an Google Gemini (Google Ireland Ltd., EU-Verarbeitung) übertragen. Das Token-Mapping zur Re-Identifikation bleibt nur im Speicher der Server-Anfrage und wird danach verworfen.

Nightly Snapshot der SQLite-Datenbank, gespiegelt in einen separaten GCS-Bucket. Da der Snapshot die feldverschlüsselten Bankdaten unverändert mitsichert, sind diese im Snapshot ebenfalls AES-256-GCM-verschlüsselt. Server-seitige Verschlüsselung auf Google-Cloud-Ebene schützt den Bucket zusätzlich. Backup-Aufbewahrung typisch 30 Tage rollend.

Eine Eigenschaft moderner Verschlüsselungs-Protokolle (TLS 1.3 standardmäßig): Selbst wenn der Server-Schlüssel später kompromittiert wird, können vergangene Sessions nicht entschlüsselt werden, weil für jede Session ein temporärer Schlüssel über Diffie-Hellman-Schlüsselaustausch generiert wird. Schutz gegen rückwirkende Decryption-Angriffe.

Eine planmäßige Rotation des FIELD_ENCRYPTION_KEY ist über die Re-Encryption-Migration (scripts/encrypt-iban.ts) möglich: bei Rotation werden alle Chiffrate mit dem neuen Schlüssel neu verschlüsselt, der alte Schlüssel wird vernichtet. Bei Sicherheitsvorfall: außerplanmäßige Rotation mit anschließender Re-Encryption. Session-Schlüssel für TLS 1.3 sind pro Verbindung neu (Forward Secrecy).

Aktuell setzt Immorium auf serverseitige Verschlüsselung: Sie können Ihre Daten weiterhin lesen, ohne einen separaten Client-Schlüssel zu verwalten. Echte End-to-End-Verschlüsselung (Daten sind auch für Immorium nicht lesbar) würde Funktionen wie Volltextsuche, OCR-Extraktion und KI-Bildbearbeitung unmöglich machen, da der Server die Klartextinhalte verarbeiten muss. Bei besonders hohen Sicherheitsanforderungen sprechen Sie uns über datenschutz@immorium.ch an.

Drei Schichten: (1) Prepared Statements überall, keine String-Konkatenation von Eingaben in SQL. (2) Input-Validation auf den API-Routen. (3) Per-Route Ownership-Checks (lib/api/with-auth.ts) filtern alle DB-Zugriffe nach userId, sodass selbst bei Bypass der Validation kein Cross-Tenant-Zugriff möglich ist. Implementierung folgt OWASP-Best-Practices.