Attributs de programmation et de protection des hôtes SQL Server
Pour charger et exécuter du code managé dans un hôte SQL Server, les exigences de l'hôte en termes de sécurité d'accès du code et de protection de ses ressources doivent être satisfaites. Les exigences en matière de sécurité d'accès du code sont spécifiées par l'un de 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é en cela qu'il identifie des constructions de code spécifiques, à savoir des types ou des méthodes, que l'hôte peut rejeter. L'utilisation de HostProtectionAttribute applique un modèle de programmation qui contribue à protéger la stabilité de l'hôte.
Attributs de protection de l'hôte
Les attributs de protection de l'hôte identifient des types ou des membres qui ne sont pas adaptés au modèle de programmation hôte et représentent les niveaux croissants suivants de menace en termes de 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 rejette l'utilisation d'un type ou d'un membre qui a un 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, exécutent la synchronisation, peuvent entraîner une fuite de ressources 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 sont rejeté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. Lorsque les assemblys sont téléchargés dans la base de données, l'auteur de l'assembly peut spécifier l'un de trois jeux d'autorisations suivants 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 à des ressources externes |
Non restreint |
Restrictions du modèle de programmation |
Oui |
Oui |
Aucune restriction |
Configuration requise pour la vérification |
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 possède 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 fournit une option de sécurité intermédiaire. Il permet au code d'accéder à des ressources externes à la base de données, mais possède néanmoins la fiabilité et la sécurité de SAFE.
UNSAFE est réservé à du code de confiance élevée qui peut être créé uniquement par les administrateurs de base de données. Ce code de confiance 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 de niveau hôte pour définir une stratégie hôte qui accorde l'un des trois jeux d'autorisations en fonction du jeu d'autorisations stocké dans les catalogues SQL Server. Le code managé exécuté à l'intérieur 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 exige des fonctions, des procédures et des types qui ne nécessitent pas l'utilisation d'un état maintenu d'un appel à un autre ou le partage de l'état sur 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 rejette 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 la création de l'assembly et échoue dans la création de tels assemblys s'il détecte l'utilisation de membres de données et des variables statiques.