Row-Level Security (RLS)

Row-Level Security (RLS) ist eine Zugriffskontrolle auf Zeilenebene: Sie sorgt dafür, dass eine Nutzerin bei der Abfrage einer Tabelle nur die Zeilen zu sehen bekommt, die für sie freigegeben sind. Die Regel wird als Filter (auch Row Filter oder Row Access Policy genannt) direkt an der Tabelle hinterlegt und greift bei jeder Abfrage automatisch. Die Daten in der Tabelle bleiben unverändert; das Ergebnis der Abfrage ist einfach kürzer.

Was ist Row-Level Security?

Row-Level Security ist eine Regel, die pro Nutzerin entscheidet, welche Zeilen einer Tabelle im Ergebnis erscheinen. Ein Beispiel: Eine Vertriebs-Tabelle enthält Bestellungen aus DACH, UK und US. Ohne RLS sieht jede Person mit Leserecht alle Zeilen. Mit RLS wird an die Tabelle eine Filterfunktion gebunden, die zur Abfragezeit prüft, wer gerade fragt (etwa über die eingeloggte Identität und ihre Gruppen-Zugehörigkeit) und liefert nur die passenden Regionen-Zeilen zurück. Die Filterfunktion ist ein kleines Stück SQL-Code (eine sogenannte User-Defined Function, kurz UDF), das Kontextinformationen wie den eingeloggten Nutzer oder seine Gruppen-Mitgliedschaft einbezieht.

Der Mechanismus existiert seit Ende der 1990er Jahre. Oracle führte mit der Virtual Private Database (VPD) in Oracle 8i (1999) einen frühen kommerziellen Standard ein, der Filter-Prädikate zur Abfragezeit an eine Tabelle anhängt. Microsoft SQL Server erhielt Row-Level Security 2016 als eigenes Sprachkonstrukt (CREATE SECURITY POLICY mit Predicate Functions). PostgreSQL brachte im selben Jahr Row Security Policies mit Version 9.5 (CREATE POLICY). Snowflake führte Row Access Policies 2021 ein, Databricks Unity Catalog Row Filters 2023. SAP HANA realisiert das Muster über Analytic Privileges.

Der Grund für ein eigenes Konstrukt ist die Zentralisierung der Filterlogik. Ohne RLS entstehen dieselben Regeln als View-per-Rolle oder als Filter im BI-Semantic-Layer; jede neue Tabelle, jede neue Rolle und jede Änderung der Sichtbarkeitsregel muss an mehreren Stellen nachgezogen werden. Die Regel bindet den Filter an das Tabellenobjekt selbst und wirkt damit für jeden Zugriffsweg gleich: SQL-Warehouse-Queries, Notebooks, JDBC/ODBC-Verbindungen und BI-Tools sehen dieselbe gefilterte Ergebnismenge.

In modernen Datenplattformen ist RLS die typische Umsetzungsstelle einer attributbasierten Sichtbarkeitsregel. Ein Aufrufer hat über RBAC das Basisrecht SELECT auf die Tabelle; erst der Row Filter entscheidet, welche Zeilen des Ergebnisses zurückgegeben werden. Damit koexistiert RLS mit dem Rollen- und Grant-Modell des Katalogs und ersetzt es nicht.

Abgrenzung zu Column-Level Security, RBAC, ABAC und Views

Row-Level Security wird häufig mit verwandten Mechanismen verwechselt, weil alle den Zugriff auf Tabellen einschränken. Die Modelle unterscheiden sich in der Wirkungsebene und der Entscheidungsbasis.

RLS vs. Column-Level Security: Column Masking transformiert einzelne Spaltenwerte einer weiterhin sichtbaren Zeile (etwa Hash oder Redaction einer E-Mail-Spalte). RLS entscheidet, ob die Zeile überhaupt im Ergebnis erscheint. Beide Konzepte kombinieren sich häufig auf derselben Tabelle: ein Row Filter für die Mandantenlogik, mehrere Column Masks für PII-Spalten.

RLS vs. RBAC: RBAC bindet Berechtigungen an Rollen und erteilt Grants auf Objekte. Die Entscheidung „darf diese Rolle die Tabelle lesen" endet an der Tabellengrenze. RLS ergänzt das Modell feingranular auf Zeilenebene und ist selbst kein Zugriffskontrollmodell im engeren Sinn.

RLS vs. ABAC: ABAC ist ein Modell auf Policy-Ebene, das Zugriffsentscheidungen aus Attributen des Subjekts, des Objekts, der Aktion und des Umgebungskontexts ableitet. Row-Level Security ist die typische Umsetzungsstelle einer ABAC-Policy im Datenbereich: eine Policy formuliert die Regel („DACH-Analysten sehen DACH-Zeilen"), ein Row Filter setzt sie an der Tabelle um.

RLS vs. View mit Filter: Eine View mit statischer WHERE-Klausel bindet keine Nutzeridentität ein und wirkt für alle Zugriffe gleich, die die View benutzen. Row-Level Security wertet den Aufrufer-Kontext dynamisch aus und wirkt direkt an der Basistabelle; jede Abfrage wird gefiltert, unabhängig davon, ob eine View dazwischenliegt.

Beispiel: Mandantenfilter in Databricks Unity Catalog

Ein Datenteam eines mittelständischen Handelsunternehmens betreibt eine Tabelle sales.orders mit Bestelldaten aus mehreren Regionen. Die Analyse-Gruppen grp-dach, grp-uk und grp-us sollen jeweils nur die Zeilen ihrer Region sehen; die Gruppe grp-compliance sieht alle Zeilen. Ohne Row-Level Security würde das Team drei getrennte Views anlegen und die BI-Tools an unterschiedliche Objekte binden. Mit einem Row Filter bleibt eine einzige Tabelle bestehen, an die eine Filterfunktion gebunden wird.

CREATE OR REPLACE FUNCTION governance.region_filter(region STRING)
RETURNS BOOLEAN
RETURN
  is_account_group_member('grp-compliance')
  OR (is_account_group_member('grp-dach') AND region = 'DACH')
  OR (is_account_group_member('grp-uk')   AND region = 'UK')
  OR (is_account_group_member('grp-us')   AND region = 'US');

ALTER TABLE sales.orders
  SET ROW FILTER governance.region_filter ON (region);

Ab der Bindung greift die Regel für jede Abfrage auf sales.orders. Ein SQL-Warehouse-Query, ein Notebook-Join, ein Power-BI-Report und ein JDBC-Zugriff aus einem Python-Job sehen dieselbe gefilterte Ergebnismenge. Die Tabelle behält Namen, Schema und Ownership; kein zusätzliches View-Objekt wird eingeführt. Wechselt eine Analystin von grp-uk nach grp-dach, ändert sich ihre sichtbare Zeilenmenge über die Gruppen-Mitgliedschaft im Identity Provider; die Filterfunktion bleibt unverändert.

Der Wirkungsbereich hängt an der Qualität der Referenzdaten. Fehlt einer Zeile die Region oder ist der Wert falsch belegt, greift der Filter unerwartet: die Zeile ist entweder für alle unsichtbar oder für alle sichtbar, je nach Formulierung der Regel. Row-Level Security setzt deshalb aktives Datenmanagement für die Filter-Attribute voraus.