SQL Server 2012: Zugriffsberechtigung abhängig vom Wert einer Spalte???

[sx2008]

Du kannst einen View anlegen in dem alle Datensätze die der User nicht sehen soll per WHERE-Bedingung ausgefiltert werden.
Der User bekommt nur Zugriff auf den View, nicht aber auf die dahinterliegende Tabelle.

[romber]

Vielen Dank!

[romber]

Ich habe nun das Problem, dass ich in die View nichts hinzufügen kann, ohne die Rechte für den User auf die Tabelle zu setzen.
Mache ich etwas falsch?

[generic]

Aus der Doku:

Zitat:

Modify Data Through a View

Permissions
Requires UPDATE, INSERT, or DELETE permissions on the target table, depending on the action being performed.

[Bernhard Geyer]

Bei so hoher Granularität der nötigen Zugriffsrechte solltest du dir eine Mehrschichtarchitektur überlegen.
Die DBMS sind nicht dafür gedacht so genau die Zugriffsrechte zu vergeben.

[jobo]

Zitat von Bernhard Geyer:

Bei so hoher Granularität der nötigen Zugriffsrechte solltest du dir eine Mehrschichtarchitektur überlegen.
Die DBMS sind nicht dafür gedacht so genau die Zugriffsrechte zu vergeben.

Das sehe ich nicht so. Was nimmt die Zwischenschicht Dir da ab? Und was, wenn mehrere Systeme mit der DB arbeiten? DBServer sind genau dafür gedacht, es gibt schon länger Berechtigungsverfahren auf Feldebene, die das Problem des TE direkt lösen. Das kostet u.U. extra bzw. ist leider nicht unbedingt standardisiert.

Code:

GRANT SELECT[,UPDATE,..] ON dbo.[myTable] (Field01, Field03, Field17) TO <user|role>;

Im Sinne der Aufgaben eines DBServers ist die Verwendung sogar empfehlenswert, besonders(?) im Mehrschichtumfeld. Die einzige Möglichkeit, Missbrauch oder Fehlzugriff, -Programmierung systematisch zu verhindern, liegt auf DB Server Seite.
Und:
Auch wenn für die Lösung des Problems evtl. gar kein View gebraucht wird, sollte die Verwendung gerade hier eine Selbstverständlichkeit sein. Ja, man muss eine oder zwei Zeilen mehr für das Create und das Grant schreiben, aber man hat dadurch ein klares Interface.
Wenn man dann noch gegen Rollen granted, statt gegen User um so besser.

[Furtbichler]

Was macht denn der Server, wenn ich bestimmte Spalten der Query nicht sehen darf? Schlägt dann die ganze Query fehl oder werden stattdessen NULL-Werte übergeben?

Wenn ersteres der Fall ist, müsste man ja bei vielen Aufgaben in der Mittelschicht die Queries individuell zusammenbauen, wobei dann ja irgendwie der Sinn dieser im Server angesiedelten Rechtevergabe nicht gegeben ist.

[Bernhard Geyer]

Zitat von jobo:

Zitat von Bernhard Geyer:

Bei so hoher Granularität der nötigen Zugriffsrechte solltest du dir eine Mehrschichtarchitektur überlegen.
Die DBMS sind nicht dafür gedacht so genau die Zugriffsrechte zu vergeben.

Das sehe ich nicht so. Was nimmt die Zwischenschicht Dir da ab? Und was, wenn mehrere Systeme mit der DB arbeiten?

I.d.R. wird immer nur die SW von einem Hersteller auf der DB arbeiten. Und diese bietet dann ein API zum Zugriff an. Ein direkter Zugriff von "Hilfsanwendungen" wird nicht unterstützt (Garantie/Gewährleistung/Support).

Zitat von jobo:

DBServer sind genau dafür gedacht, es gibt schon länger Berechtigungsverfahren auf Feldebene, die das Problem des TE direkt lösen. Das kostet u.U. extra bzw. ist leider nicht unbedingt standardisiert.

Code:

GRANT SELECT[,UPDATE,..] ON dbo.[myTable] (Field01, Field03, Field17) TO <user|role>;

Hast du die Problemstellung gelesen? Dein GRAND-Befehl löst sein Problem nicht vollständig, da die Sicherheit maximal auf Spaltenebene erfolgt. Er braucht es aber auf Zellenebene!

Fragestellung: Wie willst du die eigentliche Anforderung per Grand-Befehl genau abbilden? Gibt doch das vollständige Beispiel für die Fragestellung an.