Liens dans la sécurité d'intégration du CLR

Cette section décrit la façon dont les parties de code utilisateur peuvent s'appeler dans SQL Server, en langage Transact-SQL ou 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 un utilisateur qui appelle un objet (tel qu'un lot Transact-SQL qui appelle une procédure stockée), soit une procédure stockée ou une fonction CLR. 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. Lors de la création de l'objet x, l'autorisation REFERENCE 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 les catalogues SQL Server qui empêche un objet d'être supprimé tant qu'un autre objet dépend de lui.

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. Ils sont utilisés dans SQL Server 2000 pour les colonnes calculées et les colonnes de texte intégral indexées. À compter de SQL Server 2005, des liens contrôlés sont introduits entre les objets qui définissent des points d'entrée Transact-SQL dans des assemblys CLR (par exemple, des procédures, déclencheurs, fonctions, types et agrégats CLR) et les assemblys à partir desquels ils sont définis. La sécurité contrôlée contre ces objets implique que pour appeler un point d'entrée Transact-SQL défini dans un assembly CLR, l'appelant n'a besoin que 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

Vous trouverez ci-dessous les règles de base sous-jacentes aux contrôles de sécurité SQL Server pour les appels de et entre des objets de base de données basés sur le CLR ; les trois premières règles définissent les autorisations qui sont contrôlées et contre quel objet ; la quatrième règle définit le contexte d'exécution par rapport auquel l'autorisation est contrôlée.

  1. 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.

  2. Les liens contrôlés requièrent l'autorisation REFERENCE par 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éé.

  3. Les liens d'accès de table requièrent l'autorisation SELECT, INSERT, UPDATE ou DELETE correspondant pra rapport à la table ou vue qui est accédée.

  4. 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.