Design assemblies

Applies to:SQL Server

Cet article décrit les facteurs suivants à prendre en compte lorsque vous concevez des assemblys :

• Packaging assemblies
• Gestion de la sécurité des assemblys
• Restrictions sur les assemblys

Package assemblies

Un assembly peut contenir des fonctionnalités pour plusieurs routines OU types SQL Server dans ses classes et méthodes. En règle générale, il est opportun d'empaqueter les fonctionnalités de routines qui réalisent des fonctions apparentées dans le même assembly, notamment si ces routines partagent des classes dont les méthodes s'appellent les unes les autres. Par exemple, les classes qui exécutent des tâches de gestion d'entrée de données pour les déclencheurs CLR (Common Language Runtime) et les procédures stockées CLR peuvent être empaquetées dans le même assembly. Cela est dû au fait que les méthodes de ces classes sont plus susceptibles d’appeler les unes les autres que les méthodes de tâches moins associées.

Lorsque vous empaquetagez du code dans l’assembly, tenez compte des éléments suivants :

• Les types et index CLR définis par l'utilisateur qui dépendent de fonctions CLR définies par l'utilisateur peuvent amener des données persistantes à figurer dans la base de données qui repose sur l'assembly. La modification du code d’un assembly est fréquemment plus complexe lorsqu’il existe des données persistantes qui dépendent de l’assembly dans la base de données. Par conséquent, il est préférable de séparer le code sur lequel reposent les dépendances de données persistantes (par exemple, les types définis par l’utilisateur et les index à l’aide de fonctions définies par l’utilisateur) à partir du code qui n’a pas ces dépendances de données persistantes. For more information, see Implement assemblies and ALTER ASSEMBLY.

• Si un élément de code managé nécessite une autorisation plus élevée, il est préférable de séparer ce code dans un assembly distinct du code qui ne nécessite pas d’autorisation plus élevée.

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.

Gérer la sécurité des assemblys

Vous pouvez contrôler la quantité d’assemblys pouvant accéder aux ressources protégées par la sécurité d’accès au code .NET lorsqu’il exécute du code managé. Pour ce faire, spécifiez l’un des trois jeux d’autorisations lorsque vous créez ou modifiez un assembly : SAFE, EXTERNAL_ACCESSou UNSAFE.

SAFE permission

SAFE est le jeu d’autorisations par défaut et il est le plus restrictif. Le code exécuté par un assembly disposant SAFE d’autorisations ne peut pas accéder aux ressources système externes telles que les fichiers, le réseau, les variables d’environnement ou le Registre. SAFE le code peut accéder aux données à partir des bases de données SQL Server locales ou effectuer des calculs et une logique métier qui n’impliquent pas l’accès aux ressources en dehors des bases de données locales.

La plupart des assemblys effectuent des tâches de calcul et de gestion des données sans avoir à accéder aux ressources en dehors de SQL Server. Par conséquent, nous vous recommandons SAFE d’utiliser le jeu d’autorisations d’assembly.

EXTERNAL_ACCESS permission

EXTERNAL_ACCESS permet aux assemblys d’accéder à certaines ressources système externes telles que les fichiers, les réseaux, les services Web, les variables environnementales et le Registre. Seules les connexions SQL Server disposant EXTERNAL ACCESS d’autorisations peuvent créer EXTERNAL_ACCESS des assemblys.

SAFE et EXTERNAL_ACCESS les assemblys peuvent contenir uniquement du code vérifiable de type sécurisé. Cela signifie que ces assemblys peuvent uniquement accéder à des classes par le biais de points d'entrée correctement définis et valides pour la définition de type. Par conséquent, ils ne peuvent pas accéder arbitrairement aux mémoires tampons non détenues par le code. En outre, ils ne peuvent pas effectuer d’opérations susceptibles d’avoir un effet négatif sur la robustesse du processus SQL Server.

UNSAFE permission

UNSAFE donne aux assemblys un accès illimité aux ressources, à la fois au sein et en dehors de SQL Server. Le code qui s’exécute à partir d’un UNSAFE assembly peut appeler du code non managé.

En outre, la spécification UNSAFE permet au code dans l’assembly d’effectuer des opérations considérées comme non sécurisées par le vérificateur CLR. Ces opérations peuvent potentiellement accéder aux mémoires tampons dans l’espace de processus SQL Server de manière non contrôlée. UNSAFE Les assemblys peuvent également potentiellement subvertir le système de sécurité de SQL Server ou du Common Language Runtime. UNSAFE autorisations doivent être accordées uniquement aux assemblys hautement approuvés par des développeurs ou administrateurs expérimentés. Only members of the sysadmin fixed server role can create UNSAFE assemblies.

Restrictions sur les assemblys

SQL Server met certaines restrictions sur le code managé dans les assemblys pour s’assurer qu’ils peuvent s’exécuter de manière fiable et évolutive. Cela signifie que certaines opérations qui peuvent compromettre la robustesse du serveur ne sont pas autorisées dans SAFE et EXTERNAL_ACCESS assemblys.

Attributs personnalisés non autorisés

Les assemblys ne peuvent pas être annotés avec les attributs personnalisés suivants :

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.STAThreadAttribute
System.ThreadStaticAttribute

En outre, SAFE les EXTERNAL_ACCESS assemblys ne peuvent pas être annotés avec les attributs personnalisés suivants :

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

API .NET Framework interdites

Toute API .NET Framework annotée avec l’une des HostProtectionAttributes non autorisées ne peut pas être appelée à partir de SAFE et d’assemblys EXTERNAL_ACCESS.

HostProtectionAttribute.SelfAffectingProcessMgmt
HostProtectionAttribute.SelfAffectingThreading
HostProtectionAttribute.Synchronization
HostProtectionAttribute.SharedState
HostProtectionAttribute.ExternalProcessMgmt
HostProtectionAttribute.ExternalThreading
HostProtectionAttribute.SecurityInfrastructure
HostProtectionAttribute.MayLeakOnAbort
HostProtectionAttribute.UI

Assemblys .NET Framework pris en charge

Tout assembly référencé par votre assembly personnalisé doit être chargé dans SQL Server à l’aide CREATE ASSEMBLYde . Les assemblys .NET Framework suivants sont déjà chargés dans SQL Server et, par conséquent, peuvent être référencés par des assemblys personnalisés sans avoir à utiliser CREATE ASSEMBLY.

• mscorlib.dll
• CustomMarshalers.dll
• Microsoft.VisualBasic.dll
• Microsoft.VisualC.dll
• System.Configuration.dll
• System.Core.dll
• System.Data.OracleClient.dll
• System.Data.SqlXml.dll
• System.Data.dll
• System.Deployment.dll
• System.Security.dll
• System.Transactions.dll
• System.Web.Services.dll
• System.Xml.Linq.dll
• system.Xml.dll
• System.dll

Related content

• Assemblys (moteur de base de données)
• de sécurité d’intégration CLR