Richtlinien für Sicherheit auf Zeilenebene
Zeilen automatisch nach Benutzer filtern
Richtlinien für Sicherheit auf Zeilenebene ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.
Was ist Row-Level Security?
Row-Level Security (RLS) ist eine PostgreSQL-Funktion, mit der Sie steuern können, welche Zeilen einer Tabelle ein bestimmter Datenbankbenutzer oder eine bestimmte Rolle sehen oder ändern darf. Statt Zeilen in jeder Abfrage zu filtern, definieren Sie eine Richtlinie einmal, und PostgreSQL setzt sie automatisch bei jedem SELECT, INSERT, UPDATE und DELETE durch.
Stellen Sie sich dies als unsichtbare WHERE-Klausel vor, die an die Tabelle selbst statt an eine bestimmte Abfrage angehängt ist.
RLS für eine Tabelle aktivieren
RLS ist standardmäßig deaktiviert. Sie müssen es für jede Tabelle ausdrücklich mit ALTER TABLE ... ENABLE ROW LEVEL SECURITY aktivieren. Nach der Aktivierung sehen Rollen, die nicht Eigentümer der Tabelle sind, keine Zeilen, bis mindestens eine Richtlinie erstellt wurde.
-- Create a sample table
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
owner TEXT NOT NULL,
amount NUMERIC(10,2)
);
-- Enable RLS
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;Ihre erste Richtlinie erstellen
Eine Richtlinie wird mit CREATE POLICY erstellt. Sie geben ihr einen Namen, legen die Tabelle fest und stellen einen USING-Ausdruck bereit. Die USING-Klausel ist ein boolescher Ausdruck, der für jede Zeile ausgewertet wird — nur Zeilen, für die der Ausdruck TRUE ergibt, sind für den Benutzer sichtbar.
-- Allow each user to see only their own orders
CREATE POLICY orders_owner_policy
ON orders
FOR SELECT
USING (owner = current_user);Die Klauseln USING vs. WITH CHECK
Policies verfügen über zwei Filterklauseln mit unterschiedlichen Zwecken:
- USING — filtert Zeilen bei Leseoperationen (SELECT, UPDATE, DELETE). Eine Zeile ist nur sichtbar, wenn USING TRUE zurückgibt.
- WITH CHECK — validiert Zeilen bei Schreiboperationen (INSERT, UPDATE). Ein Schreibvorgang ist nur zulässig, wenn WITH CHECK TRUE zurückgibt. Wird die Klausel weggelassen, wird USING für die Schreibprüfungen wiederverwendet.
-- Allow users to select and insert only their own rows
CREATE POLICY orders_isolation
ON orders
FOR ALL
USING (owner = current_user)
WITH CHECK (owner = current_user);Geltungsbereich einer Policy: FOR SELECT, INSERT, UPDATE, DELETE
Eine einzelne Policy kann alle Befehle abdecken (FOR ALL) oder einen bestimmten Befehl. Wenn Sie Policies nach Befehl trennen, erhalten Sie eine fein abgestufte Kontrolle — beispielsweise können Sie allen Benutzern das Lesen aller Zeilen erlauben, aber nur Änderungen an ihren eigenen Zeilen.
-- Everyone can read all orders
CREATE POLICY read_all_orders
ON orders
FOR SELECT
USING (true);
-- But each user can only update their own orders
CREATE POLICY update_own_orders
ON orders
FOR UPDATE
USING (owner = current_user)
WITH CHECK (owner = current_user);session_user und current_user verwenden
PostgreSQL stellt integrierte Funktionen bereit, mit denen Sie den aktiven Benutzer innerhalb eines Policy-Ausdrucks ermitteln können:
- current_user — die Rolle, deren Berechtigungen derzeit aktiv sind (kann sich nach SET ROLE ändern).
- session_user — die Rolle, die die Verbindung geöffnet hat (ändert sich während der Sitzung nie).
Die meisten RLS-Policies verwenden current_user, da dieser Wert die effektive Rolle nach einem Rollenwechsel widerspiegelt.
-- Inspect the current identity inside a query
SELECT current_user, session_user;RLS auf bestimmte Rollen anwenden
Standardmäßig gilt eine Policy für PUBLIC (alle Rollen). Mit der Klausel TO können Sie sie auf eine bestimmte Rolle beschränken. Das ist nützlich, wenn Sie eine Policy für normale Benutzer und eine andere für eine Administratorrolle verwenden möchten.
-- Policy only for the 'app_user' role
CREATE POLICY app_user_policy
ON orders
FOR SELECT
TO app_user
USING (owner = current_user);
-- Separate permissive policy for 'admin' role
CREATE POLICY admin_full_access
ON orders
FOR ALL
TO admin
USING (true)
WITH CHECK (true);Permissive vs. Restrictive Policies
Mehrere Policies für dieselbe Tabelle können auf zwei Arten zusammenwirken:
- PERMISSIVE (Standard) — alle permissiven Policies werden mit OR verknüpft. Eine Zeile ist zugänglich, wenn eine beliebige permissive Policy den Zugriff erlaubt.
- RESTRICTIVE — restriktive Policies werden mit dem Ergebnis der permissiven Policies per AND verknüpft. Eine Zeile ist nur zugänglich, wenn sie die restriktive Policy erfüllt und mindestens eine permissive Policy den Zugriff erlaubt.
-- Restrictive policy: block access to archived orders for everyone
CREATE POLICY no_archived_rows
ON orders
AS RESTRICTIVE
FOR SELECT
USING (amount > 0);RLS umgehen: BYPASSRLS und Tabellenbesitzer
Der Tabellenbesitzer und Superuser umgehen RLS standardmäßig und sehen immer alle Zeilen. Sie können einer Rolle das Attribut BYPASSRLS gewähren, wenn sie uneingeschränkten Zugriff benötigt, ohne Superuser zu sein. Umgekehrt können Sie den Besitzer mit FORCE ROW LEVEL SECURITY zwingen, RLS zu befolgen.
-- Force the table owner to also obey RLS policies
ALTER TABLE orders FORCE ROW LEVEL SECURITY;
-- Grant BYPASSRLS to a trusted service account
ALTER ROLE service_account BYPASSRLS;Policies ändern und entfernen
Sie können eine vorhandene Policy mit ALTER POLICY aktualisieren oder sie mit DROP POLICY vollständig entfernen. Wenn Sie alle Policies entfernen, während RLS weiterhin aktiviert ist, sind für Rollen, die nicht Eigentümer sind, keine Zeilen zugänglich. Um RLS vollständig zu entfernen, deaktivieren Sie es mit ALTER TABLE.
-- Rename a policy
ALTER POLICY orders_owner_policy ON orders
RENAME TO user_isolation_policy;
-- Update the USING expression
ALTER POLICY user_isolation_policy ON orders
USING (owner = current_user AND amount >= 0);
-- Remove a policy
DROP POLICY admin_full_access ON orders;
-- Disable RLS entirely on the table
ALTER TABLE orders DISABLE ROW LEVEL SECURITY;Praxisbeispiel: Isolation von Mandantendaten
Ein verbreitetes RLS-Muster in Multi-Tenant-SaaS-Anwendungen besteht darin, in jeder Tabelle eine Spalte tenant_id zu speichern und eine Sitzungsvariable (set_config) zu verwenden, um die Mandantenkennung beim Verbindungsaufbau zu übergeben. Die Policy vergleicht dann die tenant_id jeder Zeile mit diesem Wert.
-- Table with tenant isolation column
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
tenant_id TEXT NOT NULL,
title TEXT
);
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
-- Policy reads the tenant from a session variable
CREATE POLICY tenant_isolation
ON documents
FOR ALL
USING (tenant_id = current_setting('app.tenant_id'))
WITH CHECK (tenant_id = current_setting('app.tenant_id'));
-- Application sets the variable before running queries
SELECT set_config('app.tenant_id', 'tenant_42', true);
-- Now only tenant_42 documents are visible
SELECT * FROM documents;Wissenscheck
Testen Sie Ihr Verständnis von Row-Level-Security-Policies in PostgreSQL.
Lektionszusammenfassung
In dieser Lektion haben Sie gelernt, wie Row-Level Security eine automatische, Policy-gesteuerte Filterung von Zeilen direkt auf Datenbankebene ermöglicht:
- RLS aktivieren Sie auf einer Tabelle mit ALTER TABLE ... ENABLE ROW LEVEL SECURITY.
- Verwenden Sie CREATE POLICY mit einer USING-Klausel, um lesbare Zeilen zu filtern, und einer WITH-CHECK-Klausel, um geschriebene Zeilen zu validieren.
- Beschränken Sie Policies mit der TO-Klausel auf bestimmte Befehle (SELECT, INSERT, UPDATE, DELETE, ALL) und bestimmte Rollen.
- Kombinieren Sie PERMISSIVE-Policies (OR-Logik) und RESTRICTIVE-Policies (AND-Logik) für eine mehrstufige Zugriffskontrolle.
- Tabellenbesitzer und Superuser umgehen RLS standardmäßig; verwenden Sie FORCE ROW LEVEL SECURITY, um dieses Verhalten zu überschreiben.
- Das Multi-Tenant-Muster mit current_setting() ist eine leistungsfähige praktische Anwendung von RLS.
RLS ist der Standardweg, um die Isolation von Daten sauber und konsistent zu erzwingen, ohne WHERE-Klauseln über jede einzelne Abfrage der Anwendung zu verteilen.
Häufig gestellte Fragen
Ist die Lektion „Richtlinien für Sicherheit auf Zeilenebene“ kostenlos?
Ja — der vollständige Text von „Richtlinien für Sicherheit auf Zeilenebene“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Richtlinien für Sicherheit auf Zeilenebene“?
Zeilen automatisch nach Benutzer filtern Du übst SQL Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um SQL Academy zu starten?
Keine Vorkenntnisse erforderlich. SQL Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „Richtlinien für Sicherheit auf Zeilenebene“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser SQL Academy-Lektion Code schreiben und ausführen?
Ja. Jede SQL Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Rollen und Berechtigungen
- Richtlinien für Sicherheit auf Zeilenebene
- Berechtigungen auf Spaltenebene
- Zugriffe prüfen