Y a-t-il des raisons pour lesquelles je ne devrais pas définir mon propriétaire de base de données sur [sa]?

Hier, j'ai posé cette question concernant la modification du dbo de plusieurs bases de données que j'ai. Le changement est logique, mais je veux être clair.

Y a-t-il une bonne raison ou circonstance pour laquelle je ne devrais pas définir le dbo d'une base de données sur [sa]?

Faire de SA le propriétaire d'une base de données simplifie et / ou résout un certain nombre de choses, mais peut avoir des implications en termes de sécurité.

En particulier, n'oubliez pas que si SA est propriétaire d'une base de données, alors dbo = 'SA'. Cela signifie, entre autres, que toutes les procédures du schéma [dbo] (qui est la valeur par défaut) qui contiennent "EXECUTE en tant que propriétaire", sont en fait exécutées en tant que SA. Ce n'est pas tout à fait aussi mauvais que cela puisse paraître, parce que si vous avez marqué la base de données FIABLE, SQL Server ne laissera pas une session ou une tâche sur la base de données avec un serveur principal niveau d' emprunt d' identité comme ça.

Ce qui soulève le point suivant: ne marquez jamais des bases de données comme TRUSTWORTHY, sauf si vous êtes vraiment , vraiment sûr qu'elles sont sécurisées. Parce que toute personne ayant la possibilité de créer des procédures dans le schéma [dbo] peut s’exécuter en tant que SA, sur l’ensemble du serveur, si elle le souhaite.

Un autre problème peut survenir car de nombreux produits et applications qui ont leur propre base de données SQL Server spécifient souvent que la connexion de leur application doit être le DBO de la base de données. De toute évidence, vous pouvez résoudre ce problème en définissant leur connexion d'application sur «SA». J'espère qu'il est également évident que vous ne devriez jamais faire cela, à moins que cette instance SQL Server ne soit utilisée pour rien d'autre (même dans ce cas, je le déconseille).