Das Backend /Sicherheit & RLS
Von der Datenbank gesichert.
Nicht von Middleware.
Autorisierung ist in Rebase Postgres-Row-Level-Security, durchgesetzt von der Datenbank selbst — und sie scheitert geschlossen: eine Tabelle ohne RLS wird abgelehnt, nie ausgeliefert. Das gilt heute, wenn du den Open-Source-Stack selbst betreibst, und es gilt auf Rebase Cloud, das denselben Server fährt.
Prüf die Datenbank, die du schon hast
Nichts davon musst du uns glauben. rls-check liest den Katalog deiner eigenen Datenbank und meldet, was tatsächlich offen liegt: Tabellen, die mit abgeschalteter Row-Level Security ausgeliefert werden, Policies, die für jeden wahr sind, Views, die an der RLS ihrer Basistabellen vorbeilesen. Es läuft gegen jedes Postgres — Supabase, Neon, RDS oder deinen eigenen Server.
Lesend per Konstruktion: Es öffnet eine Read-only-Transaktion und stellt Katalog-Queries. Es schreibt nichts, und keine Daten verlassen deine Maschine.
Row-Level Security, geschrieben, wo die Collection steht
Definiere, wer jede Zeile lesen, anlegen, ändern und löschen darf — direkt von PostgreSQL durchgesetzt. Policies werden als Code in deinem Schema geschrieben, versioniert und über Migrationen angewendet. Keine Middleware, keine ORM-Tricks. Und es scheitert geschlossen: Eine Tabelle ohne RLS hat kein Autorisierungsmodell, also weigert sich Rebase, sie auszuliefern — und druckt beim Start das genaue SQL, das sie schützt. Es gibt keinen Auth-Check zu vergessen.
Die Voreinstellung
Eine Tabelle ohne Policy liefert keine Zeilen
Die meisten Systeme dieser Kategorie sind offen, bis du daran denkst, sie zuzumachen. Rebase ist andersherum: Anfragen laufen als eingeschränkte Postgres-Rolle, die nichts besitzt — eine Tabelle, für die du eine Policy vergessen hast, wird abgelehnt statt ausgeliefert.
Das gilt für alle Eingänge zugleich — die REST-API, das typisierte SDK, das Admin-Panel, der gescopte Key eines Agenten und eine psql-Sitzung treffen auf dieselben Policies, weil die Policies nicht im Server stehen.
Keine pauschale Bypass-Rolle
Nutzer-Traffic läuft nie als Tabellen-Eigentümer. Es gibt keinen „Service“-Key, der die Policies der Bequemlichkeit halber still abschaltet.
Privilegierte Spalten standardmäßig geschützt
Auth-Collections bekommen Policies injiziert, damit ein Nutzer sich nicht selbst befördert, indem er seine eigene Rollenspalte schreibt. Der Verzicht darauf ist ausdrücklich und benannt.
Junction-Tabellen erben ihre Endpunkte
Many-to-many-Joins sind das klassische Loch. Ihre Policies werden aus beiden Seiten der Relation abgeleitet, statt dir zum Merken überlassen zu werden.
Eine Datenbank, keine zweite Kopie
Rebase spricht direkt mit deinem Postgres und zieht deine Zeilen nie in einen eigenen Speicher ein. Es gibt einen Ort, an dem die Policies halten müssen, und das ist der Ort, an dem die Daten liegen.
Du kannst das Ganze lesen
Der Server ist durchgehend MIT-lizenziert. Prüfe den Code, sieh dir das SQL an, das er ausgibt, und lies die Policies mit
rls-checkaus deiner eigenen Datenbank zurück.Drift ist erkennbar
Der Policy-Editor vergleicht, was in deinem Code steht, mit dem, was in der Datenbank steht, und markiert alles, was sich bewegt hat — auch freizügige Regeln, die sicher aussehen und es nicht sind.
Rollen, die deine Policies lesen können
Definiere Rollen in deinem Schema — Admin, Editor, Viewer oder jede eigene Rolle, die du brauchst. Jede Rolle bekommt granulare Berechtigungen pro Collection.
Berechtigungen pro Collection — SELECT, INSERT, UPDATE, DELETE pro Rolle und Collection.
RLS-Integration — Policies können die Rolle des aktuellen Nutzers referenzieren, um zeilenweise zu filtern.
JWT-Authentifizierung — Zustandslose Token-Auth mit konfigurierbarer Gültigkeit und Refresh.
Deine Daten, deine Infrastruktur
Dieser Abschnitt beschreibt das self-hosted-Modell. Anders als SaaS-Plattformen, die deine Daten einziehen und kontrollieren, verbindet sich der Open-Source-Rebase-Server direkt mit deiner eigenen PostgreSQL-Datenbank, auf Infrastruktur, die du betreibst. Wenn wir es lieber betreiben sollen, spring zum Abschnitt Rebase Cloud unten.
Keine Datenmigration nötig
Rebase introspiziert dein bestehendes Schema und passt sich ihm an.
Null Vendor-Lock-in
Hör jederzeit auf, Rebase zu benutzen — deine Daten bleiben genau da, wo sie sind.
Direkter Infrastrukturzugriff
Volle Kontrolle über deine PostgreSQL-Datenbank, deine Backups und deine Infrastruktur.
Deploy zu deinen Bedingungen
Betreib Rebase, wo du willst. Keine proprietäre Cloud nötig.
Deine Datenbank
Betreib PostgreSQL überall — AWS RDS, Supabase, Neon, ein VPS oder eigene Hardware. Rebase verbindet sich damit; dir gehört es.
Dein Server
Deploy das Rebase-Backend als Node.js-Prozess oder Docker-Container. Railway, Render, Fly.io oder Bare Metal — deine Entscheidung.
Deine Regeln
Auth, RLS-Policies und API-Berechtigungen leben in deinem Code. Prüf sie im PR, versioniere sie in Git, erzwinge sie in der CI.
Zwei Deployment-Modelle, zwei Sicherheitsgeschichten
Lies das zuerst — fast jede Aussage auf dieser Seite hängt davon ab, welches du betreibst. Self-hosted sehen wir deine Daten nie. Auf Rebase Cloud hosten wir sie für dich, was uns zum Auftragsverarbeiter macht. Rebase Cloud ist in der Private Beta: Es betreibt heute echte Tenants und öffnet in Wellen, und alles unten beschreibt, was jetzt läuft.
Du betreibst alles
Du installierst den Open-Source-Rebase-Server und richtest ihn auf eine PostgreSQL-Datenbank, die dir gehört. Deine Daten berühren unsere Server nie, es gibt keinen dritten Auftragsverarbeiter im Pfad, und du bist der alleinige Verantwortliche.
Die Abschnitte Datensouveränität und Deploy zu deinen Bedingungen unten beschreiben dieses Modell.
Wir betreiben es für dich
Rebase Cloud ist unser Managed Hosting. Wir hosten deine Datenbank und deine Anwendung auf unserer Infrastruktur, das heißt Rebase handelt als Auftragsverarbeiter in deinem Auftrag, mit Google Cloud als Unterauftragsverarbeiter. Nichts auf dieser Seite tut so, als wäre es anders.
Der Abschnitt Rebase Cloud unten beschreibt genau, wo diese Daten liegen und wie sie isoliert sind.
Wenn wir es hosten, heißt das Folgendes
Das ist die Architektur, die heute läuft: deine Datenbank und deine Anwendung auf Infrastruktur, die wir betreiben, mit Rebase als Auftragsverarbeiter für die Daten, die du hineinlegst, und dir als Verantwortlichem. Rebase Cloud ist in der Private Beta — es betreibt heute echte Tenants und öffnet in Wellen. Zugang anfragen.
In der EU gehostet
Rebase Cloud läuft auf einem Google-Kubernetes-Engine-Autopilot-Cluster in Google Cloud europe-west1 (Belgien). Deine Datenbank und deine Anwendungscontainer laufen dort. Rebase Cloud bietet derzeit keine Regionswahl.
Auftragsverarbeiter und Unterauftragsverarbeiter
Du bist der Verantwortliche für die Daten, die deine Nutzer in dein Projekt legen. Rebase ist der Auftragsverarbeiter, und Google Cloud ist Unterauftragsverarbeiter, weil es Compute, Storage und Netzwerk bereitstellt, auf denen Rebase Cloud läuft.
Eine Datenbank pro Tenant
Das ist keine Shared-Schema-Mandantenfähigkeit. Jedes Projekt bekommt eine eigene PostgreSQL-Datenbank — es gibt keine tenant_id-Spalte, die dich von anderen Kunden trennt, und eine Verbindung ist an genau eine Datenbank gebunden, sodass ein Zugriff über Mandantengrenzen nicht erreichbar statt nur per Policy verhindert ist. Diese Datenbank ist ein eigener CloudNativePG-Cluster, in einem eigenen Kubernetes-Namespace und mit eigenen Backups — keine Datenbank auf einem Cluster, den du dir mit anderen Kunden teilst.
Netzwerk-Isolation zwischen Tenants
Jeder Tenant-Namespace wird mit einer Kubernetes-NetworkPolicy für Ingress und Egress angelegt, sodass die Pods eines Projekts keine Verbindungen zu Pods oder Datenbank eines anderen öffnen können. Tenant-Anwendungen werden von *.rebase.website ausgeliefert — einer eigenen registrierbaren Domain, die bewusst nie eine mit der Konsole teilt, damit Browser-Cookie- und Same-Site-Grenzen dazwischen fallen.
Verschlüsselung im Transit und für Secrets
Traffic zur Konsole und zu jeder Tenant-Domain läuft über TLS, mit automatisch ausgestellten Zertifikaten (Let's Encrypt via cert-manager für Tenant-Domains). Secrets, die die Control Plane für dich speichert — Projekt-Umgebungsvariablen, Connection-Strings, Cluster-Zugangsdaten, Backup-Zugangsdaten — werden im Ruhezustand mit AES-256-GCM verschlüsselt. Die Control Plane startet ohne gültigen Verschlüsselungsschlüssel nicht; einen Klartext-Fallback gibt es nicht.
Nächtliche Backups, 30 Tage Aufbewahrung
Managed-Datenbanken werden mit einem nächtlichen Basis-Backup plus fortlaufender Write-Ahead-Log-Archivierung in Objektspeicher bereitgestellt, unter einer 30-Tage-Aufbewahrungsrichtlinie — die auch Point-in-Time-Recovery möglich macht. Der Backup-Status wird pro Projekt in der Konsole gemeldet, damit du siehst, ob die Archivierung tatsächlich läuft, statt es anzunehmen.
Rebase Cloud wird sich auch mit einer PostgreSQL-Datenbank verbinden können, die dir schon gehört, statt eine bereitzustellen. In dem Fall bleibt die Datenbank vollständig unter deiner Kontrolle, und die Hinweise oben zur Managed-Datenbank — Isolation, Backups, Aufbewahrung — gelten dafür nicht.
Wo du bei der DSGVO stehst
Die Antwort hängt vom Deployment-Modell ab, also hier beide.
Du bist der Verantwortliche — und der einzige Auftragsverarbeiter
- Kein dritter Auftragsverarbeiter beteiligt. Die Software läuft auf deiner Infrastruktur; wir bekommen keine Kundendaten.
- Direkter Datenzugriff. Erfülle Auskunfts- und Löschanfragen direkt aus deiner eigenen Datenbank — ohne Support-Ticket, ohne Anbieter dazwischen.
- Der Speicherort ist deine Wahl. Deploy PostgreSQL in der Region, die deine Pflichten verlangen.
Du bist der Verantwortliche, wir sind dein Auftragsverarbeiter
- Rebase verarbeitet auf deine Weisung. Du bleibst der Verantwortliche für die Daten deiner Endnutzer.
- Google Cloud ist Unterauftragsverarbeiter und stellt Compute, Storage und Netzwerk in europe-west1 (Belgien) bereit.
- Daten bleiben standardmäßig in der EU, weil das die einzige Region ist, in die Rebase Cloud provisioniert.
Brauchst du einen unterschriebenen Auftragsverarbeitungsvertrag oder eine formale Unterauftragsverarbeiter-Liste, bevor du kaufen kannst? Schreib an sales@rebase.pro, und wir sagen dir ehrlich, wo dieser Papierkram steht.
Eine Schwachstelle gefunden?
Melde es vertraulich an security@rebase.pro. Bitte öffne für ein Sicherheitsproblem kein öffentliches GitHub-Issue und gib uns die Chance, einen Fix auszuliefern, bevor du es öffentlich machst. Wir bestätigen Meldungen in der Regel innerhalb weniger Werktage.
Lies die Policies, die es schreibt.
Scaffolde ein Projekt und sieh dir die aus deinen Collection-Definitionen erzeugte Postgres-Row-Level-Security an — bevor du ihr irgendetwas anvertraust.