Les risques de sécurité de réglage de confiance = dans sql server 2012

La TRUSTWORTHY propriété d'une base de données (lorsqu'il est défini à ON) essentiellement déclare à SQL Server que le code contenu dans la base de données, et l'exécution dans un contexte représenté, devraient être autorisés à accéder à l'extérieur de la base de données tout en conservant l'identité de cet contexte de sécurité. Il permet également de tous SQLCLR Assemblées dans la Base de données pour être mis à EXTERNAL_ACCESS et UNSAFE, que ce soit ou pas que le code atteint à l'extérieur du serveur (à l'extérieur de sens: l'accès réseau, accès au système de fichiers, l'accès au registre, de l'environnement, accès, etc).

C'est plutôt un moyen générique de permettre à ce qu'il couvre l'ensemble du code dans la base de données. À l'aide de Certificats et/ou des Clés Asymétriques à signer des modules--proc et/ou assemblées--de permettre un contrôle plus précis de ce code dispose que les autorisations.

Définir une Base de données TRUSTWORTHY autorise également tout le processus de départ dans cette Base de données pour atteindre le niveau du Serveur et/ou à travers d'autres Bases de données. Normalement, un processus est confiné /mis en quarantaine à la Base de données où il a commencé. Si la Base de données est la propriété de la Connexion "sa", puis sur tout le processus initié dans la Base de données et exécute en tant que "dbo" va effectivement avoir "sa" privilèges (oups!).

Plutôt que d'essayer de décrire ici, dans le niveau de détail nécessaire pour communiquer les détails à propos de l'usurpation d'identité, s'étendant dit usurpation d'identité, la signature de modules, etc, je vous recommande de parcourir les ressources suivantes à ce sujet:

• S'il vous PLAÎT, s'il vous Plaît, veuillez Cesser d'Utiliser l'emprunt d'identité, de CONFIANCE, et de la Croix-DB Chaînage de Propriété
• Lignes directrices pour l'utilisation de la CONFIANCE paramètre de base de données dans SQL Server
• L'extension de la Base de données usurpation d'identité en Utilisant EXÉCUTER en tant QUE
  
  C'est un document très instructif qui couvre la plupart des aspects de ce sujet, et est également référencé dans la page liée ci-dessus.
• Escalier à SQLCLR Niveau 4: la Sécurité (EXTERNE et DANGEREUX Assemblées)
  
  C'est un article que j'ai écrit dans le cadre d'une série sur SQLCLR qui a des exemples qui illustrent les différences entre la méthode digne de CONFIANCE et la signature de l'Assemblée basé sur la méthode Connexion; inscription Gratuite est requise.

Vous devriez éviter la création de votre base de données pour TRUSTWORTHY autant que possible. Si vous devez vraiment avoir le multithreading /appels asynchrones ET si vous avez le code source et le compiler l'assemblée, je ne peux pas penser à une raison pour utiliser le SET TRUSTWORTHY ON option. Au lieu de cela, vous devez vous inscrire à l'assemblée avec un mot de passe et utilisez les commandes suivantes pour configurer la méthode préférée de permettre EXTERNAL_ACCESS et UNSAFE assemblées:

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 que c'est en place, vous pouvez aller à la base de données où votre assemblée a été chargé et exécuté:

ALTER ASSEMBLY [MyAssembly] WITH PERMISSION_SET = UNSAFE;

Ou vous pourriez avoir inclus WITH PERMISSION_SET = UNSAFE à la fin de la CREATE ASSEMBLY commande.

OriginalL'auteur Solomon Rutzky