Partage via

CREATE ASSEMBLY (Transact-SQL)

  • Article

S’applique à : SQL Server Azure SQL Managed Instance

Crée un module d'application managée qui contient des métadonnées de classe et du code managé sous forme d'objet dans une instance de SQL Server. En référençant ce module, il est possible de créer dans la base de données des fonctions CLR (Common Language Runtime), des procédures stockées, des déclencheurs, des agrégats et des types définis par l'utilisateur.

Conventions de la syntaxe Transact-SQL

Syntaxe

CREATE ASSEMBLY assembly_name
[ AUTHORIZATION owner_name ]
FROM { <client_assembly_specifier> | <assembly_bits> [ , ...n ] }
[ WITH PERMISSION_SET = { SAFE | EXTERNAL_ACCESS | UNSAFE } ]
[ ; ]
<client_assembly_specifier> ::=
    '[ \\computer_name\ ] share_name\ [ path\ ] manifest_file_name'
    | '[ local_path\ ] manifest_file_name'

<assembly_bits> ::=
{ varbinary_literal | varbinary_expression }

Arguments

assembly_name

Nom de l'assembly. Ce nom doit être unique dans la base de données et correspondre à un identificateur valide.

AUTHORIZATION owner_name

Spécifie le nom d'un utilisateur ou d'un rôle comme propriétaire de l'assembly. owner_name doit être le nom d’un rôle dont l’utilisateur actuel est membre, ou l’utilisateur actuel doit avoir IMPERSONATE l’autorisation sur owner_name. En l'absence de spécification, la propriété revient à l'utilisateur actuel.

<client_assembly_specifier>

Spécifie le chemin d'accès local ou l'emplacement sur le réseau où se trouve l'assembly en cours de téléchargement, et également le nom du fichier de manifeste qui correspond à l'assembly. <client_assembly_specifier> peut s’exprimer sous forme de chaîne de caractères fixe ou d’une expression qui correspond à une chaîne de caractères fixe, avec des variables. CREATE ASSEMBLY ne prend pas en charge le chargement d’assemblys multimodule. SQL Server recherche au même emplacement les assemblys dépendants de cet assembly et les télécharge avec le même propriétaire en tant qu'assembly au niveau racine. Si ces assemblys dépendants ne sont pas trouvés et qu’ils ne sont pas déjà chargés dans la base de données active, CREATE ASSEMBLY échoue. Si les assemblys dépendants sont déjà chargés dans la base de données active, leur propriétaire doit être identique à celui de l'assembly créé.

Important

Azure SQL Database & Azure SQL Managed Instance ne prend pas en charge la création d’un assembly à partir d’un fichier.

<client_assembly_specifier> ne peut pas être spécifié si l’utilisateur connecté est emprunt d’identité.

<assembly_bits>

Liste des valeurs binaires qui composent l’assembly et ses assemblys dépendants. La première valeur de la liste est considérée comme l'assembly de niveau racine. Les valeurs correspondant aux assemblys dépendants peuvent être fournies dans n'importe quel ordre. Toutes les valeurs qui ne correspondent pas aux dépendances de l’assembly racine sont ignorées.

Remarque

Cette option n'est pas disponible dans une base de données autonome.

varbinary_literal

Littéral varbinary .

varbinary_expression

Expression de type varbinary.

PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }

Spécifie un ensemble d’autorisations d’accès au code qui sont accordées à l’assembly lorsqu’ils sont accessibles par SQL Server. S’il n’est pas spécifié, SAFE est appliqué comme valeur par défaut.

L’option PERMISSION_SET est affectée par la configuration du serveur : option de sécurité clr strict. Quand clr strict security est activé, tous les assemblys sont traités en tant que UNSAFE.

Nous vous recommandons d’utiliser SAFE. SAFE est le jeu d'autorisations 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.

EXTERNAL_ACCESS permet aux assemblys d’accéder à certaines ressources système externes telles que les fichiers, les réseaux, les variables environnementales et le Registre.

UNSAFE permet aux assemblys d’accéder sans restriction aux ressources, tant au sein qu’en dehors d’une instance de SQL Server. Le code exécuté à partir d’un UNSAFE assembly peut appeler du code non managé.

SAFE est le paramètre d’autorisation recommandé pour les assemblys qui effectuent des tâches de calcul et de gestion des données sans accéder aux ressources en dehors d’une instance de SQL Server.

Remarque

Les EXTERNAL_ACCESS options et UNSAFE les options ne sont pas disponibles dans une base de données autonome.

Nous vous recommandons d’utiliser EXTERNAL_ACCESS pour les assemblys qui accèdent aux ressources en dehors d’une instance de SQL Server. EXTERNAL_ACCESS Les assemblys incluent la fiabilité et les protections d’extensibilité des assemblys, mais du point de vue de SAFE la sécurité, sont similaires aux UNSAFE assemblys. Le code dans EXTERNAL_ACCESS les assemblys s’exécute par défaut sous le compte de service SQL Server et accède aux ressources externes sous ce compte, sauf si le code emprunte explicitement l’identité de l’appelant. Par conséquent, l’autorisation de créer EXTERNAL_ACCESS des assemblys doit être accordée uniquement aux connexions approuvées pour exécuter du code sous le compte de service SQL Server. Pour plus d’informations sur l’emprunt d’identité, consultez Sécurité de l’intégration du CLR.

La spécification UNSAFE permet au code dans l’assembly d’effectuer des opérations dans l’espace de processus SQL Server qui peuvent compromettre potentiellement la robustesse de SQL Server. UNSAFE Les assemblys peuvent également potentiellement subvertir le système de sécurité de SQL Server ou du Common Language Runtime. UNSAFE les autorisations doivent être accordées uniquement aux assemblys hautement approuvés. Seuls les membres du rôle serveur fixe sysadmin peuvent créer et modifier UNSAFE des assemblys.

Pour plus d’informations sur les jeux d’autorisations d’assembly, consultez Conception d’assemblys.

La sécurité d’accès au 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 peut-être être en mesure d’accéder aux 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, clr sp_configure 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 la compatibilité descendante, mais n’est pas recommandée.

Nous vous recommandons de signer tous les assemblys par un certificat ou une clé asymétrique, avec une connexion correspondante qui UNSAFE ASSEMBLY a reçu l’autorisation dans la master base de données. Les administrateurs SQL Server peuvent également ajouter des assemblys à une liste d’assemblys, que le moteur de base de données doit approuver. Pour plus d’informations, consultez sys.sp_add_trusted_assembly.

Notes

CREATE ASSEMBLY charge un assembly qui a été précédemment compilé en tant que fichier .dll à partir du code managé pour une utilisation à l’intérieur d’une instance de SQL Server.

Quand elle est activée, l’option PERMISSION_SET dans les instructions CREATE ASSEMBLY et ALTER ASSEMBLY est ignorée au moment de l’exécution, mais les options PERMISSION_SET sont conservées dans les métadonnées. Ignorer l’option réduit la rupture des instructions de code existantes.

SQL Server n’autorise pas l’inscription de différentes versions d’un assembly portant le même nom, la même culture et la clé publique.

Lorsque vous tentez d’accéder à l’assembly spécifié dans <client_assembly_specifier>, SQL Server emprunte l’identité du contexte de sécurité de la connexion Windows actuelle. Si <client_assembly_specifier> elle spécifie un emplacement réseau (chemin UNC), l’emprunt d’identité de la connexion actuelle n’est pas transféré vers l’emplacement réseau en raison des limitations de délégation. Dans ce cas, l’accès a lieu en utilisant le contexte de sécurité du compte de service SQL Server. Pour plus d’informations, consultez Informations d’identification (moteur de base de données).

Outre l’assembly racine spécifié par assembly_name, SQL Server tente de charger les assemblys référencés par l’assembly racine en cours de chargement. Si un assembly référencé est déjà chargé dans la base de données en raison d’une instruction antérieure CREATE ASSEMBLY , cet assembly n’est pas chargé, mais est disponible pour l’assembly racine. Si un assembly dépendant n’a pas été précédemment chargé, mais QUE SQL Server ne peut pas localiser son fichier manifeste dans le répertoire source, CREATE ASSEMBLY retourne une erreur.

Si les assemblys dépendants référencés par l’assembly racine ne sont pas déjà dans la base de données et sont implicitement chargés avec l’assembly racine, ils ont le même jeu d’autorisations que l’assembly de niveau racine. Si les assemblys dépendants doivent être créés en utilisant un autre ensemble d'autorisations que celui de l'assembly racine, ils doivent être téléchargés explicitement avant l'assembly de niveau racine avec l'ensemble d'autorisations approprié.

Validation des assemblys

SQL Server analyse les fichiers binaires d’assembly chargés par l’instruction CREATE ASSEMBLY pour garantir les vérifications suivantes :

  • Le fichier assembly binaire se compose de métadonnées et de segments de code valides et ces segments de code contiennent des instructions MSIL (Microsoft Intermediate language) valides.

  • L’ensemble d’assemblys système qu’il référence est l’un des assemblys pris en charge suivants dans SQL Server : , , , , , System.Xml.dll, , Microsoft.VisualC.dll, System.Core.dllSystem.Data.SqlXml.dllSystem.Web.Services.dllCustomMarshallers.dllSystem.Security.dllet .System.Xml.Linq.dllSystem.dllSystem.Data.dllmscorlib.dllMicrosoft.VisualBasic.dll D'autres assemblys système peuvent être référencés, mais ils doivent être inscrits explicitement dans la base de données.

  • Pour les assemblys créés à l’aide SAFE ou EXTERNAL ACCESS aux jeux d’autorisations :

    • Le type du code assembly doit être sécurisé. La sécurité s'établit en exécutant l'outil de vérification CLR (Common Language Runtime) sur l'assembly.

    • L’assembly ne doit pas contenir de membres de données statiques dans ses classes, sauf s’ils sont marqués en lecture seule.

    • Les classes de l’assembly ne peuvent pas contenir de méthodes finaliseurs.

    • Les classes ou méthodes de l'assembly doivent être annotées uniquement avec des attributs de code autorisés. Pour plus d’informations, consultez intégration clR : attributs personnalisés pour les routines CLR.

Outre les vérifications précédentes effectuées lors CREATE ASSEMBLY de l’exécution, il existe des vérifications supplémentaires effectuées au moment de l’exécution du code dans l’assembly :

  • L’appel de certaines API .NET Framework qui nécessitent une autorisation d’accès au code spécifique peut échouer si le jeu d’autorisations de l’assembly n’inclut pas cette autorisation.

  • Pour SAFE et EXTERNAL_ACCESS les assemblys, toute tentative d’appel des API .NET Framework annotées avec certains HostProtectionAttributes échoue.

Pour plus d’informations, consultez Conception d’assemblys.

autorisations

Nécessite l'autorisation CREATE ASSEMBLY.

Si PERMISSION_SET = EXTERNAL_ACCESS elle est spécifiée, nécessite EXTERNAL ACCESS ASSEMBLY une autorisation sur le serveur. Si PERMISSION_SET = UNSAFE elle est spécifiée, nécessite UNSAFE ASSEMBLY une autorisation sur le serveur.

L'utilisateur doit être propriétaire des assemblys référencés par l'assembly qui doivent être téléchargés s'ils existent déjà dans la base de données. Pour charger un assembly à l’aide d’un chemin de fichier, l’utilisateur actuel doit utiliser une connexion Windows authentifiée ou être membre du rôle serveur fixe sysadmin. La connexion Windows de l’utilisateur qui s’exécute doit disposer d’une autorisation de lecture sur le partage et les fichiers chargés CREATE ASSEMBLY dans l’instruction.

Autorisations avec sécurité CLR stricte

Les autorisations suivantes sont requises pour créer un assembly CLR quand CLR strict security est activée :

  • L’utilisateur doit avoir l’autorisation CREATE ASSEMBLY.
  • Et une des conditions suivantes doit également être remplie :
    • L’assembly est signé avec un certificat ou une clé asymétrique qui a une connexion correspondante avec l’autorisation UNSAFE ASSEMBLY sur le serveur. Signer l’assembly est recommandé.
    • La base de données a la propriété TRUSTWORTHY définie sur ON, et elle est détenue par une connexion qui a l’autorisation UNSAFE ASSEMBLY sur le serveur. Cette option n’est pas recommandée.

Pour plus d’informations sur les jeux d’autorisations d’assembly, consultez Conception d’assemblys.

Exemples

R. Créer un assembly à partir d’une DLL

L’exemple suivant suppose que les exemples sql Server Moteur de base de données sont installés à l’emplacement par défaut de l’ordinateur local et que l’exemple HelloWorld.csproj d’application est compilé. Pour plus d’informations, consultez Exemple Hello World.

CREATE ASSEMBLY HelloWorld
FROM '<system_drive>:\Program Files\Microsoft SQL Server\100\Samples\HelloWorld\CS\HelloWorld\bin\debug\HelloWorld.dll'
WITH PERMISSION_SET = SAFE;

Important

Azure SQL Database ne prend pas en charge la création d’un assembly à partir d’un fichier.

B. Créer un assembly à partir de bits d’assembly

Remplacez les exemples de bits (qui ne sont pas complets ou valides) par vos bits d’assembly.

CREATE ASSEMBLY HelloWorld
    FROM 0x4D5A900000000000
WITH PERMISSION_SET = SAFE;

Contenu connexe