Description du basculement de contexte
Le contexte d'exécution est déterminé par l'utilisateur ou le nom de connexion connecté à la session, ou exécutant (appelant) un module. Il établit l'identité par rapport à laquelle sont vérifiées les autorisations d'exécution d'instructions ou d'actions. Dans SQL Server, il est possible de faire basculer le contexte d'exécution vers un autre utilisateur ou nom de connexion en exécutant l'instruction EXECUTE AS ou en spécifiant la clause EXECUTE AS dans un module. Après le basculement de contexte, SQL Server vérifie les autorisations par rapport au nom de connexion et à l'utilisateur de ce compte plutôt que par rapport à la personne qui appelle l'instruction EXECUTE AS ou le module. L'identité de l'utilisateur de base de données ou du nom de connexion SQL Server est empruntée pendant le reste de la session ou de l'exécution du module, ou jusqu'à ce que le basculement de contexte soit explicitement restauré. Pour plus d'informations sur les contextes d'exécution, consultez Présentation du contexte d'exécution.
Basculement de contexte explicite
Le contexte d'exécution d'une session ou d'un module peut être modifié explicitement en spécifiant un nom d'utilisateur ou de connexion dans une instruction EXECUTE AS. L'emprunt d'identité reste en vigueur jusqu'à ce que l'un des événements suivants se produise :
Suppression de la session.
Basculement du contexte vers une autre connexion ou utilisateur.
Restauration du contexte d'exécution précédent.
L'utilisation de EXECUTE AS pour emprunter explicitement l'identité d'un autre utilisateur est similaire à l'utilisation de SETUSER dans les anciennes versions de SQL Server. Pour plus d'informations, consultez EXECUTE AS ou SETUSER.
Basculement de contexte explicite au niveau du serveur
Pour faire passer le contexte d'exécution au niveau du serveur, utilisez l'instruction EXECUTE AS LOGIN = 'login_name'. Le nom de connexion doit être visible en tant qu'entité de sécurité dans sys.server_principals et l'appelant de l'instruction doit disposer de l'autorisation IMPERSONATE sur le nom de connexion spécifié.
Lorsque le contexte d'exécution se trouve au niveau du serveur, l'étendue de l'emprunt d'identité est la suivante :
Le jeton de connexion de login_name est authentifié par l'instance de SQL Server et est valide sur toute cette instance.
Les autorisations et les appartenances aux rôles au niveau du serveur de login_name sont respectées.
Utilisez l'instruction REVERT pour revenir au contexte précédent. L'appelant de l'instruction REVERT doit se trouver dans la même base de données que celle dans laquelle l'emprunt d'identité s'est produit.
Exemple
Dans l'exemple suivant, Peter Connelly (un administrateur réseau de Adventure Works Cycles) souhaite créer un compte de connexion SQL Server pour un nouvel employé nommé Jinghao Liuhas. La connexion SQL Server de Peter ne dispose pas de l'autorisation requise au niveau du serveur pour créer des connexions SQL Server, mais elle possède l'autorisation IMPERSONATE sur adventure-works\dan1, une connexion SQL Server qui dispose, elle, de l'autorisation requise au niveau du serveur. Lorsque Peter se connecte à SQL Server, le contexte d'exécution de la session est dérivé de sa connexion SQL Server. Pour créer une connexion SQL Server, Peter adopte temporairement le contexte d'exécution de adventure-works\dan1. Il crée ensuite la connexion. Pour terminer, il abandonne les autorisations qu'il a empruntées.
-- 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;
Basculement de contexte explicite au niveau de la base de données
Pour faire passer le contexte au niveau de la base de données, utilisez l'instruction EXECUTE AS USER = 'user_name'. Le nom d'utilisateur doit exister en tant qu'entité de sécurité dans sys.database_principals et l'appelant de l'instruction doit disposer des autorisations IMPERSONATE sur le nom d'utilisateur spécifié.
Lorsque le contexte d'exécution se trouve au niveau de la base de données, l'étendue de l'emprunt d'identité est la suivante :
Le jeton utilisateur de user_name est authentifié par l'instance de SQL Server et est valide dans la base de données en cours. Pour plus d'informations sur la manière d'étendre l'emprunt d'identité d'un utilisateur au-delà de la portée de la base de données en cours, consultez Prolongement de l'emprunt d'identité au niveau de la base de données à l'aide de EXECUTE AS.
Les autorisations et les appartenances aux rôles au niveau de la base de données de user_name pour la base de données en cours sont respectées. Les autorisations au niveau du serveur accordées explicitement aux identités dans le jeton d'utilisateur ou par l'intermédiaire des appartenances aux rôles ne sont pas respectées.
Utilisez l'instruction REVERT pour revenir au contexte précédent. L'appelant de l'instruction REVERT doit se trouver dans la même base de données que celle dans laquelle l'emprunt d'identité s'est produit.
Exemple
Dans l'exemple suivant, François Ajenstat, un administrateur de base de données pour Adventure Works Cycles, souhaite exécuter l'instruction DBCC CHECKDB sur la base de données AdventureWorksDW, mais ne dispose pas des autorisations nécessaires au niveau de la base de données. Cependant, il possède les autorisations IMPERSONATE sur l'utilisateur dan1, compte disposant de l'autorisation requise.
Lorsque François se connecte à la base de données AdventureWorksDW, le contexte d'exécution établit une correspondance à son jeton de sécurité d'utilisateur. Les autorisations d'exécution d'instructions sont vérifiées par rapport aux entités de sécurité principale et secondaire contenues dans son jeton d'utilisateur. Comme il ne dispose pas des autorisations requises pour exécuter l'instruction DBCC CHECKDB, il exécute les instructions ci-dessous.
-- 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;
Basculement de contexte implicite
Le contexte d'exécution d'un module (tel qu'une procédure stockée, un déclencheur, une file d'attente ou une fonction définie par l'utilisateur) peut être modifié implicitement en spécifiant un nom d'utilisateur ou de connexion dans une clause EXECUTE AS au sein de la définition de module.
En spécifiant le contexte dans lequel s'exécute le module, vous pouvez contrôler le compte d'utilisateur employé par SQL Server pour valider les autorisations sur tout objet référencé par le module. Cela fournit davantage de souplesse et de contrôle dans la gestion des autorisations au sein de la chaîne d'objet qui existe entre les modules définis par l'utilisateur et les objets référencés par ceux-ci. Des autorisations peuvent être accordées aux utilisateurs sur le module lui-même, sans qu'il soit nécessaire de leur accorder des autorisations explicites sur les objets référencés. Seul l'utilisateur dont le module emprunte l'identité doit disposer d'autorisations sur les objets auxquels ce module accède.
Le niveau d'emprunt d'identité est déterminé par le type de module dans lequel l'emprunt d'identité est défini.
L'emprunt d'identité au niveau du serveur peut être défini dans les éléments suivants :
- Déclencheurs DDL
L'étendue de l'emprunt d'identité au niveau du serveur est identique à celle définie précédemment dans la section « Basculement de contexte explicite au niveau du serveur ».
L'emprunt d'identité au niveau de la base de données peut être défini dans les éléments suivants :
Déclencheurs DML
Files d'attente
Procédures stockées
Fonctions définies par l'utilisateur
L'étendue de l'emprunt d'identité au niveau de la base de données est identique à celle définie précédemment dans la section « Basculement de contexte explicite au niveau de la base de données ».
Pour plus d'informations sur le basculement de contexte implicite, consultez Utilisation de EXECUTE AS dans des modules.
Exemple
Dans l'exemple suivant, Mary est la propriétaire de la table MyTable. Elle veut que l'utilisateur Scott puisse tronquer cette table, mais Scott ne dispose d'aucune autorisation directe sur la table. Elle crée donc la procédure stockée dbo.usp_TruncateMyTable et accorde à Scott les autorisations EXECUTE sur la procédure. Lorsque Scott exécute la procédure stockée, le moteur de base de données vérifie les autorisations de tronquer la table comme si Mary elle-même exécutait cette procédure. Comme elle est la propriétaire de la table, l'instruction réussit, même si Scott ne dispose d'aucune autorisation directe sur la table proprement dite.
CREATE PROCEDURE dbo.usp_TruncateMyTable
WITH EXECUTE AS SELF
AS TRUNCATE TABLE MyDB..MyTable;
Voir aussi