Assemblys - Conception
S’applique à : SQL Server
Cette rubrique décrit les facteurs suivants, à prendre en considération lors de la conception d'assemblys :
Empaquetage d’assemblys
Gestion de la sécurité des assemblys
Restrictions sur les assemblys
Empaquetage d'assemblys
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. En effet, les méthodes de ces classes sont davantage susceptibles de s'appeler les unes les autres que d'invoquer les méthodes de tâches moins apparentées.
Lorsque vous empaquetez du code en assembly, vous devez prendre en considération les points 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 souvent plus complexe lorsque la base de données contient des données persistantes dépendant de l'assembly. Par conséquent, il est généralement préférable de séparer le code sur lequel reposent les dépendances des données persistantes (par exemple des types et des index définis par l'utilisateur utilisant des fonctions définies par l'utilisateur) du code dépourvu de ces dépendances de données persistantes. Pour plus d’informations, consultez Implémentation d’assemblys et ALTER ASSEMBLY (Transact-SQL).
Si une portion de code managé requiert une autorisation plus élevée, il est préférable de la placer dans un assembly distinct du code qui ne requiert pas une telle autorisation.
Gestion de 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, vous spécifiez l'un des trois jeux d'autorisations lorsque vous créez ou modifiez un assembly : SAFE, EXTERNAL_ACCESS ou UNSAFE.
SAFE
SAFE est le jeu d'autorisations par défaut et il s'agit du plus restrictif. Le code exécuté par un assembly avec des autorisations SAFE ne peut pas accéder aux ressources système externes telles que les fichiers, le réseau, les variables d'environnement ou le Registre. Le code SAFE 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, il est recommandé d'utiliser SAFE comme jeu d'autorisations des assemblys.
EXTERNAL_ACCESS
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 d'environnement et le Registre. Seules les connexions SQL Server disposant d’autorisations EXTERNAL ACCESS peuvent créer des assemblys EXTERNAL_ACCESS.
Les assemblys SAFE et EXTERNAL_ACCESS ne peuvent contenir que du code 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 à des zones de mémoire tampon 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
UNSAFE donne aux assemblys un accès illimité aux ressources, à la fois au sein et en dehors de SQL Server. Le code exécuté depuis un assembly UNSAFE peut appeler du code non managé.
En outre, la spécification de UNSAFE permet au code de l'assembly de réaliser des opérations considérées comme étant de type non sécurisé 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. Les assemblys UNSAFE peuvent également corrompre le système de sécurité de SQL Server ou de CLR (Common Language Runtime). Les autorisations UNSAFE ne doivent être accordées par des administrateurs ou des développeurs expérimentés qu'aux assemblys hautement approuvés. Seuls les membres du rôle serveur fixe sysadmin peuvent créer des assemblys UNSAFE.
Restrictions associées aux 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 pouvant compromettre la robustesse du serveur ne sont pas autorisées dans les assemblys SAFE et EXTERNAL_ACCESS.
Attributs personnalisés interdits
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, les assemblys SAFE et EXTERNAL_ACCESS ne peuvent pas être annotés avec les attributs personnalisés suivants :
System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute
API .NET Framework interdites
Toute API Microsoft .NET Framework annotée avec l’un des hostProtectionAttributes non autorisés ne peut pas être appelée à partir de SAFE et EXTERNAL_ACCESS assemblys.
eSelfAffectingProcessMgmt
eSelfAffectingThreading
eSynchronization
eSharedState
eExternalProcessMgmt
eExternalThreading
eSecurityInfrastructure
eMayLeakOnAbort
eUI
Assemblys .NET Framework pris en charge
Tout assembly référencé par votre assembly personnalisé doit être chargé dans SQL Server à l’aide de CREATE ASSEMBLY. 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.
CustomMarshalers.dll
Microsoft.VisualBasic.dll
Microsoft.VisualC.dll
mscorlib.dll
System.dll
System.Configuration.dll
System.Core.dll
System.Data.dll
System.Data.OracleClient.dll
System.Data.SqlXml.dll
System.Deployment.dll
System.Security.dll
System.Transactions.dll
System.Web.Services.dll
system.Xml.dll
System.Xml.Linq.dll
Voir aussi
Assemblys (moteur de base de données)
Sécurité de l’intégration du CLR
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour