Was ist zeilenbasierte Sicherheit (RLS)?

Zeilenbasierte Sicherheit ist ein Datenbankmechanismus, bei dem Policies bei jeder Abfrage filtern, welche Zeilen jemand sehen oder ändern darf. Das mentale Modell ist eine erzwungene, unsichtbare WHERE-Klausel: Die Bedingung, an die Sie sonst in jeder Abfrage denken müssten, wird zu einer Eigenschaft der Tabelle selbst – angewendet von der Engine, auf jedem Zugriffspfad, auch auf denen, die Ihr Anwendungscode nie zu sehen bekommt.

Das Wichtigste in Kürze

RLS in zehn Zeilen SQL

CREATE TABLE invoices (
  tenant_id uuid NOT NULL,
  total     numeric(10,2)
);

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;   -- ab hier: standardmäßig verboten

CREATE POLICY tenant_isolation ON invoices
  USING      (tenant_id = current_setting('app.tenant')::uuid)   -- was Sie lesen dürfen
  WITH CHECK (tenant_id = current_setting('app.tenant')::uuid);  -- was Sie schreiben dürfen

-- Jede Abfrage verhält sich nun so, als endete sie mit WHERE tenant_id = <Ihrer>.
-- Eine Abfrage, die ihren Filter vergisst, liefert nichts – nicht alles.

Dieselbe Garantie existiert in Dokumentdatenbanken als Zugriffskontrolle auf der Zeile selbst – jedes Objekt trägt seine ACL, und die Plattform setzt sie bei jeder Anfrage durch:

// JavaScript / Node.js — Back4app JS SDK
// Row-level security as data: this row is readable by its owner, period
const note = new Parse.Object('Note');
note.set('text', 'Q3 salary planning');
note.setACL(new Parse.ACL(Parse.User.current())); // owner-only, on the row itself
await note.save();

// Later, any query by any user — the row exists only for its owner
const notes = await new Parse.Query('Note').find(); // others never see it

// Flutter / Dart — Back4app Flutter SDK
// Row-level security as data: this row is readable by its owner, period
final user = await ParseUser.currentUser() as ParseUser;
final acl = ParseACL(owner: user); // owner-only, on the row itself

final note = ParseObject('Note')
  ..set('text', 'Q3 salary planning')
  ..setACL(acl);
await note.save(); // other users' queries never return this row

// iOS / Swift — Back4app Swift SDK
// Row-level security as data: this row is readable by its owner, period
var note = Note()
note.text = "Q3 salary planning"
note.ACL = try ParseACL.defaultACL() // owner-only, on the row itself
note.save { result in
  if case .success = result {
    print("saved — other users' queries never return this row")
  }
}

// Android / Kotlin — Back4app Android SDK
// Row-level security as data: this row is readable by its owner, period
val note = ParseObject("Note").apply {
  put("text", "Q3 salary planning")
  acl = ParseACL(ParseUser.getCurrentUser()) // owner-only, on the row itself
}
note.saveInBackground { e ->
  if (e == null) Log.d("Notes", "saved — invisible to every other user")
}

Was die Engine aus einer Abfrage macht

USING vs. WITH CHECK, permissiv vs. restriktiv

Zwei Kompositionsregeln aus der PostgreSQL-Referenz lohnen sich zu merken: Wer WITH CHECK weglässt, verwendet USING auch für Schreibzugriffe, und mindestens eine permissive Policy muss passen, bevor die restriktiven überhaupt herangezogen werden – nur restriktive Policies heißt: niemand kommt herein.

Wo RLS unterstützt wird

Die letzte Zeile ist die, um die es in diesem Glossar geht: In Dokumentspeichern ist die Grenze auf Zeilenebene typischerweise ein Datum auf der Zeile (die ACL) statt ein Prädikat in der Engine – dieselbe Garantie, anderer Mechanismus, ausführlich beschrieben im Engineering-Beitrag von Back4app.

Die Fallstricke, endlich an einem Ort

• Überraschungen durch Default-Deny. RLS ohne Policy zu aktivieren sperrt alle außer dem Eigentümer aus – die Hälfte aller “RLS hat die Produktion lahmgelegt”-Geschichten ist genau das.
• Die Umgehungsmatrix. Superuser, BYPASSRLS-Rollen und Tabelleneigentümer überspringen Policies – setzen Sie FORCE ROW LEVEL SECURITY, wenn der Eigentümer zugleich der Benutzer der Anwendung ist, und auditieren Sie, wer was hält.
• Views laufen standardmäßig mit den Rechten ihres Eigentümers – ein View auf eine RLS-Tabelle kann sie still umgehen, sofern er nicht mit den Rechten des Aufrufers erstellt wurde (security_invoker in PostgreSQL).
• Constraints verraten Existenz. Die Verletzung einer Unique- oder Fremdschlüssel-Constraint kann offenbaren, dass eine unsichtbare Zeile existiert – der dokumentierte verdeckte Kanal; behandeln Sie Eindeutigkeit auf geschützten Werten entsprechend.
• Fehler können Werte verraten. Gezielt gebaute Ausdrücke, die bei bestimmten Daten fehlschlagen (eine Division durch null, wenn ein verborgener Wert passt), schleusen Informationen über Fehlermeldungen aus – die Klasse von Seitenkanälen, die die SQL-Server-Dokumentation beschreibt.
• Dumps und Pools haben Modi. Backup-Werkzeuge brauchen unter Umständen die abgeschaltete Zeilensicherheit, um alles zu exportieren; Pooler im Transaktionsmodus brauchen einen transaktionsweiten Kontext (SET LOCAL), sonst färben Tenants von Anfrage zu Anfrage ab.

Performance: Policies sind Code auf dem heißen Pfad

Drei Regeln decken den Großteil der Praxiserfahrung ab: Indizieren Sie jede Spalte, auf die eine Policy verweist (das Prädikat läuft vor den eigenen Filtern Ihrer Abfrage – ohne Index ist es ein voller Table Scan); halten Sie Prädikate frei von Joins, indem Sie das Nachschlagen in Funktionen oder Rollenprüfungen verlagern; und sorgen Sie dafür, dass Funktionen pro Anfrage einmal pro Abfrage ausgewertet werden, nicht einmal pro Zeile, indem Sie sie in eine skalare Unterabfrage kapseln. Sauber gemessen kostet RLS einstellige Prozentwerte; schlecht gemessen ist es die rätselhafte Verlangsamung auf jeder Tabelle, die Sie abgesichert haben.

Typische Anwendungsfälle

• Multi-Tenant-SaaS. Der kanonische Fall – Tenant-Isolation unterhalb der Anwendung durchgesetzt, dort, wo ein vergessener Filter kein Datenleck werden kann.
• Daten pro Benutzer. Nachrichten, Dokumente, Gesundheitsakten: Benutzer sehen ihre Zeilen, mehr nicht.
• Abteilungs- und Regionsgrenzen. Der Vertrieb sieht seine Region; Prüfer sehen alles, nur lesend – Policy-Schichtung in Aktion.
• Compliance-Anforderungen. Zugriffskontrolle, die sich auf der Datenschicht nachweisen lässt – genau dort, wo Prüfer sie sehen wollen.
• Geteilter analytischer Zugriff. Analysten fragen Produktionsreplikate direkt ab und sehen nur, was ihre Rolle erlaubt – sicher, weil die Datenbank es durchsetzt, nicht das Dashboard.

Sollten Sie auf Zeilenebene durchsetzen? Entscheidungsmatrix

Die ehrliche Zusammenfassung beider Spalten: Behalten Sie die Eingrenzung in der Anwendung, weil sie den Code lesbar hält – und setzen Sie sie trotzdem in der Datenbank durch. Mehrschichtige Verteidigung ist genau der Punkt.

Grenzen und Trade-offs

• Policies sind von Natur aus unsichtbar – was das Debuggen von “wo sind meine Zeilen hin?” zu einer echten Fertigkeit macht; protokollieren Sie zuerst den Session-Kontext.
• Komplexe Autorisierung sprengt Prädikate. Regeln, die Workflow-Zustand oder entitätsübergreifende Logik brauchen, gehören in die Autorisierungsschicht der Anwendung, mit RLS als Auffangnetz.
• Die operative Oberfläche ist real. Umgehungsmatrix, Dump-Modi und Pooling-Kontext sind fortlaufendes Betriebswissen, keine einmalige Einrichtung.
• Die Auswertung pro Zeile ist eine Steuer – gering, wenn sauber konstruiert, unbegrenzt, wenn nicht.
• Sie sichert Zeilen, nicht Spalten. Felder zu verbergen ist Sicherheit auf Spaltenebene; kombinieren Sie beides für eine Wirkung auf Zellebene.

Zeilenbasierte Sicherheit mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Das Modell auf Zeilenebene ist der ACL-als-Daten-Mechanismus aus den Tabs oben: Jedes Objekt trägt seine Zugriffsliste, Rollen bilden Tenants und Teams ab, und die Plattform setzt beides bei jeder Anfrage durch – SDKs, REST, GraphQL und das Dashboard inklusive, mit Klassenberechtigungen als restriktiver Schicht darüber. Es ist die Garantie der erzwungenen WHERE-Klausel, geliefert auf einer Dokumentdatenbank, mit der obigen Fallstrickliste von der Plattform absorbiert statt Ihnen aufgebürdet.