Sécurité de l’accès au code d’intégration CLR

Applies to:SQL Server

Le Common Language Runtime (CLR) prend en charge un modèle de sécurité appelé sécurité d’accès au code pour le code managé. Dans ce modèle, les autorisations sont accordées aux assemblys selon l'identité du code. Pour plus d’informations, consultez sécurité d’accès au code.

La stratégie de sécurité qui détermine les autorisations accordée aux assemblys est définie dans trois emplacements différents :

• Machine policy: This policy is in effect for all managed code running in the machine on which SQL Server is installed.

• User policy: This policy is in effect for managed code hosted by a process. Pour SQL Server, la stratégie utilisateur est spécifique au compte Windows sur lequel le service SQL Server s’exécute.

• Host policy: This policy is set up by the host of the CLR (in this case, SQL Server) that is in effect for managed code running in that host.

Le mécanisme de sécurité d'accès du code pris en charge par le CLR est basé sur la supposition que le module d'exécution peut héberger à la fois du code d'un niveau de confiance total et d'un niveau de confiance partiel. Les ressources protégées par la sécurité d’accès au code CLR sont généralement encapsulées par des interfaces de programmation d’application managées qui nécessitent l’autorisation correspondante avant d’autoriser l’accès à la ressource. La demande d'autorisation est satisfaite seulement si tous les appelants (au niveau de l'assembly) de la pile d'appels ont l'autorisation pour la ressource correspondante.

L’ensemble d’autorisations de sécurité d’accès au code accordés au code managé lors de l’exécution à l’intérieur de SQL Server est l’intersection du jeu d’autorisations accordé par les trois niveaux de stratégie précédents. Même si SQL Server accorde un ensemble d’autorisations à un assembly chargé dans SQL Server, l’ensemble d’autorisations éventuellement accordé au code utilisateur peut être plus restreint par les stratégies utilisateur et au niveau de l’ordinateur.

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.

Ensembles d’autorisations au niveau de la stratégie hôte SQL Server

L’ensemble d’autorisations de sécurité d’accès au code accordées aux assemblys par le niveau de stratégie hôte SQL Server est déterminé par le jeu d’autorisations spécifié lors de la création de l’assembly. There are three permission sets: SAFE, EXTERNAL_ACCESS, and UNSAFE (specified using the PERMISSION_SET option of CREATE ASSEMBLY).

SQL Server fournit un niveau de stratégie de sécurité au niveau de l’hôte au CLR tout en l’hébergeant. Cette stratégie est un niveau de stratégie supplémentaire inférieur aux deux niveaux de stratégie qui sont toujours en vigueur. Cette stratégie est définie pour chaque domaine d’application créé par SQL Server. Cette stratégie n’est pas destinée au domaine d’application par défaut qui serait en vigueur lorsque SQL Server crée une instance du CLR.

La stratégie au niveau de l’hôte SQL Server est une combinaison de stratégie fixe SQL Server pour les assemblys système et la stratégie spécifiée par l’utilisateur pour les assemblys utilisateur.

La stratégie fixe pour les assemblys CLR et les assemblys système SQL Server leur accorde une confiance totale.

La partie spécifiée par l’utilisateur de la stratégie d’hôte SQL Server est basée sur le propriétaire de l’assembly spécifiant l’un des trois compartiments d’autorisation pour chaque assembly. Pour plus d’informations sur les autorisations de sécurité suivantes, consultez le Kit de développement logiciel (SDK) .NET Framework.

SAFE

Seuls les calculs internes et l’accès aux données locales sont autorisés. SAFE est le jeu d’autorisations le 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.

SAFE assemblys disposent des autorisations et des valeurs suivantes :

Permission	Valeurs / Description
SecurityPermission	Execution: autorisation d’exécuter du code managé.
SqlClientPermission	Context connection = true, context connection = yes: seule la connexion contextuelle peut être utilisée et la chaîne de connexion ne peut spécifier qu’une valeur de context connection=true ou context connection=yes. AllowBlankPassword = false: les mots de passe vides ne sont pas autorisés.

EXTERNAL_ACCESS

EXTERNAL_ACCESS assemblys disposent des mêmes autorisations que les assemblys SAFE, avec la possibilité supplémentaire d’accéder aux ressources système externes telles que les fichiers, les réseaux, les variables environnementales et le Registre.

EXTERNAL_ACCESS assemblys ont également les autorisations et valeurs suivantes :

Permission	Valeurs / Description
DistributedTransactionPermission	Unrestricted: les transactions distribuées sont autorisées.
DNSPermission	Unrestricted: autorisation de demander des informations à partir de serveurs de noms de domaine.
EnvironmentPermission	Unrestricted: l’accès complet aux variables système et d’environnement utilisateur est autorisé.
EventLogPermission	Administer: les actions suivantes sont autorisées : créez une source d’événement, lisez les journaux existants, supprimez des sources d’événements ou des journaux, répondez aux entrées, effacez un journal des événements, écoutez les événements et accédez à une collection de tous les journaux d’événements.
FileIOPermission	Unrestricted: l’accès complet aux fichiers et dossiers est autorisé.
KeyContainerPermission	Unrestricted: l’accès complet aux conteneurs de clés est autorisé.
NetworkInformationPermission	Access: le test ping est autorisé.
RegistryPermission	Autorise les droits de lecture à HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIGet HKEY_USERS.
SecurityPermission	Assertion: possibilité d’affirmer que tous les appelants de ce code disposent de l’autorisation requise pour l’opération. ControlPrincipal: possibilité de manipuler l’objet principal. Execution: autorisation d’exécuter du code managé. SerializationFormatter: possibilité de fournir des services de sérialisation.
SmtpPermission	Access: les connexions sortantes au port hôte SMTP 25 sont autorisées.
SocketPermission	Connect: les connexions sortantes (tous les ports, tous les protocoles) sur une adresse de transport sont autorisées.
SqlClientPermission	Unrestricted: l’accès complet à la source de données est autorisé.
StorePermission	Unrestricted: l’accès complet aux magasins de certificats X.509 est autorisé.
WebPermission	Connect: les connexions sortantes aux ressources web sont autorisées.

UNSAFE

UNSAFE permet aux assemblys d’accéder sans restriction aux ressources, à la fois au sein et en dehors de SQL Server. Le code s’exécutant à partir d’un assembly UNSAFE peut également appeler du code non managé.

UNSAFE assemblys sont donnés FullTrust.

Paramètres d’autorisation recommandés

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 de SQL Server.

EXTERNAL_ACCESS est recommandé pour les assemblys qui accèdent aux ressources en dehors de SQL Server. EXTERNAL_ACCESS assemblys par défaut s’exécutent en tant que compte de service SQL Server. Il est possible que EXTERNAL_ACCESS code emprunte explicitement l’identité du contexte de sécurité de l’authentification Windows de l’appelant. Étant donné que la valeur par défaut consiste à s’exécuter en tant que compte de service SQL Server, l’autorisation d’exécuter EXTERNAL_ACCESS ne doit être accordée qu’aux connexions approuvées pour s’exécuter en tant que compte de service.

Du point de vue de la sécurité, les assemblys EXTERNAL_ACCESS et UNSAFE sont identiques. Toutefois, EXTERNAL_ACCESS assemblys fournissent différentes protections de fiabilité et de robustesse qui ne sont pas dans UNSAFE assemblys.

La spécification de UNSAFE permet au code dans l’assembly d’effectuer des opérations illégales sur l’espace de processus SQL Server et peut donc compromettre la robustesse et l’extensibilité de SQL Server. Pour plus d’informations sur la création d’assemblys CLR dans SQL Server, consultez Gérer les assemblys d’intégration CLR.

Important

SQL Server contient des assemblys CLR que le moteur de base de données utilise pour fournir certaines fonctionnalités. L’assembly Microsoft.SQLServer.Types inclus dans l’installation de SQL Server apparaît dans les métadonnées sous la forme d’un assembly UNSAFE. C'est la procédure normale. Ces assemblys sont considérés comme approuvés et sécurisés par défaut.

Accéder aux ressources externes

Si un type défini par l’utilisateur (UDT), une procédure stockée ou un autre type d’assembly de construction est inscrit auprès du jeu d’autorisations SAFE, le code managé s’exécutant dans la construction ne peut pas accéder aux ressources externes. Toutefois, si les jeux d’autorisations EXTERNAL_ACCESS ou UNSAFE sont spécifiés et que le code managé tente d’accéder aux ressources externes, SQL Server applique les règles suivantes :

If	Then
Le contexte d’exécution correspond à une connexion SQL Server.	Les tentatives d'accéder aux ressources externes sont refusées et une exception de sécurité est levée.
Le contexte d'exécution correspond à une connexion Windows et le contexte d'exécution est l'appelant d'origine.	La ressource externe est accessible sous le contexte de sécurité du compte de service SQL Server.
L’appelant n’est pas l’appelant d’origine.	L'accès est refusé et une exception de sécurité est levée.
Le contexte d’exécution correspond à une connexion Windows et le contexte d’exécution est l’appelant d’origine et l’appelant est emprunt d’identité.	Access utilise le contexte de sécurité de l’appelant, et non le compte de service.

Résumé du jeu d’autorisations

Le graphique suivant récapitule les restrictions et les autorisations accordées aux SAFE, EXTERNAL_ACCESSet UNSAFE jeux d’autorisations.

Functionality	SAFE	EXTERNAL_ACCESS	UNSAFE
Autorisations de sécurité d’accès au code	Execute only	Exécution + accès aux ressources externes	Illimité (y compris P/Invoke)
Restrictions du modèle de programmation	Yes	Yes	No restrictions
Verifiability requirement	Yes	Yes	No
Accès aux données locales	Yes	Yes	Yes
Possibilité d'appeler du code natif	No	No	Yes

Related content

• de sécurité d’intégration CLR
• attributs de protection de l’hôte et de programmation d’intégration CLR
• restrictions du modèle de programmation d’intégration CLR
• architecture d’intégration CLR - Environnement hébergé CLR