Pourquoi la base de données MSDB est-elle TRUSTWORTHY?

Le TRUSTWORTHYparamètre peut être assez dangereux si vous ne faites pas attention et sauf dans des circonstances spécifiques, la recommandation est de le garder éteint. Cependant, par défaut, la MSDBbase de données est TRUSTWORHTYdéfinie ONpar défaut. Je suis curieux de savoir pourquoi?

J'ai lu cette entrée dans BOL

Remarque Par défaut, le paramètre TRUSTWORTHY est défini sur ON pour la base de données MSDB. La modification de ce paramètre à partir de sa valeur par défaut peut entraîner un comportement inattendu des composants SQL Server qui utilisent la base de données MSDB.

Mais je suis curieux de connaître les détails. Pourquoi le MSDBbesoin TRUSTWORTHYest-il spécifiquement activé? Quelles fonctions l'utilisent?

— Kenneth Fisher
source

Une simple réflexion rapide sans rechercher POURQUOI serait que le service SQL Agent puisse interagir avec toutes les bases de données d'une instance, pour utiliser la messagerie DB pour les notifications, d'autres ressources externes; chemins d'accès, objets AD, etc. dans les travaux de l'Agent SQL.

— Pimp Juice IT

@JUICED_IT contient également l'historique des travaux de l'Agent SQL, l'historique du moniteur d'envoi des journaux, les packages SSIS, les données du Conseiller de réglage du moteur de base de données et les données de file d'attente Service Broker, ainsi que les informations de sauvegarde. C'est beaucoup de choses dont vous voulez un comportement standard. sqlperformance.com/2015/07/sql-maintenance/msdb

— ConstantineK

Je soupçonne qu'il est requis pour tout ce qui utilise des appels inter-bases de données. Vous devez TRUSTWORTHYdésactiver pour msdbvoir ce qui ne fonctionne plus et vous aurez au moins une partie de la réponse :). J'ai pensé que BACKUP aurait des problèmes mais j'ai juste essayé et cela a réussi.

— Solomon Rutzky

Il y a des dizaines d'objets msdbqui font référence à la masterbase de données.

Si msdb n'était pas marqué comme TRUSTWORTHY, les utilisateurs auraient besoin d'une autorisation à la fois sur l' msdbobjet avec masterlequel ils interagissent, ainsi que sur l' objet référencé.

Par exemple, les utilisateurs msdb qui obtiennent des autorisations via le rôle de base de données SQLAgentUserRole sont autorisés à s'exécuter msdb.dbo.sp_enum_sqlagent_subsystems. La pile d'appels pour cette procédure atteint finalement master:

* msdb.dbo.sp_enum_sqlagent_subsystems
    * msdb.dbo.sp_enum_sqlagent_subsystems_internal
        * master.dbo.xp_instance_regread

Si msdbn'est pas marqué comme TRUSTWORTHY, les utilisateurs faisant partie du rôle de base de données SQLAgentUserRole auraient également besoin de l'autorisation d'exécution sur master.dbo.xp_instance_regread.

Techniquement parlant, il est probablement possible de supprimer le TRUSTWORTHYparamètre dans msdbet d'accorder des autorisations spécifiques à la place master. Cependant, ces autorisations requises ne sont ni documentées ni prises en charge.

— AMtwo
source

Vous avez probablement raison, mais si c'est le cas, il est tout aussi important que le propriétaire de MSDB dispose de ces autorisations.

— Kenneth Fisher

@KennethFisher Probablement? Je ne plaisante généralement pas avec le propriétaire de la base de données pour msdb, donc je ne suis pas sûr. Je l'ai toujours laissé comme sa. Je n'y avais légitimement pas pensé.

— AM

Ahh mais si j'ai les bonnes autorisations dans MSDB, je peux utiliser cet accès sa en combinaison avec TRUSTWORTHY pour prendre en charge votre serveur :)

— Kenneth Fisher

Vrai. Mais c'est pourquoi l'accès aux bases de données système doit être soigneusement restreint. Si vous n'êtes pas un DBA, vous n'avez pas besoin d'accéder à une base de données système.

— AM