Partager via

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

  • Article

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 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 :

  • stratégie d’ordinateur: cette stratégie est en vigueur pour tout le code managé exécuté sur l’ordinateur sur lequel SQL Server est installé.

  • stratégie utilisateur: cette stratégie est appliquée au 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: cette stratégie est 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 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.

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. Il existe trois jeux d’autorisations : SAFE, EXTERNAL_ACCESSet UNSAFE (spécifié à l’aide de l’option PERMISSION_SET de 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 :

Autorisation 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 :

Autorisation 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.

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 :

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 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.

Fonctionnalités SAFE EXTERNAL_ACCESS UNSAFE
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

Contenu connexe