Rôles de base de données SQL 2005 et sécurité

Question

J'ai migré vers la création/l'utilisation de schémas dans Sql Server 2005, où j'ai également créé des rôles de base de données et des schémas assignés aux rôles. Le problème que j'ai est l'un des rôles db que je dois avoir un accès complet - disons SuperSysRole.
Cependant, lorsque j'attribue une connexion à ce rôle, il ne peut pas exécuter des commandes spécifiques. En particulier, je souhaite qu'un utilisateur de ce rôle gère les réinitialisations de mot de passe. Cependant, lorsque j'exécute la procédure stockée, elle ne renvoie pas tous les utilisateurs dans la base de données.

La procédure stockée a été exécutée qui renvoie les détails et appelle une vue qui intègre les tables sysusers et sysmembers.

L'utilisateur, par exemple myAdmin, a été affecté au rôle SuperSysRole. Le rôle SuperSysRole a été accordé à la procédure stockée selectRoles.

C'est probablement une chose simple mais quelqu'un peut-il me dire s'il vous plaît ce qui me manque?
Mon application s'authentifie à l'aide du nom d'utilisateur et du mot de passe myAdmin. Cela fonctionne très bien lorsque je me connecte avec le compte sa.

Answer 1

L'appartenance au rôle de base de données peut être interrogée via les vues de catalogue sys.database_principals et sys.database_role_members, qui sont les vues de catalogue appropriées à utiliser à la place des sysusers et sysmembers obsolètes. Tous les deux ont les mêmes restrictions de sécurité:

Dans SQL Server 2005 et les versions ultérieures, la visibilité des métadonnées dans vues de catalogue est limité à sécurisables qu'un utilisateur possède ou sur lequel l'utilisateur a été accordée certains permission.

Les autorisations nécessaires sont répertoriées dans GRANT Database Principal Permissions: VIEW DEFINITION. Aucune autorisation ne peut être accordée pour afficher une définition de principal et de rôle.

Votre meilleure option consiste à créer une procédure qui sélectionne les vues de catalogue de métadonnées appropriées et à signer cette procédure avec une information d'identification ajoutée au rôle db_securityadmin. Voir Signing an Activated Procedure pour un exemple comment signer une procédure. La subvention EXÉCUTER sur cette procédure à quiconque a besoin de voir ces principes et les appartenances aux rôles. Cependant, tout cela ne vous mènera nulle part en ce qui concerne l'intention déclarée: gérer les réinitialisations de mot de passe. Seuls les principaux du serveur (aka: logins) ont des mots de passe, et tout schéma conçu au niveau des principaux de la base de données ne peut avoir aucun effet sur les principaux du serveur, car ils sont une mauvaise abstraction. Et comme il n'y a pas de rôles de serveur à définir (vous ne pouvez avoir que des groupes Windows en tant que rôles, mais vous voulez utiliser SQL Auth), vous ne pouvez pas faire cela par l'appartenance au rôle.

Ma recommandation est, encore une fois, d'utiliser la signature de code. Créez des procédures qui effectuent les activités souhaitées (requête sys.server_principals et sys.sql_logins pour inspecter l'expiration du mot de passe, émettre des instructions ALTER LOGIN pour réinitialiser les mots de passe, etc.) puis utilisez la signature de code pour signer ces procédures et accorder les privilèges requis à la signature. Je vous renvoie à Signing an activated procedure pour un exemple comment faire cela. Accordez ensuite EXECUTE sur ces procédures aux utilisateurs "spéciaux" qui doivent les gérer.