web-dev-qa-db-fra.com

SET IDENTITY_INSERT peut-il être autorisé avec moins de privilèges que db_ddladmin?

J'ai hérité d'un système où l'application s'exécute sous le compte sysadmin. J'ai limité ce compte à db_datareader + db_datawriter + EXECUTE sur toutes les bases de données et définissez extended events session pour attraper le permission errors sur le serveur.
J'ai été très surpris de voir que inserts a échoué même si l'utilisateur est membre de db_datawriter et aucune restriction granulaire sur les tables n'est appliquée.

Ensuite, je note que seules les insertions qui définissent IDENTITY_INSERT échoué. La base de données en question est remplie de identity et il y en a trop SET IDENTITY_INSERT dans leur code. Le code signifie non seulement modules stocké sur le serveur mais aussi C# code.

Pour pouvoir définir identity_insert L'utilisateur doit posséder la table ou avoir l'autorisation ALTER sur la table. Mais le fait est que vous NE POUVEZ PAS accorder ALTER uniquement sur les tables , je suis obligé d'accorder ALTER sur un base de données entière à cette user (je ferai de cet utilisateur membre de db_ddladmin rôle qui ajoutera seulement 42 autorisations (!!!) vs 51 autorisations qui pourraient être ajoutées aux autorisations utilisateur en accordant ALTER sur la base de données)

Je ne souhaite pas refactoriser la base de données avec sequence (la version du serveur est 2014 pour que je puisse le faire théoriquement) et je ne peux pas simplement ajouter execute as dbo à tous les sp qui utilisent identity_insert parce qu'il y a aussi du code d'application à réécrire, je me demande juste POURQUOI Microsoft fait une conception d'autorisations si étrange que db_datawriter ne peut pas définir identity_insert?

Existe-t-il un autre moyen de permettre à l'utilisateur de définir identity_insert qui ajoutera moins d'autorisations que db_ddladmin?

MISE À JOUR

J'ai essayé la solution proposée par LowlyDBA avec synonyms:

create table dbo.t(id int identity);
go

alter schema sch transfer dbo.t;
go

create synonym dbo.t for sch.t;
go

set IDENTITY_INSERT dbo.t on;

Cela provoque l'erreur

Msg 1088, niveau 16, état 11, ligne 1 Impossible de trouver l'objet "dbo.t" car il n'existe pas ou vous ne disposez pas des autorisations.

enter image description here

La solution de Antoine Hernandez pour accorder à l'utilisateur ALTER uniquement sur le schéma semble être le moindre des maux, donc je l'accepte

sql-serversql-server-2014permissionssecurityidentity
4
sepupic

Je vous suggère de créer un rôle de base de données personnalisé en cliquant avec le bouton droit sur le dossier du rôle de base de données.

enter image description here

Cela fera apparaître le rôle de base de données que vous pourrez ensuite personnaliser. Sur le premier écran, vous pouvez donner au rôle le nom et le propriétaire de votre choix. Vous pouvez également ajouter l'utilisateur dont vous souhaitez être membre de ce rôle. enter image description here

Une fois cela fait, vous pouvez cliquer sur Securables afin que vous puissiez ensuite choisir quoi accorder. enter image description here

Ajouter des objets apparaîtra et je suggère de sélectionner l'option "Tous les objets des types ..." et cliquez sur OK. enter image description here

Dans Sélectionner les types d'objets, faites défiler vers le bas pour rechercher des schémas, cochez la case, puis cliquez sur OK. enter image description here

Maintenant, vous verrez une liste de schémas, choisissez donc le ou les schémas qui ont les objets auxquels vous souhaitez accorder des autorisations et il affichera les autorisations pour ce schéma ci-dessous. enter image description here

Pour cet exemple, j'ai choisi le schéma dbo. J'ai redimensionné l'écran par défaut pour en afficher plus à la fois. enter image description here

Dans ce cas, je choisirais très probablement d'accorder Alter parce que, selon Microsoft , "Lorsqu'il est accordé sur une étendue, ALTER confère également la possibilité de modifier, créer ou supprimer (accent sur le mien) tout élément sécurisable contenu dans cette étendue . " Sur la base de l'infographie sur les autorisations de base de données, située ici et ci-dessous l'octroi de la modification sur le schéma accordera la modification sur l'agrégation, la valeur par défaut, la fonction, la procédure, la file d'attente, la règle, le synonyme, la table et la vue: Microsoft link https://aka.ms/sql-permissions-poster Étant donné que je suis à ce stade, pour ce même rôle, j'accorderais probablement aussi Execute afin que le membre du rôle puisse également exécuter n'importe quelle procédure stockée, donc lorsque de nouvelles tables ou procédures stockées sont ajoutées à la base de données, je n'aurais pas pour modifier toute sécurité pour permettre aux nouveaux objets de fonctionner comme les objets existants. Ainsi, les sélections ressembleraient à ceci une fois terminées: enter image description here

J'aurais pu aller plus loin et accorder également Select, Insert, Update et Delete, et cela aurait probablement couvert tout ce dont le rôle aurait besoin pour lire, insérer, supprimer et mettre à jour n'importe quelle table ainsi que pour exécuter n'importe quelle procédure stockée sans avoir besoin d'accorder toutes les autres autorisations accordées par le rôle db_ddladmin. En procédant ainsi au niveau du schéma, cela peut faciliter la gestion de la sécurité à certains égards, en particulier lorsqu'un utilisateur particulier doit avoir beaucoup, sinon la totalité des accès au niveau du schéma, mais satisfait également à l'exigence de ne pas accorder de modification à l'ensemble. base de données. S'il y avait d'autres autorisations accordées par cette configuration et dont le rôle n'a pas besoin, vous pouvez ensuite ajouter des autorisations DENY si nécessaire.

6
Antoine Hernandez