Partager via

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

  • Article

Lorsque le code managé accède à des ressources externes, SQL Server n’emprunte pas automatiquement l’identité du contexte d’exécution actuel dans 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.

Notes

Pour plus d’informations sur les changements de comportement dans l’emprunt d’identité, consultez Modifications cassants des fonctionnalités du moteur de base de données dans SQL Server 2014.

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.

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

Les EXTERNAL_ACCESS assemblys et UNSAFE les assemblys accèdent aux ressources du système d’exploitation avec le compte de service SQL Server, sauf s’ils 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. Seules les connexions qui sont approuvées pour exécuter du code sous le compte de service SQL Server doivent bénéficier de l’autorisationEXTERNAL ACCESS.

Voir aussi

Sécurité de l'intégration du CLR
Emprunt d'identité et informations d'identification pour les connexions