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

[romber]

Hallo!

Besteht eine Möglichkeit, einem SQL-Server-Benutzer die Tabellenrechte so zu einzuschränken, dass er nur auf die Datensätze Zugriff hat, die einen bestimmten Wert in einer bestimmten Spalte dieser Tabelle haben?

Z.B. es gibt TABELLE_1, auf die der SQL_USER_1 aktuell Zugriffsrechte hat. In der TABELLE_1 gibt es eine Spalte, die Standartmässig leer ist. SQL_USER_1 soll nur auf die Datensätze zugreifen können, die eine Wert in der Spalte haben. Alle anderen Datensätze sollen für den SQL_USER_1 gesperrt/unsichtbar bleiben.

Danke!

[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:

Zitat von Bernhard Geyer (Beitrag 1230632)

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:

Zitat von jobo (Beitrag 1230706)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230632)

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:

Zitat von jobo (Beitrag 1230706)

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.

[jobo]

@ Bernhard: Ok, da hab ich etwas geschlampt, die eigentliche Antwort hat ja bereits generic geliefert. Man benötigt Grant Angaben für den View.
Der View ermöglicht die spaltenabhängige Filterung und löst das Problem.
Meine Aussage zu der Spaltenberechtigungen, die darüber hinaus direkt auf Tabellenebene möglich sind, ist lediglich eine Entgeegnung zu Deiner Aussage, dass DB dafür (".. so hohe Granularität der Zugriffsrechte..") nicht gemacht sein sollen.
Zugriffs-API, Lizenzbestimmungen und Herstellergarantie sind natürlich zu berücksichtigen, wenn man ein System gekauft hat. Ob das die Regel ist, wage ich zu bezweifeln. Es gibt sicher genügend Firmen, die selbst (eigenverantwortlich) Datenhaltung und Verarbeitung betreiben und volle Hoheit darüber haben. Auch Standardsoftwarehersteller haben anwendungsintern die Problemstellung, Zugriffssicherheit zu bewerkstelligen. Ein wasserdichtes Datenmodell ist auch da der beste Weg.
@Furtbichler: Die Wahrung der definierten Rechte ist genau eine der Hauptaufgaben eines DB Servers. Er muss es garantieren (können, ob der Entwickler es nutzt ist eine andere Frage), dazu sind die Berechtigungsverfahren einer professionellen DB ja da und zwar vollkommen unabhängig davon, wer wie darauf zugreift. Mir ist nicht klar, warum das Konzept, dass es tabellenseitig (oder View, oder Stored Procedure) gibt, auf Spaltenebene nicht geben sollte. Das Argument, die Zugriffsschicht muss dann erhöhten Aufwand treiben, ist die logische Konsequenz der Anforderung, aber kein Gegenargument. (Wasch mich, aber mach mich nicht nass?)
Standardfall: Wird programtisch ein Update auf eine Tabelle ausgeführt, für das keine Erlaubnis besteht, muss die Zugriffsschicht ja auch damit klar kommen, sprich der Programmierer entsprechende Maßnahmen ergreifen.

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1230714)

@ Bernhard: Ok, da hab ich etwas geschlampt, die eigentliche Antwort hat ja bereits generic geliefert. Man benötigt Grant Angaben für den View.
Der View ermöglicht die spaltenabhängige Filterung und löst das Problem.

Lesen schon, aber wie ist es mit dem schreiben wenn er nur entsprechende Datensätze auch schreiben darf?

Zitat:

Zitat von jobo (Beitrag 1230714)

Meine Aussage zu der Spaltenberechtigungen, die darüber hinaus direkt auf Tabellenebene möglich sind, ist lediglich eine Entgeegnung zu Deiner Aussage, dass DB dafür (".. so hohe Granularität der Zugriffsrechte..") nicht gemacht sein sollen.

Die Aussage bezieht sich auch die obige Notwendigkeit Rechte entsprechend auf Zellenwerte zu vergeben. Da kommt man mit Grants nicht weit.
Und der Alttag (ERP und PLM's zeigens) ist ja das man die so auch benötigt.
Sachbearbeiter A darf nur Stammdaten bearbeiten die im Bereich Elektrik liegen
Sachbearbeiter B darf keine Stücklisten bearbeiten welche freigegeben sind, dies müssen dann von Sachbearbeiter C als neue Version wieder in den Zustand "in Arbeit" gesetzt werden.
Wie würden hier GRANDs auf Datenbankebene aussehen?

Zitat:

Zitat von jobo (Beitrag 1230714)

Zugriffs-API, Lizenzbestimmungen und Herstellergarantie sind natürlich zu berücksichtigen, wenn man ein System gekauft hat. Ob das die Regel ist, wage ich zu bezweifeln.

Ich nicht. Bei SAP-Installationen wirst du oft nur direkten Tabellenzugriff (als mit Schreiben) bekommen wenn du das über die Geschäftsführung als Weisung an die IT bekommst. Die IT wird hier nicht die Gefahr eingehen das wegen eines Programmierfehlers das Werk stundenlang steht.

Zitat:

Zitat von jobo (Beitrag 1230714)

Es gibt sicher genügend Firmen, die selbst (eigenverantwortlich) Datenhaltung und Verarbeitung betreiben und volle Hoheit darüber haben.

Als Eigen-SW und keine Kauf-SW?

Zitat:

Zitat von jobo (Beitrag 1230714)

Auch Standardsoftwarehersteller haben anwendungsintern die Problemstellung, Zugriffssicherheit zu bewerkstelligen. Ein wasserdichtes Datenmodell ist auch da der beste Weg.

Haben wir. Wir haben 2-3 Usergruppen welche relativ einfache Rechtemodelle haben. Alles andere wird in der Anwendung erledigt.

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230723)

Zitat:

Zitat von jobo (Beitrag 1230714)

@ Bernhard: Ok, da hab ich etwas geschlampt, die eigentliche Antwort hat ja bereits generic geliefert. Man benötigt Grant Angaben für den View.
Der View ermöglicht die spaltenabhängige Filterung und löst das Problem.

Lesen schon, aber wie ist es mit dem schreiben wenn er nur entsprechende Datensätze auch schreiben darf?

Das kann auf verschiedenen Wegen sichergestellt werden, z.B. mittels "with check" im Create View statement stellt man sicher, dass Update oder Insert nicht die Where Kriterien verletzt, naheliegend wäre auch eine Stored Procedure für insert/update, die das sicherstellt.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230723)

Zitat:

Zitat von jobo (Beitrag 1230714)

Meine Aussage zu der Spaltenberechtigungen, die darüber hinaus direkt auf Tabellenebene möglich sind, ist lediglich eine Entgeegnung zu Deiner Aussage, dass DB dafür (".. so hohe Granularität der Zugriffsrechte..") nicht gemacht sein sollen.

Die Aussage bezieht sich auch die obige Notwendigkeit Rechte entsprechend auf Zellenwerte zu vergeben. Da kommt man mit Grants nicht weit.
Und der Alttag (ERP und PLM's zeigens) ist ja das man die so auch benötigt.
Sachbearbeiter A darf nur Stammdaten bearbeiten die im Bereich Elektrik liegen
Sachbearbeiter B darf keine Stücklisten bearbeiten welche freigegeben sind, dies müssen dann von Sachbearbeiter C als neue Version wieder in den Zustand "in Arbeit" gesetzt werden.
Wie würden hier GRANDs auf Datenbankebene aussehen?

Mit den oben beschriebenen Möglichkeiten lässt sich das bewerkstelligen. Was Du schilderst geht aber teilweise in den Bereich Business Logik, work flow. Wenn hier absehbar ist (oder gar systematisch vorgegeben), dass häufige Veränderungen auftreten, ist das Datenmodell ungeeignet, das abzubilden. Davon ist aber im vorliegenden Fall nicht die Rede gewesen.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230723)

Zitat:

Zitat von jobo (Beitrag 1230714)

Zugriffs-API, Lizenzbestimmungen und Herstellergarantie sind natürlich zu berücksichtigen, wenn man ein System gekauft hat. Ob das die Regel ist, wage ich zu bezweifeln.

Ich nicht. Bei SAP-Installationen wirst du oft nur direkten Tabellenzugriff (als mit Schreiben) bekommen wenn du das über die Geschäftsführung als Weisung an die IT bekommst. Die IT wird hier nicht die Gefahr eingehen das wegen eines Programmierfehlers das Werk stundenlang steht.

Äh, ich hab ja geschrieben, dass die Lizenzbestimmungen usw. einzuhalten sind. Wer an oder besser in SAP rumschraubt ist sowieso selber schuld. Da wär mir persönlich auch das Einverständnis der GF egal, die müssten mich schon "zwingen". Allein die Frage, was mir beim nächsten SAP Update alles um die Ohren fliegt, halte ich schon für nicht zu beantworten.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230723)

Zitat:

Zitat von jobo (Beitrag 1230714)

Es gibt sicher genügend Firmen, die selbst (eigenverantwortlich) Datenhaltung und Verarbeitung betreiben und volle Hoheit darüber haben.

Als Eigen-SW und keine Kauf-SW?

Genau, davon rede ich z.B.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230723)

Zitat:

Zitat von jobo (Beitrag 1230714)

Auch Standardsoftwarehersteller haben anwendungsintern die Problemstellung, Zugriffssicherheit zu bewerkstelligen. Ein wasserdichtes Datenmodell ist auch da der beste Weg.

Haben wir. Wir haben 2-3 Usergruppen welche relativ einfache Rechtemodelle haben. Alles andere wird in der Anwendung erledigt.

[/QUOTE]
Prima, solange es DB Bordmittel gibt, Missbrauch oder Programmierfehler zu verhindern, kann man die doch ganz entspannt einsetzen.

Um es mal klar zu sagen. Die Frage des TE roch nicht gerade danach, dass eine Mittelschicht eingesetzt wird. Eine solche (generell) vorzuschlagen, scheint mir halt so pauschal unpassend bzw. nicht unbedingt hilfreich für den TE. Oder eben in diesem Fall hier Kanonen auf Spatzen. Und wie ich schrieb, dass RDBMS für sowas nicht gedacht, gemacht, zu gebrauchen sind, ist halt eine sehr fragwürdige Aussage.

Ich glaub, das geht aber hier schon deutlich Richtung OT. Können wir aber gern in einem anderen Thread diskutieren.

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1230750)

Das kann auf verschiedenen Wegen sichergestellt werden, z.B. mittels "with check" im Create View statement stellt man sicher, dass Update oder Insert nicht die Where Kriterien verletzt, naheliegend wäre auch eine Stored Procedure für insert/update, die das sicherstellt.

Und wie kompliziert wird das? Vor allem Aufwändig wenn man das für alle Unterstützten DBMS realisieren müsste.

Zitat:

Zitat von jobo (Beitrag 1230750)

Mit den oben beschriebenen Möglichkeiten lässt sich das bewerkstelligen. Was Du schilderst geht aber teilweise in den Bereich Business Logik, work flow. Wenn hier absehbar ist (oder gar systematisch vorgegeben), dass häufige Veränderungen auftreten, ist das Datenmodell ungeeignet, das abzubilden.

Wirklich? Glaube ich nicht das das so eine auf DBMS-Mitteln basierende Rechtevergabe noch eine wartbare SW darstellt.

Zitat:

Zitat von jobo (Beitrag 1230750)

Davon ist aber im vorliegenden Fall nicht die Rede gewesen.

Wir wissen nicht wie komplex die Anwendung ist die realisert ist/werden soll.

Zitat:

Zitat von jobo (Beitrag 1230750)

Prima, solange es DB Bordmittel gibt, Missbrauch oder Programmierfehler zu verhindern, kann man die doch ganz entspannt einsetzen.

2-3 DB-Gruppen ist was anderes als das was ein ERP oder ein PLM als Rechtesystem benötigt.

Zitat:

Zitat von jobo (Beitrag 1230750)

Um es mal klar zu sagen. Die Frage des TE roch nicht gerade danach, dass eine Mittelschicht eingesetzt wird. Eine solche (generell) vorzuschlagen, scheint mir halt so pauschal unpassend bzw. nicht unbedingt hilfreich für den TE. Oder eben in diesem Fall hier Kanonen auf Spatzen. Und wie ich schrieb, dass RDBMS für sowas nicht gedacht, gemacht, zu gebrauchen sind, ist halt eine sehr fragwürdige Aussage.

Stimmt. Wir wissen nicht wie komplex das Gesamtsystem ist. Wenn es nur um eine solche Anforderung geht ist eine View z.B. ganz gut. Will man diese Methode für eine komplexere Anwendung als Pattern einsetzen ist man m. E. auf dem falschen weg.

Zitat:

Zitat von jobo (Beitrag 1230750)

Können wir aber gern in einem anderen Thread diskutieren.

Wäre eine möglichkeit.