EXECUTE AS (Transact-SQL)

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse Analytics

Legt den Ausführungskontext einer Sitzung fest.

Standardmäßig beginnt eine Sitzung, wenn sich ein Benutzer anmeldet, und sie endet mit dem Abmelden. Alle Vorgänge während einer Sitzung hängen von Berechtigungsüberprüfungen für diesen Benutzer ab. Wenn eine EXECUTE AS Anweisung ausgeführt wird, wird der Ausführungskontext der Sitzung auf den angegebenen Login oder Benutzernamen umgestellt. Nach dem Kontextwechsel werden die Berechtigungen mit den Login- und Benutzersicherheitstoken für dieses Konto abgeglichen, anstatt mit der Person, die die Ausweisung EXECUTE AS aufruft. Im Wesentlichen wird die Identität des Benutzer- oder Anmeldekontos für die Dauer der Sitzung oder der Modulausführung übernommen, oder der Kontextwechsel wird explizit zurückgesetzt.

Transact-SQL Syntaxkonventionen

Syntax

{ EXEC | EXECUTE } AS <context_specification>  
[;]  
  
<context_specification>::=  
{ LOGIN | USER } = 'name'  
    [ WITH { NO REVERT | COOKIE INTO @varbinary_variable } ]   
| CALLER  

Argumente

LOGIN
Gilt für: SQL Server 2008 (10.0.x) und höher.

Gibt an, dass es sich bei dem Ausführungskontext, dessen Identität übernommen werden soll, um einen Anmeldenamen handelt. Der Bereich des Identitätswechsels liegt auf Serverebene.

USER
Gibt an, dass der Kontext, der als Identität angenommen werden soll, ein Benutzer in der aktuellen Datenbank ist. Der Identitätswechselbereich ist auf die aktuelle Datenbank beschränkt. Bei einem Kontextwechsel zu einem Datenbankbenutzer werden die Berechtigungen auf Serverebene dieses Benutzers nicht geerbt.

name ist ein gültiger Benutzer- oder Anmeldename. name muss ein Mitglied der festen Serverrolle sysadmin sein oder als Prinzipal in sys.database_principals bzw. sys.server_principals vorhanden sein.

name kann als lokale Variable angegeben werden.

name muss ein einzelnes Konto und kann keine Gruppe, Rolle, kein Zertifikat, Schlüssel oder integriertes Konto sein, wie z.B. NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService oder NT AUTHORITY\LocalSystem.

Weitere Informationen finden Sie unter Angeben eines Benutzer- oder Anmeldenamens weiter unten in diesem Thema.

NEIN REVERT
Gibt an, dass der Kontextwechsel nicht auf den vorherigen Kontext zurückgesetzt werden kann. Die NEIN-Option REVERT kann nur auf Adhoc-Ebene verwendet werden.

Für weitere Informationen zum Zurückgreifen zum vorherigen Kontext siehe REVERT (Transact-SQL).

KEKS IN @varbinary_variable
Spezifiziert, dass der Ausführungskontext nur auf den vorherigen Kontext zurückgesetzt werden kann, wenn die aufrufende REVERT WITH COOKIE-Anweisung den korrekten Wert @varbinary_variable enthält. Die Datenbank-Engine übergibt das Cookie an @varbinary_variable. Die COOKIE INTO-Option kann nur auf der Ad-hoc-Ebene verwendet werden.

@varbinary_variable ist varbinary(8000).

CALLER
Bei Verwendung innerhalb eines Moduls gibt dieser Wert an, dass die Anweisungen innerhalb des Moduls im Kontext des Modulaufrufers ausgeführt werden. Bei Verwendung außerhalb eines Moduls weist die Anweisung keine Aktion auf.

Bemerkungen

Die Änderung des Ausführungskontexts bleibt wirksam, bis eine der folgenden Bedingungen auftritt:

• Eine weitere EXECUTE AS Aussage wird veröffentlicht.

• Eine Aussage REVERT wird durchgeführt.

• Die Sitzung wird gelöscht.

• Die gespeicherte Prozedur oder der Trigger, für die bzw. den der Befehl ausgeführt wurde, wird beendet.

Du kannst einen Ausführungs-Kontextstack erstellen, indem du die EXECUTE AS Anweisung mehrfach über verschiedene Prinzipien hinweg aufrufst. Beim Aufruf wechselt die Anweisung REVERT den Kontext zum Login oder Benutzer auf der nächsten Ebene im Kontextstack. Eine Demonstration dieses Verhaltens finden Sie unter Beispiel A.

Angeben eines Benutzer- oder Anmeldenamens

Der in context_specification> angegebene EXECUTE AS<Benutzer- oder Login-Name muss als Principal in sys.database_principals bzw. sys.server_principals existieren, sonst schlägt die EXECUTE AS Anweisung fehl. Zudem müssen für den Prinzipal IMPERSONATE-Berechtigungen erteilt worden sein. Sofern der Aufrufer nicht der Datenbankbesitzer ist oder Mitglied des sysadmin feste Serverrolle ist, muss der Prinzipal vorhanden sein, auch wenn der Benutzer über eine Windows Gruppenmitgliedschaft auf die Datenbank oder Instanz von SQL Server zugreift. Stellen Sie sich z. B. folgende Bedingungen vor:

• Die CompanyDomain\SQLUsers-Gruppe verfügt über Zugriff auf die Sales-Datenbank.

• CompanyDomain\SqlUser1 ist ein Element von SQLUsers und hat deshalb impliziten Zugriff auf die Sales-Datenbank.

Obwohl CompanyDomain\SqlUser1 über die Mitgliedschaft in der SQLUsers-Gruppe Zugriff auf die Datenbank besitzt, schlägt die EXECUTE AS USER = 'CompanyDomain\SqlUser1'-Anweisung fehl, da CompanyDomain\SqlUser1 nicht als Prinzipal in der Datenbank vorhanden ist.

Wenn der Benutzer verwaist ist (der zugehörige Login existiert nicht mehr) und der Benutzer nicht mit WITHOUT LOGINerstellt wurde, EXECUTE AS fehlschlägt das für den Nutzer.

Bewährte Methode

Geben Sie einen Anmelde- oder Benutzernamen an, der die geringsten Privilegien besitzt, die zum Ausführen der Vorgänge in der Sitzung erforderlich sind. Geben Sie z. B. keinen Anmeldenamen mit Berechtigungen auf Serverebene an, wenn nur Berechtigungen auf Datenbankebene erforderlich sind. Oder geben Sie nur dann ein Datenbankbesitzerkonto an, wenn diese Berechtigungen tatsächlich erforderlich sind.

Sicherheitsaspekte

Das Ausführen im DBO-Ownership-Kontext, zum Beispiel durch die Verwendung der Anweisung EXECUTE AS USER = 'dbo', ändert die Auswertung expliziter DENY Berechtigungen. Wenn du den Ausführungskontext auf den DBO-Eigentumskontext wechselst, werden die berechtigungsbasierten DENY Einschränkungen, die für den ursprünglichen aufrufenden Hauptmann gelten, während der Impersonation nicht durchgesetzt. Dadurch kann ein Prinzipal, das den Ausführungskontext in DBO wechseln kann, zum Beispiel durch die Mitgliedschaft in der db_owner festen Datenbankrolle, Aktionen ausführen, die sonst durch explizite DENY Berechtigungen auf diesen Prinzipal blockiert würden.

Dieses Verhalten ist beabsichtigt. Berücksichtigen Sie diese, wenn Sie Berechtigungen erteilen, die den Identitätswechsel des Besitzes zulassen. DENY Berechtigungen können nicht als kompensierende Kontrolle dienen, um die effektiven Berechtigungen von Hauptverantwortlichen zu begrenzen, die als DBO ausgeführt werden können.

Verwendung von OHNE REVERT

Wenn die EXECUTE AS Anweisung die optionale WITH NO-Klausel REVERT enthält, kann der Ausführungskontext einer Sitzung nicht mit REVERT oder durch Ausführung einer anderen EXECUTE AS Anweisung zurückgesetzt werden. Der über die Anweisung festgelegte Kontext bleibt aktiv, bis die Sitzung getrennt wird.

Wenn die Klausel WITH NO REVERT COOKIE = @varbinary_variable angegeben ist, übergibt die SQL Server-Datenbank-Engine den Cookie-Wert an @varbinary_variable. Der von dieser Anweisung gesetzte Ausführungskontext kann nur auf den vorherigen Kontext zurückgesetzt werden, wenn die aufrufende REVERT WITH COOKIE = @varbinary_variable-Anweisung denselben @varbinary_variable Wert enthält.

Diese Option ist in einer Umgebung nützlich, in der Verbindungspools verwendet werden. Mithilfe von Verbindungspools wird eine Gruppe von Datenbankverbindungen verwaltet, die von Anwendungen auf einem Anwendungsserver wiederverwendet werden können. Da der an @varbinary_variable übermittelte Wert nur dem Aufrufer der EXECUTE AS Anweisung bekannt ist, kann der Aufrufer garantieren, dass der von ihm hergestellte Ausführungskontext von niemand anderem geändert werden kann.

Bestimmen des ursprünglichen Anmeldenamens

Verwenden Sie die Funktion ORIGINAL_LOGIN, um den Namen der Anmeldung zurückzugeben, die mit der Instanz von SQL Server verbunden ist. Mit dieser Funktion können Sie die Identität des ursprünglichen Anmeldenamens in Sitzungen zurückgeben, in denen zahlreiche explizite oder implizite Kontextwechsel vorkommen.

Berechtigungen

Um bei einem Login anzugebenEXECUTE AS, muss der Anrufer die IMPERSONATE-Berechtigung für den angegebenen Login-Namen haben und darf KEINE LOGINIMPERSONATE-Berechtigung verweigert bekommen. Um auf einen Datenbankbenutzer zu spezifizieren EXECUTE AS , muss der Aufrufer IMPERSONATE-Berechtigungen für den angegebenen Benutzernamen haben. Wenn EXECUTE AS CALLER angegeben ist, sind keine IMPERSONATE-Berechtigungen erforderlich.

Beispiele

A. Verwendung EXECUTE AS von und REVERT zum Kontextwechsel

Im folgenden Beispiel wird ein Kontextausführungsstapel mit mehreren Prinzipalen erstellt. Mit der REVERT-Anweisung wird der Ausführungskontext anschließend auf den vorherigen Aufrufer zurückgesetzt. Die REVERT-Anweisung wird mehrmals ausgeführt und bewegt sich so durch den Stapel, bis der Ausführungskontext wieder auf den ursprünglichen Aufrufer festgelegt ist.

USE AdventureWorks2022;  
GO  
--Create two temporary principals  
CREATE LOGIN login1 WITH PASSWORD = 'J345#$)thb';  
CREATE LOGIN login2 WITH PASSWORD = 'Uor80$23b';  
GO  
CREATE USER user1 FOR LOGIN login1;  
CREATE USER user2 FOR LOGIN login2;  
GO  
--Give IMPERSONATE permissions on user2 to user1  
--so that user1 can successfully set the execution context to user2.  
GRANT IMPERSONATE ON USER:: user2 TO user1;  
GO  
--Display current execution context.  
SELECT SUSER_NAME(), USER_NAME();  
-- Set the execution context to login1.   
EXECUTE AS LOGIN = 'login1';  
--Verify the execution context is now login1.  
SELECT SUSER_NAME(), USER_NAME();  
--Login1 sets the execution context to login2.  
EXECUTE AS USER = 'user2';  
--Display current execution context.  
SELECT SUSER_NAME(), USER_NAME();  
-- The execution context stack now has three principals: the originating caller, login1 and login2.  
--The following REVERT statements will reset the execution context to the previous context.  
REVERT;  
--Display current execution context.  
SELECT SUSER_NAME(), USER_NAME();  
REVERT;  
--Display current execution context.  
SELECT SUSER_NAME(), USER_NAME();  
  
--Remove temporary principals.  
DROP LOGIN login1;  
DROP LOGIN login2;  
DROP USER user1;  
DROP USER user2;  
GO  

B. Verwenden der WITH COOKIE-Klausel

Im folgenden Beispiel wird der Ausführungskontext einer Sitzung auf einen angegebenen Benutzer festgelegt und die WITH COOKIE INTO @varbinary_variable-Klausel angegeben. In der REVERT-Anweisung muss der an die @cookie-Variable in der EXECUTE AS-Anweisung übergebene Wert angegeben sein, damit der Kontext erfolgreich auf den Aufrufer zurückgesetzt werden kann. Zur Ausführung dieses Beispiels müssen der login1-Anmeldename und der user1-Benutzer, die in Beispiel A erstellt wurden, vorhanden sein.

DECLARE @cookie VARBINARY(8000);  
EXECUTE AS USER = 'user1' WITH COOKIE INTO @cookie;  
-- Store the cookie in a safe location in your application.  
-- Verify the context switch.  
SELECT SUSER_NAME(), USER_NAME();  
--Display the cookie value.  
SELECT @cookie;  
GO  
-- Use the cookie in the REVERT statement.  
DECLARE @cookie VARBINARY(8000);  
-- Set the cookie value to the one from the SELECT @cookie statement.  
SET @cookie = <value from the SELECT @cookie statement>;  
REVERT WITH COOKIE = @cookie;  
-- Verify the context switch reverted.  
SELECT SUSER_NAME(), USER_NAME();  
GO  

Weitere Informationen

REVERT (Transact-SQL)
EXECUTE AS Klausel (Transact-SQL)