SQL Server: Sicherheit für Entwickler

EXECUTE AS

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Mit der EXECUTE AS können Stored Procedures, Funktionen oder DDL-Trigger mit den Rechten eines anderen Users/Logins ausgeführt werden.
05:51

Transkript

Es gibt noch das ein oder andere Teil, was relativ spannend ist und was ich Ihnen natürlich auch nicht vorenthalten möchte, zum einen ist es das EXECUTE AS. Sie haben das schon in vielen Demos gesehen, dass Sie mit EXECUTE AS in den Benutzerkontext eines Users wechseln können. Sie können EXECUTE AS aber auch auf anderer Stelle benutzen, nämlich bei der Ausführung von Stored Proceduren, haben Sie damit die Möglichkeit, den User und damit auch den Sicherheitskontext zu bestimmen. Sie können also Stored Procedure schreiben, die nicht in den Sicherheitskontext des Aufrufers später ausgeführt werden, sondern in einem anderen, meisten größeren Sicherheitskontext. Das heißt, eine Stored Procedure kann beispielsweise ein Backup durchführen, obwohl er einzelne User des Backups nicht von Hand hätte durchführen können, allerdings dafür die Stored Procedure aufrufen, die wechselt dann in den Sicherheitskontext eines Users, der das darf und führt dann entsprechendes Backup aus. Das wäre ein Beispiel, das Gleiche funktioniert auch bei Zugriff auf Daten, das heißt, an der Stelle haben Sie immer die Möglichkeit, der Stored Procedure unterschiedliche Rechte zu geben, als dem aufrufenden User. Sie können das auch für DDL-Trigger machen, wobei ich zugeben muss, das selber noch nicht gemacht zu haben. Ich denke mal, Prozeduren und vielleicht noch Funktionen sind da so die meisten Anwendungen. Dann können Sie angeben, als wen Sie eigentlich die Stored Procedure ausführen wollen, also den Sicherheitskontext. Da gibt es die Möglichkeit, CALLER anzugeben, SELF, OWNER oder Benutzername, respektive Loginname, wenn das ein Stored Procedure ist, die auf irgendetwas zugreifen soll, was auf Server-Ebene ist. Standard ist hier CALLER, das bedeutet, jede Stored Procedure, bei der Sie nichts weiter angeben oder jede Funktion, bei der Sie nichts weiter angeben, wird automatisch im Sicherheitskontext des Benutzers, der sie aufruft, gestartet und ausgeführt. Und das macht auch Sinn an der Stelle. So, was machen jetzt die einzelnen Angaben? Der CALLER ist der Aufrufer, das ist halt entsprechend derjenige, der die Stored Procedure auch startet. Dann gibt es den OWNER und das ist der Besitzer der Prozedur, Funktion oder Trigger, je nachdem, worauf ich es anwende, das heißt, ich bewege mich dann automatisch in dessen Sicherheitskontext. SELF ist der Ersteller der Prozedur, Funktion oder Trigger. Und da der Ersteller in der Regel auch der OWNER ist, wenn ich das nicht irgendwie geärgert habe, ist das meistens auch synonym zu verwenden, wobei ich immer vorschlagen würde, da auch wirklich OWNER zu schreiben, wenn ich das an der Stelle meine, und SELF, wenn es wirklich der Ersteller sein sollte, aber in der Praxis wird es höchstwahrscheinlich zu 99,9% immer das Gleiche sein. Oder Sie können explizit angeben entsprechend, ob Sie einen User oder einen Login haben wollen. Sie müssen das entsprechende Recht auf dieses Login haben und Logins können nur angegeben werden für DDL-Trigger, das heißt, Trigger, die in der Tat wirklich auf die Strukturänderung, auf dem Server oder Strukturänderung in der Datenbank reagieren. Und auch das werde ich Ihnen jetzt im SQL Server Management Studio einmal kurz vorführen. So, ich habe hier die Datei ExecuteAs.sql geöffnet. Zunächst lege ich in dem Skript eine Datenbank an, dann lege ich ein Login und einen User für dieses Login an. Und ich erzeuge 4 Stored Procedures, die Erste hat WITH EXECUTE AS 'dbo', die Zweite WITH EXECUTE AS CALLER, dann WITH EXECUTE AS OWNER' und last but not least WITH EXECUTE AS SELF. Das heißt, diese 4 Stored Procedures werde ich später aufrufen, und alle geben mir quasi die Namen des Users, der sie ausführt beziehungsweise in dessen Sicherheitskontext die sich befinden, zurück. Das ist in einem Rutsch angelegt. Dann gebe ich dem angelegten Benutzer das Execute-Recht auf das komplette Schema und wechsle hier mit EXECUTE AS in den Sicherheitskontext dieses Benutzers und führe die 4 Stored Procedures aus. Und mal gucken, was rumgekommen ist. ExecuteAsCaller, das ist letztendlich der User, mit dem ich es aufgerufen habe. Der dbo ist entsprechend der Dbo natürlich, der Owner ist ebenfalls dbo und Self ist ebenfalls dbo. Kommen Sie nicht durcheinander, weil das die gleichen Werte sind. Wie gesagt, Owner und Self sind sowieso meistens die gleichen Werte, und der Dbo an der Stelle kommt, weil ich hier oben explizit auf diesen User verwiesen habe. So, damit kann ich für die Ausführung einer Stored Procedure, einer Funktion oder einem Trigger den Sicherheitskontext quasi ändern, er wird dann so ausgeführt, als hätte ein anderer User ihn gestartet. Bedenken Sie, es ist eine mächtige Sache, dies zu benutzen, allerdings kann es auch bei, sagen wir mal etwas unvorsichtiger Benutzung, sehr schnell dazu führen, dass man nicht mehr so genau weiß, was mit welcher Berechtigung unterwegs ist. Wenn Sie sich vorstellen, Sie haben jede Stored Procedure mit einem anderen User bei der Ausführung, macht das irgendwann die Sache nicht wirklich noch verständlich. Insofern das würde gegen das "Keep it simple"-Prinzip verstoßen, insofern würde ich es Ihnen raten, wirklich nur gezielt einzusetzen. Wofür man es aber auch einsetzen kann, ist ein bisschen trickreicher. Man kann EXECUTE AS, wie Sie gesehen haben, hier einmal so verwenden und man kann EXECUTE AS auch so verwenden. Das macht exakt das Gleiche. Auch das können Sie natürlich, gerade dies hier, in Stored Proceduren versuchen einzusetzen. Aber auch das hat so ein bisschen das Problem, dass Sie dann irgendwann nicht mehr so genau wissen, was denn welche Stored Procedure wirklich mit welchem Sicherheitskontext zu tun hat, aber für Testzwecke ist das sicherlich nicht schlecht. Also wenn ich das noch mal so laufen lasse, bekomme ich genau das gleiche Ergebnis hier unten, wie ich es auch hier oben bekommen habe. Das ist also für Testzwecke durchaus eine schöne Sache. Ich benutze das sehr häufig für Demos darüber hinaus, aber wenn Sie wirklich versuchen, Ihre Sicherheit ein bisschen zu testen, können Sie das entweder mit dem einem Einsatz, ja, es ist wirklich EXECUTE AS und hier ist es, na ja, eigentlich auch EXECUTE AS mit dem String und den runden Klammern dazwischen, entsprechend testen, wie es mit Ihrer Sicherheit bestellt ist, ohne dass Sie sich jedes Mal neu anmelden müssen oder Ähnliches.

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!