Grundlegendes zum Wechseln des Kontexts
Der Ausführungskontext wird von Benutzer oder Anmeldenamen bestimmt, der mit der Sitzung verbunden ist oder der ein Modul ausführt (aufruft). Er stellt die Identität her, gegen die Berechtigungen für die Ausführung von Anweisungen oder Ausführung von Aktionen geprüft werden. Bei SQL Server kann der Ausführungskontext auf einen anderen Benutzer oder Anmeldenamen gewechselt werden, indem die EXECUTE AS-Anweisung ausgeführt oder die EXECUTE AS-Klausel in einem Modul angegeben wird. Nach dem Kontextwechsel prüft SQL Server die Berechtigungen gegen dem Anmeldenamen und den Benutzer für das entsprechende Konto und nicht gegen die Person, die die EXECUTE AS-Anweisung oder das Modul aufruft. Die Identität des Datenbankbenutzers oder des SQL Server-Anmeldenamens wird für die Dauer der Ausführung der Sitzung oder des Moduls angenommen, oder der Kontextwechsel wird explizit wiederhergestellt. Weitere Informationen zum Ausführungskontext finden Sie unter Grundlegendes zum Ausführungskontext.
Explizites Wechseln des Kontexts
Der Ausführungskontext einer Sitzung oder eines Moduls kann explizit geändert werden, indem ein Benutzer- oder Anmeldename in einer EXECUTE AS-Anweisung angegeben wird. Der Identitätswechsel bleibt wirksam, bis eines der folgenden Ereignisse eintritt:
Die Sitzung wird gelöscht.
Kontext wird zu einem anderen Anmeldenamen oder Benutzer gewechselt.
Kontext wird auf den vorherigen Ausführungskontext zurückgesetzt.
Die Verwendung von EXECUTE AS für die explizite Annahme der Identität eines anderen Benutzers ähnelt der Verwendung von SETUSER in früheren Versionen von SQL Server. Weitere Informationen finden Sie unter EXECUTE AS im Vergleich zu SETUSER.
Explizites Wechseln des Kontexts auf Serverebene
Um den Ausführungskontext auf Serverebene zu wechseln, verwenden Sie die EXECUTE AS LOGIN = 'login_name'-Anweisung. Der Anmeldename muss als Prinzipal in sys.server_principals sichtbar sein, und der Aufrufer der Anweisung muss über die IMPERSONATE-Berechtigung für den angegebenen Anmeldenamen verfügen.
Der Umfang des Identitätswechsels sieht für den Fall, dass der Ausführungskontext sich auf der Serverebene befindet, wie folgt aus:
Das Anmeldetoken für login_name wird durch die Instanz von SQL Server authentifiziert und ist auf der gesamten Instanz gültig.
Berechtigungen auf Serverebene und Rollenmitgliedschaften von login_name werden berücksichtigt.
Verwenden Sie die REVERT-Anweisung, um zum vorherigen Kontext zurückzukehren. Der Aufrufer der REVERT-Anweisung muss sich in derselben Datenbank befinden, in der der Identitätswechsel stattfand.
Beispiel
Im folgenden Beispiel möchte Peter Connelly, Netzwerkadministrator bei Adventure Works Cycles, ein SQL Server-Anmeldekonto für einen neuen Mitarbeiter, Jinghao Liuhas, erstellen. Der SQL Server-Anmeldename von Peter verfügt nicht über die Berechtigung auf Serverebene, die erforderlich ist, um SQL Server-Anmeldenamen zu erstellen, verfügt jedoch über die IMPERSONATE-Berechtigung für adventure-works\dan1, ein SQL Server-Anmeldename, der über die erforderliche Berechtigung auf Serverebene verfügt. Wenn Peter eine Verbindung mit SQL Server herstellt, wird der Ausführungskontext für die Sitzung von seinem SQL Server-Anmeldenamen abgeleitet. Um einen SQL Server-Anmeldenamen zu erstellen, nimmt Peter zeitweise den Ausführungskontext von adventure-works\dan1 an. Er erstellt dann den Anmeldenamen. Schließlich gibt er seine angenommenen Berechtigungen freiwillig ab.
-- Switch execution context to the adventure-works\dan1 login account.
EXECUTE AS LOGIN = 'adventure-works\dan1';
-- Create the new login account.
CREATE LOGIN Jinghao1 WITH PASSWORD = '3KHJ6dhx(0xVYsdf';
-- Revert to the previous execution context.
REVERT;
Explizites Wechseln des Kontexts auf Datenbankebene
Um den Kontext auf Datenbankebene zu wechseln, verwenden Sie die EXECUTE AS USER = 'user_name'-Anweisung. Der Anmeldename muss als Prinzipal in sys.database_principals vorhanden sein, und der Aufrufer der Anweisung muss über IMPERSONATE-Berechtigungen für den angegebenen Benutzernamen verfügen.
Der Umfang des Identitätswechsels sieht für den Fall, dass der Ausführungskontext sich auf der Datenbankebene befindet, wie folgt aus:
Das Benutzertoken für user_name wird durch die Instanz von SQL Server authentifiziert und ist in der aktuellen Datenbank gültig. Informationen dazu, wie Sie den Benutzeridentitätswechsel über den Umfang der aktuellen Datenbank hinaus erweitern können, finden Sie unter Erweitern des Identitätswechsels bei Datenbanken durch Verwenden von EXECUTE AS.
Berechtigungen auf Datenbankebene und Rollenmitgliedschaften von user_name für die aktuelle Datenbank werden berücksichtigt. Berechtigungen auf Serverebene, die explizit Identitäten im Benutzertoken oder durch Rollenmitgliedschaften gewährt werden, werden nicht berücksichtigt.
Verwenden Sie die REVERT-Anweisung, um zum vorherigen Kontext zurückzukehren. Der Aufrufer der REVERT-Anweisung muss sich in derselben Datenbank befinden, in der der Identitätswechsel stattfand.
Beispiel
Im folgenden Beispiel möchte François Ajenstat, Datenbankadministrator bei Adventure Works Cycles, die DBCC CHECKDB-Anweisung gegen die AdventureWorksDW-Datenbank ausführen. Er verfügt jedoch nicht über die für diesen Vorgang erforderlichen Berechtigungen auf Datenbankebene. Er verfügt jedoch über die IMPERSONATE-Berechtigungen für Benutzer dan1, ein Konto, das über die erforderliche Berechtigung verfügt.
Wenn François eine Verbindung mit der AdventureWorksDW-Datenbank herstellt, wird der Ausführungskontext seinem Benutzersicherheitstoken zugeordnet. Berechtigungen für die Ausführung von Anweisungen werden gegen die primären und sekundären Prinzipale in seinem Benutzertoken geprüft. Da er nicht über die erforderlichen Berechtigungen für die Ausführung der DBCC CHECKDB-Anweisung verfügt, führt er folgende Anweisungen aus.
-- EXECUTE AS USER = 'dan1';
-- Create a table in dan1's default schema
CREATE TABLE t_NewTable( data nvarchar(100) );
go
-- Revert to the previous execution context.
REVERT
go;
Implizites Wechseln des Kontexts
Der Ausführungskontext eines Moduls, wie beispielsweise eine gespeicherte Prozedur, ein Trigger, eine Warteschlange oder eine benutzerdefinierte Funktion, kann implizit geändert werden, indem ein Benutzer- oder Anmeldename in einer EXECUTE AS-Klausel in der Moduldefinition angegeben wird.
Durch das Angeben des Kontexts, in dem das Modul ausgeführt wird, können Sie steuern, welches Benutzerkonto von SQL Server verwendet wird, um Berechtigungen für beliebige Objekte, auf die durch das Modul verwiesen wird, zu überprüfen. Dies gewährleistet eine zusätzliche Flexibilität und Steuerung bei der Verwaltung von Berechtigungen auf der gesamten Objektkette, die zwischen benutzerdefinierten Modulen und den Objekten, auf die durch diese Module verwiesen wird, vorhanden ist. Berechtigungen können Benutzern für das Modul selbst erteilt werden, ohne dass explizite Berechtigungen für die Objekte, auf die verwiesen wird, erteilt werden müssen. Nur der Benutzer, dessen Identität das Modul annimmt, benötigt Berechtigungen für die Objekte, auf die das Modul zugreift.
Die Identitätswechselebene wird durch den Typ des Moduls bestimmt, in dem der Identitätswechsel definiert wird.
Der Identitätswechsel auf Serverebene kann in folgenden Modulen definiert werden:
- DDL-Trigger
Der Umfang des Identitätswechsels auf Serverebene entspricht dem zuvor im Abschnitt zum expliziten Wechseln des Kontexts auf Serverebene definierten Umfang.
Der Identitätswechsel auf Datenbankebene kann in folgenden Modulen definiert werden:
DML-Trigger
Warteschlangen
Gespeicherte Prozeduren
Benutzerdefinierte Funktionen
Der Umfang des Identitätswechsels auf Datenbankebene entspricht dem zuvor im Abschnitt zum expliziten Wechseln des Kontexts auf Datenbankebene definierten Umfang.
Weitere Informationen zum impliziten Wechseln des Kontexts finden Sie unter Verwenden von EXECUTE AS in Modulen.
Beispiel
Im folgenden Beispiel ist Mary Besitzer der MyTable-Tabelle. Sie möchte, dass Benutzer Scott in der Lage sein soll, die Tabelle abzuschneiden. Scott verfügt jedoch über keine direkten Berechtigungen für die Tabelle. Sie erstellt deshalb die gespeicherte Prozedur dbo.usp_TruncateMyTable und erteilt Scott EXECUTE-Berechtigungen für die Prozedur. Wenn Scott die gespeicherte Prozedur ausführt, überprüft Database Engine (Datenbankmodul) die Berechtigungen zum Abschneiden der Tabelle, so als würde Mary selbst die gespeicherte Prozedur ausführen. Da sie Tabellenbesitzer ist, ist die Anweisung erfolgreich, obwohl Scott über keine direkten Berechtigungen für die Tabelle selbst verfügt.
CREATE PROCEDURE dbo.usp_TruncateMyTable
WITH EXECUTE AS SELF
AS TRUNCATE TABLE MyDB..MyTable;
Siehe auch