Restrictions du modèle de programmation de l'intégration du CLR

  • Article

S’applique à :SQL ServerAzure SQL Managed Instance

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 doivent être prises en compte. SQL Server effectue 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 CREATE ASSEMBLY, ainsi qu’au moment de l’exécution. Le code managé est également vérifié pendant l'exécution, car dans un assembly il peut y avoir des chemins d'accès de code qui peuvent ne jamais être atteints pendant l'exécution. Cela fournit la souplesse nécessaire pour inscrire notamment des assemblys tiers, afin qu'un assembly ne soit pas bloqué là où il y a du code « potentiellement dangereux » conçu pour s'exécuter dans un environnement client, mais ne soit jamais exécuté dans le CLR hébergé. Les exigences que le code managé doit respecter varient selon que l’assembly est enregistré comme SAFE, EXTERNAL_ACCESS ou UNSAFE, SAFE étant le plus strict, et sont répertoriés 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 du code 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 CAS différentes. Pour plus d’informations, consultez Sécurité d’accès au code d’intégration DU CLR.

Contrôles CREATE ASSEMBLY

Lorsque l’instruction CREATE ASSEMBLY est exécutée, les vérifications suivantes sont effectuées pour chaque niveau de sécurité. Si une case activée é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 l’emplacement> CREATE ASSEMBLY FROM<, et tous les assemblys référencés et leurs dépendances sont disponibles à l’emplacement<>.

  • Vous utilisez CREATE ASSEMBLY FROM<octets ...>, et toutes les références sont spécifiées via des octets séparés par l’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 satisfont les spécifications de sécurité de type, est fourni dans le Kit de développement SDK .NET Framework.

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

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

Les attributs personnalisés suivants ne sont pas autorisés 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.

Contrôles d'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 remplie, le code managé n'est pas autorisé à s'exécuter et une exception est levée.

UNSAFE

Le chargement d’un assembly - soit explicitement en appelant la méthode System.Reflection.Assembly.Load() à partir d’un tableau d’octets, soit implicitement via l’utilisation de l’espace de noms Reflection.Emit - 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

  • Synchronization

  • SharedState

  • ExternalProcessMgmt

  • ExternalThreading

  • SecurityInfrastructure

  • MayLeakOnAbort

  • UI

Pour plus d’informations sur les HPA et une liste des types et membres non autorisés dans les assemblys pris en charge, consultez Host Protection Attributes and CLR Integration Programming.

SAFE

Toutes les conditions EXTERNAL_ACCESS sont vérifiées.

Voir aussi

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