Risques de sécurité ou de performances à l'aide de SQL CLR [fermé]

Existe-t-il des risques de sécurité ou de performances particuliers dans l'utilisation du CLR dans SQL Server?

La question, comme l'a souligné Remus, est trop générique pour obtenir une réponse car la réponse dépend du contexte de la fonctionnalité à utiliser et de la façon dont elle sera utilisée.

Concernant la "Sécurité":

Si vous posez des questions sur tout ce qui peut être fait dans un assemblage marqué PERMISSION_SET = SAFE, il n'y a aucun problème que j'ai jamais pu trouver. Et SQLCLR est "plus sûr" que d'utiliser xp_cmdshellou les merveilleux sp_OA*procs ( c'était du sarcasme) (ou même des procédures stockées étendues, mais j'espère que personne n'en crée plus).

Si vous souhaitez une explication de ce que signifie «SAFE» en termes pratiques, veuillez consulter cet article: Escalier vers SQLCLR Niveau 3: Sécurité (assemblées générales et SAFE) (inscription gratuite requise).

Si vous posez des questions sur tout ce qui peut être fait dans un assemblage marqué par PERMISSION_SET = EXTERNAL_ACCESS, alors il y a certainement des risques, encore une fois, selon la fonctionnalité utilisée. Si vous écrivez une routine pour lire les répertoires et les noms de fichiers (c'est-à-dire en lecture seule), il s'agit simplement de ce qui doit être vu et non vu. Si vous écrivez du code qui permet de supprimer un fichier, le risque augmente. Mais ce qui peut être fait avec ces ressources externes est contrôlé par:

• que vous utilisiez ou non l'emprunt d'identité:
  • aucune usurpation d'identité signifie que l'accès aux ressources externes se fait via le compte «Se connecter en tant que» du service SQL Server. Quoi que ce compte ait accès, votre fonction SQLCLR pourra le faire.
  • l'utilisation de l'emprunt d'identité signifie que la connexion dans SQL Server qui exécute la fonction, si cette connexion correspond à une connexion Windows, peut faire tout ce que cette connexion Windows particulière est autorisée à faire. Si la connexion dans SQL Server est une connexion SQL Server, une tentative d'utilisation de l'emprunt d'identité entraînera une erreur.
• Quelles autorisations sont configurées sur la ressource externe. Pour l'accès au système de fichiers, cela est contrôlé via des ACL sur les lecteurs NTFS.

Si vous posez des questions sur tout ce qui peut être fait dans un assemblage marqué d'un PERMISSION_SET = UNSAFE, c'est assez ouvert. De nombreuses fonctionnalités sont jugées utilisables uniquement dans les assemblages NON SÉCURITAIRES, car ce sont des problèmes de stabilité et / ou de comportement cohérent plus que de sécurité ou de performances. Par exemple, dans un assemblage UNSAFE, il est possible d'avoir une variable statique inscriptible. Ce n'est généralement pas une bonne chose à faire car les classes SQLCLR sont partagées entre toutes les sessions. Si votre intention est de partager des données en mémoire sur toutes les sessions et que vous avez planifié les conditions de course (et fait de nombreux tests), alors tout devrait bien se passer, car vous vous attendez à ce comportement. Mais si vous vouliez simplement qu'une variable statique inscriptible pour mettre en cache une valeur pour une session particulière n'ait pas à la rechercher à nouveau ou à la calculer à nouveau, et que vous ne saviez pas que d'autres sessions lisent cette valeur et éventuellement la remplacent, eh bien, ce serait un problème.

Mais si vous craignez que quelqu'un écrive dans le Registre, mais que vous n'ayez pas de code qui écrit réellement dans le Registre, vous n'avez probablement pas à vous en préoccuper ;-).

Si vous souhaitez découvrir comment EXTERNAL_ACCESS et UNSAFE fonctionnent en termes pratiques, et la différence entre la configuration TRUSTWORTHY ON(non préférée) et l'utilisation d'une connexion basée sur une clé ou un certificat asymétrique, veuillez consulter cet article: Escalier vers SQLCLR niveau 4: Sécurité (assemblages EXTERNES et NON SÉCURITAIRES) (inscription gratuite requise).

Concernant la "Performance":

Tout dépend de ce que vous essayez de faire et de la façon dont vous vous y prenez. Il y a certaines choses qui sont beaucoup plus rapides dans SQLCLR, et certaines choses qui sont plus lentes. Mais tout comme avec T-SQL, il est possible de prendre une tâche quelque peu simple et / ou efficace et de la rendre compliquée et / ou inefficace en faisant les choses de manière incorrecte. Mais l'utilisation de SQL CLR n'est pas intrinsèquement, par nature, plus lente.

Ensembles SQLCLR peuvent être installés avec trois niveaux d'accès de sécurité: SAFE | EXTERNAL_ACCESS | UNSAFE. Ceci est amplement documenté, consultez CREATE ASSEMBLYet assemblées Conception :

Gestion de la sécurité des
assemblys Vous pouvez contrôler dans quelle mesure un assemblage peut accéder aux ressources protégées par .NET Code Access Security lorsqu'il exécute du code managé. Pour ce faire, vous spécifiez l'un des trois jeux d'autorisations lorsque vous créez ou modifiez un assembly: SAFE, EXTERNAL_ACCESS ou UNSAFE.

SAFE
SAFE est l'ensemble d'autorisations par défaut et il est 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. Le code SAFE peut accéder aux données des bases de données SQL Server locales ou effectuer des calculs et une logique métier qui n'impliquent pas l'accès aux ressources en dehors des bases de données locales.
La plupart des assemblys effectuent des tâches de calcul et de gestion des données sans avoir à accéder aux ressources en dehors de SQL Server. Par conséquent, nous recommandons SAFE comme jeu d'autorisations d'assembly.

EXTERNAL_ACCESS
EXTERNAL_ACCESS permet aux assemblys d'accéder à certaines ressources système externes telles que les fichiers, les réseaux, les services Web, les variables d'environnement et le registre. Seules les connexions SQL Server avec des autorisations EXTERNAL ACCESS peuvent créer des assemblys EXTERNAL_ACCESS. Les assemblys SAFE et EXTERNAL_ACCESS ne peuvent contenir que du code dont le type est vérifiable. Cela signifie que ces assemblys peuvent uniquement accéder aux classes via des points d'entrée bien définis qui sont valides pour la définition de type. Par conséquent, ils ne peuvent pas accéder arbitrairement aux tampons de mémoire n'appartenant pas au code. En outre, ils ne peuvent pas effectuer d'opérations qui pourraient avoir un effet négatif sur la robustesse du processus SQL Server.

UNSAFE
UNSAFE offre aux assemblys un accès illimité aux ressources, à la fois à l'intérieur et à l'extérieur de SQL Server. Le code qui s'exécute à partir d'un assembly UNSAFE peut appeler du code non managé. En outre, la spécification UNSAFE permet au code de l'assembly d'effectuer des opérations considérées comme non sécurisées par le vérificateur CLR. Ces opérations peuvent potentiellement accéder aux tampons de mémoire dans l'espace de processus SQL Server de manière incontrôlée. Les assemblages UNSAFE peuvent également potentiellement renverser le système de sécurité de SQL Server ou du Common Language Runtime. Les autorisations UNSAFE ne doivent être accordées qu'à des assemblys hautement fiables par des développeurs ou des administrateurs expérimentés. Seuls les membres du rôle serveur fixe sysadmin peuvent créer des assemblys UNSAFE.

Il existe d'autres restrictions sur les attributs CLR autorisés et seul un sous-ensemble des assemblys .Net Framework est pris en charge. Encore une fois, reportez-vous à la documentation liée.

En ce qui concerne les performances, le plus important est de se rappeler que SQL Server est un environnement multitâche coopératif, contrairement à CLR. Le code SQLCLR doit appeler Thread.BeginThreadAffinity()chaque fois qu'il monopolise le processeur pour n'importe quelle durée (y compris le blocage). Adam Machanic a une excellente présentation sur le sujet, regardez Data, Faster: Microsoft SQL Server Performance Techniques with SQLCLR .

Le sujet est vaste et la question vague. SQLCLR peut effectuer certaines tâches uniques qu'aucune autre fonctionnalité ne peut égaler. Et SQLCLR n'est qu'une autre arme dans l'arsenal de SQL Server avec laquelle vous pouvez vous tirer une balle dans le pied, la performance ou la sécurité. Lisez la documentation.