Row-Level Security erklärt:Daten-Schutz für Gründer

Row-Level Security erklärt: RLS ist eine Datenbankfunktion, die jede Abfrage automatisch filtert, sodass jeder Kunde immer nur seine eigenen Daten sieht — selbst wenn dein Anwendungscode Bugs hat. Du definierst die Regel einmal in der Datenbank, und sie lässt sich nicht umgehen. Ehrlich gesagt ist sie der Grund, warum ich nachts schlafen kann.

Wenn du eine SaaS mit KI baust und nicht technisch bist, ist RLS das eine Sicherheitskonzept, das du wirklich verstehen solltest. Hier erfährst du, was es ist, warum es jede Alternative schlägt und welche Checkliste du deiner KI mitgibst.

Row-Level Security erklärt: die Türsteher-Analogie

Stell dir vor, deine Datenbank ist ein Archivraum und die Unterlagen jedes Kunden sind Ordner darin. Ohne RLS steht die Tür des Archivraums offen, und du verlässt dich darauf, dass jeder Mitarbeiter — jedes Stück deines Anwendungscodes — jedes einzelne Mal daran denkt, nur die Ordner des richtigen Kunden zu holen. Ein vergesslicher Moment, und jemand verlässt den Raum mit den Akten eines Konkurrenten.

RLS stellt einen Türsteher in den Archivraum selbst. Der Türsteher prüft den Ausweis dessen, der fragt, und reicht physisch nur Ordner heraus, die zu dessen Organisation gehören. Es spielt keine Rolle, ob der Mitarbeiter vergisst, richtig zu fragen, oder alles verlangt — der Türsteher filtert, was zurückkommt. Jede Anfrage. Automatisch. Ohne Ausnahmen.

Technisch: Statt dass deine Anwendung Daten filtert („zeige nur Zeilen dieses Kunden“), definierst du diese Regel einmal in der Datenbank als Policy. Von da an wird jede Abfrage gefiltert, bevor Daten die Datenbank verlassen. Es ist in PostgreSQL eingebaut, und Plattformen wie Supabase machen es zu einer erstklassigen Funktion.

Warum Filtern im App-Code nicht reicht

Hier die unbequeme Wahrheit über die Alternative. Ohne RLS hängt die Datenisolation davon ab, dass ein Mensch — oder eine KI — daran denkt, an jeder einzelnen Stelle, an der dein Produkt Daten anfasst, „nur für diesen Kunden“ hinzuzufügen. Hunderte Stellen. Für immer. Bei jedem neuen Feature, jedem schnellen Fix, jeder nächtlichen Änderung.

Menschen vergessen. KI vergisst auch — bitte sie an einem müden Dienstag um ein Reporting-Feature, und sie fragt vielleicht fröhlich alles ab. Ein echtes Beispiel aus der Praxis: Ein Entwickler vergaß, in einem Reporting-Endpoint nach Organisation zu filtern. Ohne RLS hätte er Kundendaten an Konkurrenten geleakt. Mit RLS blockierte die Datenbank den unbefugten Zugriff automatisch. Niemand bemerkte es bis zum Code-Review — weil nichts Schlimmes passiert ist.

Sicherheitsleute nennen das Defense in Depth: Verlass dich nicht darauf, dass eine Schicht perfekt ist. Dein App-Code filtert Daten (erste Schicht), und RLS erzwingt es in der Datenbank (zweite Schicht). Fällt die erste Schicht aus — ein Bug, ein schlechter Prompt, eine KI-Halluzination —, hält die zweite. Das gilt doppelt, wenn die KI den Großteil deines Codes schreibt, denn KI-generierter Code scheitert auf Weisen, die du erst bemerkst, wenn es teuer wird.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Die vier Berechtigungen, die jede Tabelle braucht

RLS-Policies gibt es in vier Varianten, eine für jede Sache, die ein Nutzer mit Daten tun kann. Stell sie dir als vier Fragen vor, die der Türsteher stellt:

Jede Tabelle mit Kundendaten bekommt alle vier. Das ist das ganze System: Das organization_id-Label auf jeder Tabelle sagt, wem jede Zeile gehört; die vier Policies sorgen dafür, dass die Datenbank es durchsetzt.

Wie ich RLS gelernt habe (von Claude)

Ich bin ehrlich — ich habe RLS nicht in einem Sicherheitskurs gelernt. Ich habe es von Claude gelernt. Als ich mit Supabase anfing, fragte ich: „Wie stelle ich sicher, dass Nutzer nur die Daten ihrer eigenen Organisation sehen?“ Claude erklärte RLS-Policies. Ich setzte sie auf jeder Tabelle um. Jetzt läuft es automatisch.

Das ist der Punkt für nicht-technische Gründer: Du schreibst diese Policies nicht von Hand. Du verstehst das Konzept — Türsteher im Archivraum, vier Berechtigungen pro Tabelle — und gibst deiner KI die Anweisung: „Aktiviere Row-Level Security auf jeder Tabelle, mit Policies für Ansehen, Anlegen, Ändern und Löschen, begrenzt auf die Organisation des Nutzers.“ Die KI erzeugt die Policies; die Datenbank setzt sie für immer durch.

Meine Plattform FIKR Space hat 964 Tabellen. Alle sind auf diese Weise geschützt. Ohne Ausnahme. Diese Größenordnung ist nur beherrschbar, weil die Regel von der Datenbank durchgesetzt wird und nicht von meinem Gedächtnis — derselbe Grund, aus dem ich dafür plädiere, die Datenbank zu entwerfen, bevor du ein Feature schreibst.

Die RLS-Checkliste für Gründer

Du musst keine Zeile SQL schreiben. Du musst auf fünf Dinge bestehen:

1. RLS auf jeder Tabelle mit Kundendaten aktiviert. Frag deine KI direkt: „Ist Row-Level Security auf allen Tabellen aktiviert? Liste alle auf, bei denen es nicht so ist.“
2. Alle vier Policy-Typen pro Tabelle — ansehen, anlegen, ändern, löschen. Eine Tabelle mit nur einer Ansehen-Policy leckt trotzdem über Schreibzugriffe.
3. Policies nach Organisation begrenzt, passend zu deinem Multi-Tenancy-Setup.
4. Mit zwei Accounts testen. Lege zwei Testorganisationen an. Logge dich als eine ein und versuche, die Daten der anderen zu lesen und zu bearbeiten. Kommt irgendetwas zurück, stopp und behebe es vor dem Release.
5. Nach jeder neuen Tabelle erneut prüfen. Mach „RLS mit den vier Standard-Policies aktivieren“ zu einer festen Regel, die deine KI auf jede Tabelle anwendet, die sie anlegt — nicht zu etwas, woran du pro Feature denken musst.

Einfacherer App-Code ist der Bonus: Sobald die Datenbank die Isolation durchsetzt, braucht keines deiner Features überall verstreute Logik zum Kundenfiltern. Sicherheit als Standard, weniger Code, und du hörst auf, dir Sorgen um die eine Abfrage zu machen, die jemand vergessen hat.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Häufig gestellte Fragen

Was ist Row-Level Security in einfachen Worten?

Es ist eine Regel, die du einmal in der Datenbank definierst und die jede Abfrage automatisch filtert, sodass jeder Nutzer nur Zeilen seiner Organisation sieht. Wie ein Türsteher im Archivraum: Egal, wer fragt oder wie, es kommen nur die richtigen Ordner heraus.

Brauche ich RLS, wenn meine Anwendung bereits Daten filtert?

Ja. Das Filtern in der Anwendung hängt davon ab, dass jedes Stück Code — von Menschen oder KI geschrieben — für immer an den Filter denkt. RLS ist das Sicherheitsnetz, wenn etwas es vergisst: Ein Bug in deiner App kann nicht mehr zum Datenleck werden, weil die Datenbank das Leck selbst blockiert.

Kann ich RLS ohne SQL-Kenntnisse einrichten?

Ja. Verstehe das Konzept und gib dann deiner KI die Anweisung: „Aktiviere Row-Level Security auf jeder Tabelle, mit Policies für Ansehen, Anlegen, Ändern und Löschen, begrenzt auf die Organisation des Nutzers.“ Prüfe dann mit zwei Testaccounts, die versuchen, gegenseitig ihre Daten zu lesen. Die KI schreibt die Policies; die Checkliste gehört dir.

Macht RLS mein Produkt langsamer?

Nicht nennenswert, wenn deine Tabellen richtig eingerichtet sind — der Schlüssel ist ein Index auf der Organisationsspalte, die die Policies prüfen (etwas, das in die festen Anweisungen deiner KI gehört). Plattformen mit Tausenden geschützten Tabellen laufen genau nach diesem Muster; FIKR Space betreibt 964 davon.