SQL Server: Sicherheit für Entwickler

Vergabe von Rechten

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
In diesem Video lernen Sie wie Sie Rechte vergeben können, was positive und negative Rechte (also Verbote) sind und wie sich Recht vererben.
10:35

Transkript

So, wir haben dann alles zusammen, um Rechte zu vergeben. Und bei Rechten haben Sie die Möglichkeit, positive Rechte zu vergeben, als auch negative Rechte zu vergeben. Und negative Rechte sind entsprechend Verbote und haben die höchste Priorität, das heißt, wenn ein User oder ein Login in irgendeiner Form ein Verbot ausgesprochen bekommen hat, eine gewisse Aktion nicht ausführen zu dürfen, dann hat er das Nachsehen, egal wie oft er möglicherweise an anderer Stelle durch Rollenmitgliedschaften oder Ähnliches dazu berechtigt wäre. Dann gibt es eine unübersichtliche Liste an möglichen Rechten, also ich habe es mir hier gespart, die in die Folien hineinzupressen. Die wichtigsten DML-Rechte, also die Data-Manipulation-Language-Rechte um mit Daten zu arbeiten, sind sicherlich SELECT, INSERT, DELETE und UPDATE und die wichtigsten DDL-Rechte, also Data Definition Language, das ist der Teil des T-SQL, womit Objekte angelegt, gelöscht oder verändert werden, beginnen mit CREATE, DROP, oder ALTER. Und danach folgt in der Regel so etwas wie Procedure, wie Function, wie Table, wie View und so weiter und so fort. Das sind die Rechte, die ich da vergeben kann sowohl, und das ist ein wichtiger Punkt, als positives als auch ein negatives Recht. Denken Sie bei negativen Rechten immer automatisch auch an Verbote und die höchste Priorität, die diese genießen. Und dann gibt es einen Umstand, der relativ mächtig ist, aber auch dafür sorgt, dass Rechte relativ schnell unübersichtlich werden können, nämlich Rechte können vererbt werden von der Datenbank auf das Schema auf die einzelnen Objekte. Und das bedeutet im Wesentlichen, ich habe die Möglichkeit, zum Beispiel ein Recht zu lesen, auf Datenbank-Ebene sogar zu vergeben. Das macht man relativ selten, aber es ist durchaus möglich. Das bedeutet, dass ich ein Select-Recht in allen Schemata habe und das wiederum bedeutet, dass ich alles, was in irgendeiner Form lesbar ist, im Wesentlichen sind das Tabellen und Sichten, dass ich dort ein entsprechendes Select-Recht genieße, es sei denn, es gibt irgendeine Art von Einschränkung von negativem Recht, sprich, Verbot an der Stelle. Das bedeutet wiederum aber auch, um rauszufinden, wer welche Rechte hat, muss ich möglicherweise über mehrere Instanzen gehen, ich muss auf das Objekt gucken, ich muss auf das Schema gucken, ich muss auf die Datenbank gucken. Und das macht die Sache wirklich relativ unübersichtlich. Dazu kommt noch der Umstand, dass ein Besitzer eines Objektes, zudem werden wir gleich noch kommen, entsprechend alles mit einem Objekt tun kann. Und das heißt, wenn ich beispielsweise Database-Owner bin, dann darf ich in der Datenbank eh alles machen, ohne dass ich explizit dafür das Recht dazu bekommen habe, aber das ist eine andere Geschichte. Sie müssen also sehr, sehr vorsichtig sein und sehr, sehr überlegt vorgehen, wie Sie Rechte vergeben. Ich gebe Ihnen im Laufe des Kapitels noch 1, 2 Tipps an die Hand, was Sie definitiv als Best Practice tun sollten, nämlich eigentlich um es kurz im Kern vorwegzunehmen: Vergeben Sie möglich spärlich einzelne Rechte. Wenn Sie sich vorstellen, Sie haben eine Datenbank mit allein 10 Tabellen und sagen wir mal 2 Sichten und 3 Stored Proceduren und Sie fangen an wild Rechte zu vergeben, dann garantiere ich Ihnen, dass Sie bei einer relativ kleinen Anzahl von Benutzern oder vielleicht sogar, wenn Sie nur auf Rollen-Ebene gehen, bei einer relativ kleinen Anzahl von Rollen unheimlich schnell die Übersicht verlieren. Und damit möglicherweise etwas administrieren von der Berechtigungsseite her, was entweder schlicht und ergreifend die Anwendung bei Ihrer Ausführung hindert oder was einfach Lücken in Ihrem Sicherheitskonzept aufreißt. Das macht nicht wirklich Spaß, das macht auch keinen Sinn. Und damit stürzen wir uns wieder ins SQL Server Management Studio und ich zeige Ihnen, wie Sie Rechte vergeben können und wie das in der Oberfläche und von Seiten des T-SQLs aus aussehen kann. So, ich habe mir hier zu Demo-Zwecken eine kleine Datenbank aufgebaut, die Datenbank selber beinhaltet eine Tabelle und einen User mit dem Namen Jens. Es gibt auf Server-Ebene das gleiche Login wieder und mit diesem Login habe ich hier eine alternative Verbindung über das SQL Server Management Studio aufgebaut, nämlich genau mit diesem Login. Und wenn ich hier in die Datenbank jetzt reinschaue, ich aktualisiere extra noch mal, dann sehen Sie, er sieht nichts an der Stelle. Während jetzt mit der Admin ist der wohl die Tabelle. So, und damit kann ich Ihnen zum Beispiel zeigen, dass ich auf Datenbank-Ebene hingehen kann und Berechtigung vergeben, Eigenschaften der Datenbank, Permissions und diese ganz lange Liste. Benötige übrigens auch ein Connect-Recht, damit kann ich in der Tat auch über diesen Weg selbst User-Objekte deaktivieren. Wenn ich weiter runterscrolle und genau schaue, sehe ich hier, es gibt hier in der Tat ein Select-Recht und das kann ich dann datenbankweise vergeben. Das heißt, alles, was in der Datenbank ist, kann mein User oder Rolle, in dem Fall ist es ja ein User, entsprechend mit einem Select abgreifen. Das Gleiche gibt es für Execute, Delete, Insert, also die ganzen DML-Rechte. Und wenn ich mal wieder weiter hoch in der Liste gehe, da steht dann so etwas wie Alter any contract, Alter any irgendetwas. Das heißt, ich habe damit eine Möglichkeit, eine ganze, ganze Menge an Berechtigungen auf Datenbank-Ebene zu vergeben und das vererbt sich dann quasi über die Schemata durch bis zu den einzelnen Objekten. Hier bleibe ich aber bei dem Select-Recht, das heißt, hier kann ich entsprechend den Haken setzen. Ich drücke auf OK und dann gehe ich mal runter zu der zweiten Verbindung wieder, aktualisiere noch mal die Tabellen. Und Sie sehen, jetzt taucht da in der Tat auch wirklich was auf. So, und jetzt konnte ich Rechte vergeben auf Ebene des einzelnen Objektes und das mache ich mal, aber Vorsicht! Ich nehme hier bewusst mal die falsche Verbindung, nämlich der User selber, um Ihnen zu zeigen, dass das Management Studio an der Stelle einen relativ fiesen kleinen Back hat. Ich kann zwar hingehen und Permissions auswählen, ich kann mich selber an der Stelle oben als User auswählen und kann sagen, ich möchte zum Beispiel mir das Recht explizit nehmen, sprich, ein Verbot aussprechen auf diese Tabelle. Wenn ich dann auf OK klicke, dann sieht es für mich erst mal so aus, als wenn alles ganz toll geklappt hätte. Ich kann allerdings jetzt hier sowohl ein Refresh machen, ich sehe nach wie vor die Tabelle und ich kann auch hingehen und hier in der Tat ein Select ausführen. Es ist zwar nichts drin, aber ich bekomme kein Fehler zurück. Der Trick an der Sache oder, na ja, der Pferdefuß an der Sache eher ist Folgender: Wenn ich hingehe und hier auf Eigenschaften, Permissions, wenn ich mich selber auswähle, dann kann ich hier mir in der Tat auch ein Verbot ausstellen. Und ich kann hier über diese Schaltfläche mir mal anschauen, was für T-SQL-Statement das SQL Server Management Studio denn zusammenbaut und an den Server schickt. Und das sieht dann so aus: Er wechselt in die Datenbank, also jetzt rein prophylaktisch einfach und er sagt dann DENY SELECT ON, danach kommt der Name der Tabelle und dann TO [Jens] und das ist entsprechend der Benutzer. Ich breche das mal ab. Ich führe das mal aus, weil das ist nämlich das genau, was auch das Management Studio an sich tut. Und hier kriege ich kein Fehler, aber zumindestens einen Text zurück, der sagt, dass ich mir selber keine Rechte entziehen kann und ich kann dem sa, den dbo, den Besitzer, information_schema, sys und, na ja, yourself, also in dem Fall dem User selber keine Rechte entziehen. Das hat offensichtlich das Management Studio nicht so ganz auf dem Radar und da es kein Fehler gibt, geht es davon aus, dass alles hervorragend funktioniert hat. So, jetzt machen wir es aber mal richtig. Ich schließe mal dieses Fenster hier, gehe mal hoch auf unsere administrative Verbindung, gehe hier auf die Eigenschaften, auf Permissions. Ich mache eigentlich im Wesentlichen genau das Gleiche und gehe auch hier auf Select und auf Deny und drücke auf OK. Wechsle ich wieder runter in die Verbindung des Users Jens, gehe auf Aktualisieren. Und Sie sehen schon, hier die Tabelle ist verschwunden und das ist so ein Beispiel für negatives Recht. Ich habe auf Datenbank-Ebene festgelegt, der User darf lesen, also auch auf diesen Tabellen lesen und aus dieser einen Tabelle darf er dann aber wiederum nicht lesen, indem ich ihn ein expliziten Verbot erteile. So, ich gehe dann noch mal hoch in die administrative Verbindung. Sie sehen, es gibt ein Rauf und Runter hier. Gehe hier noch mal auf die Eigenschaften, auf die Permissions. Und Sie sehen hier, Ihnen wird aufgefallen sein, es gibt 3 Spalten, wobei in der Praxis eigentlich nur die ersten beiden so richtig von Relevanz sind, nämlich das Recht einräumen Grant, ein Verbot aussprechen Deny und die Spalte dazwischen hat eigentlich relativ geringe Relevanz. Das bedeutet, ich räume jemandem das Recht ein, etwas zu tun und gleichzeitig das Unterrecht das Recht weiterzuvergeben. Da Benutzer aber normalerweise ihre Rechte nicht selber verwalten, spielt das eigentlich in vielen Fällen keine Rolle. Das heißt, hier könnten Sie ein Häkchen setzen, und wenn ich eins setze, sehen Sie, dass es hier in der Oberfläche auch gleichzeitig das Grant gesetzt wird. Und das würde zum Beispiel bedeuten, darf lesen, Select-Recht und darf gleichzeitig anderen Usern dieses Recht geben. Insofern das nur als Anmerkung, warum es denn jetzt hier 3 Spalten gibt. Wichtig aber, in den meisten Fällen dürften nur die ersten beiden Spalten hier sein. So, und außerdem fällt vielleicht auf, dass es hier unten mehrere Zeilen geben kann. Auch das ist ein Darstellungsproblem der Oberfläche. Was er mir eigentlich damit mitteilen möchte, ist, dass ich das Recht mit einmal hier auswählen kann, das ist quasi die Standardzeile hier und dass ich hier von dem Grantor dbo dieses Recht bekommen habe. Und das sieht dann so aus: Ein bisschen unglücklich vielleicht. Wenn ich jetzt auf OK drücke hier, noch mal in den Dialog gehe, dann sehen Sie, dass sowohl Jens eigentlich auch komplett verschwunden ist, als auch, dass wenn ich ihn hier noch mal auswähle, dass ich dann nur noch eine Zeile habe. Also das ist auch ein Darstellungsdefizit eher, und bedeutet nicht, dass Sie das doppelte Recht oder Ähnliches haben an der Stelle. Das war der erste Teil rund um Rechte und deren Vergabe. Im zweiten Teil wird es noch weitere Grundlagen geben und ein praxistauglicher Ansatz, wie man mit den vielfältigen Möglichkeiten umgehen kann.

SQL Server: Sicherheit für Entwickler

Lernen Sie, wie sich das Thema Sicherheit im Entickleralltag mit Microsofts Datenbankserver umsetzen lässt.

2 Std. 31 min (25 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Exklusiv für Abo-Kunden
Erscheinungsdatum:15.01.2016

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!