Quelles sont les autorisations minimales requises pour effectuer des tâches administratives sur la base de données système ?
Question
Quelles sont les autorisations minimales nécessaires pour effectuer des tâches administratives sur la base de données système BarTender dans BarTender 2019 et versions ultérieures ?
Réponse
Rôle serveur : dbcreator et Rôle base de données : db_owner sont les autorisations minimales requises pour effectuer toutes les tâches administratives disponibles dans la Console d’administration pour la base de données système BarTender.
Voici un récapitulatif des autorisations nécessaires pour chaque tâche dans la Console d’administration :
| Action/Procédure | Autorisations minimales |
| Afficher la taille de la base de données | Autorisation base de données : Afficher l’état de la base de données |
| Sauvegarder la base de données |
Autorisation base de données : Sauvegarder la base de données Le dossier où la sauvegarde est enregistrée doit exister, et le service SQL Server doit avoir les droits de lecture/écriture sur ce dossier. |
| Restaurer la base de données |
Rôle serveur : dbcreator Rôle base de données : db_owner |
| Exécuter la maintenance maintenant |
Autorisations base de données : Connecter, supprimer, exécuter, insérer, sélectionner, mettre à jour, sauvegarder la base de données (si la case « Archiver les enregistrements supprimés » est cochée) |
| Purger tous les enregistrements maintenant |
Autorisations base de données : Connecter, supprimer, exécuter, insérer, sélectionner, mettre à jour, sauvegarder la base de données (si la case « Archiver les enregistrements supprimés » est cochée) Rôle base de données : db_ddladmin |
Cependant, même avec le bon ensemble d’autorisations, il existe actuellement un problème connu qui fait échouer l’exécution de la maintenance à moins que l’utilisateur qui lance l’action ait le rôle sysadmin. Le message d’erreur sera similaire à celui-ci :
Stored Procedure: sp_updatestats Failed; Inner Message: User does not have permission to perform this action.
Processed 584 pages for database 'SystemDB', file 'SystemDB' on file 1.
Processed 1 pages for database 'SystemDB', file 'SystemDB_log' on file 1.
BACKUP DATABASE successfully processed 585 pages in 0.091 seconds (50.217 MB/sec).
Il s’agit d’un problème connu de SQL Server. L’une des procédures stockées utilisées lors de la maintenance, « SpDeleteRecords », appelle une procédure « builtin » de SQL Server nommée « sp_updatestats ». Cela permet d’améliorer les performances des requêtes après la suppression des enregistrements.
Malheureusement, même si la documentation Microsoft indique que le propriétaire de la base de données (dbo) a l’autorisation d’exécuter cette procédure, il existe actuellement un bug dans SQL Server qui provoque l’échec de cette opération.
Une solution de contournement pour les clients consiste à modifier la procédure stockée « SpDeleteRecords » (via SQL Server Management Studio) comme suit :
Générez un script ALTER pour « SpDeleteRecords » en faisant un clic droit dessus dans le volet de gauche de SQL Server Management Studio sous « VotreBaseDeDonnées\Programmabilité\Procédures stockées », faites un clic droit sur dbo.SpDeleteRecords et sélectionnez « Script procédure stockée en tant que ALTER vers > Nouvelle fenêtre de l’éditeur de requête ».
Ajoutez « with execute as 'dbo' » à la ligne ALTER du script comme suit :
ALTER PROC [dbo].[SpDeleteRecords](@pastUtcTicks bigint, @categories nvarchar(1024)) with execute as 'dbo'
Exécutez ce script avec F5 ou le bouton « ! Exécuter » de la barre d’outils.
Cela forcera l’exécution de « SpDeleteRecords » sous les identifiants du propriétaire de la base de données. Après avoir modifié la procédure stockée, essayez de relancer la maintenance (avec les autorisations minimales mentionnées dans le tableau ci-dessus) et cela devrait fonctionner.
Informations supplémentaires (Usage interne uniquement)
Voir DEVQ-4363 et BUG-2270
De plus, tôt ou tard, nous aurons probablement des retours concernant la nécessité d’accorder certains rôles serveur ou autorisations de base de données, ce qui peut représenter un risque de sécurité (comme db_owner). En fait, j’ai reçu cette question d’un client aujourd’hui, et voici ce que j’ai répondu :
Plutôt que de se concentrer sur le rôle de base de données attribué à cet utilisateur SQL Server, j’aborderais la question sous l’angle suivant :
- Le mot de passe du compte SQL Server utilisé par la base de données système BarTender est-il complexe et donc plus sécurisé ?
- Quel membre de votre entreprise connaît ou a accès à ce mot de passe ?
L’autorisation db_owner sur la base de données est déjà un sujet de préoccupation pour un administrateur SQL Server, mais je pense que l’essentiel est de savoir qui a accès au mot de passe de ce compte SQL Server, et à quel point ce mot de passe est complexe.