SQL Server: quelle est la raison de privilégier les rôles de base de données personnalisés par rapport aux rôles fixes?

Cela peut être un peu vague, mais je me demandais dans quelle mesure les DBA utilisent des rôles de base de données fixes contrôlant la sécurité des bases de données. La question est donc de savoir s'il existe une raison de privilégier les rôles de base de données personnalisés par rapport aux rôles de base de données fixes (db_datareader, etc.)?

Les rôles de base de données fixes fournissent des autorisations à toute la base de données. Les rôles personnalisés entrent en jeu lorsque vous ne souhaitez pas accorder aux utilisateurs des autorisations sur l'ensemble de la base de données, juste une partie de celle-ci.

Par exemple, db_datareader fournit l'autorisation SELECT à chaque table, vue, etc. de cette base de données. Pour des raisons de conformité, il peut y avoir des tableaux ou des vues que le personnel des RH ne devrait pouvoir sélectionner que d'autres et non. C'est généralement là que les rôles personnalisés entrent en jeu.

Les rôles de base de données standard sont parfaits pour les bases de données où il n'y a que quelques utilisateurs ou lorsqu'il n'y a pas d'équipe de DBA pour gérer les autorisations. Cependant, s'il y a plusieurs utilisateurs avec une grande équipe de base de données et des données sensibles, il serait sage de créer des rôles personnalisés afin de savoir qui regarde quoi.

En ce qui concerne la sécurité des données (et des bases de données), vous souhaitez verrouiller les choses autant que vous le pouvez tout en permettant à chacun de faire son travail sans défis majeurs. Les rôles personnalisés correspondent très bien à ce projet de loi.

Non, je ne pense pas qu'il y ait une raison de privilégier les rôles de base de données personnalisés, SAUF qu'ils sont plus spécialisés et adaptés à votre environnement et à vos besoins. Les développeurs examineront l'offre standard, et si elle convient au travail - parfait! Mais si ce n'est pas le cas, il est temps de personnaliser!

Raisons pratiques, notamment avec db_datareader et db_datawriter

• les utilisateurs finaux peuvent altérer l'historique et les tables d'audit
• Conformité PCI / SOX / Adit
• vous aurez des feuilles de calcul se connectant à votre base de données
• ... ce qui vous donne également des dépendances inconnues sur la table et les vues
• les utilisateurs ne comprendront pas la normalisation ou la conception de la base de données
• toutes les données ne sont pas destinées à tous les utilisateurs
• ...

Les autres rôles db ne sont pas vraiment utilisés, j'ai trouvé