EXECUTE AS (Transact-SQL)

Si applica a: SQL ServerDatabase SQL di AzureIstanza gestita di SQL di AzureAzure Synapse Analytics

Imposta il contesto di esecuzione di una sessione.

Per impostazione predefinita, una sessione inizia quando un utente si connette e termina quando l'utente si disconnette. Tutte le operazioni eseguite durante una sessione sono soggette alle verifiche delle autorizzazioni dell'utente connesso. Quando viene eseguita un'istruzione EXECUTE AS , il contesto di esecuzione della sessione viene spostato al nome di login o utente specificato. Dopo il cambio di contesto, i permessi vengono controllati con i token di login e di sicurezza utente per quell'account invece che con la persona che chiama l'istruzione EXECUTE AS . In pratica, l'account utente o l'account di accesso viene rappresentato per l'intera durata dell'esecuzione della sessione o del modulo oppure il passaggio di contesto viene ripristinato in modo esplicito.

convenzioni di sintassi Transact-SQL

Sintassi

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

Argomenti

LOGIN
Applica a: SQL Server 2008 (10.0.x) e versioni successive.

Specifica che il contesto di esecuzione da rappresentare è un account di accesso. L'ambito di rappresentazione è a livello di server.

USER
Specifica che il contesto da rappresentare è un utente nel database corrente. L'ambito di rappresentazione è limitato al database corrente. Un cambio di contesto a un utente del database non eredita le autorizzazioni a livello di server di tale utente.

'name' Nome utente o nome account di accesso valido. name deve essere membro del ruolo predefinito del server sysadmin oppure esistere come entità di sicurezza rispettivamente in sys.database_principals o sys.server_principals.

name può essere specificato come variabile locale.

name deve essere un account singleton e non può essere un gruppo, un ruolo, un certificato, una chiave oppure un account predefinito, ad esempio NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService o NT AUTHORITY\LocalSystem.

Per altre informazioni, vedere Specifica di un nome utente o un nome account di accesso di seguito in questo argomento.

NO REVERT
Specifica che non è possibile ripristinare il contesto precedente in seguito a un cambio di contesto. L'opzione NO REVERT può essere utilizzata solo a livello ad hoc.

Per maggiori informazioni sul ritorno al contesto precedente, vediREVERT (Transact-SQL).

COOKIE IN @varbinary_variable
Specifica che il contesto di esecuzione può essere riportato al contesto precedente solo se l'istruzione chiamata REVERT WITH COOKIE contiene il valore @varbinary_variable corretto. Il motore di database passa il cookie a @varbinary_variable. L'opzione COOKIE INTO può essere usata solo a livello ad hoc.

@varbinary_variable è varbinary(8000).

CALLER
Se utilizzato all'interno di un modulo, specifica che le istruzioni all'interno del modulo vengono eseguite nel contesto del chiamante del modulo. Se utilizzato all'esterno di un modulo, l'istruzione non esegue alcuna azione.

Osservazioni:

Il cambio di contesto di esecuzione rimane valido finché non si verifica una delle situazioni seguenti:

• Un'altra EXECUTE AS affermazione è run.

• Viene eseguita una REVERT dichiarazione.

• La sessione viene rimossa.

• La stored procedure o il trigger in cui è stato eseguito il comando è esistente.

Puoi creare uno stack contestuale di esecuzione chiamando l'istruzione EXECUTE AS più volte su più principi. Quando viene chiamata, la REVERT sentenza cambia il contesto verso il login o l'utente al livello successivo nello stack contestuale. Per una dimostrazione di questo comportamento, vedere l'esempio A.

Specifica di un nome utente o un nome account di accesso

Il nome utente o login specificato in EXECUTE AS<context_specification> deve esistere come principale in sys.database_principals o sys.server_principals, rispettivamente, altrimenti l'istruzione EXECUTE AS fallisce. È inoltre necessario concedere le autorizzazioni IMPERSONATE per l'entità. A meno che il chiamante non sia il proprietario del database o sia membro del sysadmin ruolo predefinito del server, l'entità deve esistere anche quando l'utente accede al database o all'istanza di SQL Server tramite un'appartenenza a un gruppo Windows. Si suppongano ad esempio le condizioni seguenti:

• Il gruppo CompanyDomain\SQLUsers ha accesso al database Sales.

• CompanyDomain\SqlUser1 è membro del gruppo SQLUsers e pertanto può implicitamente accedere al database Sales.

Anche se CompanyDomain\SqlUser1 può accedere al database in virtù dell'appartenenza al gruppo SQLUsers, l'istruzione EXECUTE AS USER = 'CompanyDomain\SqlUser1' ha esito negativo in quanto CompanyDomain\SqlUser1 non esiste come entità nel database.

Se l'utente è orfano (l'accesso associato non esiste più) e l'utente non è stato creato con WITHOUT LOGIN, EXECUTE AS fallirà per l'utente.

Procedure consigliate

Specificare un account di accesso o un utente che disponga almeno dei privilegi necessari per eseguire operazioni nella sessione. Ad esempio, non specificare un nome account di accesso con autorizzazioni a livello di server se sono richieste solo autorizzazioni a livello di database oppure non specificare l'account di un proprietario di database a meno che siano richieste le autorizzazioni corrispondenti.

Considerazioni relative alla sicurezza

Eseguire nel contesto di proprietà del dbo, ad esempio usando l'istruzione EXECUTE AS USER = 'dbo', cambia il modo in cui vengono valutati i permessi espliciti DENY . Quando si passa il contesto di esecuzione al contesto di proprietà del DBO, le restrizioni basate DENY sui permessi che si applicano al principale chiamante originale non vengono applicate per tutta la durata dell'impersonazione. Di conseguenza, un principal che può passare al contesto di esecuzione a dbo, ad esempio tramite l'appartenenza al ruolo db_owner fisso del database, può eseguire azioni che altrimenti sarebbero bloccate da permessi espliciti DENY applicati a quel principe.

Questo comportamento è predefinito. Tenere conto di quando si concedono autorizzazioni che consentono la rappresentazione della proprietà. DENY I permessi non possono fungere da controllo compensativo per limitare i permessi effettivi dei principali che possono eseguire come DBO.

Usando WITH NO REVERT

Quando l'istruzione EXECUTE AS include la clausola opzionale WITH NO REVERT , il contesto di esecuzione di una sessione non può essere resettato usando REVERT o eseguendo un'altra EXECUTE AS istruzione. Il contesto impostato dall'istruzione rimane valido fino all'eliminazione della sessione.

Quando viene specificata la clausola WITH NO REVERT COOKIE = @varbinary_variable, la Motore di database di SQL Server passa il valore del cookie a @varbinary_variable. Il contesto di esecuzione impostato da quell'istruzione può essere riportato al contesto precedente solo se l'istruzione chiamata REVERT WITH COOKIE = @varbinary_variable contiene lo stesso valore @varbinary_variable .

Questa opzione risulta utile in un ambiente in cui vengono utilizzati i pool di connessioni. Tramite i pool di connessioni vengono gestiti i gruppi di connessioni al database in modo che tali connessioni possano essere riutilizzate dalle applicazioni in un server applicazioni. Poiché il valore passato a @varbinary_variable è noto solo al chiamante dell'istruzione EXECUTE AS , il chiamante può garantire che il contesto di esecuzione che stabilisce non possa essere modificato da nessun altro.

Determinazione dell'account di accesso originale

Usare la funzione ORIGINAL_LOGIN per restituire il nome dell'account di accesso connesso all'istanza di SQL Server. È possibile utilizzare questa funzione per restituire l'identità dell'account di accesso originale in sessioni in cui si verificano numerosi cambi di contesto espliciti o impliciti.

Autorizzazioni

Per specificare EXECUTE AS in un accesso, il chiamante deve avere il permesso di IMPERSONARE il nome di accesso specificato e non deve essere negato ALCUN LOGINpermesso all'IMPERSONAGGIO. Per specificare EXECUTE AS su un utente del database, il chiamante deve avere i permessi di IMPERSONARE il nome utente specificato. Quando EXECUTE AS viene specificato il CHIAMANTE , non sono necessari i permessi di impersonare persona.

Esempi

R. Uso EXECUTE AS di e REVERT per cambiare contesto

Nell'esempio seguente viene creato uno stack di contesti di esecuzione utilizzando più entità. Viene quindi utilizzata l'istruzione REVERT per ripristinare il contesto di esecuzione al chiamante precedente. L'istruzione REVERT viene eseguita più volte per innalzare di livello lo stack finché il contesto di esecuzione viene impostato sul chiamante originale.

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. Utilizzo della clausola WITH COOKIE

Nell'esempio seguente il contesto di esecuzione di una sessione viene impostato su un utente specificato e viene specificata la clausola WITH COOKIE INTO @varbinary_variable. Nell'istruzione REVERT è necessario specificare il valore passato alla variabile @cookie nell'istruzione EXECUTE AS per ripristinare correttamente il contesto al chiamante originale. Per eseguire questo esempio, l'account di accesso login1 e l'utente user1 creato nell'esempio A devono esistere.

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  

Vedi anche

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