Partager via

Emprunt d'identité et sécurité de l'intégration du CLR

  • Article

Lorsque du code managé accède à des ressources externes, SQL Server n'emprunte pas automatiquement l'identité du contexte d'exécution actuel sous lequel la routine s'exécute. Le code dans les assemblys EXTERNAL_ACCESS et UNSAFE peut emprunter l'identité du contexte d'exécution actuel de manière explicite.

[!REMARQUE]

Pour plus d'informations sur les différences de comportement au niveau de l'emprunt d'identité, consultez Changements essentiels dans les fonctionnalités du moteur de base de données de SQL Server 2012.

Le fournisseur d'accès aux données in-process fournit une interface de programmation d'applications, SqlContext.WindowsIdentity, qui peut être utilisée pour extraire le jeton associé au contexte de sécurité actuel. Le code managé dans les assemblys EXTERNAL_ACCESS et UNSAFE peut utiliser cette méthode pour extraire le contexte et utiliser la méthode WindowsIdentity.Impersonate .NET Framework pour emprunter l'identité de contexte. Les restrictions suivantes s'appliquent lorsque le code utilisateur emprunte l'identité de manière explicite :

  • L'accès aux données in-process n'est pas autorisé lorsque le code managé est dans un état d'emprunt d'identité. Le code peut annuler l'emprunt d'identité, puis appeler l'accès aux données in-process. Notez que cela requiert le stockage de la valeur de retour (un objet WindowsImpersonationContext) de la méthode Impersonate d'origine, puis l'appel à la méthode Undo sur ce WindowsImpersonationContext.

    Cette restriction signifie que lorsque l'accès aux données in-process se produit, c'est toujours dans le contexte de sécurité actuel effectif pour la session. Cela ne peut pas être modifié par l'emprunt d'identité explicite dans le code managé.

  • Pour le code managé qui s'exécute de façon asynchrone (par exemple, par le biais d'assemblys UNSAFE créant des threads et exécutant du code de façon asynchrone), l'accès aux données in-process n'est jamais autorisé. Cela est vrai qu'il y ait emprunt d'identité ou non.

Lorsque le code s'exécute dans un contexte dont l'identité a été empruntée qui est différent de SQL Server, il ne peut pas effectuer d'appels d'accès aux données in-process ; il doit annuler le contexte d'emprunt d'identité avant d'effectuer des appels d'accès aux données in-process. Lorsque l'accès aux données in-process est effectué à partir de code managé, le contexte d'exécution d'origine du point d'entrée Transact-SQL dans le code managé est toujours utilisé pour l'autorisation.

Les assemblys EXTERNAL_ACCESS et UNSAFE accèdent tous deux aux ressources de système d'exploitation avec le compte de service SQL Server, à moins qu'ils n'empruntent volontairement l'identité du contexte de sécurité actuel comme décrit précédemment. Pour cette raison, les auteurs des assemblys EXTERNAL_ACCESS nécessitent un niveau supérieur d'approbation que ceux des assemblys SAFE, spécifié par l'autorisation au niveau de la connexion EXTERNAL ACCESS. L'autorisation EXTERNAL ACCESS doit être accordée uniquement aux connexions approuvées pour exécuter du code sous le compte de service SQL Server.

Voir aussi

Concepts

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

Emprunt d'identité et informations d'identification pour les connexions