Sicherheit

Sicherheit als Funktion, nicht nachträglich drangeschraubt.

Name: Sicherheit
Brand: Rekomi

Jede Tabelle mit Kundendaten läuft mit Postgres Row-Level Security, mit FORCE und einer WITH-CHECK-Klausel. Webhooks sind signiert und gegen Replay geschützt. Die Datenbankrolle zur Laufzeit kann RLS nicht umgehen. Wir dokumentieren alles unter /trust.

RLS pro Kunde. Webhook-Prüfung auf Stripe-Niveau. Zwei getrennte Postgres-Rollen.

14 Tage kostenlos testen →Alle Funktionen

live

Sicherheit

3 Module · Teil von Rekomi

Das steckt drin

3 Module. Ein Bereich: Sicherheit.

Jede Karte springt zum ausführlichen Abschnitt weiter unten. Jedes Modul ist heute verfügbar, sofern der Text nichts anderes sagt.

01 / 03

Von Grund auf unmöglich

Ein Datenleck zwischen Kunden ist kein Bug, den wir patchen. Die Datenbank lässt es gar nicht zu.

Jede kundenbezogene Tabelle hat eine Postgres-Row-Level-Security-Richtlinie, die an die aktuelle Organisation gebunden ist. Die Laufzeitrolle ist NOSUPERUSER NOBYPASSRLS, selbst bei einer fehlerhaften Abfrage kommt also keine Zeile eines anderen Kunden zurück. Die Trennung zwischen Kunden testen wir in CI mit Testcontainers.

Zum Abschnitt

02 / 03

Webhooks, die sich weder fälschen noch wiederholen lassen

Niemand kann einen Webhook fälschen oder einen alten erneut abspielen.

Jeder Webhook von Stripe und Clerk wird per HMAC-SHA256-Signatur mit einer Replay-Toleranz von 300 Sekunden verifiziert. Wir halten jede verarbeitete Event-ID pro Organisation in billing_events mit einem UNIQUE-Index fest, Replays sind also No-ops. Fehlgeschlagene Signaturprüfungen antworten still mit 401 und verraten nie, warum.

Zum Abschnitt

03 / 03

Nur anhängen, Änderung für Änderung

Jede Zustandsänderung protokolliert. Für immer.

Audit-Log-Einträge entstehen bei jeder Kampagnenerstellung, Affiliate-Einladung, Auszahlung, jedem Abrechnungsereignis, jeder KI-Co-Pilot-Aktion und jedem Admin-Eingriff. Das Log lässt nur Anhängen zu, ist auf die Organisation begrenzt, erfasst Akteur, Aktion, Ziel, Zeitstempel und die Herkunft der Anfrage, wie unser Edge sie sieht, und ist in der Admin-App durchsuchbar.

Zum Abschnitt

In Zahlen

Was dieser Bereich leistet.

Sicherheit auf einen Blick

RLS pro Kunde. Webhook-Prüfung auf Stripe-Niveau. Zwei getrennte Postgres-Rollen.

Enthaltene Module

Fest in Sicherheit eingebaut

100%

Audit-Log-Abdeckung

Jede Änderung, jeder Akteur

300s

Webhook-Replay-Fenster

HMAC-SHA256-verifiziert

RLS

Trennung pro Kunde

Direkt in der Datenbank erzwungen

Von Grund auf unmöglich

Ein Datenleck zwischen Kunden ist kein Bug, den wir patchen. Die Datenbank lässt es gar nicht zu.

FORCE ROW LEVEL SECURITY auf jeder Tabelle mit Kundendaten (heute 15+)
WITH-CHECK-Klausel verhindert Inserts über Kundengrenzen hinweg
Zwei Postgres-Rollen: rekomi (Superuser, Migrationen) und rekomi_app (Laufzeit, NOSUPERUSER NOBYPASSRLS)
Trennung zwischen Kunden durch Testcontainers-Integrationstests in CI abgesichert

Modul 01 von 03

Postgres RLS · Trennung pro Kundeerzwungen

-- enforced on every tenant table

ALTER TABLE programs FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_iso ON programs

USING (organization_id = current_setting('app.org')::uuid)

WITH CHECK (organization_id = current_setting('app.org')::uuid);

-- runtime role

SET ROLE rekomi_app; -- NOSUPERUSER NOBYPASSRLS

Geschützte Tabellen

15+ · jede Kundenzeile

Trennungstests

in CI verifiziert

Auf Datenbankebene erzwungen · nicht in der AppNOSUPERUSER · NOBYPASSRLS

Webhooks, die sich weder fälschen noch wiederholen lassen

Niemand kann einen Webhook fälschen oder einen alten erneut abspielen.

Stripe-Webhooks: HMAC-SHA256-Signatur mit 300s Replay-Fenster
Clerk-Webhooks: Signaturprüfung über Svix
Jedes Event landet für Idempotenz und Audit in billing_events
Fehlgeschlagene Signatur antwortet mit 401 und verrät nie, welche Prüfung gescheitert ist

Modul 02 von 03

Webhook-Prüfung · Stripe + Clerkverifiziert

Eingehender Webhook

POST /api/stripe mit signiertem Payload

HMAC-SHA256 verifiziert

Stripe-Signature-Header passt zum Secret

300s Replay-Fenster

Zeitstempel innerhalb der Toleranz

Idempotenz über billing_events

UNIQUE event_id · Replay ist ein No-op

Fehlerfall

Falsche Signatur → 401, ohne Begründung

Clerk-Webhooks

Gleicher Ablauf · Svix-verifiziert

HMAC-SHA256 · 300s ToleranzIdempotent · im Audit-Log

Nur anhängen, Änderung für Änderung

Jede Zustandsänderung protokolliert. Für immer.

audit_log-Tabelle pro Organisation, nur anhängen
Erfasst Akteur, Aktion, Ziel, Zeitstempel und die Herkunft der Anfrage, wie unser Edge sie sieht
In der Admin-App durchsuchbar
Für Compliance-Prüfungen unbegrenzt aufbewahrt

Modul 03 von 03

Audit-Log · org_acmenur anhängen

program.createdvonsam@acme.com

id=prog_4c2 · summer-2026

14:32:08 UTC

payout.dispatchedvonsam@acme.com

8 Affiliates · $24,917.00

14:35:21 UTC

affiliate.invitedvonai-copilot

kenji.sato@northwind.io

14:38:02 UTC

commission.adjustedvonsam@acme.com

tier=gold · 35% → 28%

14:42:11 UTC

billing_event.recordedvonstripe.webhook

evt_1Q… · charge.succeeded

14:44:53 UTC

Pro Eintrag erfasst

Akteur · Aktion · Ziel · Herkunft der Anfrage

Aufbewahrung

Unbegrenzt aufbewahrt

Nur anhängen · kryptografisch geordnetAls CSV exportierbar

FAQ

Häufige Fragen.

Wo liegen die Daten?

Postgres bei einem gemanagten Anbieter (Produktion); App und Klick-Tracking-API laufen auf gemanagter regionaler Infrastruktur. Heute nur in der US-Region. EU-Hosting steht auf der Roadmap.

Sind die Daten im Ruhezustand verschlüsselt?

Ja. AES-256 im Ruhezustand, TLS 1.3 bei der Übertragung. Signatur-Secrets für API-Schlüssel sind über ASP.NET Core Data Protection im Ruhezustand verschlüsselt. Eine Verschlüsselung auf Feldebene für die identifizierenden Felder der Steuerformulare ist als weitere Härtung geplant.

Habt ihr einen SOC-2-Bericht, den ich lesen kann?

Noch nicht. Wir behaupten keine Zertifizierung, die wir noch nicht haben. Unser Sicherheitsmodell ist unter /security und /trust ausführlich dokumentiert. Sobald ein unabhängiges Audit abgeschlossen ist, schicken wir den Bericht auf Anfrage unter NDA.

Was passiert mit meinen Daten, wenn ich kündige?

Du kannst deine Daten jederzeit exportieren, vor oder nach der Kündigung. Nach der Kündigung bleiben deine Daten erhalten, damit du reaktivieren kannst, und werden auf Anfrage oder beim Löschen des Kontos gelöscht. Audit-Log-Einträge zu deiner Organisation werden aus rechtlichen Gründen unbegrenzt aufbewahrt.

Kann ich meine eigene AWS-, GCP- oder Azure-Umgebung nutzen?

Derzeit nicht. Eine eigene Cloud steht auf der Enterprise-Roadmap. Wir nutzen einen gemanagten Postgres-Anbieter und Cloudflare für den Edge. Beide erfüllen die Sicherheitsstandards für Enterprise.

Gibt es ein öffentliches Bug-Bounty-Programm?

Noch nicht. Ein formelles Programm steht auf der Roadmap. Bis dahin melde Sicherheitslücken bitte an support@rekomi.com, wir bestätigen innerhalb eines Werktags.

Gibt es SAML-SSO?

Noch nicht. SAML-SSO steht auf der Enterprise-Roadmap. Heute übernimmt Clerk die Anmeldung mit E-Mail + Passwort, Magic Link und OAuth-Anbietern.

Auch einen Blick wert

Weitere Teile von Rekomi.

Sicherheit ist einer von acht Bereichen. Alle bauen auf denselben Grundbausteinen auf (Stripe, Postgres mit RLS, Clerk, Anthropic) und bringen dieselbe Messlatte bei Audit und Sicherheit mit.