Sécurité d'accès du code de l'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 relative à la sécurité d'accès du code dans le kit de développement logiciel (SDK) .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é s’exécutant sur l’ordinateur sur lequel SQL Server est installé.

• Stratégie de l'utilisateur : il s'agit de la stratégie appliquée pour le code managé hébergé par un processus. Par SQL Server service est 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 pour l’autorisation n’est satisfaite que si tous les appelants (au niveau de l’assembly) de la pile d’appels disposent de l’autorisation de ressource correspondante.

L’ensemble d’autorisations de sécurité d’accès au code qui sont accordées 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, l’ensemble d’autorisations éventuellement accordé au code utilisateur peut être restreint davantage par les stratégies au niveau de l’utilisateur et de l’ordinateur.

Jeux d'autorisations au niveau stratégie de l'hôte de 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és à l’aide de l’option PERMISSION_SET deCREATE ASSEMBLY (Transact-SQL)).

Serveur SQL Server. Cette stratégie n'est pas destinée au domaine d'application par défaut qui serait effectif lorsque SQL Server crée une instance du CLR.

Le SQL Server fixedpolicy 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 octroie 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 qui spécifie l’un des trois compartiments d’autorisations 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.

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 à l'aide 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.

Les assemblys SAFE ont les autorisations et valeurs suivantes :

Autorisation	Valeur(s)/description
SecurityPermission	Execution: autorisation d'exécuter le code managé.
SqlClientPermission	Context connection = true, context connection = yes: seule la connexion contextuelle peut être utilisée et la chaîne de connexion peut spécifier uniquement 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.

Les assemblys EXTERNAL_ACCESS 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 aux serveurs de noms de domaine.
EnvironmentPermission	Unrestricted: l'accès complet aux variables du système et de l'environnement utilisateur est accordé.
EventLogPermission	Administer: les actions suivantes sont autorisées : création d'une source d'événement, lecture de journaux existants, suppression de sources d'événements ou de 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 des événements.
FileIOPermission	Unrestricted: l'accès complet aux fichiers et aux dossiers est accordé.
KeyContainerPermission	Unrestricted: l'accès complet aux conteneurs de clés est accordé.
NetworkInformationPermission	Access: l'exécution de requêtes ping est autorisée.
RegistryPermission	Autorise des droits de lecture à HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIG et HKEY_USERS.
SecurityPermission	Assertion: possibilité de déclarer que tous les appelants de ce code ont l'autorisation requise pour l'opération. ControlPrincipal: possibilité de manipuler l'objet principal Execution: autorisation d'exécuter le code managé. SerializationFormatter: possibilité de fournir des services de sérialisation.
SmtpPermission	Access: les connexions sortantes au port 25 hôte SMTP 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 accordé.
StorePermission	Unrestricted: l'accès complet aux magasins de certificats X.509 est accordé.
WebPermission	Connect: les connexions sortantes aux ressources Web sont autorisées.

UNSAFE

UNSAFE autorise les assemblys à accéder sans restriction aux ressources, tant à l’intérieur qu’à l’extérieur de SQL Server. Le code qui s'exécute dans un assembly UNSAFE peut également appeler du code non managé.

Les assemblys UNSAFE dispose de l'approbation FullTrust.

Important

SAFEest 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_ACCESSles assemblys s’exécutent par défaut en tant que compte de service SQL Server. L’autorisation d’exécution EXTERNAL_ACCESS doit uniquement être accordée 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, les assemblys EXTERNAL_ACCESS fournissent différentes protections en matière de fiabilité et de robustesse absentes des assemblys UNSAFE. UNSAFE La spécification permet au code dans l’assembly d’effectuer des opérations illégales sur le 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 autre type d'assembly de construction est inscrit avec le jeu d'autorisations SAFE, le code managé qui s'exécute dans la construction ne peut pas accéder aux ressources externes. Toutefois, si les jeux d’autorisations ou UNSAFE sont spécifiés et que le EXTERNAL_ACCESS 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.	L'accès à la ressource externe se fait dans 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é impersonné.	L'accès s'effectue en utilisant le contexte de sécurité de l'appelant, et non le compte de service.

Synthèse des jeux d'autorisations

Le graphique suivant résume les restrictions et autorisations accordées aux jeux d'autorisations SAFE, EXTERNAL_ACCESS et UNSAFE.

	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 de l'intégration CLR
Restrictions du modèle de programmation de l'intégration du CLR
Environnement hébergé CLR