MSSQL Row Level Security (RLS) ohne Schema Binding?
Mahlzeit.
Ich habe ein konkretes Projekt wo ich Daten aus anderen Datenbanken, in denen ich nur lesen darf, dem Benutzer in einer Auswertungsdatenbank zugänglich machen will. Konkret sind das Zeiterfassungsdaten in einer View in der jeder nur Daten von sich selbst sehen soll. Perfekt um RLS auszuprobieren, dachte ich.
RLS scheint noch relativ neu, ich kann es auch erst seit dem Kauf des aktuellen MSSQL nutzen. Die Beiträge im Netz beschränken sich immer wieder auf das Wesentliche:
https://learn.microsoft.com/de-de/sql/relational-databases/security/row- ...
https://blog.netwrix.com/2019/06/27/how-to-implement-row-and-column-leve ...
Grundsätzlich lässt sich RLS auf Views anwenden, allerdings setzt RLS zwingend SCHEMABINDING voraus, was in meinem konkreten Fall natürlich nicht geht (ich herrsche nur über die Auswertungsdatenbank). Ich finde nichts im Netz dazu ob man das irgendwie abschalten oder "ignorieren" lassen kann. Ich meine der Benutzer selbst hat natürlich nicht das Recht die View anzupassen, damit sähe ich das ohne Schema Binding gar nicht als Sicherheitsproblem.
An dieser Stelle mal die Frage ob sich hier irgendjemand schon mit RLS in irgendeiner Form befasst hat oder vielleicht mal was zu dem Punkt Schema Binding gelesen hat. Vielleicht hat auch jemand einen anderen Lösungsansatz für mich.
Ich habe mir jetzt erstmal einen eigenen Lösungsweg gebastelt: Dabei verwende ich eine Tabelle Users, die in der Auswertungsdatenbank liegt. Diese Tabelle muss ich in Intervallen aus der eigentlichen Quelle aktualisieren. Auf diese wende ich RLS an, jeder sieht also nur seinen eigenen Datensatz in der einen statischen Tabelle. Alle Views auf die eigentlichen Daten der Quelle machen immer einen INNER JOIN mit dieser Tabelle - das funktioniert soweit wie gedacht.
Eigentlich finde ich den Weg auch sinnig, ich bin aber absolut noch nicht mit Dingen wie RLS vertraut. Da ich das an weiteren Stellen im Controlling verwenden möchte, gibt es einen besseren Weg?
Ich habe ein konkretes Projekt wo ich Daten aus anderen Datenbanken, in denen ich nur lesen darf, dem Benutzer in einer Auswertungsdatenbank zugänglich machen will. Konkret sind das Zeiterfassungsdaten in einer View in der jeder nur Daten von sich selbst sehen soll. Perfekt um RLS auszuprobieren, dachte ich.
RLS scheint noch relativ neu, ich kann es auch erst seit dem Kauf des aktuellen MSSQL nutzen. Die Beiträge im Netz beschränken sich immer wieder auf das Wesentliche:
https://learn.microsoft.com/de-de/sql/relational-databases/security/row- ...
https://blog.netwrix.com/2019/06/27/how-to-implement-row-and-column-leve ...
Grundsätzlich lässt sich RLS auf Views anwenden, allerdings setzt RLS zwingend SCHEMABINDING voraus, was in meinem konkreten Fall natürlich nicht geht (ich herrsche nur über die Auswertungsdatenbank). Ich finde nichts im Netz dazu ob man das irgendwie abschalten oder "ignorieren" lassen kann. Ich meine der Benutzer selbst hat natürlich nicht das Recht die View anzupassen, damit sähe ich das ohne Schema Binding gar nicht als Sicherheitsproblem.
An dieser Stelle mal die Frage ob sich hier irgendjemand schon mit RLS in irgendeiner Form befasst hat oder vielleicht mal was zu dem Punkt Schema Binding gelesen hat. Vielleicht hat auch jemand einen anderen Lösungsansatz für mich.
Ich habe mir jetzt erstmal einen eigenen Lösungsweg gebastelt: Dabei verwende ich eine Tabelle Users, die in der Auswertungsdatenbank liegt. Diese Tabelle muss ich in Intervallen aus der eigentlichen Quelle aktualisieren. Auf diese wende ich RLS an, jeder sieht also nur seinen eigenen Datensatz in der einen statischen Tabelle. Alle Views auf die eigentlichen Daten der Quelle machen immer einen INNER JOIN mit dieser Tabelle - das funktioniert soweit wie gedacht.
Eigentlich finde ich den Weg auch sinnig, ich bin aber absolut noch nicht mit Dingen wie RLS vertraut. Da ich das an weiteren Stellen im Controlling verwenden möchte, gibt es einen besseren Weg?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6922683529
Url: https://administrator.de/contentid/6922683529
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Grundsätzlich lässt sich RLS auf Views anwenden, allerdings setzt RLS zwingend SCHEMABINDING voraus, was in meinem konkreten Fall natürlich nicht geht (ich herrsche nur über die Auswertungsdatenbank).
SCHEMABINDING wird seitens SQL Server in Verbindung mit Views erzwungen. Hingegen bei Select Abfragen ist es optional.Vielleicht hat auch jemand einen anderen Lösungsansatz für mich.
Leider nein. Wir lassen es durch die DBAs einrichten. Gruß,
Dani
Moin,
dein aktueller Weg ist meines Erachtens auch der beste Weg.
Schemabinding ist leider nicht optional und legt Stolpersteine - für andere :D
Hast du eine View mit Schemabinding, sind enthaltene Objekte (Tabellen bzw. in der Query verwendete Spalten, Funktionen, Views) für Änderungen gesperrt.
Die Fehlermeldung ist dann etwas in der Art von "Änderung fehlgeschlagen weil eines oder mehrere Objekte auf die Spalte zugreifen".
RLS hat einen nicht unerheblichen Impact auf die Performance (Ausführungspläne ohne / mit RLS vergleichen).
Gruß
Grinskeks
dein aktueller Weg ist meines Erachtens auch der beste Weg.
Schemabinding ist leider nicht optional und legt Stolpersteine - für andere :D
Hast du eine View mit Schemabinding, sind enthaltene Objekte (Tabellen bzw. in der Query verwendete Spalten, Funktionen, Views) für Änderungen gesperrt.
Die Fehlermeldung ist dann etwas in der Art von "Änderung fehlgeschlagen weil eines oder mehrere Objekte auf die Spalte zugreifen".
RLS hat einen nicht unerheblichen Impact auf die Performance (Ausführungspläne ohne / mit RLS vergleichen).
Gruß
Grinskeks
Ich muss mich korrigieren:
Wenn die Policy mit Schemabinding = Off definiert ist, können auch die beteiligten Funktionen und Views ohne Schemabinding erzeugt werden.
Das hat aber auch einige Nachteile.
Dazu zählt unter anderem auch, dass Select und Execute Rechte für die zugreifenden User explizit für relational verwendete Objekte gecheckt werden, was bei Schemabinding = On ignoriert wird.
Administrativer Albtraum trifft es ganz gut.
Gruß
Grinskeks
Wenn die Policy mit Schemabinding = Off definiert ist, können auch die beteiligten Funktionen und Views ohne Schemabinding erzeugt werden.
Das hat aber auch einige Nachteile.
Dazu zählt unter anderem auch, dass Select und Execute Rechte für die zugreifenden User explizit für relational verwendete Objekte gecheckt werden, was bei Schemabinding = On ignoriert wird.
Administrativer Albtraum trifft es ganz gut.
Gruß
Grinskeks