SQL Server: Sicherheit für Entwickler

Besitzerverkettung

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Besitzerverkettung bedeutet, dass der SQL Server nur Objektzugriffe prüft, welche von Objekten ausgehen, die einem anderen Besitzer gehören. In diesem Video erfahren Sie, was es genau mit dieser Verkettung auf sich hat und wie man sie gezielt nutzen kann.
08:12

Transkript

SQL Server kennt Besitzerverkettung. Das bedeutet, wenn Objekte aufeinander zugreifen, zum Beispiel eine Prozedur oder eine Sicht auf eine Tabelle, dann schaut der SQL Server sich jedes Mal den Besitzer der Objekte an, und wenn dieser Besitzer gleich ist, dann wird keine Rechteüberprüfung durchgeführt. Das sieht dann im Beispiel so aus: Der User Michael greift auf eine Sicht zu Juli 2015, dieser Sicht gehört der Besitzerin Silke, und weil nicht Michael der Besitzer ist, sonst würde SQL Server auch keine Rechteprüfung durchführen, weil dann wäre der Owner in dieser Sicht, weil er entsprechend aber nicht der Owner ist, wird die Berechtigung geprüft. Das heißt, er muss die entsprechenden Rechte haben, um auf diese Sicht zuzugreifen, beispielsweise Select-Rechte. Dieser View kann auf einen anderen View zugreifen VerkaufXY und da sowohl Juli 2015 als auch VerkaufXY die gleiche Besitzerin haben, prüft der SQL Server an der Stelle keine Berechtigung. Gleiches passiert auch bei Schritt 3 von VerkaufXY auf Rechnungen, beide haben den gleichen Owner, deswegen keine Berechtigungsprüfung Dann jedoch gibt es einen Bruch, die View Rechnungen greift auf AcctAlterXY zu und hier ist der Besitzer ein Uwe. Das heißt, auf Schritt 4 wird wieder nach Berechtigung geprüft, das heißt, der ursprüngliche Aufrufer, nämlich Michael muss Rechte auf AcctAlterXY haben. Und weil dieser View auf eine Tabelle zugreift, die wiederum nochmal einem anderen User gehört, muss Michael entsprechend auch Rechte auf diese Tabelle haben. Das heißt, unterm Strich, muss Michael Rechte auf Juli 2015 haben, für VerkaufXY und Rechnungen spielt es keine Rolle. Er muss Rechte auf AcctAlterXY haben und er muss auf die Tabelle SpesenXY Rechte haben, um entsprechend sein Zugriff durchführen zu können. Das Gleiche kann auch datenbankübergreifend stattfinden, also die Besitzverkettung, wie Sie sehen können, von Database 1 nach Database 2 gehen. Und auch da kann der SQL Server so etwas wie eine Besitzerverkettung anwenden, er würde die gleichen Regeln nutzen. Allerdings, Achtung, die datenbankübergreifende Besitzerverkettung muss erst aktiviert werden, also sollte nach bestem Willen nicht aktiviert werden. Der Punkt ist nämlich Folgender: Ich habe 2 verschiedene Datenbanken, und auch wenn ich 2 verschiedene Benutzer habe, dann können die durchaus den gleichen Namen in jeweils den Datenbanken haben. Das heißt, der Jens der einen Datenbank muss nicht der Jens der anderen Datenbank, die Silke der einen Datenbank muss nicht die Silke der anderen Datenbank sein. Und entsprechend würde das bedeuten, dass ich versehentlich Berechtigung vergebe, wo ich es gar nicht möchte. Wenn nämlich, ich gehe noch mal zurück, zum Beispiel in Database 2 die Silke ein ganz anderer Benutzer ist, dann könnte es sein, dass der SQL Server trotzdem sieht, es ist der gleiche Besitzer, ich muss nicht auf Rechte prüfen und Michael könnte dann quasi über die Sicht aus einer Datenbank auf eine Sicht einer anderen Datenbank zugreifen. Das will man in vielen, vielen Fällen nicht, es sei denn natürlich, Sie haben Datenbanken, die wie eine Datenbank gesehen wird, dann macht es durchaus Sinn, dann kann ich das einschalten, allerdings standardmäßig sollte es meistens ausgeschaltet sein, weil damit kann ich sehr, sehr große Sicherheitslöcher auftun. So, wie das Ganze praktisch aussieht, zeige ich Ihnen jetzt im SQL Server Management Studio. Um den Zusammenhang in einem Skript zu zeigen, braucht es eine ganze Menge Skript. Ich habe hier die Datei OwnershipChaining.sql geöffnet und dieses legt zunächst eine Datenbank an. Es werden 4 Logins angelegt, es werden die entsprechenden User angelegt. Die User bekommen die entsprechenden Rechte, die Elemente, die Sie benötigen, anzulegen, sei es Schema, Tabelle oder als alternativen Weg auch eine Prozedur und Sichten. Dann wird die Tabelle angelegt, dann wird die erste Sicht vom User Uwe angelegt und entsprechend die 3 Sichten der Userin Silke. Und der User Michael bekommt Select-Rechte auf die oberste Sicht, nämlich auf Juli 2015 aus dem Schema von der Silke. Und wenn ich das dann ausführe, bekomme ich ein Fehler, allerdings erst beim Zugriff auf AcctAlterXY. Das war nämlich eine Sicht, die dem User Uwe gehörte. Und auf die anderen Sichten, sei es Rechnungen oder VerkaufXY, wird keine Berechtigung benötigt. Das heißt, da funktioniert die Besitzverkettung, erst in dem Moment, in dem die gebrochen wird, nämlich in dem eine Sicht von Silke auf eine Sicht von Uwe zugreift, erst in diesem Moment wird entsprechend noch mal die Rechte geprüft und festgestellt: Michael hat gar nicht die entsprechenden Rechte. Das heißt, ich kann ihm hier jetzt, indem ich das markiere, mehr Rechte geben. Kann ich das Ganze noch mal ausprobieren und ich werde wieder eine Fehlermeldung bekommen, allerdings diesmal eine andere, nämlich dass ich auf die entsprechende Tabelle im Schema von Jens nicht zugreifen kann. Und das kann ich damit abstellen, indem ich auch hier Rechte vergebe, dann kann ich es noch mal versuchen, und dann funktioniert es endlich. Sie verstehen hoffentlich, warum ich Ihnen den Tipp gegeben habe, möglich einen einheitlichen Besitzer zu haben, weil das ist ein Umstand, der ziemlich kompliziert ist, wo Sie relativ viel an Investition hineinstecken müssen und an Recherche reinstecken müssen, bevor Sie herausfinden, wo denn nun das Problem wirklich in der Tat liegt. Eine kleine Hilfe kann diese Abfrage sein, die ich Ihnen schon gezeigt habe, wie Sie ermitteln können, welches Objekt wem gehört. Und Sie sehen hier, die Liste der Objekte nebst Ihrer Besitzer. Ich kann die Besitzverkettung oder Besitzerverkettung auch durchaus gezielt einsetzen, zum Beispiel bei diesem alternativen Zugriff. Ich kann dem User Michael die Rechte auf alles aus dem Schema Jens nehmen, sprich, auf alle Select-Anweisungen. Und dafür die Ausführung aller Execute-Objekte, das heißt, alles, wo ich ein Execute drauf anwenden kann, Stored Procedure in dem Fall, kann ich ihm geben und kann Jens eine Stored Procedure anlegen lassen, die auf genau diese Tabelle zugreift, auf die jetzt der User Michael keinen direkten Zugriff mehr hat. Dann kann ich in den Sicherheitskontext des Benutzers wechseln und ich darf die Stored Procedure ausführen. Das funktioniert, das heißt, ich komme an die Daten ran, was ich allerdings nicht machen darf, ich komme nicht direkt mit dem Select-Statement an diese Daten heran. Das heißt, nur durch dieses Stored Procedure, das heißt, nur das, was mir die Stored Procedure erlaubt, und in dem Fall stellt die Stored Procedure eine Art API dar, die genau steuert, wie ich die Daten sehen darf, ob ich sie filtern darf, ob ich möglicherweise einige Zeilen nicht sehen darf, ob das Ganze protokolliert werden soll und, und, und. All das kann ich in dem Stored Procedure unterbringen. Und das hat den Vorteil, dass ich genau steuern kann, wer wie welche Daten sieht, indem ich halt so eine Schicht dazwischenlege, die aus Stored Proceduren besteht. Das ist durchaus ein ganz netter Ansatz und somit kann ich also die Besitzverkettung durchaus gezielt einsetzen. Hier in dem Fall gehören Tabelle und Prozedur ein und demselben User, ein und demselben Login und können an der Stelle entsprechend drauf verzichten, dass beim Zugriff von der Stored Procedure aus der Tabelle noch einmal die Berechtigung geprüft wird. Und damit darf quasi der User in dem Moment eigentlich auf Daten zugreifen durch die Stored Procedure, auf die er direkt kein Zugriff hat. Nette Sache. Damit wissen Sie, warum die Objekte in einer Datenbank möglichst nur ein und demselben Owner gehören sollten. Sie wissen, wie Sie herausfinden können, welches Objekt welchem Owner gehört und Sie können genau erklären oder verstehen, warum die Besitzverkettung durchaus ein mächtiges Instrument ist, um Zugriffe auf Objekte zu gestatten, die direkt nicht möglich sind, sondern nur in Form von Sichten oder Stored Proceduren oder ähnliche Funktionen wären da auch eine Möglichkeit, um eine gewisse API zur Datenbank zu realisieren.

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!