Partager via

Présentation du contexte d'exécution

  • Article

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 entités de sécurité primaire et secondaires par rapport auxquelles 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 :

  • Une entité de sécurité de serveur ou de base de données comme identité primaire
  • Une ou plusieurs entités de sécurité comme identités secondaires
  • Zéro ou plusieurs authentificateurs
  • Les privilèges et autorisations des identités primaire et secondaires

Les entités de sécurité sont des individus, des groupes et des processus qui peuvent demander des ressources SQL Server. Les entités de sécurité sont classées 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é.

Les authentificateurs sont des entités de sécurité, 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ègles 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'une entité de sécurité 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.

ms187096.note(fr-fr,SQL.90).gifImportant :
Les membres du rôle de 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

L'ensemble 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'une entité de sécurité, 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

L'ensemble de résultats peut être identique à celui-ci :

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.

L'ensemble 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 2005, 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 et Chaînes de propriétés et changement de contexte.

Voir aussi

Concepts

Entités de sécurité

Autres ressources

Changement de contexte
EXECUTE (Transact-SQL)
EXECUTE AS (Transact-SQL)
Clause EXECUTE AS (Transact-SQL)
sys.database_principals (Transact-SQL)
sys.server_principals (Transact-SQL)

Aide et Informations

Assistance sur SQL Server 2005