Présentation du contexte d'exécution
Le contexte d'exécution est déterminé par l'utilisateur ou la 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 de réalisation d'actions. Le contexte d'exécution est représenté par une paire de jetons de sécurité : un jeton de connexion et un jeton d'utilisateur. Les jetons identifient la source qui sert à leur authentification et les principaux primaire et secondaires par rapport auxquels les autorisations sont vérifiées. Une connexion qui se connecte à une instance de SQL Server possède un jeton de connexion et un ou plusieurs jetons d'utilisateur, suivant le nombre de bases de données auxquelles le compte a accès.
Jetons de sécurité d'utilisateur et de connexion
Un jeton de sécurité pour un utilisateur ou une connexion contient les éléments suivants :
Un principal de serveur ou de base de données comme identité primaire
Un ou plusieurs principaux comme identités secondaires
Zéro ou plusieurs authentificateurs
Les privilèges et autorisations des identités primaire et secondaires
Les principaux sont des individus, des groupes et des processus qui peuvent demander des ressources SQL Server. Les principaux sont classés par étendue d'influence : niveau Windows, niveau SQL Server ou niveau base de données. Pour plus d'informations, consultez Entités de sécurité (moteur de base de données).
Les authentificateurs sont des principaux, des certificats ou des clés asymétriques qui se portent garants de l'authenticité du jeton. Il est courant que l'authentificateur d'un jeton soit l'instance de SQL Server. Pour plus d'informations sur les authentificateurs, consultez Prolongement de l'emprunt d'identité au niveau de la base de données à l'aide de EXECUTE AS. Pour plus d'informations sur les certificats et les clés asymétriques, consultez Hiérarchie de chiffrement.
Un jeton de connexion est valide sur l'ensemble de l'instance de SQL Server. Il contient les identités primaire et secondaires par rapport auxquelles sont vérifiées les autorisations de niveau serveur et toutes les autorisations de niveau base de données associées à ces identités. L'identité primaire est la connexion proprement dite. L'identité secondaire inclut les autorisations héritées des rôles et des groupes.
Un jeton d'utilisateur n'est valide que pour une base de données spécifique. Il contient les identités primaire et secondaires par rapport auxquelles sont vérifiées les autorisations de niveau base de données. L'identité primaire est l'utilisateur de base de données proprement dit. L'identité secondaire inclut les autorisations héritées des rôles de base de données. Les jetons d'utilisateur ne contiennent pas d'appartenances à un rôle de serveur et n'honorent pas les autorisations de niveau serveur accordées aux identités dans le jeton qui comprend celles accordées au rôle public de niveau serveur.
Si un compte d'utilisateur ou de connexion SQL Server est explicitement créé, l'ID de connexion ou d'utilisateur généré pour ce compte fait office d'identité primaire dans le jeton de connexion ou d'utilisateur. Lorsqu'un principal dispose d'un accès implicite à une instance de SQL Server ou d'un accès à une base de données par le biais d'autorisations CONTROL SERVER, l'identité primaire dans le jeton de connexion est le rôle public par défaut. L'identité primaire dans le jeton d'utilisateur est public.
Important
Les membres du rôle serveur fixe sysadmin possèdent toujours dbo comme identité primaire de leur jeton d'utilisateur.
Exemple de jeton de connexion
Mary possède une connexion SQL Server mappée avec son compte Windows MyDomain\Mary. Pour afficher les informations sur le jeton de connexion créé pour elle, Mary exécute l'instruction suivante :
SELECT principal_id, sid, name, type, usage FROM sys.login_token;
GO
Le jeu de résultats peut présenter l'aspect suivant :
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)
L'ensemble de résultats montre que le compte Windows de Mary est l'identité primaire de son jeton de connexion. Le principal_id créé lorsque son compte de connexion a été généré fait office de principal_id primaire dans le jeton de connexion. Le rôle public est répertorié en tant qu'identité secondaire car Mary est membre de ce rôle par défaut. Si Mary était membre d'autres rôles de niveau serveur, ils seraient également répertoriés en tant qu'identités secondaires. Au moment où la connexion a été créée, son compte Windows a été validé par l'instance de SQL Server. Par conséquent, lorsque Mary se connecte à l'instance de SQL Server, celle-ci est l'authentificateur de son jeton de connexion. Étant donné que l'instance de SQL Server est l'authentificateur du jeton de connexion de Mary, aucun authentificateur, tel qu'un principal, un certificat ou une clé asymétrique, n'est retourné dans la requête.
Exemple de jeton d'utilisateur
Mary possède un jeton d'utilisateur pour chaque base de données à laquelle elle a accès. Dans ce premier exemple, Mary est connectée à la base de données master. Pour afficher les informations sur le jeton d'utilisateur créé pour elle dans la base de données master, Mary exécute l'instruction suivante :
SELECT principal_id, sid, name, type, usage FROM sys.user_token;
GO
Le jeu de résultats peut présenter l'aspect suivant :
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)
L'ensemble de résultats montre que Mary n'est pas un utilisateur explicite dans la base de données master, mais qu'elle dispose d'un accès par le biais du compte guest. L'identité primaire de son jeton d'utilisateur est l'utilisateur guest. Le rôle public est répertorié en tant qu'identité secondaire car guest est membre de ce rôle par défaut. Le jeton d'utilisateur de Mary dans la base de données master contient la totalité des autorisations et des privilèges de niveau base de données pour l'utilisateur guest et le rôle public.
Dans l'exemple suivant, un compte d'utilisateur explicite a été créé pour Mary dans la base de données Sales. En outre, elle a été ajoutée au rôle de base de données fixe db_ddladmin de cette base de données. En utilisant la base de données Sales comme base de données actuelle, Mary réexécute l'instruction SELECT * FROM sys.user_token.
Le jeu de résultats peut présenter l'aspect suivant :
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
Cet ensemble de résultats reflète le jeton d'utilisateur créé pour Mary dans la base de données Sales. Étant donné que Mary a été explicitement ajoutée en tant qu'utilisateur à la base de données Sales, elle est répertoriée en tant qu'identité primaire. Les deux rôles dont elle est membre sont répertoriés en tant qu'identités secondaires. L'authentificateur du jeton d'utilisateur de Mary est l'instance de SQL Server.
Changement de contexte d'exécution
Dans SQL Server, vous pouvez modifier explicitement le contexte d'exécution d'une session en spécifiant un nom d'utilisateur ou de connexion dans une instruction EXECUTE AS. Vous pouvez modifier implicitement le contexte d'exécution d'un module, tel qu'une procédure stockée, un déclencheur ou une fonction définie par l'utilisateur, en spécifiant un nom d'utilisateur ou de connexion dans une clause EXECUTE AS de la définition du module. Lorsque le contexte d'exécution est basculé vers un autre utilisateur ou une autre connexion, SQL Server vérifie les autorisations par rapport aux jetons de connexion et d'utilisateur de ce compte. L'identité de ce compte est essentiellement empruntée pour la durée de la session ou de l'exécution du module. Pour plus d'informations, consultez Description du basculement de contexte.