Quelles permissions accordent aux utilisateurs des bases de données «réelles»?

Question

En lisant @ réponse de PerformanceDBA à Historical/auditable database a fait cette déclaration:

Dans une véritable base de données (SQL standard ISO/IEC/ANSI), nous ne GRANT INSERT/UPDATE/DELETE autorisation aux utilisateurs. Nous accordons SELECT et REFERENCES seulement (aux utilisateurs choisis) Tous les INSERT/UPDATE/DELETE sont codés dans les transactions, ce qui signifie process enregistré. Ensuite, nous accordons EXEC sur chaque proc stocké aux utilisateurs sélectionnés (utilisez ROLES pour réduire l'administration).

Est-ce vrai? Comment cela jive avec les outils ORM qui génèrent dynamiquement INSERT/UPDATEs?

MISE À JOUR

OK, donc voici un exemple. J'ai une application web avec deux interfaces, un Admin et un Utilisateur. Le côté administrateur utilise lourd ORM capable de générer dynamiquement des centaines sinon des milliers de commandes SQL distinctes.

L'interaction de l'utilisateur est beaucoup plus simple, et j'ai une douzaine de SP qui traitent les UPDATE/INSERT pour quelques boutons de vote. Évidemment, les utilisateurs sous lesquels les applications s'exécutent ont des ensembles d'autorisations très différents. Du côté administrateur, l'utilisateur DB de l'ORM a un accès CRUD complet pour relier les tables, il n'y a aucun SP utilisé pour cette application - et je ne penserais pas à toucher les données sans passer par la logique métier dans le modèle de domaine . Même les importations de données en masse sont traitées via l'ORM. Les PS du côté des utilisateurs Je considère une petite concession à ce principe simplement parce que c'est un cas si spécial.

Maintenant, je trouve quelque peu dérangeant l'énoncé ci-dessus dans la question originale, car je considère que c'est quelque chose d'une base de données «réelle», ou du moins proche de celle-ci.

Answer 1

Il jives comme votre grampa à une rave. Les ORM peuvent utiliser des SP mais ils n'en tirent pas le meilleur parti.

SP n'a été certainement la vie d'autrefois être, ce fut comme le onzième commandement, mais comme vous le soulignez ORM ne fonctionne pas vraiment comme ça. J'avais l'habitude de penser à toute la couche SP comme une sorte d'ORM prépubère en elle-même, vous avez pris votre DB relationnel, fait un tas de jointures et retourné un ensemble de données avec les colonnes/propriétés nécessaires pour remplir vos objets. De nos jours, avec les applications dynamiques de type ORM, les autorisations doivent être spécifiées sur la table, il n'est pas moins sûr si votre DBA fait son travail, c'est juste un peu plus de travail et il faut plus de communication concernant ce qui est autorisé sur les tables, si vous n'avez pas besoin de DELETE, votre DBA doit savoir ne pas donner d'autorisations pour cela.

Bon DBA savent qu'un DB sécurisé avec accès à la table est tout aussi sécurisé comme DB avec SP accès uniquement. Convaincre les DBA moins confiants de cela est une question beaucoup plus difficile.

Answer 2

Je dirais que c'est le meilleur design, et ce que j'aime généralement pratiquer. Parce que les requêtes ad hoc de l'application peuvent être désordonnées, difficiles à régler, et encore plus difficiles à dépanner et à tracer, il est plus facile d'avoir le niveau d'abstraction en utilisant des procédures stockées. L'application peut uniquement effectuer des appels de procédure stockée. Pensez à la procédure stockée en tant qu'API de la base de données.

Donc, si ce qui précède est l'objectif de conception, l'utilisateur de l'application n'a besoin que de SELECT et EXECUTE sur la base de données. Voici pourquoi:

create procedure MyTestProcedure 
with execute as 'UserWithDMLRights' 
as 

    -- your CRUD code 

go 

Si l'utilisateur typique d'application ne dispose que SELECT et EXECUTE, alors les autorisations d'exécuter la procédure stockée ci-dessus serait suffisant. Le INSERT/UPDATE/DELETE dans la procédure stockée serait exécuté dans le contexte de sécurité de UserWithDMLRights, et cet utilisateur de base de données devrait avoir les autorisations INSERT/DELETE/UPDATE. En ce qui concerne les ORM, je suis d'accord avec vous. Je crois que L2S fait juste de nombreux appels de requête ad hoc avec sp_executesql, donc je crois que vous rencontrerez un problème avec cette théorie et en utilisant la pratique de sécurité ci-dessus.