SQL Server 2016 Grundkurs: Administration

Objektrechte

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Sehen Sie, wie Sie Rechte für einzelne Objekte auf Datenbankebene vergeben können. Bei einem einzelnen Objekt kann es sich um eine Tabelle oder beispielsweise eine Prozedur handeln.
12:22

Transkript

In diesem Video sehen Sie, wie Sie im SQL Server Objektrechte verwalten können, das heißt, wir vergeben jetzt Rechte auf Objekte einzeln, das kann eine Tabelle oder eine Prozedur zum Beispiel sein. Wenn Sie einzelne Objektrechte vergeben wollen, wie gehen Sie am besten vor? Im Grunde genommen wissen wir, dass ein Benutzer über einen Login verfügen muss, im Grunde genommen wissen wir, dass ein Benutzer innerhalb einer Datenbank, ich habe dazu mal eine neue Datenbank angelegt, DBRechte, im Knoten Sicherheit als Benutzer existieren muss, es ist nicht der Fall. Müssen wir hier ihn hinzufügen. Wir suchen entsprechend das zugeordnete Login raus, weisen ihm intern in der Datenbank den Namen zu und können dann natürlich über die Mitgliedschaft sagen, er ist zum Beispiel datareader und datawriter. Das sind ja die Zuweisungen über die Rollen. Das heißt, wenn wir halt jetzt überprüfen hier unten, wir sind als der Benutzer angemeldet, gehen zum Knoten Datenbanken, gehen zu dieser Datenbank, öffnen wir jetzt den Knoten Tabellen, sehen wir, dass alle Tabellen sichtlich sind. Wenn ich jetzt das Ganze korrigiere, ich gehe also hier wieder hoch zu dem Benutzer und sage "OK". Er fliegt aus den beiden Rollen raus, scrolle runter. Mache hier eine Aktualisierung, sehe ich die Tabellen sind weg. Jetzt möchte ich dem Einzelobjekt Rechte geben, das heißt also, da wo ich die Rechte verwalte, hier oben als Admin, auf die Datenbank zum Knoten Sicherheit. Und habe hier meine sicherungsfähigen Elemente, und kann das natürlich jetzt einzeln raussuchen, das wäre jetzt eine Variante, die Alternative, ich gehe zu den Objekten, also in meine Datenbank, zu der Tabelle, speziell zu der Tabelle "Kunden", rechte Maustaste, "Eigenschaften", ich möchte jetzt Objektrechte vergeben. Habe hier den Knoten oder diese Seitenberechtigung. Tabellenname "Kunden". Suche mir jetzt meinen Benutzer, MMuster, übernehme den. Und habe dann die Möglichkeit zu sagen, er darf in Bezug auf die Tabelle Daten lesen. Okay, scrolle jetzt runter zu Tabellen, hier ist er angemeldet. Aktualisiere und sehe, er sieht die Tabelle. Gehe wieder zurück. Das ist die Tabelle "Kunden". "Eigenschaften", "Berechtigungen", "Auswählen", kann sogar bis auf Spaltenberechtigungen gehen, man kann sagen, die ID darf er nicht sehen. Name und Vorname. Scrolle runter. Aktualisiere, die Tabelle ist da. Würde jetzt rechte Maustaste, alle Zeilen auswählen, und sehe natürlich, dass die Selectberechtigungen für die ID-Spalte nicht vergeben ist. In dem Moment wenn ich jetzt sage, in meinem Select, okay, die ID-Spalte will ich nicht sehen, sondern ich will die Abfrage so ausführen, dann funktioniert das wunderbar. Aber sobald die ID-Spalte drin ist oder ich hier einen Stern für alle Spalten angebe, schlägt das fehl, weil ich die Berechtigung an der Stelle auf Spaltenebene eingegrenzt habe. Gehe abermals drauf in die Eigenschaften, zu Berechtigungen, zu den Spaltenberechtigungen beziehungsweise hier erst auswählen, zu den Spaltenberechtigungen und so kann ich jetzt von der Granularität her bestimmen, in Bezug auf einzelnes Objekt, einen User entsprechend dann berechtigen, kommt ein weiteres, also hier darf er noch lesen, kommt zum Beispiel ein weiteres Objekt, eine weitere Tabelle eben dazu, müsste ich mir die Tabelle jetzt nehmen, müsste die dann genau so wie wir es eben gemacht haben, mit dem gleichen Ansatz entsprechend von den Berechtigungen her das ganze definieren. Wie verhält sich das Ganze jetzt bei Prozeduren? Dazu lege ich mal eine Prozedur an. "Usp" für User definded stored procedure. So und die soll zum Beispiel ViewAllAbt, also soll Selectstatement ausführen, also alles aus Abteilungen anzeigen, "as select* from". Will also jetzt wirklich mal alle Spalten, keine Einschränkungen, wähle meine Tabelle aus und erstelle an der Stelle diese Prozedur. Das habe ich jetzt gemacht. Zu beachten, das ich hier als Administrator angemeldet bin, ich habe Sie jetzt angelegt. Und ich führe jetzt mal mit "exec" diese Prozedur aus, das ist der Name der Prozedur. So, rufe die auf und sehe, wenn die Prozedur ausgeführt wird, dass ist das Ergebnis oder im Ergebnis des Aufrufs im Prinzip alle Daten angezeigt bekomme. Wie verhält sich das jetzt, wenn diesen Aufruf, der Benutzer ausführt, jetzt der MMuster? Dazu gehe ich jetzt hier zur Instanz, in der der Benutzer angemeldet ist. Mach über "neue Abfrage" ein neues Fenster, weil je nachdem wo ich selektiere, ist auch das Script entsprechend als dieser Benutzer zugeordnet. Füge jetzt die Ausführung der Prozedur, diese Zeile ein und kriege die Nachricht, dass die Exicute-Berechtigungen verweigert wurden. Das heißt, im Grunde genommen müsste ich jetzt diesen Benutzer MMuster das Recht erteilen, dass er diese Prozedur ausführen darf. Das werde ich jetzt entsprechend mal administrieren, das heißt, ich begebe mich jetzt zu meiner Datenbank. So kann jetzt natürlich nicht bei Tabellen, sondern unter Programmierbarkeit mir untergespeicherte Prozeduren, diese Prozedur als Objekt raussuchen, rechte Maustaste, Eigenschaften, Berechtigungen, suche mir jetzt den Benutzer, also in dem Fall den MMuster, dem möchte ich das Recht erteilen. Bei Prozeduren ist es so, er bekommt das Recht jetzt die Prozedur auszuführen. Okay, zurück in mein Scriptfenster. Ausgeführt als MMuster die Prozedur und er sieht entsprechend die Daten. Wie verhält sich das jetzt mit den Rechten in Bezug auf die Tabellen? Man sieht, dass das die Abteilungen sind. Ich habe ihn, das sehen wir hier unten, wenn wir jetzt bei Tabellen sind und aktualisieren, nur Rechte auf die Tabelle "Kunden" gegeben, nicht auf die Abteilung, die tauchen hier nicht auf. Da er aber das Recht hat diese Prozedur auszuführen und in der Prozedur nachher "select*from Abteilung" steht, ist es also völlig unerheblich, ob er hier ein Insert drin steht, ein Update, ein Delete, ein Select, derjenige, der die Prozedur ausführen darf, und das darf er in dem Fall, der bekommt halt das Recht, das Exicute-Recht auf die Prozedur, und dann wird auch das ausgeführt, was letztendlich an Code in der Prozedur enthalten ist. Unser Benutzer MMuster hat jetzt Rechte über Rollen zugewiesen bekommen. Wir haben einmal die MarketUser, das testen wir noch mal, das ist das Select-Recht, wir haben das Update-Recht über die Rolle SalesUser. Hopla, nochmal komplett markiert. Es funktioniert wunderbar. Jetzt verlässt der Benutzer die Firma und hat über verschiedenste Rollen entsprechend Rechtezuweisungen und für mich ist es jetzt Erstmal ja eine Aufgabenstellung, schnell ihn Zugriff zu verweigern. Jetzt gibt es natürlich verschiedene Ansätze. Ich kann auf der einen Seite sagen, okay, ich deaktiviere seinen Login, ich kann im zweiten Schritt ihn als Datenbank-User entfernen, was auch ein Weg wäre. Aber wir wollen ja Berechtigungen testen, wir wollen natürlich jetzt auch mal schauen, wie so eine explizite Verweigerung funktioniert. Wir haben hier Update, wir haben hier Select und wir haben jetzt zwei Rollen, denydatareader, denydatawriter. Ich gehe mal zur Rolle datawriter. So hier existiert jetzt diese Rolle. Und ich werde jetzt im nächsten Schritt ihn zum Mitglied dieser Rolle machen. Suche mir den Benutzer MMuster aus, bestätige das "OK", habe ihn hier drin. Bestätige das Ganze mit "OK". Teste zunächst das Select-Recht, das klappt völlig problemlos. Teste jetzt das Thema mit dem Update. Und ich habe ihn ja mit denydatawriter praktisch Schreibrechte entzogen und damit funktioniert das auch wunderbar. Ich nehme das jetzt an der Stelle noch mal raus. Entferne ihn. So, wir testen jetzt die Situation hier noch mal durch, es klappt wieder. Das Update, es klappt wieder das Select. Umgekehrt gehe ich jetzt mal zur Rolle denydatareader und mache das gleiche Spiel mit der denydatareader-Rolle. Nehme den MMuster, füge ihn hinzu. Bestätige das mit "OK". Da hier das Wort Reader drin steckt, dürfte jetzt auch das Select nicht mehr funktionieren. Genauso ist es und beim Update kriege ich genauso eine Fehlermeldung, weil ein Select-Recht notwendig ist, um ein Update auszuführen und er hier jetzt auch das Ganze entsprechend verweigert. Seitens der Fachabteilung wird jetzt entschieden, dass die SalesUser weiteren Zugriff bekommen, dazu gehe ich zu der Gruppe, zu den sicherungsfähigen Elementen, gehe auf "Suchen". Suche mir weitere sicherungsfähige Elemente raus, diesmal gehe ich einen Stück einen anderen Weg. Und wähle hier mal, wir haben ja Datenbanken, wir haben Tabellen, wir haben Assemblys, ich gehe mal zu Schema. Sage an der Stelle "OK". Durchsuchen. Scrolle jetzt ein Stück runter und habe zum Beispiel das Schema "Sales". Sage "OK". Für das Schema "Sales" gibt es Auswählen-Rechte, bestätige das mit "OK". Der Vorteil der Rechtevergabe auf ein Schema besteht darin, dass wir uns mal die Tabellenstruktur der AdventureWorks-Datenbank anschauen und sehen, dass alle Objekte, also sprich die Tabellen in Schema organisiert sind, hier gibt es das Schema "HumanResources", also immer das, was links vom Punkt steht ist das Schema, das was rechts steht ist das Objekt, in dem Fall die Tabelle. Schema "Person", Tabelle "Adress". Schema "Person", Tabelle "Password". Und wenn ich jetzt ein Stück weitergehe, sehe ich dass auch ein Schema "Sales" existiert. Ich habe der Rolle jetzt das Recht gegeben auf ein Schema, das bedeutet, dass letztendlich dadurch das Recht auf alle Objekte, die sich im Schema befinden jetzt besteht und das kann man recht einfach jetzt überprüfen. Das geht natürlich auf den schnellen Weg, wenn mal schaut, ob man hier auf der linken Seite im Objektexplorer als der Benutzer angemeldet ist, der in der AdventureWorks-Datenbank bisher diese Tabelle hatte, und wenn ich jetzt diesen Knoten mal aktualisiere, "F5", hopla, dann kriege ich eine Fehlermeldung, wurde für das Objekt und so weiter, Schema verweigert. In diesem Video haben Sie gesehen, wie Sie einen Benutzer über einzelne Objektrechte innerhalb von SQL Server berechtigen können. Der einfachste Weg ist, dass man sich dorthin begibt, wo das Objekt existiert zum Beispiel in die Datenbank einer Tabelle. Mit der rechten Maustaste draufgeht, sagt "Eigenschaften", "Berechtigungen", den User raussucht und dann das Recht auf die Tabelle erteilt, Insert, update, delete. Oder bei Prozeduren im Konten Programmierbarkeit, [Unverständlich], die Prozedur raussucht und dort das Recht "Ausführen" dem Benutzer auf die Prozedur erteilt.

SQL Server 2016 Grundkurs: Administration

Erlernen Sie die Administration des SQL Server 2016 vom Umgang mit dem Management Studio bis zu Automatisierung und Monitoring.

6 Std. 10 min (60 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:08.05.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!