Partager via

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

  • Article

S’applique à : SQL Server Azure SQL Managed Instance

Lorsque vous générez une procédure stockée managée ou un autre objet de base de données managée, SQL Server effectue certaines vérifications de code qui doivent être prises en compte. Ces vérifications sont effectuées sur l’assembly de code managé lors de la première inscription dans la base de données, à l’aide de l’instruction et également lors 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 réellement être atteints au moment de l’exécution.

Ces vérifications de code offrent une flexibilité pour l’inscription d’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 Common Language Runtime (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 est le niveau de sécurité le plus strict.

En plus des restrictions imposées sur les assemblys de code managé, des autorisations de sécurité du code sont également accordées. Le CLR prend en charge un modèle de sécurité appelé sécurité d'accès du 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.

Si la stratégie d’éditeur est définie, CREATE ASSEMBLY échoue.

Vérifications CREATE ASSEMBLY

Lorsque l’instruction CREATE ASSEMBLY s’exécute, 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 <location>, et tous les assemblys référencés et leurs dépendances sont disponibles dans <location>.

  • Vous utilisez CREATE ASSEMBLY FROM <bytes ...>et toutes les références sont spécifiées via des 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 CIL (Common Intermediate Language) 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

SAFE

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

Vérifications à l’exécution

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.

UNSAFE

Vous ne pouvez pas charger un assembly, soit explicitement en appelant la System.Reflection.Assembly.Load() méthode à partir d’un tableau d’octets, soit en utilisant implicitement l’espace Reflection.Emit de noms.

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
  • Synchronization
  • SharedState
  • ExternalProcessMgmt
  • ExternalThreading
  • SecurityInfrastructure
  • MayLeakOnAbort
  • UI

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.

SAFE

Toutes les conditions EXTERNAL_ACCESS sont vérifiées.

Contenu connexe