Was ist Sicherheit auf Zeilenebene (RLS)?
Row-Level Security (RLS) dient dazu, einzuschränken, welche Zeilen einzelne Benutzer oder Rollen aus einer Datenbank abrufen können – und hilft so dabei, Dateneinschränkungen innerhalb gemeinsam genutzter Tabellen auf der Grundlage von Identität, Rolle oder kontextbezogenen Attributen durchzusetzen, ohne dass Daten dupliziert werden.
Die wichtigsten Erkenntnisse
Datenzugriff in großem Maßstab kontrollieren
Row-Level Security wurde entwickelt, um den Datenzugriff auf Datensatzebene durchzusetzen – und ermöglicht so eine fein abgestufte Steuerung über gemeinsam genutzte Plattformen hinweg, ohne dass Schemaänderungen, Datenduplikate oder die Verwendung von benutzerdefinierten Abfragefiltern erforderlich sind.
Definition von „Row-Level Security“ (RLS): RLS hilft dabei, einzuschränken, welche Zeilen ein Benutzer oder eine Rolle aus einer Datenbank abrufen darf – und ermöglicht so eine fein abgestufte Datenisolierung innerhalb gemeinsam genutzter Tabellen, ohne dass Datensätze dupliziert oder Schemata umstrukturiert werden müssen.
Entscheidend für die Compliance: DSGVO, HIPAA, CCPA und PCI DSS verlangen nachweisbare Zugriffskontrollen auf Datensatzebene. RLS ist darauf ausgelegt, den Zugriff bereits bei der Abfrage durchzusetzen und die Ergebnisse automatisch auf autorisierte Datensätze zu beschränken.
Native vs. zentralisierte Ansätze: Einige Datenbanken bieten native Kontrollen auf Zeilenebene – doch deren Verwaltung in großem Maßstab über mehrere Datenspeicher hinweg kann zu einer unübersichtlichen Vielzahl von Richtlinien, Wartungsaufwand und Transparenzlücken führen.
Richtliniengesteuert und identitätsorientiert: Modernes RLS verknüpft Zugriffsentscheidungen mit Attributen von Identitätsanbietern – und ermöglicht so dynamische, kontextbezogene Kontrollen, die auf Änderungen bei Benutzern, Gruppen und Attributen reagieren, ohne dass Schemaänderungen erforderlich sind.
Plattformübergreifende zentrale Verwaltung: Eine zentrale Sicherheitsebene hilft dabei, Richtlinien auf Zeilenebene konsistent über Data Warehouses, Cloud-Datenbanken und Data Lakes hinweg anzuwenden – über eine einzige Richtlinien-Engine statt über datenbankbezogene Konfigurationen.
Keine sicheren Ansichten erforderlich: Plattformbasiertes RLS trägt dazu bei, die Abhängigkeit von sicheren Ansichten zu verringern – wodurch Nachteile bei der Abfrageoptimierung beseitigt werden und gleichzeitig ausgefeiltere Kontrollen ermöglicht werden, die Zeilen- und Spaltenbeschränkungen in einer Richtlinie kombinieren.
Risk der Datenoffenlegung
Warum Sicherheit auf Zeilenebene wichtig ist
Datenpannen kosten Unternehmen im Jahr 2025 durchschnittlich 4,44 Millionen US-Dollar – und ein zu weitreichender Datenzugriff ist nach wie vor eine der Ursachen. RLS hilft dabei, die Lücke zwischen dem, worauf Benutzer zugreifen können, und dem, worauf sie zugreifen sollten, zu schließen, indem es Beschränkungen auf Datensatzebene durchsetzt, bevor unbefugte Daten die Datenbank überhaupt verlassen.
Wie setzt RLS das Prinzip des „Least Privilege“-Zugriffs durch?
In Unternehmen, in denen mehrere Teams, Regionen oder Geschäftsbereiche Datenplattformen gemeinsam nutzen, sind Berechtigungen auf Tabellenebene oft zu grob gefasst. RLS wurde entwickelt, um den Zugriff nach dem Prinzip der geringsten Berechtigung auf Datensatzebene durchzusetzen, sodass:
- Ein regionales Vertriebsteam nur die Datensätze seines Gebiets abfragen kann.
- Ein Gesundheitsdienstleister nur die Datensätze seiner Patienten einsehen kann.
- Ein Analyst nur die Zeilen abrufen kann, zu denen ihn seine Rolle berechtigt.
Diese Granularität trägt dazu bei, die Auswirkungen einer Kompromittierung von Anmeldedaten zu begrenzen und die Offenlegung interner Daten zu verhindern – und das ohne Schemaänderungen oder Datenduplizierung.
Wie hilft RLS bei der Erfüllung von Compliance-Anforderungen?
DSGVO, HIPAA, CCPA und PCI DSS verlangen nachweisbare Kontrollen darüber, welche Benutzer auf personenbezogene und sensible Datensätze zugreifen dürfen. RLS unterstützt die Durchsetzung bereits bei der Abfrage – indem die Ergebnisse automatisch auf autorisierte Datensätze beschränkt werden – und hilft dabei, die von den Aufsichtsbehörden geforderten Nachweise im Prüfpfad zu generieren. Unternehmen in den Bereichen Finanzdienstleistungen, Gesundheitswesen und Unternehmensdatenumgebungen können sich auf RLS verlassen, um ihre Compliance-Situation aufrechtzuerhalten, ohne Daten umstrukturieren oder sensible Datensätze replizieren zu müssen.
Wie lässt sich RLS in Umgebungen mit mehreren Datenspeichern skalieren?
Die meisten Unternehmen verwalten Daten plattformübergreifend, wobei jede Plattform über eine eigene RLS-Implementierung verfügt. Native Kontrollen funktionieren in der Regel innerhalb einer einzelnen Plattform, führen jedoch zu einer Fragmentierung der Richtlinien über verschiedene Umgebungen hinweg. Eine zentralisierte Sicherheitsebene ist darauf ausgelegt, einheitliche Zugriffsrichtlinien auf Zeilenebene über den gesamten Datenspeicher hinweg von einem einzigen Kontrollpunkt aus anzuwenden – dies trägt dazu bei, den Wartungsaufwand zu reduzieren und die Compliance-Situation auch bei der Weiterentwicklung der Dateninfrastruktur aufrechtzuerhalten.
Grundlegende Konzepte
So funktioniert Sicherheit auf Zeilenebene
RLS hilft dabei, Abfrageergebnisse einzuschränken, indem es Zugriffsbedingungen zur Laufzeit auswertet – also Zeilen basierend auf der Identität, Rolle oder den Attributen des anfragenden Benutzers filtert –, bevor Ergebnisse zurückgegeben werden. Die Implementierungen reichen von nativen Datenbankmechanismen bis hin zu zentralisierten Richtlinienebenen, die konsistent über mehrere Datenplattformen hinweg angewendet werden.
Explizite und implizite Zeilenfilterung
RLS wird in zwei grundlegenden Modi implementiert: explizit und implizit. Bei der expliziten Durchsetzung müssen Benutzer in jede Abfrage Filterbedingungen einfügen – wodurch die Einhaltung der Richtlinien vom Benutzerverhalten abhängt und ein Risk entsteht, wenn Filter weggelassen werden. Bei der impliziten Durchsetzung erfolgt die Filterung automatisch über sichere Ansichten, Zeilenzugriffsrichtlinien oder eine Plattform-Sicherheitsschicht – sodass Benutzer nur die Zeilen erhalten, auf die sie Zugriffsberechtigung haben, unabhängig davon, wie die Abfrage formuliert ist.
Die implizite Durchsetzung ist der Standard für Produktionsumgebungen, die eine zuverlässige und überprüfbare Zugriffskontrolle erfordern.
Snowflake-Zugriffsrichtlinien für Zeilen
Snowflake implementiert RLS über Zeilenzugriffsrichtlinien (Row Access Policies, RAPs) – Objekte auf Schemaebene, die einmalig erstellt und einer oder mehreren Tabellen oder Ansichten zugeordnet werden. Zum Zeitpunkt der Abfrage hüllt Snowflake das geschützte Objekt in eine dynamische sichere Ansicht ein, gleicht den Richtlinieninhalt mit den tatsächlichen Zeilenwerten ab und gibt nur die Zeilen zurück, bei denen der Ausdruck TRUE ist. RAPs erfordern die Enterprise Edition oder höher und werden mit der Rolle des Richtlinieninhabers ausgeführt – nicht mit der Rolle des abfragenden Benutzers –, was dazu beiträgt, eine Rechteausweitung zu verhindern. RAPs lassen sich mit dynamischer Datenmaskierung kombinieren, um einen gleichzeitigen Schutz auf Zeilen- und Spaltenebene für dieselbe Tabelle zu ermöglichen.
Zentralisiertes, plattformübergreifendes RLS
Native RLS-Mechanismen – sichere Ansichten, Zeilenzugriffsrichtlinien, virtuelle private Datenbanken – mögen innerhalb eines einzelnen Datenspeichers effektiv sein, können jedoch in plattformübergreifenden Umgebungen zu Fragmentierung führen. Eine zentralisierte Sicherheitsebene ermöglicht die Anwendung von Richtlinien auf Zeilenebene in allen Datenspeichern über eine einzige Richtlinien-Engine hinweg, wobei Attribute von Identitätsanbietern wie Okta oder anderen Identitätsanbietern genutzt werden, um Zugriffsentscheidungen dynamisch zu treffen. Dies verringert die Notwendigkeit, Zuordnungen zwischen Benutzern und Zeilen in jeder Datenbank zu replizieren, und trägt zu einer konsistenten Durchsetzung bei, unabhängig davon, welche Datenplattform abgefragt wird.
In der Praxis
Anwendungsfälle für Row-Level Security
Unternehmen aus den Bereichen Finanzdienstleistungen, Gesundheitswesen und Unternehmensanalytik können RLS einsetzen, um Datengrenzen durchzusetzen, sensible Datensätze zu schützen und regulatorische Anforderungen in gemeinsam genutzten und mandantenfähigen Datenumgebungen zu erfüllen.
Regionale Datenisolierung für Vertrieb und Analytik
Finanzinstitute, die Vertriebsdaten, Kundenkontodaten und Transaktionshistorien verwalten, sollten den Zugriff nach Geschäftsbereich, Region oder Rolle einschränken, ohne gemeinsam genutzte Datenplattformen umstrukturieren zu müssen. RLS wurde entwickelt, um Datengrenzen zum Zeitpunkt der Abfrage durchzusetzen – so können Analysten und Vertriebsmitarbeiter nur die Datensätze abrufen, zu denen ihre Rolle sie berechtigt. Außerdem unterstützt es Compliance-Teams dabei, Prüfpfade für die Anforderungen der DSGVO, des CCPA und des PCI DSS zu führen, ohne sensible Datensätze in mehreren eingeschränkten Kopien zu duplizieren.
Zugriff auf Patientenakten nach Anbieter und Abteilung
Gesundheitsorganisationen, die elektronische Patientenakten verwalten, sollten HIPAA-konforme Zugriffskontrollen durchsetzen – damit Ärzte nur auf die Akten ihrer eigenen Patienten zugreifen, Abteilungen nur relevante Fälle einsehen und Forscher nur anonymisierte Daten erhalten. RLS hilft dabei, diese Grenzen zum Zeitpunkt der Abfrage durchzusetzen, ohne dass für jede Zugriffsebene separate Datenkopien erforderlich sind. In Kombination mit der Datenmaskierung auf Spaltenebene ermöglicht RLS die Durchführung von Analysen und KI-Workloads an Produktionsdaten, ohne die Privatsphäre der Patienten oder die HIPAA-Verpflichtungen zu gefährden.
Sicherer Datenaustausch in Multi-Tenant-Umgebungen und teamübergreifend
Unternehmensdatenplattformen, die mehrere Geschäftsbereiche, externe Partner oder mandantenfähige Workloads bedienen, erfordern in der Regel Garantien zur Datenisolierung innerhalb einer gemeinsam genutzten Infrastruktur. RLS hilft dabei, jeden Mandanten, jedes Team oder jeden Partner auf autorisierte Datensätze innerhalb gemeinsam genutzter Tabellen zu beschränken, wodurch doppelte Datensätze und die physische Trennung von Daten reduziert werden. Eine zentralisierte Sicherheitsebene sorgt dafür, dass diese Richtlinien bei der Skalierung der Plattform konsistent über Data Warehouses und Cloud-Data-Lakes hinweg angewendet werden.
Häufig gestellte Fragen
Was ist Sicherheit auf Zeilenebene (RLS)?
RLS ist eine Methode zur Datenzugriffskontrolle, die darauf ausgelegt ist, basierend auf Bedingungen, die an die Identität, die Rolle oder kontextbezogene Attribute des Anfragenden geknüpft sind, einzuschränken, welche Zeilen ein Benutzer, eine Rolle oder eine Gruppe aus einer Datenbanktabelle abrufen darf. Im Gegensatz zu Berechtigungen auf Tabellenebene hilft RLS dabei, Zugriffsbeschränkungen auf der Ebene einzelner Datensätze durchzusetzen, sodass verschiedene Benutzer, die dieselbe Tabelle abfragen, je nach ihrer Berechtigung unterschiedliche Teilmengen von Zeilen erhalten. Dies kann eine zentrale Funktion für die Datenisolierung in gemeinsam genutzten Plattformen, mandantenfähigen Umgebungen und regulierten Daten-Workloads sein.
Was ist der Unterschied zwischen Sicherheit auf Zeilenebene und Sicherheit auf Spaltenebene?
Die Sicherheit auf Zeilenebene dient dazu, einzuschränken, welche Datensätze ein Benutzer aus einer Tabelle abrufen kann – wobei die Ergebnisse basierend auf Identität oder Rolle gefiltert werden. Die Sicherheit auf Spaltenebene (Datenmaskierung) hilft dabei, einzuschränken, welche Felder innerhalb dieser Datensätze der Benutzer sehen kann, indem sensible Werte für nicht autorisierte Benutzer ausgeblendet oder unkenntlich gemacht werden. Die beiden Mechanismen ergänzen sich: RLS hilft bei der Steuerung des Zugriffs auf Datensatzebene, während die Sicherheit auf Spaltenebene die Sichtbarkeit auf Feldebene innerhalb der Datensätze steuert, auf die der Benutzer zugreifen darf. Viele Unternehmen setzen beide Mechanismen gleichzeitig ein, um in regulierten Umgebungen einen mehrschichtigen Datenschutz zu gewährleisten.
Wie setzt Snowflake RLS um?
Snowflake stellt RLS über Row Access Policies (RAPs) bereit – Objekte auf Schemaebene, die in der Enterprise Edition oder höher verfügbar sind. Jede RAP definiert einen booleschen Ausdruck; zum Zeitpunkt der Abfrage hüllt Snowflake das geschützte Objekt in eine dynamische sichere Ansicht ein, wertet den Richtlinienkörper aus und gibt nur die Zeilen zurück, bei denen der Ausdruck TRUE ist. RAPs werden mit der Rolle des Richtlinieninhabers ausgeführt, nicht mit der Rolle des abfragenden Benutzers, was dazu beiträgt, eine Privilegieneskalation zu verhindern. RAPs sind über mehrere Tabellen hinweg wiederverwendbar und lassen sich mit Dynamic Data Masking kombinieren, um gleichzeitig Schutz auf Zeilen- und Spaltenebene in derselben Tabelle zu gewährleisten.
Was sind die Einschränkungen von nativem RLS im großen Maßstab?
Native RLS-Mechanismen sind in der Regel innerhalb ihrer jeweiligen Plattformen effektiv, können jedoch in Umgebungen mit mehreren Datenspeichern zu einer Fragmentierung der Richtlinien führen. Jeder Datenspeicher erfordert eine eigene Richtlinienkonfiguration und -pflege. Ansätze mit sicheren Ansichten führen zu Einbußen bei der Abfrageoptimierung. Zuordnungen von Rollen zu Zeilen sollten bei Änderungen am Identitätsanbieter synchronisiert bleiben. In Umgebungen mit mehreren Datenspeichern oder einer großen Anzahl von Rollen kann die konsistente Wartung von nativem RLS über den gesamten Datenstack hinweg betrieblich komplex werden.
Wie unterstützt Commvault RLS?
Die Daten- und KI-Sicherheitsfunktionen von Commvault ermöglichen eine zentralisierte Durchsetzung von RLS über mehrere Datenspeicher hinweg – einschließlich Cloud-Data-Warehouses, lokaler Datenbanken und Data Lakes – über eine einzige Richtlinienebene. Richtlinien auf Zeilenebene nutzen Identitätsattribute von verbundenen Identitätsanbietern wie Okta und ermöglichen so dynamische, attributbasierte Zugriffsentscheidungen, ohne dass eine Synchronisierung der Datenbankrollen erforderlich ist. Die Richtlinien gelten einheitlich über alle Datenplattformen in der Umgebung hinweg, mit Protokollierung von Zugriffsereignissen und automatischer Klassifizierung, um festzustellen, welche Zeilen sensible Daten enthalten.
Wie unterstützt RLS die Einhaltung gesetzlicher Vorschriften?
DSGVO, HIPAA, CCPA und PCI DSS verlangen nachweisbare Kontrollen darüber, welche Benutzer auf personenbezogene Daten, Gesundheitsdaten und Finanzdaten zugreifen dürfen. RLS wurde entwickelt, um die Einhaltung von Vorschriften direkt zu unterstützen, indem es dabei hilft, Zugriffsbeschränkungen bereits zum Zeitpunkt der Abfrage durchzusetzen – sodass unbefugte Benutzer keine Datensätze erhalten, auf die sie keinen Zugriff haben sollten, und zwar automatisch und ohne auf vom Benutzer angewandte Abfragefilter angewiesen zu sein. Umfassende Audit-Protokolle zu Zugriffsereignissen helfen dabei, zu erfassen, wer wann welche Daten abgefragt hat, um die von Prüfern benötigten Nachweise zu liefern und den Aufwand für die Compliance-Berichterstattung zu reduzieren.
Verwandte Ressource
Commvault – Daten- und KI-Sicherheit
Datenklassifizierung
Identity and Access Management (IAM)
