SQL Server Denali : Les rôles de serveurs

La CTP3 de SQL Server Code Denali nous laisse entrevoir un bon nombre de fonctionnalités qui seront présentes dans la version définitive du prochain SQL Server. Parmi ces nouvelles fonctionnalités quelques unes concernent la sécurité. Je commencerai donc par là en parlant des rôles de serveurs. Avec la prochaine version de SQL Server il est maintenant possible de créer ses propres rôles de serveurs, ce qui va permettre de faciliter l’administration de la sécurité en gérant les droits au niveau du rôle et non plus au niveau du compte de connexion lui-même comme c’était le cas jusqu’à maintenant lorsque les rôles prédéfinis de serveur ne suffisaient pas. Vous allez me dire qu’il était possible de contourner le problème en créant des groupes Windows et en leur affectant directement les privilèges nécessaires . Effectivement l’idée est plutôt bonne mais qu’en est il des comptes de connexion non Windows. L’un empêche pas l’autre et l’on pourra par exemple ajouter un groupe Windows à un rôle de serveur. 

Prenons un exemple parmi tant d’autres pour lesquel il serait intéressant d’avoir un rôle de serveur « personnalisé ».

  • Nous voulons donner les accès suffisants au groupe de DBA junior pour qu’il puisse effectuer du monitoring quotidien et créer des traces profiler

Prenons le premier cas :

– Création d’un rôle de serveur monitoring
CREATE SERVER ROLE monitoringRole AUTHORIZATION sa;

– Paramétrage des privilèges pour le nouveau rôle de serveur
GRANT VIEW SERVER STATE TO monitoringRole;
GRANT ALTER TRACE TO monitoringRole;

Notez au passage la nouvelle syntaxe (normalisée) permettant d’ajouter un login à un rôle de serveur (enfin !!). Il est encore possible d’utiliser les procédures connues telles que sp_addsrvrolemember ou sp_dropsrvrolemember mais celle-ci seront dépréciées dans la future version.

– Ajout du login test au nouveau rôle de serveur
ALTER SERVER ROLE monitoringRole
ADD MEMBER test;

L’audit des privilèges pour ces nouveaux rôles de serveur restent les mêmes que pour les rôles de serveurs classiques :

SELECT
P.name AS role_name,
P2.name AS [login_name],
SP.permission_name
FROM sys.server_principals AS P
INNER JOIN sys.server_permissions AS SP
ON P.principal_id = SP.grantee_principal_id
LEFT JOIN sys.server_role_members SRM
ON P.principal_id = SRM.role_principal_id
LEFT JOIN sys.server_principals AS P2
ON P2.principal_id = SRM. member_principal_id
WHERE P.[type] = ‘R’
AND P.[name] = ‘monitoringRole’
   AND P2.type IN (‘S’, ‘U’, ‘G’);

qui donne le résultat suivant dans mon cas :

image

David BARBARIN (Mikedavem)
MVP SQL Server

Laisser un commentaire