Le TRUSTWORTHY propriété d'une base de données (lorsqu'elle est définie sur ON ) déclare essentiellement à SQL Server que le code contenu dans cette base de données et s'exécutant dans un contexte imité, doit être autorisé à atteindre l'extérieur de cette base de données tout en maintenant ce contexte de sécurité imité. Il permet également à tous Assemblages SQLCLR dans cette base de données à définir sur EXTERNAL_ACCESS et UNSAFE , que ce code atteigne ou non l'extérieur du serveur (sens extérieur :accès au réseau, accès au système de fichiers, accès au registre, accès à l'environnement, etc.).
C'est un moyen plutôt générique de permettre cela car il couvre tout le code de la base de données. L'utilisation de certificats et/ou de clés asymétriques pour signer des modules (procs et/ou assemblys) permet un contrôle plus précis sur le code disposant de quelles autorisations.
Définition d'une base de données sur TRUSTWORTHY permet également à tout processus commençant dans cette base de données d'atteindre le niveau du serveur et/ou d'autres bases de données. Normalement, un processus est confiné / mis en quarantaine dans la base de données où il a démarré. Si la base de données appartient à la connexion "sa", alors tout processus initié dans cette base de données et exécuté en tant que "dbo" aura effectivement les privilèges "sa" (yikes !).
Plutôt que d'essayer de décrire ici, dans la quantité de détails nécessaires pour communiquer pleinement les spécificités de l'usurpation d'identité, l'extension de ladite usurpation d'identité, la signature de modules, etc., je vous recommande de consulter les ressources suivantes sur ce sujet :
- Veuillez, s'il vous plaît , veuillez cesser d'utiliser l'emprunt d'identité, TRUSTWORTHY et le chaînage de propriété entre bases de données
- Instructions pour l'utilisation du paramètre de base de données TRUSTWORTHY dans SQL Server
- Étendre l'emprunt d'identité à la base de données en utilisant EXECUTE AS
Il s'agit d'un document très informatif qui couvre la plupart des aspects de ce sujet, et est également référencé dans la page liée ci-dessus. - Escalier vers SQLCLR niveau 4 :sécurité (assemblages EXTERNES et UNSAFE)
Ceci est un article que j'ai écrit dans le cadre d'une série sur SQLCLR qui contient des exemples qui illustrent les différences entre la méthode TRUSTWORTHY et la méthode de connexion basée sur l'assemblage signé ; Une inscription gratuite est requise.
Vous devez éviter de définir votre base de données sur TRUSTWORTHY autant que possible. Si vous devez vraiment avoir des appels multithreading / asynchrones ET si vous avez le code source et compilez l'assembly, alors je ne vois pas de raison d'utiliser le SET TRUSTWORTHY ON option. Au lieu de cela, vous devez signer l'assembly avec un mot de passe et utilisez les commandes suivantes pour configurer la méthode préférée d'autorisation de EXTERNAL_ACCESS et UNSAFE assemblages :
USE [master];
CREATE ASYMMETRIC KEY [ClrPermissionsKey]
AUTHORIZATION [dbo]
FROM EXECUTABLE FILE = 'C:\path\to\my\assembly.dll';
CREATE LOGIN [ClrPermissionsLogin]
FROM ASYMMETRIC KEY [ClrPermissionsKey];
GRANT UNSAFE ASSEMBLY TO [ClrPermissionsLogin];
Une fois cela en place, vous pouvez accéder à la base de données où votre assemblage a été chargé et exécuté :
ALTER ASSEMBLY [MyAssembly] WITH PERMISSION_SET = UNSAFE;
Ou vous auriez pu inclure WITH PERMISSION_SET = UNSAFE à la fin de la CREATE ASSEMBLY commande.
