Buchungsdaten-Sicherheit: DSGVO, ISO & HIPAA by Design

Ein Buchungssystem ist selten nur ein Kalender. In dem Moment, in dem jemand einen Termin reserviert, halten Sie seinen Namen, seine E-Mail-Adresse, seine Telefonnummer - und in einer Praxis, einem Salon oder einer Therapieeinrichtung oft etwas weitaus Sensibleres: den Grund seines Besuchs.

Diese Daten sind das Wertvollste, das Sie besitzen - und das, was am leichtesten verloren geht. Eine falsch konfigurierte Tabelle, ein geleaktes Token, ein Mandant, der die Datensätze eines anderen lesen kann, und das über Jahre aufgebaute Vertrauen ist an einem Nachmittag dahin.

Deshalb behandeln wir bei Timerise Sicherheit nicht als Funktion, die man einschaltet. Wir behandeln sie als Architektur. Jede Schicht - Netzwerk, Datenbank, Authentifizierung, Verschlüsselung, Geheimnisse, Audit und die Tests, die alles zusammenhalten - geht davon aus, dass die darüberliegende Schicht versagen könnte. Das ist Defense in Depth, und so funktioniert es in unseren Buchungsprodukten.

Datenspeicherung in der EU, auf die Sie verweisen können

Compliance beginnt mit einer einfachen Frage: Wo liegen meine Daten physisch? Für europäische Kunden muss die Antwort „in Europa" lauten - ohne Sternchen.

Timerise läuft auf Google Cloud, Vercel und Supabase - drei Anbietern, die unabhängig auditiert, nach ISO 27001 zertifiziert und HIPAA-fähig sind und jeweils durch unterzeichnete Auftragsverarbeitungsverträge abgesichert werden. Wir binden Speicher und Rechenleistung an EU-Regionen (Frankfurt für unsere Deployments mit höchsten DSGVO-Anforderungen), sodass personenbezogene Daten von vornherein im Europäischen Wirtschaftsraum bleiben - nicht durch Zufall.

Das heißt: Wenn ein Kunde fragt, wo die Daten seiner Patienten gespeichert sind, nennen Sie eine Region, kein Schulterzucken. Datenspeicherung ist eine Konfiguration, die wir kontrollieren, keine Hoffnung, die wir hegen.

Sicherheits-Header bei jeder Antwort

Bevor auch nur ein Byte Anwendungslogik läuft, wurde dem Browser bereits gesagt, wie er sich zu verhalten hat. Wir setzen gehärtete HTTP-Sicherheits-Header global, bei jeder Antwort:

HSTS erzwingt HTTPS für zwei Jahre (und steht auf der Preload-Liste der Browser). X-Frame-Options: DENY und eine frame-ancestors 'none' Content Security Policy machen Clickjacking zur Nicht-Bedrohung. Die CSP-Baseline beginnt bei default-src 'self' und wird von dort aus enger gezogen - object-src 'none', base-uri und form-action auf den eigenen Ursprung beschränkt - sodass die Menge der Orte, von denen eine Seite Code laden oder ein Formular senden kann, klein und explizit ist.

Das sind keine Schalter, an die ein Kunde denken muss. Sie sind überall standardmäßig aktiv.

Mandantentrennung in der Datenbank erzwungen

Die meisten Datenlecks in Multi-Tenant-Systemen sind keine spektakulären Exploits. Es ist ein vergessenes WHERE tenant_id = ? in irgendeiner Abfrage, die um 2 Uhr nachts geschrieben wurde. Die einzige verlässliche Verteidigung besteht darin, dem Anwendungscode nicht mehr zu vertrauen, sich daran zu erinnern.

Deshalb liegt die Mandantentrennung bei Timerise in der Datenbank selbst - über Postgres Row-Level Security (RLS). Jede Tabelle mit Mandantendaten hat Richtlinien, die eine Zeile für jeden außerhalb ihres Mandanten unsichtbar machen - beim Lesen, Schreiben und Einfügen. In Kombination mit einem Server-First-Schreibmodell (Clients erhalten nie einen direkten, privilegierten Pfad zu den Daten) kann ein Mandant die Buchungen, Kunden oder Datensätze eines anderen schlicht nicht sehen oder verändern. Die Datenbank erzwingt es - selbst wenn eine Abfrage es vergisst.

Das ist keine Behauptung, die Sie uns glauben müssen. Wir beweisen es bei jedem Commit - dazu gleich mehr.

Authentifizierung für sensible Workloads

Bei Sessions kämpfen Komfort und Sicherheit normalerweise gegeneinander. Wir lösen das mit Supabase Auth und ein paar nicht verhandelbaren Punkten.

• Gehärtete Cookies. Sessions laufen in HTTP-only-, Secure-, SameSite-Cookies, verwaltet von @supabase/ssr - niemals von JavaScript lesbar, niemals seitenübergreifend gesendet.
• Kurzlebige Tokens mit Rotation. JWTs laufen nach einer Stunde ab, und Refresh-Tokens rotieren bei jeder Nutzung. Ein gestohlenes, wiederverwendetes Refresh-Token wird erkannt und macht die gesamte Session-Familie ungültig - ein geleaktes Token ist eine Sackgasse, kein Generalschlüssel.
• Begrenzte Identität. Jede Anfrage trägt die Rolle und den Mandanten des Nutzers, und die maßgebliche Zugriffsprüfung läuft serverseitig auf geschützten Layouts - nicht nur optimistisch am Edge.
• Brute Force abgefedert. Wiederholt fehlgeschlagene Logins lösen Throttling und CAPTCHA-Eskalation aus; sensible API- und Auth-Routen sind per Token-Bucket ratenbegrenzt.
• Starke Anmeldedaten. Passwörter müssen mindestens 12 Zeichen lang sein und werden im Moment der Festlegung gegen bekannte Leak-Datenbanken geprüft.
• MFA für die Generalschlüssel. TOTP-Multi-Faktor-Authentifizierung schützt Owner- und Manager-Konten - die Rollen, die am meisten sehen und ändern können.

Verschlüsselung für Gesundheitsdaten (DSGVO Artikel 9)

Gesundheitsdaten sind besondere Kategorien personenbezogener Daten nach DSGVO Artikel 9, und wir behandeln sie auch so - mit einem eigenen Stack, nicht mit einem Häkchen.

Klinische Felder leben in einem eigenen, isolierten clinical-Schema und werden mit anwendungsseitiger Envelope-Verschlüsselung geschützt: Jeder Mandant erhält seinen eigenen Datenverschlüsselungsschlüssel, und dieser Schlüssel wird selbst von einem Master-Key umhüllt, der in Supabase Vault oder einem externen EU-KMS liegt - niemals im Repository, mit dokumentierter Rotationsrichtlinie. Die Entschlüsselung erfolgt ausschließlich serverseitig; die Klartextwerte erreichen den Browser nie. Die gespeicherten Spalten sind Chiffretext, nutzlos für jeden, der die Datenbank direkt liest.

Vorher-/Nachher-Fotos und andere sensible Medien liegen in einem privaten Bucket ganz ohne öffentliche URLs. Zugriff wird nur über kurzlebige signierte URLs gewährt, ausgestellt nach einer serverseitigen Rollenprüfung - ein Link lässt sich also nicht erraten, abgreifen oder über sein Ablaufdatum hinaus teilen.

Geheimnisse, die das Repository nie berühren

Der schnellste Weg, alles zu leaken, ist, einen Schlüssel zu committen. Wir machen das schwer, versehentlich zu tun.

Geheimnisse leben ausschließlich in der Plattform-Umgebung (Vercel env), niemals im Code; .env.local ist gitignored und wird bei Bedarf abgerufen. gitleaks scannt nach Anmeldedaten sowohl in der CI als auch als Pre-Commit-Hook, sodass ein versehentlicher Schlüssel erkannt wird, bevor er je einen Remote-Branch erreicht. Verschlüsselungsschlüssel liegen, wie oben erwähnt, in einem Vault oder KMS - vollständig getrennt von der Anwendung.

Jede sensible Aktion wird protokolliert

Wenn doch etwas schiefgeht - oder ein Kunde, eine Aufsichtsbehörde oder ein Auditor fragt „Wer hat diesen Datensatz angefasst?" - brauchen Sie eine Antwort, keine Vermutung.

Jede Änderung an klinischen und finanziellen Daten schreibt eine Zeile in ein append-only Audit-Log: wer es getan hat (der Akteur), wann (Zeitstempel), was (die Entität) und ein Vorher-/Nachher-Diff genau dessen, was sich geändert hat. Auch Lesezugriffe auf klinische Datensätze werden protokolliert, denn im Gesundheitskontext ist das Ansehen selbst ein regulierter Vorgang. Das Log ist per Design append-only - Einträge können geschrieben, aber niemals stillschweigend bearbeitet oder gelöscht werden.

Bewiesen, nicht versprochen: volle Testabdeckung

Sicherheitsversprechen sind wertlos, wenn nach dem nächsten Refactoring nichts sie prüft. Deshalb sind die obigen Kontrollen nicht dokumentiert und vergessen - sie werden getestet, und die Tests sind Voraussetzung für jedes Deployment.

• Unit-Tests mit erzwungener Abdeckung. Vitest mit v8-Coverage hält eine 80%-Schwelle für unseren Kern-Bibliothekscode, einschließlich der Verschlüsselungsschicht - Round-Trip-Korrektheit, Mandanten-Schlüsselisolation und Manipulationserkennung (ein veränderter Chiffretext muss die Entschlüsselung verweigern).
• Die Isolationsmatrix. Integrationstests laufen gegen ein echtes Postgres, nicht gegen Mocks, und prüfen das Wichtigste: Mandant A kann die Zeilen von Mandant B niemals lesen, schreiben oder einfügen, und das Audit-Log bleibt append-only. Eine parallele klinische Matrix beweist, dass Datensätze besonderer Kategorien für klinische Rollen sichtbar und für die Rezeption verborgen sind - und dass die gespeicherten Spalten echter Chiffretext sind.
• End-to-End-Smoke-Pfade. Playwright durchläuft bei jedem Deployment die echten Buchungsabläufe, mit automatisierten Barrierefreiheitsprüfungen (Axe), die den Build bei schwerwiegenden oder kritischen Verstößen scheitern lassen.
• Lasttests. Wöchentliche k6-Läufe halten Hot Paths unter Druck schnell, denn Verfügbarkeit ist auch Teil der Sicherheit.

Linting, Typprüfung und ein dedizierter RLS-Policy-Linter sind ebenfalls Voraussetzung für die CI. Eine Änderung, die die Isolation schwächt, bekommt kein strenges Code-Review - sie bekommt einen roten Build.

Was das für DSGVO, ISO und HIPAA bedeutet

Frameworks sichern keine Systeme; Kontrollen tun das. Aber es hilft zu sehen, wie sich das zuordnen lässt:

• DSGVO. Datenspeicherung in der EU, Envelope-Verschlüsselung nach Artikel 9 für Gesundheitsdaten, ein vollständiger Audit-Trail, Datenminimierung auf Datenbankebene und unterzeichnete Auftragsverarbeitungsverträge mit jedem Unterauftragsverarbeiter.
• ISO 27001. Wir bauen auf ISO-27001-zertifizierter Infrastruktur und spiegeln deren Disziplin in der Praxis - Least-Privilege-Zugriff, Geheimnisverwaltung, durch CI abgesicherte Änderungskontrolle und getestete Isolation.
• HIPAA. Die Plattform läuft auf HIPAA-fähiger Infrastruktur mit den technischen Schutzmaßnahmen, die regulierte Gesundheitsdaten verlangen: Verschlüsselung im Ruhezustand und bei der Übertragung, strikte Zugriffskontrolle und protokollierter Zugriff auf geschützte Datensätze.

Wir überreichen Ihnen kein gerahmtes Zertifikat und machen Feierabend. Wir überreichen Ihnen die Architektur - und die Tests, die immer wieder beweisen, dass sie noch stimmt.

Zusammenfassung

Sicherheit bei Timerise ist keine Einstellung; sie ist die Art, wie das Produkt gebaut ist. Datenspeicherung in der EU, gehärtete Header, datenbankseitig erzwungene Mandantentrennung, kurzlebige rotierende Sessions mit MFA, Envelope-verschlüsselte Gesundheitsdaten, im Vault gelagerte Geheimnisse, append-only Audit-Logs - und eine Testsuite, die den Build scheitern lässt, sobald etwas davon ins Rutschen gerät.

Die Daten Ihrer Kunden sind das Sensibelste, das Sie je für sie verwahren werden. Bauen Sie auf einem Fundament, das sie so behandelt.

Lesen Sie unsere Sicherheits- & Datenschutzdokumentation →

Prüfen Sie unseren AVV, unsere Datenschutzerklärung & Bedingungen →

Starten Sie Ihr Projekt →

<br>

Matt Sowa