Sicherheit & Datenstandorte

Diese Seite beschreibt den tatsächlichen Stand. Wo eine Maßnahme fehlt, steht das hier ausdrücklich — Auslassungen an dieser Stelle wären eine Behauptung. Zum Stand dieser Seite ist zudem noch keine Produktivumgebung in Betrieb: die TLS/HSTS-Kopfzeile sowie die unten genannten automatisierten Prüf-, Sicherungs- und Löschaufträge sind konfiguriert, aber am laufenden System noch nicht bestätigt beziehungsweise noch nicht gelaufen.

1. Wo deine Daten liegen

  • Anwendung, Datenbank, Archiv: Hetzner Online GmbH — Falkenstein und Nürnberg (Deutschland), Objektspeicher wahlweise Helsinki (Finnland).
  • E-Mail-Versand: AWS SES, Region eu-central-1 (Frankfurt).
  • Zahlungsabwicklung: Stripe Payments Europe, Ltd. (Irland).
Der zulässige Standortbereich des Archivs wird beim Start technisch erzwungen: ein Endpunkt oder eine Region außerhalb der EU führt zum Startabbruch (packages/storage/src/eu-hosting.ts). Eine Verlagerung des Archivs in einen Drittstaat (§ 146 Abs. 2b AO) findet nicht statt.

2. Unterauftragsverarbeiter

UnternehmenLeistungOrt
Hetzner Online GmbHHosting, Objektspeicher, verschlüsselte SicherungenDE / FI
Amazon Web Services EMEA SARLE-Mail-Versand inkl. RechnungsanhangFrankfurt (eu-central-1)
Stripe Payments Europe, Ltd.ZahlungsabwicklungIrland
Cloudflare Germany GmbHAuslieferung, TLS-Terminierung, Schutzweltweites Anycast-Netz, keine EU-Standortbindung konfiguriert
GitHub / MicrosoftQuellcode und CI — keine KundendatenUSA
An Stripe übermittelt dieses System keine personenbezogenen Daten: beim Anlegen eines Zahlungskunden wird ausschließlich die interne Organisations-ID gesetzt, keine E-Mail-Adresse und kein Name. Zahlungsdaten gibst du selbst auf den von Stripe gehosteten Seiten ein.

3. Verschlüsselung — Stand und Lücken

  • Transport: TLS, HSTS. Der Edge terminiert TLS; Rechnungsinhalte passieren diesen Punkt im Klartext, bevor sie an den Ursprungsserver gehen.
  • Sicherungen: mit age (X25519) verschlüsselt, im Datenstrom — der Klartext berührt nie eine Platte. Grund: der Objektspeicheranbieter bietet keine serverseitige Verschlüsselung an, das übernehmen wir clientseitig. Unkompensierte Lücke: der private age-Schlüssel liegt auf demselben Host wie die Schreib-Zugangsdaten des Sicherungsziels — wer diesen Host kompromittiert, kann Sicherungen lesen.
  • Archiv: ohne zusätzliche Verschlüsselung auf Anwendungsebene. Der Objektspeicheranbieter bietet dafür keine serverseitige Verschlüsselung an; die Artefakte liegen unverschlüsselt beim Anbieter. Wir nennen das, weil eine gegenteilige Angabe unzutreffend wäre.
  • Datenbank: das MongoDB-Volume auf dem Host ist weder auf Anwendungs- noch auf Engine-Ebene verschlüsselt (Community-Ausgabe); die Systemplatte des Hosts ist ebenfalls nicht zusätzlich verschlüsselt. Dort liegen Konto-, Rechnungs- und Zustelldaten. Wirksam sind Netztrennung ohne veröffentlichten Port, eine Firewall mit Default-Deny (infra/vm/provision.sh) und Keyfile-Authentifizierung.

4. Integrität

Zu jedem erzeugten Dokument wird ein SHA-256-Wert gespeichert. Je Organisation besteht eine fortlaufende Hash-Kette über alle Rechnungsdatensätze; das Rezept steht genau einmal im Code (packages/db/src/hash-chain.ts) und wird von Schreib- und Prüfpfad gemeinsam benutzt. Das Urbild der Kette enthält nur Hashwerte — die Kette bleibt daher auch nach Vernichtung sämtlicher Dateien prüfbar. Eine monatliche Prüfung verifiziert jede Kette vollständig. Vor jedem E-Mail-Versand wird die Prüfsumme des Anhangs erneut gegen den gespeicherten Wert geprüft.

5. Aufbewahrung und Löschung

Rechnungen werden bis zum Ende des Kalenderjahres der Erstellung zuzüglich acht oder zehn Jahren aufbewahrt (§ 147 Abs. 4 AO). Testdokumente werden nach sieben Tagen gelöscht. Nach Fristablauf löscht ein nächtlicher Auftrag die Dateien; Datensatz und Prüfsummen bleiben erhalten, damit die Kette nachvollziehbar bleibt. Eine organisationsweite Sperre setzt die Löschung aus.

6. Export — dein Ausgang, jederzeit

Du kannst jederzeit ein ZIP mit den noch vorhandenen Originaldokumenten, einer CSV aller Metadaten und einer chain-proof.json erzeugen. Die enthaltene README beschreibt das Prüfrezept im Klartext: die Integritätskette lässt sich allein aus dem Bundle nachrechnen — ohne Zugriff auf dieses System und ohne diese Software. Das ist unser Weg, dich nicht einzusperren, und zugleich der Weg zur Datenträgerüberlassung nach § 147 Abs. 6 AO.

7. Zugang

Anmeldung per Magic-Link, keine Passwörter. API-Schlüssel werden ausschließlich als SHA-256-Hashwert gespeichert und laufzeitkonstant verglichen. Download-Links sind auf 15 Minuten befristet. Jede fachliche Abfrage ist organisationsgebunden.

8. Ausführliche Unterlagen

Verfahrensdokumentation, AVV-Vorlage und die vollständigen technischen und organisatorischen Maßnahmen liegen im Repository unter docs/legal/ und werden Beta-Teilnehmern auf Anfrage zugesandt: [email protected].Sicherheitsmeldungen bitte ebenfalls an [email protected]. Wir antworten in der Regel innerhalb weniger Werktage.

In English, briefly

Application, database and invoice archive run on Hetzner in Falkenstein and Nuremberg (Germany), with object storage optionally in Helsinki (Finland). Email is sent through AWS SES in eu-central-1 (Frankfurt). Payments run through Stripe Payments Europe, Ltd. (Ireland), and this system sends Stripe no personal data. Backups are encrypted with age (X25519); the archive itself carries no additional application-level encryption, and TLS is terminated at the edge — we say so rather than imply otherwise. Every invoice is SHA-256 digested and linked into a per-organisation hash chain that can be re-verified offline from an export bundle alone. Invoices are kept to the end of the calendar year of issue plus eight or ten years (§ 147(4) AO); test documents are deleted after seven days. Full documents on request: [email protected].
Stand: Juli 2026