TRUSTWORTHY, SysAdmin et DB_Owner

L’option de base de données Trustworthy peut être utile dans certaines situations. Cependant, j’ai quand même pas mal de réticences à l’activer. Surtout quand je ne maitrise pas complètement la sécurité de mon serveur (libre de mes choix niveau délégation), et plus particulièrement les membres du groupe fixe de base de données DB_OWNER.

Petite démonstration.

En tant que sysadmin, ce qui correspond à une très grande majorité des configurations, créez deux bases de données et un login (pas de droits particuliers niveau instance) :

USE master
GO


CREATE LOGIN TestLogin WITH PASSWORD = 'pwd', 
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

CREATE DATABASE ToBeDropped
GO

CREATE DATABASE TestTrustworthy
GO

La base de donnée va donc avoir comme propriétaire : vous, un sysadmin.

Ensuite, donnons des droits à ce login dans le base de test. Vu que le boss a décrété que cet utilisateur était “de confiance” et que vous craignez d’être “embêtés” si cet utilisateur ne dispose pas de droits suffisants par la suite, le rôle db_owner (OK, soyons fous) a été choisi !

USE TestTrustworthy
GO

CREATE USER [TestUser] 
FOR LOGIN [TestLogin] WITH DEFAULT_SCHEMA=[dbo]
GO
ALTER ROLE [db_owner] ADD MEMBER [TestUser]
GO

 

Et là, un développeur me demande d’activer l’option TRUSTWORTHY sur ma base de données, pour une histoire de CLR … (sans rancune Seb, il me fallait quelqu’un et c’est tombé sur toi … , mais je te fais confiance pour rebondir et me rendre la pareille – droit de réponse autorisé, of course).

SET TRUSTWORTHY ON
GO

Et maintenant, connectons nous avec ce fameux compte et soyons joueur … En tant que membre du groupe db_owner, vous héritez implicitement des droits EXECUTE AS ….

USE TestTrustworthy 
EXECUTE AS USER = 'dbo'
DROP DATABASE ToBeDropped

Oups, la boulette !!!! Je viens de supprimer une base de données. Un utilisateur de base de données, sans droits niveau instance vient d’hériter de droits qui peuvent lui permettre de faire n’importe quoi niveau instance ….. C’est pas cool, ou du moins pas très clair côté sécurité.

Si l’option TRUSTWORTHY n’avait pas été activée, il n’aurait pas été possible de supprimer la base (refaites le test sans l’instruction SQL qui positionne le paramètre Trustworthy).

Si on était encore plus mal intentionné, on pourrait supprimer toutes les bases, faire le ménage dans les historiques des jobs, stopper l’instance, ou plus pernicieusement, altérer des données, ce qui serait plus difficile à détecter.

Cela est possible car on vient de s’accaparer les droits et l’identité du propriétaire de la base TestTrustworthy :

SELECT user_name(), SUSER_SNAME()

Imaginez maintenant que vous ayez activé l’option “xp_cmdshell” au niveau de l’instance … Ca pourrait être encore pire !

Moralité :

• TRUSTWORTHY seul, pourquoi pas (ouf, je suis sauvé, Seb ne m’en voudra pas trop)
• TRUSTWORTHY + délégation d’une partie de l’administration au travers du rôle DB_Owner :
• si le propriétaire de la base est simple utilisateur et ne dispose pas de droits niveau instance, vous limitez les conséquences aux bases dont l’utilisateur est propriétaire
• si le propriétaire de la base est sysadmin, vous avez une belle faille de sécurité.

Mon conseil :
Si vous voulez éviter tout risque, vous pouvez créer un login, niveau instance, qui ne va servir qu’a être le propriétaire d’une base de donnée. Ainsi, même avec le TRUSTWORTHY activé et plusieurs logins membres du rôle db_owner, vous héritez seulement des droits l’un login qui n’a pas de droits niveau instance.