Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La possibilité de charger et d’exécuter du code managé dans un hôte SQL Server nécessite de répondre aux exigences de l’hôte pour la sécurité de l’accès au code et la protection des ressources de l’hôte. Les exigences de sécurité de l’accès au code sont spécifiées par l’un des trois ensembles d’autorisations SQL Server : SAFE, EXTERNAL-ACCESS ou UNSAFE. Le code s’exécutant dans les jeux d’autorisations SAFE ou EXTERNAL-ACCESS doit éviter certains types ou membres auxquels l’attribut HostProtectionAttribute est appliqué. L’autorisation HostProtectionAttribute de sécurité n’est pas autant qu’une garantie de fiabilité dans le fait qu’elle identifie des constructions de code spécifiques, soit des types ou des méthodes, que l’hôte peut interdire. L’utilisation du HostProtectionAttribute applique un modèle de programmation qui permet de protéger la stabilité de l’hôte.
Remarque
La sécurité de l’accès au code (CAS) a été déconseillée dans toutes les versions de .NET Framework et .NET. Les versions récentes de .NET n’honorent pas les annotations CAS et produisent des erreurs si les API associées à CAS sont utilisées. Les développeurs doivent rechercher d’autres moyens d’accomplir des tâches de sécurité.
Attributs de protection de l'hôte
Les attributs de protection de l’hôte identifient les types ou les membres qui ne correspondent pas au modèle de programmation hôte et représentent les niveaux croissants de menace de fiabilité suivants :
Sans gravité par ailleurs.
Susceptible de déstabiliser le code utilisateur géré par le serveur.
Susceptible de déstabiliser le processus serveur lui-même.
SQL Server interdit l’utilisation d’un type ou d’un membre qui a une HostProtectionAttribute qui spécifie une valeur HostProtectionResource de SharedState, Synchronization, MayLeakOnAbort, ou ExternalProcessMgmt. Cela empêche les assemblys d’appeler des membres qui activent l’état de partage, effectuent la synchronisation, peuvent entraîner une fuite de ressource à l’arrêt ou affectent l’intégrité du processus SQL Server.
Types et membres non autorisés
Le tableau suivant identifie les types et les membres dont HostProtectionResource les valeurs sont interdites par SQL Server.
Jeux d’autorisations SQL Server
SQL Server permet aux utilisateurs de spécifier les exigences de fiabilité pour le code déployé dans une base de données. Lorsque des assemblys sont chargés dans la base de données, l’auteur de l’assembly peut spécifier l’un des trois ensembles d’autorisations pour cet assembly : SAFE, EXTERNAL-ACCESS ou UNSAFE.
| Ensemble d’autorisations | SÛR | EXTERNAL-ACCESS | DANGEREUX |
|---|---|---|---|
| Sécurité de l’accès au code | Exécution uniquement | Exécution + accès aux ressources externes | Non restreint |
| Restrictions du modèle de programmation | Oui | Oui | Sans restriction |
| Vérifiabilité requise | Oui | Oui | Non |
| Possibilité d'appeler du code natif | Non | Non | Oui |
SAFE est le mode le plus fiable et sécurisé avec des restrictions associées quant au modèle de programmation autorisé. Le code SAFE a des fonctionnalités de fiabilité et de sécurité élevées. Les assemblys SAFE bénéficient d'autorisations suffisantes pour s'exécuter, effectuer des calculs et avoir accès à la base de données locale. Les assemblys SAFE doivent être de type sécurisé vérifié et ne sont pas autorisés à appeler du code non managé.
EXTERNAL-ACCESS offre une option de sécurité intermédiaire, ce qui permet au code d’accéder aux ressources externes à la base de données, tout en ayant toujours la fiabilité et la sécurité de SAFE.
UNSAFE est réservé à du code hautement approuvé qui peut être créé uniquement par les administrateurs de base de données. Ce code approuvé n’a aucune restriction d’accès au code et peut appeler du code non managé (natif).
SQL Server utilise la couche de stratégie de sécurité d’accès au code hôte pour configurer une stratégie hôte qui accorde l’un des trois ensembles d’autorisations en fonction du jeu d’autorisations stocké dans les catalogues SQL Server. Le code managé qui s'exécute au sein de la base de données obtient toujours l'un de ces jeux d'autorisations d'accès du code.
Restrictions du modèle de programmation
Le modèle de programmation pour le code managé dans SQL Server nécessite des fonctions, des procédures et des types qui ne nécessitent pas l’utilisation de l’état détenu entre plusieurs appels ou le partage d’état entre plusieurs sessions utilisateur. Par ailleurs, comme décrit précédemment, la présence d'un état partagé peut provoquer des exceptions critiques qui affectent l'évolutivité et la fiabilité de l'application.
Compte tenu de ces considérations, SQL Server interdit l’utilisation de variables statiques et de membres de données statiques. Pour les assemblys SAFE et EXTERNAL-ACCESS, SQL Server examine les métadonnées de l’assembly au moment de CREATE ASSEMBLY et échoue la création de ces assemblys s’il trouve l’utilisation de membres et de variables de données statiques.