Partager via

  • Article

Utilisation de EXECUTE AS dans des modules

EXECUTE AS peut être utilisé pour définir le contexte d'exécution des modules définis par l'utilisateur suivants : fonctions, procédures, files d'attente et déclencheurs. Par exemple, le contexte d'exécution peut basculer de l'appelant du module au propriétaire du module ou à un utilisateur spécifié. Dans les versions antérieures de SQL Server, ces modules s'exécutent toujours dans le contexte de l'appelant du module.

En spécifiant le contexte dans lequel le module s'exécute, vous pouvez contrôler le compte d'utilisateur utilisé par le Moteur de base de données pour valider les autorisations sur tout objet auquel le module fait référence. Cela procure une flexibilité et un contrôle accrus de la gestion des autorisations dans la chaîne d'objets qui existe entre les modules définis par l'utilisateur et les objets auxquels ces modules font référence. Les utilisateurs du module ont besoin uniquement d'autorisations d'exécution du module lui-même ; aucune autorisation explicite sur les objets référencés n'est requise. Seul l'utilisateur sous le contexte duquel le module s'exécute doit posséder des autorisations sur les objets auxquels le module accède.

EXECUTE AS CALLER

EXECUTE AS CALLER spécifie que les instructions à l'intérieur du module sont exécutées dans le contexte de l'appelant du module.

Utilisez EXECUTE AS CALLER dans les scénarios suivants :

  • Vous souhaitez que les instructions du module s'exécutent dans le contexte de l'utilisateur appelant.

  • Vous souhaitez baser les vérifications d'autorisations pour les instructions du module contre l'utilisateur appelant et vous fier uniquement sur le chaînage de propriété pour contourner les vérifications d'autorisations sur les objets sous-jacents. Souvenez-vous que le chaînage de propriété s'applique uniquement aux instructions DML. Pour plus d'informations sur le chaînage de propriété, consultez Chaînes de propriétés.

  • Votre application n'exige pas de cacher à l'utilisateur les objets référencés sous-jacents ou vous faites référence uniquement à des objets de la même propriété et pouvez par conséquent vous fier au chaînage de propriété pour cacher le schéma.

  • Vous souhaitez préserver le comportement de SQL Server 2000.

Scénario de EXECUTE AS CALLER

Mary crée une procédure stockée qui fait référence à une table dont elle n'est pas propriétaire mais pour laquelle elle dispose d'autorisations SELECT. Elle spécifie EXECUTE AS CALLER dans l'instruction CREATE PROCEDURE, comme illustré dans l'exemple suivant :

CREATE PROCEDURE AccessTable
WITH EXECUTE AS CALLER
AS SELECT * FROM dbo.SomeTable;

Mary accorde ensuite à Scott des autorisations EXECUTE sur la procédure stockée. Lorsque Scott exécute la procédure stockée, le Moteur de base de données vérifie qu'il (l'appelant) en a l'autorisation. Scott dispose de l'autorisation EXECUTE, mais Mary n'étant pas propriétaire de la table à laquelle il est fait référence, le Moteur de base de données vérifie si Scott possède des autorisations sur la table. Si ce n'est pas le cas, l'instruction de procédure stockée échoue.

EXECUTE AS user_name

EXECUTE AS user_name spécifie que les instructions à l'intérieur du module s'exécutent dans le contexte de l'utilisateur spécifié dans user_name.

Utilisez EXECUTE AS user_name dans les scénarios suivants :

  • Vous souhaitez que les instructions du module s'exécutent dans le contexte d'un utilisateur spécifié.

  • Vous ne pouvez pas vous fier au chaînage de propriété (par exemple, le module accède à des objets avec différentes propriétés) pour cacher le schéma sous-jacent et vous souhaitez éviter d'accorder des autorisations sur ces objets référencés.

  • Vous souhaitez créer un jeu d'autorisations personnalisé. Par exemple, pour fournir des autorisations à des opérations DDL pour lesquelles des autorisations spécifiques ne sont normalement pas accordées. Pour plus d'informations, consultez Utilisation d'EXECUTE AS pour créer des jeux d'autorisations personnalisés.

    [!REMARQUE]

    Un utilisateur spécifié comme contexte d'exécution d'un module ne peut pas être supprimé tant que le contexte d'exécution de ce module n'a pas changé.

Scénario de EXECUTE AS user_name

Mary crée une procédure stockée qui fait référence à une table dont elle n'est pas propriétaire mais pour laquelle elle dispose d'autorisations SELECT. Elle spécifie EXECUTE AS 'Mary' dans l'instruction CREATE PROCEDURE, comme illustré dans l'exemple suivant :

CREATE PROCEDURE AccessMyTable
WITH EXECUTE AS 'Mary'
AS SELECT * FROM dbo.MyTable;

Mary accorde à Scott des autorisations EXECUTE sur la procédure stockée. Lorsque Scott exécute la procédure stockée, le Moteur de base de données vérifie qu'il en a l'autorisation ; toutefois, les autorisations pour la table à laquelle il est fait référence sont vérifiées pour Mary. Dans ce scénario, bien que Scott n'ait pas directement d'autorisation SELECT sur la table, il peut accéder aux données par le biais de la procédure car Mary, dans le contexte de laquelle la procédure s'exécute, a l'autorisation d'accéder aux données de la table.

EXECUTE AS SELF

EXECUTE AS SELF est équivalent à EXECUTE AS user_name, où l'utilisateur spécifié est la personne qui crée ou modifie le module.

Utilisez EXECUTE AS SELF dans les scénarios suivants :

  • Vous souhaitez un raccourci pour vous spécifier en tant qu'utilisateur dans le contexte duquel vous souhaitez exécuter les instructions du module que vous créez ou modifiez.

  • Vous avez une application qui crée des modules pour les utilisateurs qui l'appellent et vous souhaitez que ces modules soient créés avec ces utilisateurs comme contexte d'exécution. Dans ce scénario, vous ne connaissez pas, au moment de la conception, le nom d'utilisateur de l'appelant.

EXECUTE AS OWNER

EXECUTE AS OWNER spécifie que les instructions à l'intérieur du module sont exécutées dans le contexte du propriétaire actuel du module. Si le module n'a pas de propriétaire spécifié, le propriétaire du schéma du module est utilisé.

Utilisez EXECUTE AS OWNER dans le scénario suivant :

  • Vous souhaitez pouvoir modifier le propriétaire du module sans avoir à modifier le module lui-même. Autrement dit, OWNER mappe automatiquement au propriétaire actuel du module au moment de l'exécution.

OWNER est le propriétaire explicite du module ou, s'il n'y a pas de propriétaire explicite, le propriétaire du schéma du module au moment où celui-ci est exécuté. OWNER doit être un compte singleton, et non un groupe ou un rôle. La propriété du module ne peut pas être modifiée et attribuée à un groupe ou un rôle lorsque le module spécifie EXECUTE AS OWNER et qu'il a un propriétaire explicite. La propriété d'un schéma ne peut pas être modifiée et attribuée à un groupe ou un rôle lorsqu'il contient un module qui spécifie EXECUTE AS OWNER et que le module n'a pas de propriétaire explicite.

Scénario de EXECUTE AS OWNER

Mary crée une procédure stockée qui fait référence à une table dont elle est propriétaire. Elle spécifie EXECUTE AS OWNER dans l'instruction CREATE PROCEDURE, comme illustré dans l'exemple suivant :

CREATE PROCEDURE Mary.AccessMyTable
WITH EXECUTE AS OWNER
AS SELECT * FROM Mary.MyTable;

Mary accorde à Scott des autorisations EXECUTE sur la procédure stockée. Lorsque Scott exécute la procédure stockée, le Moteur de base de données vérifie qu'il en a l'autorisation ; toutefois, les autorisations pour la table à laquelle il est fait référence sont vérifiées pour Mary car c'est elle la propriétaire actuelle de la procédure. Mary décide de quitter l'entreprise et attribue la propriété de la procédure et de la table à Tom. Lorsque Scott exécute la procédure stockée après le changement de propriété, il est encore en mesure d'accéder aux données par le biais de la procédure car OWNER est automatiquement mappé à Tom.