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 du 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 de l'ordinateur : il s'agit de la stratégie appliquée pour tout le code managé qui s'exécute 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. Pour SQL Server, la stratégie de l'utilisateur est spécifique au compte Windows sur lequel le service SQL Server s'exécute.

• Stratégie de l'hôte : il s'agit de la stratégie configurée par l'hôte du CLR (dans ce cas, SQL Server) qui est appliquée pour le code managé qui s'exécute sur 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 du code CLR sont généralement intégrées à des interfaces de programmation d'applications managées qui requièrentl'autorisation correspondante avant d'accorder l'accès à la ressource. La demanded'autorisation est satisfaite seulement si tous les appelants (au niveau de l'assembly) de la pile d'appels possèdent l'autorisation pour la ressource correspondante.

Le jeu d'autorisations de sécurité d'accès du code accordées au code managé en cas d'exécution à l'intérieur de SQL Server est l'intersection du jeu d'autorisations accordées par les trois niveaux de stratégie précités. Même si SQL Server accorde un jeu d'autorisations à un assembly chargé dans SQL Server, le jeu éventuel d'autorisations accordées au code utilisateur peut être restreint davantage par les stratégies de l'utilisateur et de l'ordinateur.

Jeux d'autorisations au niveau stratégie de l'hôte de SQL Server

Le jeu d'autorisations de sécurité d'accès du code accordées aux assemblys par le niveau de stratégie de l'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 : SAFE, EXTERNAL_ACCESS et UNSAFE (spécifiées à l'aide de l'option PERMISSION_SET de CREATE ASSEMBLY (Transact-SQL)).

SQL Server fournit un niveau de stratégie de sécurité au niveau de l'hôte au CLR (Common Language Runtime) quand il l'héberge ; cette stratégie est un niveau de stratégie supplémentaire sous les deux niveaux de stratégie qui sont toujours effectifs. Cette stratégie est définie pour chaque domaine d'application qui est créé par SQL Server. Cette stratégie n'est pas destinée au domaine d'application par défaut appliqué lorsque SQL Server crée une instance du CLR.

La stratégie de niveau hôte de SQL Server est une combinaison de la stratégie fixe de SQL Server pour les assemblys système et de 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 de l'hôte SQL Server est basée sur le propriétaire de l'assembly spécifiant 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.

SAFE

Seul un accès aux données local et le calcul interne 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 pour 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 vierges ne sont pas autorisés.

EXTERNAL_ACCESS

Les assemblys EXTERNAL_ACCESS ont les mêmes autorisations que les assemblys SAFE , avec la capacité supplémentaire d'accéder aux ressources système externes telles que les fichiers, réseaux, variables d'environnement 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 auprès de serveurs de noms de domaines.
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 offre aux assemblies un accès sans restriction aux ressources, à la fois à l'intérieur et à 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.

Remarque relative à la sécurité

SAFE est le paramètre recommandé pour les autorisations des assemblys qui effectuent des calculs et des tâches de gestion des données sans accéder à des ressources extérieures à SQL Server. EXTERNAL_ACCESS est recommandé pour les assemblys qui accèdent à des ressources en dehors de SQL Server. Par défaut, les assemblys EXTERNAL_ACCESS s'exécutent en tant que compte de service SQL Server. Le code EXTERNAL_ACCESS peut explicitement emprunter l'identité du contexte de sécurité d'Authentification Windows de l'appelant. Étant donné que la valeur par défaut est l'exécution en tant que compte de service SQL Server, l'autorisation d'exécuter EXTERNAL_ACCESS ne doit être accordée qu'aux connexions habilitées à 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. Si vous indiquez UNSAFE, le code au sein de l'assembly peut effectuer des opérations illégales à l'encontre de l'espace de traitement SQL Server. C'est ainsi que la robustesse et l'évolutivité de SQL Server risquent d'être compromises. Pour plus d'informations sur la création d'assemblys dans SQL Server, consultez Gestion des assemblys d'intégration du 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 le jeu d'autorisations EXTERNAL_ACCESS ou UNSAFE est spécifié 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 accédée 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 est l'appelant d'origine, et l'identité de l'appelant a été empruntée.	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	Aucune restriction
Verifiability requirement	Oui	Oui	Non
Local data access	Oui	Oui	Oui
Ability to call native code	Non	Non	Oui

Voir aussi

Concepts

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