Dois-je donner à un client une connection SQL Server avec le rôle 'db_owner'?

Un de nos clients a demandé que nous incluions le rôle 'db_owner' sur la connection à la database utilisée par son site Web, afin qu'il puisse download un script (une page ASP) pour exécuter certaines modifications de la database. Normalement, les connections pour les bases de données hébergées sur notre server n'incluent que 'db_reader' et 'db_writer'. Est-ce correct, ou devrais-je requestr qu'ils nous envoient le script SQL pour s'exécuter en leur nom?

Ou suis-je trop protecteur? Merci

Je suggère que vous agissiez comme un filter entre eux et tout ce qu'ils pourraient vouloir faire à la database comme le téléchargement et l'exécution de ces scripts. S'ils obtiennent db_owner et arrosent tout, il sera probablement votre tête sur le billot pour les laisser l'avoir pour commencer.

Je pense que je voudrais avoir un accord de niveau de service qui soit acceptable pour tout le monde avant que je puisse donner autant de contrôle sur la database. Par exemple, vous pouvez spécifier que si le client endommage ses bases de données d'une manière qu'il ne peut pas corriger, votre réponse se limitera à le restaurer sur un sharepoint sauvegarde de son choix dans un certain timeout. Vous pourriez également leur requestr de maintenir un contact technique spécifique pour les problèmes de database qui sera le premier contact pour leurs développeurs, etc. Le SLA devrait préciser les différents risques, y compris la perte de données, hériter en ayant ce niveau de capacité.

En général, je suis en faveur de donner plus de contrôle, plutôt que less, si le client est prêt à accepter la responsabilité. En tant que personne qui utilise de tels services, je sais que cela peut certainement améliorer la productivité si je suis autorisé à faire les changements qui doivent être faits sans avoir à passer par des cerceaux. Je suis également prêt à accepter les risques impliqués, mais je sais clairement quelles sont les implications.

Quel genre de scripts utilisent-ils?

Plutôt que de leur fournir un access direct, vous pourriez fournir une sorte d'interface comme suggéré par TheTXI. Je serais très inquiet de donner l'access à db_owner inutilement.

C'est peut-être vous, ou un membre de l'équipe, ou selon le type de scripts, vous pouvez leur fournir une sorte d'interface web (ce qui vous permet d'avoir au less une certaine validation autour du script).

Mais s'ils exécutent directement quelque chose sur le système que vous ne voulez pas, il sera probablement sur vous (que ce soit juste la gestion d'une restauration ou quelque chose de plus sérieux)

Vous pouvez get plus de détails avec vos permissions pour les laisser faire ce que vous voulez. Cela dépend de combien de fois ils veulent apporter des changements et comment vous êtes responsable de leurs données. Je ne voudrais pas accorder dbo à quelqu'un à less qu'il y ait une très bonne raison.

Assurez-vous qu'ils sont le propriétaire de la database non seulement dans le rôle dbo. Si dbchaining est activé dans une autre database avec le même propriétaire, ils peuvent l'activer dans leur database et disposer des permissions dbo dans cette autre database.

Ou, faites-leur signer un accord qui stipule que "tout dommage que vous causez aux données ou au schéma de database causé par vous ou quelqu'un connecté sous ce count db n'est pas de votre faute et aucun blâme ne peut vous être imputé, etc." less s'ils bousillent quelque chose, de cette façon vous êtes couvert et le client rest heureux. Bien que vous pourriez vouloir leur donner un login séparé pour ceci, afin qu'ils ne puissent pas blâmer des changements incorrects sur le code de site Web.

Il y a un mot pour les DBA qui sont surprotecteurs: "Employé"

Le rest, pas tellement.