Was ist Sicherheit auf Zeilenebene?

Row-Level Security (RLS) ist eine Datenbank-Zugriffskontrolle, die einschränkt, welche Zeilen einer Tabelle ein Benutzer basierend auf seiner Identität, Rolle oder dem Sitzungskontext lesen oder ändern kann.

Anstatt den Zugriff auf ganze Tabellen oder bestimmte Spalten zu beschränken, filtert RLS Daten Zeile für Zeile. Die Datenbank-Engine wendet den Filter automatisch zum Abfragezeitpunkt an, sodass dieselbe Regel gilt, unabhängig davon, welches Tool der Benutzer für den Zugriff auf die Daten verwendet.

RLS ist Teil der feingranularen Zugriffskontrolle, zusammen mit:

• Sicherheit auf Spaltenebene
• Datenmaskierung
• Berechtigungen auf Tabellenebene

Beispielsweise kann ein Vertriebsmitarbeiter die Bestelltabelle des Unternehmens abfragen, sieht aber nur die Bestellungen für seine zugewiesene Region, obwohl die Tabelle die Daten aller Regionen enthält. Der Benutzer schreibt eine normale SELECT-Anweisung, und die Engine gibt nur die Zeilen zurück, die er sehen darf.

RLS ist heute ein zentraler Baustein für mandantenfähige SaaS, regionale Datentrennung und Compliance-Anwendungsfälle. Dieser Artikel beschreibt, wie RLS funktioniert, wo es hilft, wo es an seine Grenzen stößt und wie es auf der Databricks-Plattform funktioniert.

Wie funktioniert Row-Level Security?

Row-Level Security funktioniert, indem eine Filterregel, oft als Richtlinie (Policy) oder Prädikat bezeichnet, auf eine Tabelle angewendet wird. Wenn ein Benutzer eine Abfrage ausführt, wendet die Datenbank-Engine diesen Filter automatisch an und gibt nur die Zeilen zurück, die der Benutzer sehen darf.

In der Praxis funktioniert RLS in der Regel in drei Schritten:

1. Der Benutzer führt eine Abfrage aus: Der Benutzer schreibt eine Standardabfrage, ohne selbst Sicherheitsfilter hinzuzufügen.
2. Die Datenbank überprüft die Identität des Benutzers: Die Engine wertet den Benutzer über eine integrierte Funktion wie CURRENT_USER, eine von der Anwendung festgelegte Sitzungsvariable oder eine Zuordnungstabelle aus, die Benutzer und Gruppen mit den zulässigen Daten verknüpft.
3. Die Engine filtert das Ergebnis: Das RLS-Prädikat gibt TRUE für Zeilen zurück, die der Benutzer sehen kann, und FALSE für alles andere. Es werden nur Zeilen zurückgegeben, die das Prädikat erfüllen.

Da die Durchsetzung auf Datenbankebene erfolgt, gilt dieselbe Regel konsistent für jeden Zugriffspfad, einschließlich BI-Dashboards, Notebooks, Ad-hoc-SQL, APIs und Drittanbieter-Tools. Diese Konsistenz macht RLS so leistungsstark: Eine Regel, überall angewendet, von der Engine durchgesetzt.

Die meisten Engines unterscheiden auch zwischen der Durchsetzung auf Lese- und Schreibseite. Ein Lese-Prädikat steuert, was eine SELECT-Abfrage zurückgibt. Ein Schreib-Prädikat, das oft separat mit einer WITH CHECK-Klausel definiert wird, steuert, welche Zeilen ein Benutzer einfügen, aktualisieren oder löschen kann.

Die beiden Prädikate können identisch sein, müssen es aber nicht. Beispielsweise darf ein Benutzer möglicherweise Zeilen für jede Region lesen, aber nur Zeilen für seine eigene Region einfügen. Die Definition beider Seiten ist wichtig, wenn eine Tabelle Schreibvorgänge zulässt, da das Auslassen der Schreibprüfung eine der häufigsten Fehlkonfigurationen von RLS in Produktionsumgebungen ist.

Row-Level Security vs. Column-Level Security und andere Zugriffskontrollen

RLS ist eine von mehreren feingranularen Zugriffskontrollen und wird in der Produktion fast immer mit anderen kombiniert. Die folgende Tabelle zeigt, wie die einzelnen Kontrollen ineinandergreifen.

Diese Kontrollen sind so konzipiert, dass sie übereinandergelegt werden können. Ein typisches Setup verwendet Berechtigungen auf Tabellenebene, um zu steuern, wer auf eine Tabelle zugreifen kann, RLS, um festzulegen, welche Zeilen sichtbar sind, und Column-Level Security oder Datenmaskierung, um sensible Felder innerhalb dieser Zeilen zu schützen. Sie als Stack statt als Auswahl einzelner Alternativen zu betrachten, macht die Governance sowohl auditierbar als auch resilient. Eine Fehlkonfiguration in einer Ebene gefährdet nicht die anderen.

Häufige Anwendungsfälle für Row-Level Security

RLS ist die Standardmethode, um durchzusetzen, wer was in einer freigegebenen Tabelle sehen kann, indem Zeilen basierend auf den Attributen eines Benutzers mit einer Schlüsselspalte wie Region, Mandant oder Klassifizierung abgeglichen und gefiltert werden. Die meisten Teams nutzen diese Methode, wenn ein einzelner Datensatz für mehrere Zielgruppen mit unterschiedlichen Sichtbarkeitsregeln bereitgestellt werden muss.

• Mandantenfähiges SaaS: Isolieren Sie die Daten jedes Kunden in gemeinsam genutzten Tabellen mithilfe einer tenant_id-Spalte und des Sitzungskontexts. Dies vermeidet die Betriebskosten für ein Schema oder eine Datenbank pro Mandant, während die Daten jedes Kunden zum Abfragezeitpunkt vollständig getrennt bleiben.
• Regionale Datentrennung: Schränken Sie Vertriebs-, HR- oder Bestelldaten so ein, dass Benutzer nur Datensätze für ihr Land oder ihre Region sehen, ohne die zugrunde liegende Tabelle geografisch aufzuteilen.
• Abteilungsbezogener Zugriff: Geben Sie Finanz-, Marketing- und Betriebsteams Zugriff auf dieselbe Tabelle, aber auf unterschiedliche Zeilen, die über eine Abteilungs- oder Kostenstellen-Spalte zugeordnet werden.
• Einhaltung gesetzlicher Vorschriften (Compliance): Setzen Sie Regeln zur Datenresidenz durch, indem Sie beispielsweise EU-Datensätze gemäß GDPR nur für in der EU ansässige Mitarbeiter sichtbar machen oder geschützte Kategorien gemäß HIPAA, CCPA oder branchenspezifischen Vorschriften einschränken.
• Gesundheitswesen und klinische Daten: Ermöglichen Sie es Klinikern, eine Patiententabelle gemeinsam zu nutzen, während sie nur ihre eigenen Patienten sehen. Dies unterstützt den minimal erforderlichen Zugriff gemäß HIPAA, ohne Datensätze über Silos hinweg zu duplizieren.
• Partner- und Lieferantenportale: Teilen Sie einen einzelnen Datensatz mit externen Partnern, während Sie die Ansicht für jeden Partner auf seine eigenen Datensätze filtern. So kann eine einzige Source-of-Truth-Tabelle Dutzende von partnerseitigen Ansichten speisen.

So implementieren Sie Row-Level Security: 4 Schritte

Das allgemeine Muster ist plattformübergreifend konsistent, wobei bei Bedarf herstellerspezifische Syntax ergänzt wird.

1. Filterlogik identifizieren: Entscheiden Sie, was den Zugriff bestimmt: Benutzer-ID, Gruppenmitgliedschaft, Region, Mandanten-ID oder eine Zuordnungstabelle. Die Filterlogik sollte aus dem Sitzungskontext oder einer stabilen Lookup-Tabelle ableitbar sein, nicht aus Werten, die der Benutzer zum Abfragezeitpunkt steuert.
2. Schlüsselspalte hinzufügen oder bestätigen: Stellen Sie sicher, dass die Tabelle eine Spalte enthält, die der Filter verwenden kann, wie z. B. tenant_id, region oder owner_id. Wenn noch keine solche Spalte vorhanden ist, planen Sie einen Backfill, bevor die Richtlinie live geht, und erwägen Sie, die Spalte zu indizieren, um das Prädikat ressourcenschonend zu halten.
3. Richtlinie oder Zeilenfilter definieren: Schreiben Sie das Prädikat, das TRUE für Zeilen zurückgibt, die der Benutzer sehen darf, und eine separate Prüfung für Schreibvorgänge, falls die Tabelle diese zulässt. Halten Sie die Logik nach Möglichkeit in SQL. Die meisten Engines optimieren SQL-Prädikate besser als Funktionsaufrufe in andere Sprachen.
4. Mit mehreren Benutzeridentitäten testen: Führen Sie Abfragen als verschiedene Rollen aus und bestätigen Sie, dass die richtigen Zeilen angezeigt werden und keine Daten mandantenübergreifend offengelegt werden. Fügen Sie einen Negativtest hinzu: Ein Benutzer ohne übereinstimmende Zeilen sollte ein leeres Ergebnis sehen, keinen Fehler, und ein privilegierter Benutzer sollte separat getestet werden, um das Owner-Bypass-Verhalten zu bestätigen.

Vorteile von Row-Level Security

Die Verlagerung der Zugriffslogik in die Datenebene zahlt sich in mehrfacher Hinsicht aus. Kurz gesagt: Die Datenbank wird zur Source of Truth für den Zugriff, anstatt jede Anwendung, die mit den Daten arbeitet.

• Zentralisierte Logik: Zugriffsregeln liegen direkt bei den Daten und sind nicht über den Anwendungscode oder BI-Tools verstreut.
• Konsistente Durchsetzung: Es gilt dieselbe Regel, unabhängig davon, ob ein Benutzer eine Abfrage über ein Notebook, ein Dashboard oder eine API ausführt.
• Defense in Depth: RLS bietet eine zusätzliche Schutzebene, falls Prüfungen auf Anwendungsebene umgangen werden oder fehlerhaft sind.
• Einfacherer Anwendungscode: Entwickler müssen nicht in jeder Abfrage manuell WHERE-Klauseln anhängen.
• Einfachere Audits: Compliance-Teams können eine einzige Richtlinie überprüfen, anstatt die Zugriffslogik über verschiedene Systeme hinweg nachzuverfolgen.

Einschränkungen und Risiken der Sicherheit auf Zeilenebene

RLS ist leistungsstark, bringt jedoch bekannte Fallstricke mit sich, die Teams einplanen sollten. Die meisten davon treten erst in der Produktion oder bei einem Audit auf, weshalb man sie im Vorfeld kennen sollte.

Umgehung durch Admins und Eigentümer

In vielen Datenbanken umgehen Tabelleneigentümer und Admins mit hohen Berechtigungen RLS standardmäßig. PostgreSQL erfordert beispielsweise die Einstellung FORCE ROW LEVEL SECURITY, um Richtlinien auf den Tabelleneigentümer anzuwenden, und ähnliche Einstellungen gibt es auch in anderen Engines. Dies ist ein häufiges Ergebnis bei Audits: Gehen Sie davon aus, dass privilegierte Benutzer jede Zeile sehen können, es sei denn, Ihre Konfiguration erzwingt die Anwendung der Richtlinie explizit auch für sie. Testen Sie die Richtlinie in einer privilegierten Sitzung und nicht nur in einer normalen, bevor Sie sie freigeben.

Keine Ausblendung von Spalten oder Zusammenfassungen

RLS filtert Zeilen, blendet jedoch keine Spalten aus und blockiert keine aggregierten Ergebnisse. Ein Analyst, der keine einzelnen EU-Datensätze sehen darf, kann dennoch SELECT COUNT(*) auf der ungefilterten Tabelle ausführen, wenn RLS nicht mit Spalten- oder Aggregationsbeschränkungen kombiniert wird. Kombinieren Sie RLS mit Sicherheit auf Spaltenebene oder Datenmaskierung, um diese Lücke zu schließen, und prüfen Sie, ob Aggregationsabfragen für besonders sensible Tabellen selbst reguliert werden müssen.

Performance-Overhead

Auf jede Abfrage wird das RLS-Prädikat angewendet, was die Performance beeinträchtigen kann, wenn die Filterlogik komplex oder die Schlüsselspalte nicht indiziert ist. Indizieren Sie die Spalten, auf die sich die Richtlinie bezieht, und halten Sie das Prädikat so einfach wie möglich. Bevorzugen Sie einfache CASE-Ausdrücke gegenüber Unterabfragen oder Zuordnungstabellen-Lookups innerhalb des Filters. Wenn die Engine dies unterstützt, materialisieren Sie die Benutzer-zu-Zeilen-Zuordnung in einer kleinen, gut indizierten Tabelle, anstatt sie direkt zur Laufzeit zu berechnen.

Komplexität beim Debugging

Leere Ergebnismengen, die durch RLS verursacht werden, sehen genauso aus wie „keine übereinstimmenden Daten“. Entwickler, die nach einer fehlenden Zeile suchen, verbringen oft Stunden, bevor sie merken, dass die Richtlinie sie herausgefiltert hat. Protokollieren Sie während der Entwicklung die effektive Benutzeridentität und die Richtlinienversion, geben Sie Engineers eine Möglichkeit zu prüfen, ob RLS aktiv ist, wenn die Ergebnisse fehlerhaft erscheinen, und dokumentieren Sie die Richtlinie am selben Ort wie das Tabellenschema, damit sie auffindbar ist.

Fehlkonfigurierte Schreibregeln

RLS-Richtlinien haben oft zwei Seiten: eine USING-Klausel, die filtert, was Benutzer lesen können, und eine WITH CHECK-Klausel, die steuert, was sie einfügen oder aktualisieren können. Die eine ohne die andere zu definieren, ist ein klassischer Fehler: Ein Lesefilter ohne Schreibprüfung ermöglicht es Benutzern, Zeilen einzufügen oder zu aktualisieren, die sie eigentlich nicht besitzen sollten. Definieren Sie immer beide Seiten, wenn die Tabelle Schreibvorgänge zulässt, und führen Sie im Rahmen der Richtlinienprüfung einen Test auf Schreibseite durch.

Sicherheit auf Zeilenebene auf der Databricks-Plattform

Auf der Databricks-Plattform wird die Sicherheit auf Zeilenebene über Zeilenfilter in Unity Catalog verwaltet, der einheitlichen Governance-Ebene von Databricks für Daten und KI. Das Muster ist einfach: Definieren Sie eine benutzerdefinierte SQL-Funktion, die für die Zeilen, die ein bestimmter Benutzer sehen darf, „true“ zurückgibt, und weisen Sie diese dann der Zieltabelle zu. Der Filter wird automatisch zur Abfragezeit ausgeführt und nutzt die Identität oder den Sitzungskontext des aktuellen Benutzers, um zu bestimmen, welche Zeilen zurückgegeben werden sollen.

Zeilenfilter werden konsistent über Databricks SQL, Notebooks, Jobs und verbundene BI-Tools hinweg erzwungen, ohne dass eine benutzerdefinierte Logik pro Oberfläche erforderlich ist. Sie arbeiten zusammen mit Spaltenmasken für eine umfassende, feingranulare Zugriffskontrolle, und jede Abfrage, die eine gefilterte Tabelle betrifft, wird in den Lineage- und Audit-Protokollen von Unity Catalog erfasst. So können Governance- und Sicherheitsteams genau sehen, welche Richtlinien für welche Tabellen gelten und welche Benutzer was abgefragt haben.

Häufig gestellte Fragen

Was ist dynamische Sicherheit auf Zeilenebene? Dynamische RLS wertet die Zugriffsregel zur Abfragezeit anhand der Identität oder des Sitzungskontexts des aktuellen Benutzers aus, sodass dieselbe Richtlinie für verschiedene Benutzer unterschiedliche Ergebnisse liefert. Alle modernen RLS-Implementierungen funktionieren auf diese Weise, einschließlich der ABAC-Richtlinien, Zeilenfilter und dynamischen Ansichten von Databricks.

Was ist der Unterschied zwischen Sicherheit auf Zeilenebene und Sicherheit auf Spaltenebene? RLS schränkt ein, welche Zeilen ein Benutzer sehen kann; Sicherheit auf Spaltenebene schränkt die Spalten ein, typischerweise um sensible Felder wie Gehalt oder Sozialversicherungsnummern auszublenden. Die meisten Produktionsumgebungen nutzen beide Ansätze zusammen.

Reicht die Sicherheit auf Zeilenebene allein aus, um sensible Daten zu schützen? Nein. RLS regelt die Sichtbarkeit von Zeilen, maskiert jedoch keine Spaltenwerte, blockiert keine Aggregationsabfragen und ersetzt kein Identitäts- und Zugriffsmanagement. Kombinieren Sie sie mit Sicherheit auf Spaltenebene, Berechtigungen auf Tabellenebene und Audit-Protokollierung als Teil einer Defense-in-Depth-Strategie.

Wie implementiert Databricks die Sicherheit auf Zeilenebene? Über Unity Catalog mit drei Optionen: ABAC-Richtlinien, Zeilenfilter auf Tabellenebene und dynamische Ansichten. ABAC wird für Governance im großen Stil empfohlen; Zeilenfilter und dynamische Ansichten stehen für speziellere Anforderungen zur Verfügung.

Beeinträchtigt die Sicherheit auf Zeilenebene die Abfrage-Performance? Ja, aber die Auswirkungen sind in der Regel überschaubar. Halten Sie die Richtlinienlogik einfach, indizieren Sie die Spalten, auf die sich die Richtlinie bezieht, und bevorzugen Sie SQL-UDFs gegenüber Python-UDFs. Analysieren Sie Abfragen vor und nach Richtlinienänderungen, um Performance-Einbußen frühzeitig zu erkennen.

Erste Schritte mit feingranularer Zugriffskontrolle auf Databricks

Sicherheit auf Zeilenebene ist am effektivsten als Teil eines umfassenderen Governance-Modells, das auch Spalten, Maskierung, Lineage und Audits abdeckt. Erfahren Sie, wie Unity Catalog Sicherheit auf Zeilenebene, Spaltenmaskierung und einheitliche Governance auf der Databricks-Plattform zusammenführt.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag