Sécurité CLR stricte
S'applique à : SQL Server
Contrôle l’interprétation de l’autorisation SAFE
,EXTERNAL ACCESS
, UNSAFE
dans SQL Server.
Valeur | Description |
---|---|
0 | Désactivée : fournie pour la compatibilité ascendante. La valeur Disabled n’est pas recommandée. |
1 | Activée : le Moteur de base de données ignore les informations PERMISSION_SET sur les assemblys et les interprète toujours comme UNSAFE . À compter de SQL Server 2017 (14.x), la valeur par défaut est Enabled . |
Avertissement
CLR utilise la sécurité d’accès du code (CAS) dans le .NET Framework, qui n’est plus pris en charge comme limite de sécurité. Un assembly CLR créé avec PERMISSION_SET = SAFE
peut être en mesure d’accéder à des ressources système externes, d’appeler du code non managé et d’acquérir des privilèges sysadmin. À compter de SQL Server 2017 (14.x), une option de sp_configure
appelée clr strict security
est introduite pour renforcer la sécurité des assemblys CLR. clr strict security
est activée par défaut et traite les assemblys SAFE
et EXTERNAL_ACCESS
comme s’ils étaient marqués UNSAFE
. L’option clr strict security
peut être désactivée pour assurer une compatibilité descendante, mais ceci n’est pas recommandé. Microsoft recommande que tous les assemblys soient signés par un certificat ou une clé asymétrique avec une connexion correspondante à laquelle a été accordée l’autorisation UNSAFE ASSEMBLY
dans la base de données master. Les administrateurs SQL Server peuvent également ajouter des assemblys à une liste d’assemblys, que le moteur de base de données doit approuver. Pour plus d’informations, consultez sys.sp_add_trusted_assembly.
Notes
Quand elle est activée, l’option PERMISSION_SET
dans les instructions CREATE ASSEMBLY
et ALTER ASSEMBLY
est ignorée au moment de l’exécution, mais les options PERMISSION_SET
sont conservées dans les métadonnées. Ignorer cette option réduit les risques de rupture des instructions de code existantes.
CLR strict security
est une advanced option
.
Important
Une fois la sécurité stricte activée, le chargement des assemblys qui ne sont pas signés échoue. Vous devez modifier, ou bien supprimer et recréer, chaque assembly, de façon à ce qu’il soit signé avec un certificat ou une clé asymétrique qui a une connexion correspondante avec l’autorisation UNSAFE ASSEMBLY
sur le serveur.
Autorisations
Pour changer cette option
Requiert l’autorisation CONTROL SERVER
ou l’appartenance au rôle serveur fixe sysadmin
.
Pour créer un assembly CLR
Les autorisations suivantes sont requises pour créer un assembly CLR quand CLR strict security
est activée :
- L’utilisateur doit avoir l’autorisation
CREATE ASSEMBLY
. - Et une des conditions suivantes doit également être remplie :
- L’assembly est signé avec un certificat ou une clé asymétrique qui a une connexion correspondante avec l’autorisation
UNSAFE ASSEMBLY
sur le serveur. Signer l’assembly est recommandé. - La base de données a la propriété
TRUSTWORTHY
définie surON
, et elle est détenue par une connexion qui a l’autorisationUNSAFE ASSEMBLY
sur le serveur. Cette option n’est pas recommandée.
- L’assembly est signé avec un certificat ou une clé asymétrique qui a une connexion correspondante avec l’autorisation
Voir aussi
Options de configuration du serveur (SQL Server)
sp_configure (Transact-SQL)
clr enabled (option de configuration de serveur)
Commentaires
https://aka.ms/ContentUserFeedback.
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir:Soumettre et afficher des commentaires pour