Attributs de programmation et de protection des hôtes SQL Server
Pouvoir charger et exécuter du code managé sur un hôte SQL Server nécessite de remplir les exigences de l’hôte en matière de sécurité d’accès du code et de protection des ressources de l’hôte. Les exigences pour la sécurité d’accès du code sont spécifiées par l’un des trois jeux d’autorisations SQL Server : SAFE, EXTERNAL-ACCESS ou UNSAFE. Le code exécuté dans les jeux d’autorisations SAFE ou EXTERNAL-ACCESS doit éviter certains types ou membres dont l’attribut HostProtectionAttribute est appliqué. HostProtectionAttribute n’est pas tant une autorisation de sécurité qu’une garantie de fiabilité, car il identifie des constructions de code spécifiques, à savoir des types ou des méthodes, que l’hôte peut interdire. L'utilisation de HostProtectionAttribute applique un modèle de programmation qui contribue à protéger la stabilité de l'hôte.
Notes
La sécurité d’accès du code (CAS) a été déconseillée dans toutes les versions du .NET Framework et de .NET. Les versions récentes de .NET ne respectent pas les annotations CAS et produisent des erreurs si les API liées à CAS sont utilisées. Les développeurs doivent chercher des moyens alternatifs pour accomplir les tâches liées à la 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 sont pas adaptés au modèle de programmation de l’hôte et représentent les niveaux croissants suivants de menace pour la fiabilité :
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 n’autorise pas l’utilisation d’un type ou d’un membre dont l’attribut HostProtectionAttribute spécifie une valeur HostProtectionResource égale à 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 rejetés
Le tableau suivant identifie les types et les membres dont les valeurs HostProtectionResource ne sont pas autorisées par SQL Server.
Jeux d’autorisations SQL Server
SQL Server permet aux utilisateurs de spécifier les exigences de fiabilité du code déployé dans une base de données. Quand des assemblys sont chargés dans la base de données, l’auteur de l’assembly peut spécifier l’un des trois jeux d’autorisations pour cet assembly : SAFE, EXTERNAL-ACCESS ou UNSAFE.
| Jeu d’autorisations | SAFE | EXTERNAL-ACCESS | UNSAFE |
|---|---|---|---|
| Sécurité d'accès du 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 présente des fonctionnalités de sécurité et de fiabilité é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 fournit une option de sécurité intermédiaire. Il permet au code d’accéder à des ressources externes à la base de données, tout en offrant 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 entièrement fiable n’a pas de restrictions d’accès du code et peut appeler du code non managé (natif).
SQL Server utilise la couche de stratégie de sécurité d’accès du code au niveau de l’hôte pour définir une stratégie d’hébergement qui accorde l’un des trois jeux 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 du code managé dans SQL Server nécessite des fonctions, des procédures et des types qui n’ont pas besoin d’utiliser un état maintenu entre les appels ou de partager l’é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.
Pour ces raisons, SQL Server n’autorise pas l’utilisation de variables statiques ni de membres de données statiques. Pour les assemblys SAFE et EXTERNAL-ACCESS, SQL Server examine les métadonnées des assemblys au moment de leur création et ne crée pas ces assemblys s’il détecte la présence de membres de données ou variables statiques.
