Sicherheit

1. Was diese Seite ist

Diese Seite beschreibt die technischen Maßnahmen, die Cardim heute anwendet, geschrieben anhand des Codes, wie er veröffentlicht ist. Sie ist kein Vertrag: Die vertraglichen Zusagen stehen in den AGB, und was wir mit personenbezogenen Daten tun und auf welcher Grundlage, steht in der Datenschutzerklärung.

Cardim ist ein junges Produkt und wird von einem sehr kleinen Team betrieben. Wir sagen das lieber hier, gleich zu Beginn, als es zwischen den Zeilen stehen zu lassen: Abschnitt 7 zählt auf, was es nicht gibt.

2. Wo die Daten liegen

Buchungen und Kundendaten liegen in einer Postgres-Datenbank, die Neon in London im Vereinigten Königreich betreibt, auf AWS-Infrastruktur in der Region eu-west-2. Die Anwendung läuft bei Vercel, die Transaktions-E-Mails stellt Resend zu, und Fehlerberichte gehen an Sentry. Die vollständige Liste der Anbieter mit ihrem jeweiligen Zweck steht in Abschnitt 5 der Datenschutzerklärung.

Der gesamte Verkehr wird über HTTPS ausgeliefert. Die Verschlüsselung des Speichers selbst ist die, die diese Anbieter veröffentlichen, und liegt nicht bei uns; auf Anwendungsebene verschlüsseln oder hashen wir genau das, was der nächste Abschnitt aufzählt, und sonst nichts.

3. Passwörter, Schlüssel und Links

Nichts aus dieser Liste wird in einer Form gespeichert, die ein Lesen der Datenbank wiederverwendbar machen würde — mit einer benannten Ausnahme: Kalender-Tokens müssen an den Anbieter zurückgegeben werden und werden deshalb verschlüsselt statt gehasht.

• Passwörter der Betriebe — werden nie gespeichert. Wir speichern das Ergebnis von scrypt, mit einem eigenen Salt pro Nutzer, und die Prüfung erfolgt über einen Vergleich in konstanter Zeit.
• Links zum Zurücksetzen des Passworts — 32 Byte kryptografischer Zufall, und die Datenbank speichert nur den SHA-256 des Tokens: Wer die Datenbank liest, kann damit niemandes Passwort zurücksetzen.
• Google-Kalender- und Outlook-Tokens — vor dem Schreiben mit AES-256-GCM verschlüsselt, mit einem Schlüsselbund, der den Schlüssel austauschbar macht, ohne bereits Gespeichertes unlesbar zu machen.
• Sitzungen und Buchungslinks — 128-Bit-Kennungen aus dem kryptografischen Generator des Systems. Die Sitzung reist in einem httpOnly-Cookie und läuft nach 30 Tagen ab.

Der Link, den der Kunde per E-Mail erhält, ist für sich genommen die Berechtigung, diese Buchung einzusehen, zu ändern oder zu stornieren — auf Kundenseite gibt es weder Konto noch Passwort. Deshalb werden diese Links und E-Mail-Adressen aus Fehlerberichten entfernt, bevor sie die Anwendung verlassen, und deshalb begrenzen die öffentlichen Formulare die Zahl der Versuche pro Herkunft.

4. Was die Datenbank nicht zulässt

Zwei Buchungen können dieselbe Ressource nicht zur selben Zeit belegen, und diese Garantie steckt nicht im Anwendungscode: Jede Belegungszeile trägt ihren eigenen Zeitraum, und eine Ausschluss-Bedingung von Postgres weist jede Überschneidung ab. Zwei Anfragen, die im selben Augenblick eintreffen, können nicht beide gewinnen — was auch immer oberhalb der Datenbank geschieht.

Ein eigener Trigger verhindert, dass derselbe Kunde zwei sich überschneidende Buchungen erhält. Bei Tischen und Räumen mit geteilter Kapazität wird die Personenzahl innerhalb derselben Transaktion geprüft, mit Sperren pro Ressource, die immer in derselben Reihenfolge genommen werden, damit zwei gleichzeitige Anfragen nicht aufeinander warten.

5. Wer was sieht

Jeder Bildschirm im Verwaltungsbereich fragt nur die Daten des Betriebs ab, zu dem die Sitzung gehört, und Export- wie Löschanfragen verlangen denselben Rahmen: Ein Betrieb kann die Daten eines anderen weder exportieren noch löschen.

Es gibt eine interne Konsole für den Betrieb des Dienstes, deren Zugang auf eine geschlossene Liste von E-Mail-Adressen in der Serverkonfiguration beschränkt ist. Ist diese Liste nicht konfiguriert, weist die Konsole alle ab, statt jemanden hereinzulassen.

6. Aufbewahrung, Löschung und Export

In regelmäßigen Abständen läuft eine Bereinigung, die löscht, was zu nichts mehr nütze ist:

• abgelaufene Sitzungen — eine verlassene Sitzung bleibt ein gültiger Zugang, solange die Zeile existiert;
• bereits verfallene vorläufige Platzreservierungen;
• Einträge der Versuchsbegrenzung, die älter als 24 Stunden sind und ohnehin einen Hash und nicht die ursprüngliche Adresse enthalten;
• Wartelisteneinträge für Termine, die mehr als 30 Tage zurückliegen — ein Name, eine Telefonnummer und eine E-Mail-Adresse von jemandem, der nie Kunde geworden ist.

Buchungen und Kunden werden nicht per Zeitschaltung gelöscht: Sie sind die Geschäftsunterlagen des Betriebs. Gelöscht wird auf Anfrage, und zwar als Anonymisierung an Ort und Stelle — Buchung, Uhrzeit und Betrag bleiben bestehen, die Identität der Person verschwindet, einschließlich der Freitextnotizen und der gespiegelten Einträge im verbundenen Kalender. Lässt sich einer dieser Einträge nicht löschen, wird dem Betrieb das gesagt, statt ihn zu beruhigen.

Ein Betrieb kann den Export seiner Daten und die vollständige Löschung des Kontos verlangen.

7. Was wir nicht haben

Diese Liste gibt es, weil die Alternative wäre, die Frage unbeantwortet zu lassen und zu hoffen, dass sie niemand stellt:

• wir haben weder eine SOC-2- noch eine ISO-27001- noch irgendeine andere Zertifizierung;
• es gab weder ein externes Sicherheitsaudit noch einen Penetrationstest durch Dritte;
• wir bieten keine Vereinbarung über die Verfügbarkeit an, und die tatsächliche Verfügbarkeit hängt von den in Abschnitt 2 genannten Anbietern ab;
• wir haben kein Programm für die belohnte Meldung von Schwachstellen.

8. Ein Problem melden

Wenn Sie eine Sicherheitslücke gefunden haben, schreiben Sie an support@usecardim.com und beschreiben Sie die Schritte, mit denen sie sich nachvollziehen lässt. Wir antworten und beheben, was in unserer Reichweite liegt, und bitten Sie, sie vor der Behebung nicht öffentlich zu machen.