Sécurité d’accès du code d’intégration du CLR

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 la section « Sécurité de l’accès au code » dans le kit de développement logiciel .NET Framework.

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

• Stratégie d’ordinateur : il s’agit de la stratégie en vigueur pour tout le code managé exécuté sur l’ordinateur sur lequel SQL Server est installé.

• Stratégie utilisateur : il s’agit de la stratégie en vigueur pour le code managé hébergé par un processus. Pour le service SQL Server en cours d’exécution.

• Stratégie d’hôte : il s’agit de la stratégie configurée par l’hôte du CLR (dans ce cas, SQL Server) qui est en vigueur pour le code managé s’exécutant dans cet hôte.

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 de l’autorisation est satisfaite uniquement si tous les appelants (au niveau de l’assembly) de la pile des appels disposent de l’autorisation de 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 accorde un ensemble d’autorisations à un assembly chargé dans SQL Server, le jeu d’autorisations éventuellement accordé au code utilisateur peut être restreint davantage par les stratégies utilisateur et au niveau de l’ordinateur.

Ensembles d’autorisations au niveau de la stratégie d’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. Il existe trois jeux d’autorisations : SAFEet EXTERNAL_ACCESSUNSAFE (spécifié à l’aide de l’option PERMISSION_SETCREATE ASSEMBLY (Transact-SQL)).

Serveur 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 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é répertoriées ci-dessous, consultez le Kit de développement logiciel (SDK) .NET Framework.

SÛR

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 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 assemblys disposent des autorisations et des valeurs suivantes :

Autorisation	Valeur(s)/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 SAFE les assemblys, 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 :

Autorisation	Valeur(s)/Description
DistributedTransactionPermission	Unrestricted: Les transactions distribuées sont autorisées.
DNSPermission	Unrestricted: Autorisation de demander des informations auprès de serveurs de noms de domaine.
EnvironmentPermission	Unrestricted: L’accès complet aux variables d’environnement système et utilisateur est autorisé.
EventLogPermission	Administer: Les actions suivantes sont autorisées : création d’une source d’événement, lecture des journaux existants, suppression de sources d’événements ou journaux, réponse aux entrées, effacement d’un journal des événements, écoute des événements et accès à 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.

DANGEREUX

UNSAFE autorise les assemblys à accéder sans restriction aux ressources, tant au sein qu’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.

Important

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 Les assemblys par défaut s’exécutent en tant que compte de service SQL Server, l’autorisation d’exécution 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 les assemblys fournissent différentes protections de fiabilité et de robustesse qui ne se trouvent pas dans UNSAFE les assemblys. La spécification UNSAFE permet au code dans l’assembly d’effectuer des opérations illégales sur SQL Server. Pour plus d’informations sur la création d’assemblys CLR dans SQL Server, consultez Gestion des assemblys d’intégration CLR.

Accès 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 :

Si	Alors
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 a été 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.

	SAFE	EXTERNAL_ACCESS	UNSAFE
Code Access Security Permissions	Exécution uniquement	Exécution + accès aux ressources externes	Illimité (y compris P/Invoke)
Programming model restrictions	Oui	Oui	Sans restriction
Verifiability requirement	Oui	Oui	Non
Local data access	Oui	Oui	Oui
Ability to call native code	Non	Non	Oui

Voir aussi

Sécurité de l’intégration du CLR
Attributs de protection de l’hôte et programmation d’intégration CLR
Restrictions du modèle de programmation d’intégration CLR
Environnement hébergé CLR