Liens dans la sécurité d'intégration du CLR
Cette section décrit comment des éléments de code utilisateur peuvent s’appeler dans SQL Server, soit dans Transact-SQL, soit dans l’un des langages managés. Ces relations entre objets sont connues sous le nom de liens.
Liens d'appel
Les liens d’appel correspondent à un appel de code, soit à partir d’un utilisateur appelant un objet (tel qu’un lot Transact-SQL appelant une procédure stockée), soit une procédure stockée ou une fonction CLR (Common Language Runtime). Les liens d'appel provoquent la vérification d'une autorisation EXECUTE sur l'appelé.
Liens d'accès de table
Les liens d'accès de table correspondent à l'extraction ou à la modification de valeurs dans une table, une vue ou une fonction table. Ils sont semblables aux liens d'appel, mais offrent un contrôle d'accès affiné en ce qui concerne les autorisations SELECT, INSERT, UPDATE et DELETE.
Liens contrôlés
Les liens contrôlés signifient que pendant l'exécution, les autorisations ne sont pas vérifiées dans toute la relation d'objet une fois qu'elle a été établie. Lorsqu'il y a un lien contrôlé entre deux objets (par exemple, l'objet x et l'objet y), les autorisations sur l'objet y et autres objets accédés à partir de l'objet y sont vérifiés 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. Lors de l'exécution (par exemple, lorsque quelqu'un appelle l'objet x), il n'y a aucune autorisation vérifiée par rapport à y ou autres objets auquel il fait référence de manière statique. Lors de l'exécution, une autorisation appropriée est vérifiée par rapport à l'objet x lui-même.
Les liens contrôlés sont toujours utilisés conjointement à une dépendance de métadonnées entre deux objets. Cette dépendance de métadonnées est une relation établie dans SQL Server catalogues qui empêche la suppression d’un objet tant qu’un autre objet en dépend.
Les liens contrôlés sont utiles lorsqu'il n'est ni approprié ou réalisable d'accorder des autorisations à de nombreux objets dépendants. Les liaisons contrôlées sont introduites entre les objets qui définissent des points d’entrée Transact-SQL dans des assemblys CLR (par exemple, des procédures CLR, des déclencheurs, des fonctions, des types et des agrégats) et les assemblys à partir desquels ils sont définis. La sécurité contrôlée sur ces objets implique que pour 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 obligé d'avoir des autorisations sur cet assembly ou tout autre assembly auquel il fait référence de manière statique. Les autorisations sur l’assembly sont vérifiées au moment de la création du point d’entrée Transact-SQL.
Sécurité SQL Server basée sur l'autorisation
Voici les règles de base derrière la SQL Server vérifications de sécurité pour les appels d’objets de base de données clr et entre les objets de base de données clr ; les trois premières règles définissent les autorisations qui sont vérifiées et par rapport à quel objet ; la quatrième règle définit le contexte d’exécution sur lequel l’autorisation est vérifiée.
Tous les appels requièrent l'autorisation
EXECUTE, à moins que les appels ne se produisent dans le même objet ; cela signifie que les appels dans le même assembly ne nécessitent aucun contrôle d'autorisation. L'autorisation est contrôlée au moment de l'exécution.Les liens contrôlés requièrent l'autorisation
REFERENCEpar rapport à l'appelé lorsque l'objet appelant est créé. L'autorisation est contrôlée pour le propriétaire de l'objet appelant lorsque l'objet est créé.Les liens d'accès de table requièrent l'autorisation
SELECT,INSERT,UPDATEouDELETEcorrespondant pra rapport à la table ou vue qui est accédée.L'autorisation est contrôlée par rapport au contexte d'exécution actuel. Il est possible de créer des procédures et fonctions avec un contexte d'exécution différent de l'appelant. Un assembly est toujours créé avec le contexte d'exécution de la procédure, de la fonction ou du déclencheur défini contre lui.