Informazioni sul cambio di contesto
Il contesto di esecuzione è determinato dall'utente o dall'account di accesso che è connesso alla sessione o che esegue (chiama) un modulo. Stabilisce l'identità in base a cui vengono controllate le autorizzazioni per l'esecuzione di istruzioni o azioni. In SQL Server 2005 è possibile cambiare il contesto di esecuzione modificando l'utente o l'account di accesso attraverso l'esecuzione dell'istruzione EXECUTE AS o specificando la clausola EXECUTE AS in un modulo. Dopo il cambio di contesto, SQL Server controlla le autorizzazioni in base all'account di accesso e all'utente di tale account invece che in base alla persona che chiama l'istruzione EXECUTE AS o il modulo. L'utente del database o l'account di accesso di SQL Server viene rappresentato per il resto della sessione o dell'esecuzione del modulo, oppure finché il contesto viene ripristinato in modo esplicito. Per ulteriori informazioni sul contesto di esecuzione, vedere Informazioni sul contesto di esecuzione e l'esercitazione relativa alla protezione Catene di proprietà e cambio di contesto.
Cambio di contesto esplicito
Il contesto di esecuzione di una sessione o di un modulo può essere cambiato in modo esplicito specificando un nome utente o un nome di account di accesso in un'istruzione EXECUTE AS. La rappresentazione rimane attiva finché non si verifica uno degli eventi seguenti:
- La sessione viene interrotta.
- Il contesto viene impostato per un altro utente o account di accesso.
- Viene ripristinato il contesto di esecuzione precedente.
L'utilizzo di EXECUTE AS per rappresentare esplicitamente un altro utente produce un risultato simile all'utilizzo dell'istruzione SETUSER nelle versioni precedenti di SQL Server. Per ulteriori informazioni, vedere Confronto tra EXECUTE AS e SETUSER.
Cambio di contesto a livello di server esplicito
Per cambiare il contesto a livello di server, utilizzare l'istruzione EXECUTE AS LOGIN = 'login_name'. Il nome dell'account di accesso deve essere visibile come entità in sys.server_principals e l'utente che chiama l'istruzione deve disporre dell'autorizzazione IMPERSONATE per il nome di account di accesso specificato.
L'ambito di rappresentazione, quando il contesto di esecuzione è impostato a livello di server, è il seguente:
- Il token dell'account di accesso per login_name viene autenticato dall'istanza di SQL Server ed è valido in tutta l'istanza.
- Vengono applicate le appartenenze al ruolo e le autorizzazioni a livello di server di login_name.
Utilizzare l'istruzione REVERT per ripristinare il contesto precedente. L'utente che chiama l'istruzione REVERT deve essere incluso nello stesso database in cui si è verificata la rappresentazione.
Esempio
Nell'esempio seguente Peter Connelly, amministratore di rete di Adventure Works Cycles, desidera creare un account di accesso SQL Server per un nuovo dipendente, Jinghao Liuhas. L'account di accesso di Peter per SQL Server non dispone dell'autorizzazione a livello di server necessaria per creare account di accesso di SQL Server, tuttavia dispone dell'autorizzazione IMPERSONATE in adventure-works\dan1, un account di accesso di SQL Server dotato dell'autorizzazione a livello di server necessaria. Quando Peter si connette a un'istanza di SQL Server, il contesto di esecuzione della sessione viene derivato dal suo account di accesso di SQL Server. Per creare un account di accesso di SQL Server, Peter assume temporaneamente il contesto di esecuzione di adventure-works\dan1, quindi crea l'account di accesso. Infine, cede le autorizzazioni da lui assunte.
-- 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;
Cambio di contesto a livello di database esplicito
Per cambiare il contesto a livello di database, utilizzare l'istruzione EXECUTE AS USER = 'user_name'. Il nome utente deve essere disponibile come entità in sys.database_principals e l'utente che chiama l'istruzione deve disporre di autorizzazioni di rappresentazione per il nome utente specificato.
L'ambito di rappresentazione, quando il contesto di esecuzione è impostato a livello di database, è il seguente:
- Il token utente per user_name viene autenticato dall'istanza di SQL Server ed è valido nel database corrente. Per informazioni su come estendere la rappresentazione utente oltre l'ambito del database corrente, vedere Estensione della rappresentazione di database tramite EXECUTE AS.
- Vengono applicate le appartenenze al ruolo e le autorizzazioni a livello di database di user_name per il database corrente. Non vengono invece applicate le autorizzazioni a livello di server concesse esplicitamente a identità nel token utente o attraverso appartenenze al ruolo.
Utilizzare l'istruzione REVERT per ripristinare il contesto precedente. L'utente che chiama l'istruzione REVERT deve essere incluso nello stesso database in cui si è verificata la rappresentazione.
Esempio
Nell'esempio seguente François Ajenstat, amministratore di database di Adventure Works Cycles, desidera eseguire l'istruzione CREATE TABLE nel database AdventureWorksDW, ma non dispone delle autorizzazioni necessarie a livello di database. Dispone però delle autorizzazioni di rappresentazione per l'utente dan1, un account con l'autorizzazione necessaria.
Quando François si connette al database AdventureWorksDW, il contesto di esecuzione viene mappato al suo token di protezione utente. Le autorizzazioni per l'esecuzione delle istruzioni vengono controllate in base alle entità primaria e secondaria incluse nel token utente di François. Poiché François non dispone delle autorizzazioni necessarie per eseguire l'istruzione CREATE TABLE, esegue le istruzioni seguenti.
-- 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;
Cambio di contesto implicito
Il contesto di esecuzione di un modulo, ad esempio una stored procedure, un trigger, una coda o una funzione definita dall'utente, può essere cambiato implicitamente specificando un nome utente o un nome di account di accesso in una clausola EXECUTE AS nella definizione del modulo.
Specificando il contesto di esecuzione del modulo è possibile controllare quale account utente viene utilizzato da SQL Server per convalidare le autorizzazioni per gli oggetti a cui fa riferimento il modulo. Ciò garantisce maggiore controllo e flessibilità nella gestione delle autorizzazioni per la catena di oggetti esistente tra i moduli definiti dall'utente e gli oggetti a cui fanno riferimento tali moduli. È possibile concedere agli utenti le autorizzazioni solo nel modulo stesso, senza dover concedere loro le autorizzazioni esplicite per gli oggetti cui viene fatto riferimento. Solo all'utente rappresentato dal modulo devono essere concesse le autorizzazioni necessarie per gli oggetti cui accede il modulo.
Il livello di rappresentazione è determinato dal tipo di modulo in cui viene definita la rappresentazione.
La rappresentazione a livello di server può essere definita negli elementi seguenti:
- Trigger DDL
L'ambito della rappresentazione a livello di server è identico a quello definito in precedenza nel paragrafo "Cambio di contesto a livello di server esplicito".
La rappresentazione a livello di database può essere definita negli elementi seguenti:
- Trigger DML
- Code
- Stored procedure
- Funzioni definite dall'utente
- L'ambito della rappresentazione a livello di database è identico a quello definito in precedenza nel paragrafo "Cambio di contesto a livello di database esplicito".
- Per ulteriori informazioni sul cambio di contesto implicito, vedere Utilizzo di EXECUTE AS nei moduli.
Esempio
Nell'esempio seguente Mary è la proprietaria della tabella MyTable e desidera concedere all'utente Scott l'autorizzazione per il troncamento della tabella, ma Scott non dispone di autorizzazioni dirette per la tabella. Mary crea quindi la stored procedure dbo.usp_TruncateMyTable e concede a Scott autorizzazioni EXECUTE per la stored procedure. Quando Scott esegue la stored procedure, il Motore di database verifica le autorizzazioni per il troncamento della tabella come se la stored procedure fosse eseguita da Mary. Poiché Mary è la proprietaria della tabella, l'istruzione ha esito positivo anche se Scott non dispone di autorizzazioni dirette per la tabella.
CREATE PROCEDURE dbo.usp_TruncateMyTable
WITH EXECUTE AS SELF
AS TRUNCATE TABLE MyDB..MyTable;
Vedere anche
Altre risorse
Cambi di contesto
EXECUTE (Transact-SQL)
Clausola EXECUTE AS (Transact-SQL)
EXECUTE AS (Transact-SQL)
REVERT (Transact-SQL)