Clausola EXECUTE AS (Transact-SQL)
In SQL Server è possibile definire il contesto di esecuzione dei seguenti moduli definiti dall'utente: funzioni (ad eccezione delle funzioni inline valutate a livello di tabella), procedure, code e trigger.
Specificando il contesto in cui viene eseguito il modulo, è possibile controllare quale account utente viene utilizzato da Motore di database per convalidare le autorizzazioni per gli oggetti a cui viene fatto riferimento dal modulo. Ciò consente maggiore flessibilità e controllo nella gestione delle autorizzazioni all'interno della catena di oggetti esistente tra i moduli definiti dall'utente e gli oggetti cui viene fatto riferimento da tali moduli. È necessario concedere agli utenti le autorizzazioni solo nel modulo stesso, senza dover concedere loro le autorizzazioni esplicite per gli oggetti a cui viene fatto riferimento. Solo l'account utente con il quale viene eseguito il modulo deve disporre delle autorizzazioni per gli oggetti a cui ha accesso il modulo.
Sintassi
Functions (except inline table-valued functions), Stored Procedures, and DML Triggers
{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | 'user_name' }
DDL Triggers with Database Scope
{ EXEC | EXECUTE } AS { CALLER | SELF | 'user_name' }
DDL Triggers with Server Scope and logon triggers
{ EXEC | EXECUTE } AS { CALLER | SELF | 'login_name' }
Queues
{ EXEC | EXECUTE } AS { SELF | OWNER | 'user_name' }
Argomenti
CALLER
Specifica che le istruzioni all'interno del modulo vengono eseguite nel contesto del chiamante del modulo. L'utente che esegue il modulo deve disporre delle autorizzazioni appropriate non solo per il modulo stesso, ma anche per tutti gli oggetti di database a cui fa riferimento il modulo.CALLER è il valore predefinito per tutti i moduli ad eccezione delle code e mantiene lo stesso funzionamento di SQL Server 2005.
CALLER non può essere specificato in un'istruzione CREATE QUEUE o ALTER QUEUE.
SELF
EXECUTE AS SELF equivale a EXECUTE AS user_name, dove l'utente specificato è la persona che crea o modifica il modulo. L'ID utente effettivo della persona che crea o modifica i moduli viene archiviato nella colonna execute_as_principal_id della vista del catalogo sys.sql_modules o sys.service_queues.SELF è il valore predefinito per le code.
[!NOTA]
Per modificare l'ID utente della colonna execute_as_principal_id nella vista del catalogo sys.service_queues, è necessario specificare in modo esplicito l'impostazione EXECUTE AS nell'istruzione ALTER QUEUE.
OWNER
Specifica che le istruzioni all'interno del modulo vengono eseguite nel contesto del proprietario corrente del modulo. Se per modulo non esiste un proprietario specificato, viene utilizzato il proprietario dello schema del modulo. Non è possibile specificare OWNER per i trigger DDL o LOGON.Importante OWNER deve essere mappato a un account singleton e non può essere un ruolo o un gruppo.
'user_name'
Specifica che le istruzioni all'interno del modulo vengono eseguite nel contesto dell'utente specificato in user_name. Le autorizzazioni per gli oggetti del modulo vengono verificate in base a user_name. Non è possibile specificare user_name per i trigger LOGON o DDL con ambito server. Utilizzare login_name in alternativa.user_name deve esistere nel database corrente e deve essere un account singleton. user_name non può essere un gruppo, un ruolo, un certificato, una chiave o un account predefinito, ad esempio NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService o NT AUTHORITY\LocalSystem.
L'ID utente del contesto di esecuzione viene archiviato nei metadati e può essere visualizzato nella colonna execute_as_principal_id della vista del catalogo sys.sql_modules o sys.assembly_modules.
'login_name'
Specifica che le istruzioni all'interno del modulo vengono eseguite nel contesto dell'account di accesso di SQL Server specificato in login_name. Le autorizzazioni per gli oggetti del modulo vengono verificate in base a login_name. È possibile specificare login_name solo per i trigger LOGON o DDL con ambito server.login_name non può essere un gruppo, un ruolo, un certificato, una chiave o un account predefinito, ad esempio NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService o NT AUTHORITY\LocalSystem.
Osservazioni
La modalità in cui Motore di database valuta le autorizzazioni per gli oggetti cui viene fatto riferimento nel modulo dipende dalla catena di proprietà esistente tra gli oggetti chiamanti e gli oggetti cui viene fatto riferimento. Nelle versioni precedenti di SQL Server, la concatenazione della proprietà rappresenta l'unico metodo disponibile per evitare di dover concedere all'utente chiamante l'accesso a tutti gli oggetti a cui viene fatto riferimento.
La concatenazione della proprietà presenta le limitazioni seguenti:
Si applica solo a queste istruzioni DML: SELECT, INSERT, UPDATE e DELETE.
I proprietari degli oggetti chiamanti devono corrispondere a quelli degli oggetti chiamati.
Non si applica alle query dinamiche all'interno del modulo.
Per ulteriori informazioni sulla concatenazione della proprietà, vedere Catene di proprietà.
A prescindere dal contesto di esecuzione specificato nel modulo, vengono sempre applicate le azioni seguenti:
Se il modulo viene eseguito, Motore di database verifica innanzitutto che l'utente che esegue il modulo disponga dell'autorizzazione EXECUTE per il modulo.
Le regole di concatenazione della proprietà continuano ad essere applicate. Ciò vuol dire che se i proprietari degli oggetti chiamanti corrispondono a quelli degli oggetti chiamati, le autorizzazioni per gli oggetti sottostanti non vengono controllate.
Quando un utente esegue un modulo che è stato specificato per essere eseguito in un contesto diverso da CALLER, viene verificata l'autorizzazione utente per l'esecuzione del modulo, ma i controlli delle autorizzazioni aggiuntive per gli oggetti a cui ha accesso il modulo vengono eseguiti in base all'account utente specificato nella clausola EXECUTE AS. In sostanza, l'utente che esegue il modulo rappresenta l'utente specificato.
Il contesto specificato nella clausola EXECUTE AS del modulo è valido solo per la durata dell'esecuzione del modulo. Il contesto ritorna al chiamante al termine dell'esecuzione del modulo. Per ulteriori informazioni sul cambio del contesto di esecuzione in un modulo, vedere Utilizzo di EXECUTE AS nei moduli.
Specifica di un account di accesso o di un nome utente
Non è possibile rimuovere un account di accesso a un server o un nome utente di database specificato nella clausola EXECUTE AS di un modulo fino a quando il modulo non è stato modificato per consentire l'esecuzione in un altro contesto.
Il nome utente o l'account di accesso specificato nella clausola EXECUTE AS deve esistere come entità in sys.database_principals o sys.server_principals, rispettivamente. In caso contrario l'operazione di creazione o modifica del modulo non può essere completata. Inoltre, l'utente che crea o modifica il modulo deve disporre delle autorizzazioni IMPERSONATE per l'entità.
Se l'utente ha accesso implicito al database o all'istanza di SQL Server tramite l'appartenenza a un gruppo di Windows, l'utente specificato nella clausola EXECUTE AS viene creato implicitamente al momento della creazione del modulo quando sussiste uno dei requisiti seguenti:
L'utente o l'account di accesso specificato è un membro del ruolo predefinito del server sysadmin.
L'utente che crea il modulo dispone dell'autorizzazione per creare entità.
Se non viene soddisfatto nessuno di questi requisiti, l'operazione di creazione del modulo non può essere completata.
Importante |
---|
Se il servizio SQL Server (MSSQLSERVER) viene eseguito come account locale (servizio locale o account utente locale), non disporrà dei privilegi per ottenere l'appartenenza ai gruppi di un account di dominio di Windows specificato nella clausola EXECUTE AS. Di conseguenza, l'esecuzione del modulo non potrà essere completata. |
Si suppongano ad esempio le condizioni seguenti:
Il gruppo CompanyDomain\SQLUsers ha accesso al database Sales.
CompanyDomain\SqlUser1 è un membro di SQLUsers e ha pertanto accesso al database Sales.
L'utente che crea o modifica il modulo possiede le autorizzazioni per creare entità.
Quando viene eseguita l'istruzione CREATE PROCEDURE seguente, CompanyDomain\SqlUser1 viene creato implicitamente come entità di database nel database Sales.
USE Sales;
GO
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT user_name();
GO
Utilizzo dell'istruzione autonoma EXECUTE AS CALLER
Utilizzare l'istruzione autonoma EXECUTE AS CALLER all'interno di un modulo per impostare il contesto di esecuzione sul chiamante del modulo.
Presupporre che la stored procedure seguente venga chiamata da SqlUser2.
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'SqlUser1'
AS
SELECT user_name(); -- Shows execution context is set to SqlUser1.
EXECUTE AS CALLER;
SELECT user_name(); -- Shows execution context is set to SqlUser2, the caller of the module.
REVERT;
SELECT user_name(); -- Shows execution context is set to SqlUser1.
GO
Utilizzo di EXECUTE AS per definire i set di autorizzazioni personalizzati
La specifica di un contesto di esecuzione per un modulo può risultare molto utile quando si desidera definire set di autorizzazioni personalizzati. Per alcune azioni ad esempio, come TRUNCATE TABLE, non è possibile concedere le autorizzazioni. Incorporando l'istruzione TRUNCATE TABLE all'interno di un modulo e specificando che il modulo viene eseguito come utente che dispone delle autorizzazioni per modificare la tabella, è possibile estendere le autorizzazioni necessarie per troncare la tabella all'utente al quale vengono concesse le autorizzazioni EXECUTE per il modulo. Per ulteriori informazioni, vedere Utilizzo di EXECUTE AS per la creazione di set di autorizzazioni personalizzati.
Per visualizzare la definizione del modulo con il contesto di esecuzione specificato, utilizzare la vista del catalogo sys.sql_modules (Transact-SQL).
Procedura consigliata
Specificare un account di accesso o un utente che dispone delle autorizzazioni minime necessarie per eseguire le operazioni definite nel modulo. Ad esempio, non specificare un account di un proprietario di database a meno che non siano necessarie tali autorizzazioni.
Autorizzazioni
Per eseguire un modulo specificato con EXECUTE AS, il chiamante deve disporre delle autorizzazioni EXECUTE per il modulo.
Per eseguire un modulo CLR specificato con EXECUTE AS che ha accesso alle risorse in un altro database o server, il database o server di destinazione deve considerare attendibile l'autenticatore del database nel quale ha origine il modulo (il database di origine). Per ulteriori informazioni su come stabilire l'attendibilità per l'autenticatore, vedere Estensione della rappresentazione di database tramite EXECUTE AS.
Per specificare la clausola EXECUTE AS quando si crea o si modifica un modulo, è necessario disporre delle autorizzazioni IMPERSONATE per l'entità specificata, nonché delle autorizzazioni per creare il modulo. È sempre possibile rappresentare se stessi. Quando non è specificato alcun contesto di esecuzione o è specificato EXECUTE AS CALLER, le autorizzazioni IMPERSONATE non sono necessarie.
Per specificare un login_name o user_name che dispone dell'accesso implicito al database tramite l'appartenenza a un gruppo di Windows, è necessario disporre delle autorizzazioni CONTROL per il database.
Esempi
Nell'esempio seguente viene creata una stored procedure e viene quindi assegnato il contesto di esecuzione a OWNER.
USE AdventureWorks;
GO
CREATE PROCEDURE HumanResources.uspEmployeesInDepartment
@DeptValue int
WITH EXECUTE AS OWNER
AS
SET NOCOUNT ON;
SELECT e.EmployeeID, c.LastName, c.FirstName, e.Title
FROM Person.Contact AS c
INNER JOIN HumanResources.Employee AS e
ON c.ContactID = e.ContactID
INNER JOIN HumanResources.EmployeeDepartmentHistory AS edh
ON e.EmployeeID = edh.EmployeeID
WHERE edh.DepartmentID = @DeptValue
ORDER BY c.LastName, c.FirstName;
GO
-- Execute the stored procedure by specifying department 5.
EXECUTE HumanResources.uspEmployeesInDepartment 5;
GO
Vedere anche