Partager via


Liens dans CLR Integration Security

Cette section décrit comment les éléments de code utilisateur peuvent s’appeler mutuellement dans SQL Server, soit dans Transact-SQL, soit dans l’une des langues gérées. Ces relations entre les objets sont appelées liens.

Les liens d’appel correspondent à un appel de code, soit à partir d’un utilisateur appelant un objet (par exemple, un lot Transact-SQL appelant une procédure stockée), soit une procédure stockée CLR (Common Language Runtime) ou une fonction stockée. Les liens d’appel entraînent la vérification d’une EXECUTE autorisation sur l’appelé.

Les liens d’accès aux tables correspondent à la récupération ou à la modification de valeurs dans une table, une vue ou une fonction table. Ils sont similaires aux liens d’appel, sauf qu’ils ont un contrôle d’accès plus précis en termes d’autorisations SELECT, INSERT, UPDATE et DELETE.

Les liens contrôlés signifient qu’au cours de l’exécution, les autorisations ne sont pas vérifiées dans la relation d’objet une fois qu’elles ont été établies. Lorsqu’il existe un lien contrôlé entre deux objets (par exemple, l’objet x et l’objet y), les autorisations sur l’objet y et d’autres objets accessibles à partir de l’objet y sont vérifiées uniquement au moment de la création de l’objet x. Au moment de la création de l’objet x, REFERENCE l’autorisation est vérifiée sur y par rapport au propriétaire de x. Au moment de l’exécution(par exemple, lorsqu’une personne appelle un objet x), aucune autorisation n’est vérifiée sur y ou sur d’autres objets qu’elle référence statiquement. Au moment de l’exécution, une autorisation appropriée est vérifiée sur l’objet x lui-même.

Les liens avec contrôle sont toujours utilisés conjointement avec une dépendance de métadonnées entre deux objets. Cette dépendance de métadonnées est une relation établie dans les catalogues SQL Server qui empêche la suppression d’un objet tant qu’un autre objet dépend de celui-ci.

Les liens avec contrôle sont utiles lorsqu’il n’est pas approprié ou gérable d’accorder des autorisations à de nombreux objets dépendants. Les liens avec contrôle sont introduits entre les objets qui définissent Transact-SQL points d’entrée dans les assemblys CLR (par exemple, les procédures CLR, les déclencheurs, les fonctions, les types et les agrégats) et les assemblys à partir desquels ils sont définis. La sécurité contrôlée contre ces objets implique qu’afin d’appeler un point d’entrée Transact-SQL défini dans un assembly CLR, l’appelant a uniquement besoin d’une autorisation appropriée sur ce point d’entrée Transact-SQL. L’appelant n’est pas tenu d’avoir des autorisations sur cet assembly ou d’autres assemblys qu’il référence statiquement. Les autorisations sur l’assembly sont vérifiées au moment de la création du point d’entrée Transact-SQL.

Sécurité Authorization-Based SQL Server

Voici les règles de base derrière les vérifications de sécurité SQL Server pour les appels d’objets de base de données CLR et entre eux ; les trois premières règles définissent quelles autorisations sont vérifiées et sur quel objet ; la quatrième règle définit le contexte d’exécution sur lequel l’autorisation est vérifiée.

  1. Tous les appels nécessitent EXECUTE une autorisation, sauf si les appels se produisent dans le même objet ; cela signifie que les appels dans le même assembly ne nécessitent pas de vérifications d’autorisation. L’autorisation est vérifiée au moment de l’exécution.

  2. Les liens avec contrôle nécessitent REFERENCE l’autorisation sur l’appelé lors de la création de l’objet appelant. L’autorisation est vérifiée pour le propriétaire de l’objet appelant lors de la création de l’objet.

  3. Les liens d’accès aux tables nécessitent l’accès à la table ou à l’affichage correspondantSELECTINSERTUPDATE, ou DELETE l’autorisation d’accès à la table ou à la vue.

  4. L’autorisation est vérifiée par rapport au contexte d’exécution actuel. Les procédures et fonctions peuvent être créées avec un contexte d’exécution différent de l’appelant. Les assemblys sont toujours créés avec le contexte d’exécution de la procédure, de la fonction ou du déclencheur qui est défini sur celui-ci.

Voir aussi

Sécurité de l’intégration du CLR