Partager via

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

Applies to:SQL ServerAzure 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.

These code checks provide flexibility for registering third-party assemblies especially, so that an assembly isn't blocked where there's unsafe code designed to run in a client environment, but would never be executed in the hosted common language runtime (CLR). 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 la sécurité de l’accès au code d’intégration CLR.

If the publisher policy is set, CREATE ASSEMBLY fails.

La sécurité d’accès du code n’est plus prise en charge

CLR utilise la sécurité d’accès du code (CAS) dans le .NET Framework, qui n’est plus pris en charge comme limite de sécurité. Un assembly CLR créé avec PERMISSION_SET = SAFE pourrait être en mesure d’accéder à des ressources système externes, d’appeler du code non managé et d’acquérir des privilèges sysadmin. Dans SQL Server 2017 (14.x) et versions ultérieures, l’option sp_configure, clr strict security, améliore la sécurité des assemblys CLR. clr strict security est activée par défaut et traite les assemblys SAFE et EXTERNAL_ACCESS comme s’ils étaient marqués UNSAFE. L’option clr strict security peut être désactivée pour assurer une compatibilité descendante, mais cela n’est pas recommandé.

Nous vous recommandons de signer tous les assemblys par un certificat ou une clé asymétrique, avec une connexion correspondante à laquelle a été accordée l’autorisation UNSAFE ASSEMBLY dans la base de données master. Les administrateurs SQL Server peuvent également ajouter des assemblys à une liste d’assemblys, que le moteur de base de données doit approuver. For more information, see sys.sp_add_trusted_assembly.

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.

Runtime checks

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 la programmation d’intégration CLR.

SAFE

Toutes les conditions EXTERNAL_ACCESS sont vérifiées.

Related content

  • Last updated on