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

Lorsque le code managé accède aux 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 EXTERNAL_ACCESS et UNSAFE les assemblys peut emprunter explicitement l’identité du contexte d’exécution actuel.

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

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

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

• Pour le code managé s’exécutant de manière asynchrone (par exemple, par le biais UNSAFE d’assemblys créant des threads et d’exécution de code de manière asynchrone), l’accès aux données in-process n’est jamais autorisé. C’est vrai s’il y a ou non l’emprunt d’identité.

Lorsque le code s’exécute dans un contexte emprunt d’identité 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 du 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 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. En raison de cela, les auteurs d’assemblys EXTERNAL_ACCESS nécessitent un niveau de confiance supérieur à celui des SAFE assemblys, qui est spécifié par l’autorisation au niveau de la EXTERNAL ACCESS connexion. Seules les connexions approuvées pour exécuter du code sous le compte de service SQL Server doivent recevoir l’autorisation EXTERNAL ACCESS .

Voir aussi

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