Partager via

Restrictions du modèle de programmation d’intégration CLR

Lorsque vous créez une procédure stockée managée ou un autre objet de base de données managée, certaines vérifications de code effectuées par SQL Server effectuent des vérifications sur l’assembly de code managé lorsqu’il est inscrit pour la première fois dans la base de données, à l’aide de l’instruction, et également au moment de l’exécution CREATE ASSEMBLY . Le code managé est également vérifié au moment de l’exécution, car dans un assembly, il peut y avoir des chemins de code qui ne peuvent jamais être réellement atteints au moment de l’exécution. Cela permet d’inscrire des assemblys tiers, en particulier, afin qu’un assembly ne soit pas bloqué lorsqu’il existe un code « non sécurisé » conçu pour s’exécuter dans un environnement client, mais qu’il n’est jamais exécuté dans le CLR hébergé. Les exigences que le code managé doit respecter varient selon que l’assembly est inscrit en tant que SAFE, EXTERNAL_ACCESSou UNSAFE, SAFE étant le plus strict et répertorié ci-dessous.

En plus des restrictions imposées sur les assemblys de code managé, des autorisations de sécurité du code sont également accordées. Le Common Language Runtime (CLR) prend en charge un modèle de sécurité appelé sécurité d’accès au code (CAS) pour le code managé. Dans ce modèle, les autorisations sont accordées aux assemblys selon l'identité du code. Les assemblys SAFE, EXTERNAL_ACCESS et UNSAFE ont des autorisations de sécurité d'accès du code différentes. Pour plus d’informations, consultez CLR Integration Code Access Security.

CREATE ASSEMBLY Checks

Lorsque l’instruction CREATE ASSEMBLY est exécutée, les vérifications suivantes sont effectuées pour chaque niveau de sécurité. Si une vérification échoue, CREATE ASSEMBLY échoue avec un message d’erreur.

Global (tout niveau de sécurité)

Tous les assemblys référencés doivent satisfaire un ou plusieurs des critères suivants :

  • L'assembly est déjà inscrit dans la base de données.

  • L'assembly est l'un des assemblys pris en charge. Pour plus d’informations, consultez Bibliothèques .NET Framework prises en charge.

  • Vous utilisez CREATE ASSEMBLY FROM<l’emplacement>, et tous les assemblys référencés et leurs dépendances sont disponibles à <l’emplacement>.

  • Vous utilisez CREATE ASSEMBLY FROM<des octets ...>, et toutes les références sont spécifiées par le biais d’octets séparés par espace.

EXTERNAL_ACCESS

Tous les assemblys EXTERNAL_ACCESS doivent répondre aux critères suivants :

  • Les champs statiques ne sont pas utilisés pour stocker des informations. Les champs statiques en lecture seule sont autorisés.

  • Le test PEVerify est réussi. L’outil PEVerify (peverify.exe), qui vérifie que le code MSIL et les métadonnées associées répondent aux exigences de sécurité de type, est fourni avec le Kit de développement logiciel (SDK) .NET Framework.

  • La synchronisation, par exemple avec la SynchronizationAttribute classe, n’est pas utilisée.

  • Les méthodes finaliseur ne sont pas utilisées.

Les attributs personnalisés suivants sont interdits dans les assemblys EXTERNAL_ACCESS :

  • System.ContextStaticAttribute

  • System.MTAThreadAttribute

  • System.Runtime.CompilerServices.MethodImplAttribute

  • System.Runtime.CompilerServices.CompilationRelaxationsAttribute

  • System.Runtime.Remoting.Contexts.ContextAttribute

  • System.Runtime.Remoting.Contexts.SynchronizationAttribute

  • System.Runtime.InteropServices.DllImportAttribute

  • System.Security.Permissions.CodeAccessSecurityAttribute

  • System.Security.SuppressUnmanagedCodeSecurityAttribute

  • System.Security.UnverifiableCodeAttribute

  • System.STAThreadAttribute

  • System.ThreadStaticAttribute

SÛR

  • Toutes les conditions d'assembly EXTERNAL_ACCESS sont vérifiées.

Vérifications du runtime

Pendant l'exécution, les conditions suivantes sont vérifiées pour l'assembly de code. Si l’une de ces conditions est trouvée, le code managé n’est pas autorisé à s’exécuter et une exception est levée.

DANGEREUX

Le chargement d’un assembly explicitement en appelant la System.Reflection.Assembly.Load() méthode à partir d’un tableau d’octets ou implicitement à l’aide de l’espace de Reflection.Emit noms n’est pas autorisé.

EXTERNAL_ACCESS

Toutes les conditions UNSAFE sont vérifiées.

Tous les types et méthodes annotés avec les valeurs d'attribut de protection de l'hôte suivantes dans la liste d'assemblys prise en charge sont interdits.

  • SelfAffectingProcessMgmt

  • SelfAffectingThreading

  • Synchronisation

  • SharedState

  • ExternalProcessMgmt

  • ExternalThreading

  • SecurityInfrastructure

  • MayLeakOnAbort

  • interface utilisateur

Pour plus d’informations sur les hpas et une liste de types et de membres non autorisés dans les assemblys pris en charge, consultez Attributs de protection de l’hôte et programmation d’intégration CLR.

SÛR

Toutes les conditions EXTERNAL_ACCESS sont vérifiées.

Voir aussi

Bibliothèques .NET Framework prises en charge
Sécurité de l’accès au code d’intégration CLR
Attributs de protection de l’hôte et programmation d’intégration CLR
Création d’un assembly