Trennung pro Kunde
Jede Datenbanktabelle mit Kundendaten läuft mit „FORCE ROW LEVEL SECURITY“ und „WITH CHECK“ in Postgres. Die Datenbankrolle zur Laufzeit ist NOSUPERUSER NOBYPASSRLS. Der Zugriff auf Daten anderer Kunden wird auf Datenbankebene verhindert, nicht erst in der Anwendung. Die Trennung zwischen Kunden wird von einer Integrationstest-Suite geprüft, die über Testcontainers an einer echten Postgres-Instanz läuft.
Zwei Postgres-Rollen
Wir trennen die Rechte für Migrationen von den Rechten zur Laufzeit. Migrationen laufen als Superuser rekomi über eine explizite Verbindungszeichenfolge. Abfragen zur Laufzeit laufen als rekomi_app, eine Rolle, die RLS nicht umgehen kann. Eine SQL-Injection im Anwendungscode kann also keine Daten eines anderen Kunden lesen.
Webhook-Sicherheit
Stripe-Webhooks werden mit EventUtility.ConstructEvent und einem Toleranzfenster von 300 Sekunden geprüft. Wiederholungen außerhalb des Fensters werden abgelehnt. Jede verarbeitete Ereignis-ID wird in billing_events mit einem UNIQUE-Index gespeichert, doppelte Zustellungen bleiben also ohne Wirkung. Clerk-Webhooks nutzen die Svix-Signaturprüfung mit demselben Schutz vor Wiederholungen.
Verschlüsselung
Daten im Ruhezustand: AES-256 (verwaltet vom Hosting-Anbieter). Daten bei der Übertragung: TLS 1.3 erzwungen. Die Signaturgeheimnisse der API-Schlüssel sind im Ruhezustand über ASP.NET Core Data Protection mit persistentem Schlüsselspeicher verschlüsselt. Die Verschlüsselung einzelner Felder mit identifizierenden Angaben aus Steuerformularen ist als nächster Härtungsschritt geplant.
Authentifizierung und Zugriff
Authentifizierung über Clerk (SOC 2 Type 2 zertifiziert). Sitzungs-JWTs werden bei jeder API-Anfrage geprüft. SAML-SSO steht auf der Enterprise-Roadmap.
Audit-Log
Jede Änderung in der Admin-App wird pro Organisation in einer Append-only-Tabelle audit_log gespeichert. Erfasst werden Akteur, Aktion, Ziel, Zeitstempel und die Herkunft der Anfrage, wie wir sie am Edge sehen. Das Log ist in der Admin-App durchsuchbar und als CSV exportierbar.
Eine Schwachstelle melden
Auf unserer Seite zur Offenlegung von Sicherheitslücken steht, wie du eine Schwachstelle meldest, oder schreib an support@rekomi.com. Wir bestätigen den Eingang innerhalb eines Werktags und beheben kritische Probleme innerhalb von 7 Tagen.
Unterauftragsverarbeiter und Datenstandort
Die vollständige Liste der Unterauftragsverarbeiter findest du unter /legal/subprocessors, Details zum Datenstandort in unserem Trust Center.