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.
Paramètres d’autorisation recommandés
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