Discussion :

[ricil78]

Bonjour,

Sur le serveur d'un client nous sommes plusieurs prestataire sur le même compte Windows
La base est en authentification Windows et on ne peut pas changer de système.
ça fait plusieurs fois que l'on a des vues qui sont modifiés

On voudrait juste un mot de passe sur la modification d'une vue.
j'ai cherché mais j'ai rien trouvé dans ce sens.

On ne veut pas crypter les vues car pour modifier la vue il nous faudrait rejouer le script/code de la vue
les besoins du client change régulièrement et se serait dangereux pour nous au final de ne pas pouvoir modifier en direct la vue.


une idée ?

Merci

[SQLpro]

Ça n'est pas possible et c'est une imbécilité que d'utiliser un seul et même compte Windows pour accéder au serveur. Imaginez que tous les étrangers qui veulent venir en France possède le même passeport ?


Commencez par régler le problème d’authentification par une individualisation et le problème se réglera de manière "naturelle".

A +

[julien94320]

+1 avec SQLPro et verifiez avec votre administrateur que les utilisateurs disposent des bons droits...

Ont ils la nécessité de faire des modifications ?

Le probleme de droit sera toujours le même si vous vous autorisez tous a modifier vos vues ... Avez vous quelqu'un pour centraliser ces modifications ?

Julien

[Invité]

J'en rajoute une couche avec mes prédécesseurs.
Donner les droits sysadmin à un utilisateur applicatif est injustifié et dangereux.
Ou utiliser SA comme utilisateur applicatif, non c'est débile.
Bien sûr, il y a moyen de changer ça mais il va falloir être inventif et lutter contre les mauvaises pratiques qui s'installent inutilement.

La semaine dernière, j'ai montré à un dev (intelligent) qu'il était assez simple d'impacter un serveur de prod sans se forcer : avec une petite table et un produit cartésien, le CPU a pris grimper de 10 points !
Juste un preuve par l'exemple que l'impact d'un utilisateur n'est jamais à prendre à la légère et ses droits avec !

[ricil78]

Votre description d'un monde parfait me fait rêver mais la réalité est tout autre :

- le serveur ne nous appartient pas, il appartient à mon client
- nous ne gérons aucune sécurité du site, cela est à la charge d'un prestataire de mon client qui ne veut rien entendre (aucun lien avec nous)

Vous pensez bien que l'on a déjà essayé de changer la situation.
Pour faire court les réponses obtenues : Non non et non
bref, quand vous n'avez pas le choix et que l'on vous impose, vous faites avec.

Merci quand même pour votre aide

[Bernardos]

bref, quand vous n'avez pas le choix et que l'on vous impose, vous faites avec.

alors là pas d'accord du tout!!!!
je travaille comme consultant depuis maintenant 6 ans (et sous sql server depuis 15 ans)
Je suis d'accord avec le principe de dire "C'est le Business qui guide les décisions", "au final, les décisions appartiennent au Client"...jusqu'à un certain point.
Nous, "prestataires", avons un devoir de conseil (chacun à notre niveau). si tu vois une grosse connerie du genre 1 login pour 20 personnes d'entreprises différentes, tu peux pas laisser faire.
Moi perso dans ton cas, je serais déjà à la direction de mon client, en train de démontrer la stupidité de la situation. et si la direction décide de laisser en l'état, je prend mes clics et mes clacs et je m'en vais.
Si tu n'as pas les épaules assez solides pour faire ça en direct, tu remontes à la direction de ta boite pour qu'il gère avec la direction de ton client.

Cordialement,

[François DORIN]

Vous pensez bien que l'on a déjà essayé de changer la situation.
Pour faire court les réponses obtenues : Non non et non
bref, quand vous n'avez pas le choix et que l'on vous impose, vous faites avec.

Merci quand même pour votre aide

Effectivement, il y a bien souvent des choix qui nous sont imposés et il faut faire avec. Maintenant, si un autre de ses prestataires "s'amuse" à modifier vos vues, et que le client ne veut rien entendre, il faut frapper au porte monnaie. Cela lui fera peut être changé d'avis (ce qui n'est pas sur !).

Sinon, à défaut de mot de passe sur les vues, tu peux peut être essayer de mettre des triggers via les événements DDL qui vont déclencher des exceptions quand tu vas mettre à jour des vues justement. Pour pouvoir mettre à jour les vues, il faudra désactiver les triggers. Un petit lien d'aide. C'est du bricolage, mais en fonction du niveau du presta en face (et modifier des vues qui ne leur appartiennent pas donne quelques indications...) cela suffira peut être pour les bloquer.

[aieeeuuuuu]

Bonjour

- nous ne gérons aucune sécurité du site, cela est à la charge d'un prestataire de mon client qui ne veut rien entendre (aucun lien avec nous)

Vous pensez bien que l'on a déjà essayé de changer la situation.
Pour faire court les réponses obtenues : Non non et non
bref, quand vous n'avez pas le choix et que l'on vous impose, vous faites avec.

Bah alors, un petit DROP DATABASE, et le prestataire en question devrait vite être remplacé par quelqu'un de compétant (à moins qu'il n'arrive à démontrer qui est à l'origine de la boulette, mais ça va être compliqué puisque tout le monde utilise le même compte...)

plus sérieusement, si le remplacement de vos vues est un acte malintentionné, il n'y a en effet pas grand chose à faire dans cette situation.
S'il s'agit d'erreur (collision de nom entre vos vues et celles d'un autre presta par exemple), alors vous pourriez tout simplement créer vos vues dans un schéma séparé, ça limiterait la casse (et en plus, vous vous y retrouveriez mieux ! ).

[SQLpro]

bref, quand vous n'avez pas le choix et que l'on vous impose, vous faites avec.

Donc vous ne faites pas parce que c'est juste impossible...
Il suffit donc de le dire à votre client :
"la sécurité mise en place par votre prestataire est si déficiente qu'elle interdit toute possibilité de satisfaire votre demande."

A +