Informazioni sul contesto di esecuzione
Il contesto di esecuzione è determinato dall'utente o dall'account di accesso che ha stabilito la connessione alla sessione o che esegue un modulo e definisce l'identità per la quale vengono verificate le autorizzazioni per l'esecuzione di istruzioni o di operazioni. Il contesto di esecuzione è rappresentato da una coppia di token di protezione, ovvero un token dell'account di accesso e un token dell'utente. I token identificano le entità primarie e secondarie che vengono sottoposte alla verifica delle autorizzazioni e l'origine utilizzata per l'autenticazione del token. Un account che si connette a un'istanza di SQL Server dispone di un token dell'account di accesso e di uno o più token dell'utente, a seconda del numero di database ai quali può accedere.
Token di protezione dell'utente e dell'account di accesso
Un token di protezione per un utente o per un account di accesso include:
Un'entità server o database che rappresenta l'identità primaria
Una o più entità che rappresentano le identità secondarie
Zero o più autenticatori
I privilegi e le autorizzazioni delle identità primarie e secondarie
Le entità sono rappresentate da singoli utenti, gruppi e processi che possono richiedere risorse di SQL Server e sono suddivise in categorie in base al relativo ambito di influenza, che può essere a livello di Windows, di SQL Server o di database. Per ulteriori informazioni, vedere Entità (Motore di database).
Gli autenticatori sono entità, certificati o chiavi asimmetriche che garantiscono l'autenticità del token e sono spesso rappresentati dall'istanza di SQL Server. Per ulteriori informazioni sugli autenticatori, vedere Estensione della rappresentazione di database tramite EXECUTE AS. Per ulteriori informazioni sui certificati e sulle chiavi asimmetriche, vedere Gerarchia di crittografia.
Un token dell'account di accesso è valido nell'istanza di SQL Server e contiene le identità primarie e secondarie per le quali vengono verificate le autorizzazioni a livello del server e dei database. L'identità primaria è l'account di accesso stesso. L'identità secondaria include le autorizzazioni ereditate da ruoli e gruppi.
Un token dell'utente è valido unicamente per un database specifico. e contiene le identità primarie e secondarie per le quali vengono verificate le autorizzazioni a livello di database. L'identità primaria è l'utente del database stesso. L'identità secondaria include le autorizzazioni ereditate dai ruoli del database. I token dell'utente non contengono appartenenze al ruolo del server e non rispettano le autorizzazioni a livello del server concesse alle identità nel token, incluse quelle concesse al ruolo a livello del server public.
Se si crea in modo esplicito un account di accesso o un account utente di SQL Server, l'account di accesso o l'ID utente creato per l'account verrà utilizzato come l'identità primaria nel token dell'account di accesso o dell'utente. Se un'entità può accedere in modo implicito a un'istanza di SQL Server o può accedere a un database tramite le autorizzazioni CONTROL SERVER, l'identità primaria nel token dell'account di accesso è il ruolo public predefinito. e l'identità primaria nel token dell'utente è public.
.gif "Nota importante") Importante |
|---|
Per i membri del ruolo predefinito del server sysadmin, l'identità primaria del token dell'utente è sempre dbo. |
Esempio di token dell'account di accesso
Mary dispone di un account di accesso di SQL Server mappato al proprio account di Windows MyDomain\Mary. Per visualizzare le informazioni relative al proprio token dell'account di accesso, Mary esegue l'istruzione seguente:
SELECT principal_id, sid, name, type, usage FROM sys.login_token;
GO
Il set di risultati è simile al seguente:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
261 0x583EA MyDomain\Mary WINDOWS LOGIN GRANT OR DENY
2 0x02 public SERVER ROLE GRANT OR DENY
(2 row(s) affected)
Il set di risultati indica che l'account di Windows di Mary è l'identità primaria del relativo token dell'account di accesso. Nel token dell'account di accesso, come principal_id primario viene utilizzato il valore principal_id creato insieme all'account di accesso di Mary. Il ruolo public è visualizzato come identità secondaria, perché Mary è un membro di questo ruolo predefinito. Se Mary fosse un membro di altri ruoli a livello del server, tali ruoli sarebbero anch'essi visualizzati come identità secondarie. L'account di Windows di Mary è stato convalidato al momento della creazione dall'istanza di SQL Server. Quando Mary si connette all'istanza di SQL Server, tale istanza funge pertanto da autenticatore del token dell'account di accesso di Mary. Poiché l'istanza di SQL Server è l'autenticatore del token dell'account di accesso di Mary, nella query non viene restituito alcun autenticatore, ad esempio un'entità, un certificato o una chiave asimmetrica.
Esempio di token dell'utente
Mary dispone di un token dell'utente per ogni database al quale può accedere. Nel primo esempio, Mary è connessa al database master. Per visualizzare le informazioni relative al proprio token dell'utente creato nel database master, Mary esegue l'istruzione seguente:
SELECT principal_id, sid, name, type, usage FROM sys.user_token;
GO
Il set di risultati è simile al seguente:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
2 NULL guest SQL USER GRANT OR DENY
0 NULL public ROLE GRANT OR DENY
(2 row(s) affected)
Il set di risultati indica che Mary non è un utente esplicito del database master, ma che può tuttavia accedervi tramite l'account guest. L'identità primaria per il token dell'utente di Mary è l'utente guest. Il ruolo public è visualizzato come identità secondaria, perché guest è un membro di questo ruolo predefinito. Il token dell'utente di Mary nel database master include tutti i privilegi e le autorizzazioni a livello del database per l'utente guest e per il ruolo public.
Nell'esempio seguente è stato creato un account utente esplicito per Mary nel database Sales. Inoltre, Mary è stata aggiunta nel ruolo predefinito del database db_ddladmin relativo al database specifico. Con Sales come database corrente, Mary esegue di nuovo SELECT * FROM sys.user_token.
Il set di risultati è simile al seguente:
principal_id sid name type usage
------------ ----------- ------------- -------------- -------------
5 0x36CC4BBD1 Mary SQL USER GRANT OR DENY
0 NULL public ROLE GRANT OR DENY
16387 NULL db_ddladmin ROLE GRANT OR DENY
Il set di risultati indica il token dell'utente creato per Mary nel database Sales. Poiché Mary è stata aggiunta in modo esplicito come utente al database Sales, viene visualizzata come identità primaria. I due ruoli dei quali Mary è membro vengono visualizzati come identità secondarie. L'autenticatore del token dell'utente di Mary è l'istanza di SQL Server.
Cambio del contesto di esecuzione
In SQL Server è possibile cambiare in modo esplicito il contesto di esecuzione di una sessione specificando un nome utente o un nome di account di accesso in un'istruzione EXECUTE AS. Il contesto di esecuzione di un modulo, ad esempio una stored procedure, un trigger o una funzione definita dall'utente, può essere cambiato in modo implicito specificando un nome utente o un nome di account di accesso in una clausola EXECUTE AS nella definizione del modulo. Se si cambia il contesto di esecuzione specificando un altro utente o a un altro account di accesso, SQL Server verifica le autorizzazioni nei token dell'utente e dell'account di accesso relativi al nuovo account. Tale account viene in effetti rappresentato per la durata della sessione o dell'esecuzione del modulo. Per ulteriori informazioni, vedere Informazioni sul cambio di contesto.
Vedere anche