Partager via


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

S’applique à : 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 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é exécuté 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 utilisateur est spécifique au compte Windows sur lequel le service SQL Server s’exécute.

  • 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 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 ci-dessus. Même si SQL Server accorde un ensemble d’autorisations à un assembly chargé dans SQL Server, l’ensemble éventuel d’autorisations accordées au code utilisateur peut être limité par les stratégies utilisateur et de niveau 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 : SAFE, EXTERNAL_ACCESS et UNSAFE (spécifié à l’aide de l’option PERMISSION_SET CREATE ASSEMBLY (Transact-SQL)).

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é 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 disposant d’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 disposent des autorisations et des valeurs suivantes :

Autorisation Valeur(s)/description
SecurityPermission Exécution : autorisation d’exécuter du code managé.
SqlClientPermission Connexion contextuelle = true, connexion de contexte = oui : seule la connexion contextuelle peut être utilisée et l’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 les valeurs suivantes :

Autorisation Valeur(s)/description
DistributedTransactionPermission Non restreint : les transactions distribuées sont autorisées.
DNSPermission Sans restriction : autorisation de demander des informations à partir de serveurs de noms de domaine.
EnvironmentPermission Illimité : l’accès total aux variables d’environnement système et utilisateur est autorisé.
EventLogPermission Administrer : 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 Illimité : l’accès total aux fichiers et dossiers est autorisé.
KeyContainerPermission Illimité : l’accès total aux conteneurs de clés est autorisé.
NetworkInformationPermission Accès : Le ping est autorisé.
RegistryPermission Autorise les droits de lecture à HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIG et 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.

Exécution : autorisation d’exécuter du code managé.

SerializationFormatter : possibilité de fournir des services de sérialisation.
SmtpPermission Accès : les connexions sortantes au port hôte SMTP 25 sont autorisées.
SocketPermission Connexion : les connexions sortantes (tous les ports, tous les protocoles) sur une adresse de transport sont autorisées.
SqlClientPermission Illimité : l’accès total à la source de données est autorisé.
StorePermission Illimité : l’accès total aux magasins de certificats X.509 est autorisé.
WebPermission Connexion : les connexions sortantes aux ressources web sont autorisées.

UNSAFE

UNSAFE autorise les assemblys à accéder sans restriction aux ressources, tant au sein qu’en dehors de SQL Server. Le code qui s’exécute à partir d’un assembly UNSAFE peut également appeler du code non managé.

Les assemblys UNSAFE reçoivent FullTrust.

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 les assemblys UNSAFE .

Spécifier UNSAFE permet au code de 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 Gestion des 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è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é. 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écapitule les restrictions et les autorisations accordées aux jeux d’autorisations SAFE, EXTERNAL_ACCESS et UNSAFE .

Fonctionnalités SÛR EXTERNAL_ACCESS DANGEREUX
Autorisations de sécurité d’accès au code Exécution uniquement Exécution + accès aux ressources externes Illimité (y compris P/Invoke)
Restrictions du modèle de programmation Oui Oui Sans restriction
Vérifiabilité requise Oui Oui Non
Accès aux données locales Oui Oui Oui
Possibilité d'appeler du code natif 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 du CLR
Restrictions du modèle de programmation de l’intégration du CLR
Environnement hébergé CLR