Mot de passe sur des vues

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

Ç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 +

+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

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 !

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

Citation:

---

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,

Citation:

---

Envoyé par ricil78

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.

@dorinf => pour ton aide


@Bernardos => C'est bien que tu puisses travailler que dans un contexte parfait mais nous sommes (société pour qui je travaille) soyons dans une autre réalité
Désolé mais nous n'avons pas pour habitude de lâcher nos clients à la moindre bêtise qu'ils ont compris mais ne veulent pas entendre.


Merci à tous.

Citation:

---

@Bernardos => C'est bien que tu puisses travailler que dans un contexte parfait

---

ah ben non c'est pas tout à fait ce que j'ai dit. je suis loin de travailler dans des contextes parfaits...que du contraire. il m'arrive très régulièrement d'arriver chez un client dans un contexte de crise.
Avec soit des services en interne qui se tire dans les pattes et/ou des fournisseurs et prestataires qui se renvoient la balle.
La réticence au changement est aussi un paramètre qui rentre très souvent en compte.

Citation:

---

mais nous sommes (société pour qui je travaille) soyons dans une autre réalité
Désolé mais nous n'avons pas pour habitude de lâcher nos clients à la moindre bêtise qu'ils ont compris mais ne veulent pas entendre.

---

Prendre mes clics et mes clacs, c'est l'extreme solution. il y a plein d'étapes avant.
Ce qui est important s'est de ne pas se complaire dans une situation anormale voir merdique.
Ce que je dis c'est qu'il faut faire bouger les choses au maximum pour autant que cela soit du domaine du possible... mais qui ne risque rien n'a rien.
As tu essayer de remonter ce problème directement au client(et non pas au prestataire qui refuse de bouger)?
Cordialement,

Désolé on s'est pas compris.
oui j'ai essayé à tous les niveaux mais rien n'y fait.

Bonjour

Citation:

---

Envoyé par ricil78

- 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 :aie: (à 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 ! ).

Citation:

---

Envoyé par ricil78

Désolé on s'est pas compris. oui j'ai essayé à tous les niveaux mais rien n'y fait.

---

Alors, je dirais aussi : facturation pour toutes les réparations...
Sinon, pour ta vue, tu peux passer par une autre bd, voir une autre instance.
Dans ma boite actuelle (pour encore quelques heures... :ptdr:), on a un user sysdamin sur une bd vitale que tout le monde connaît et qui traîne même sur des post-it sur les écrans...
Bien sûr, ce compte est tellement vieux et inclus dans des myriades de scripts que l'on jamais pris le risque de changer le mot de passe ou de réduire ses droits d'accès.
On a maîtrisé ça en verrouillant l'accès à la machine par biais du firewall et distribué les accès à encore trop de monde à mon goût mais les bidouilleurs de bas étages en sont exclu tout de même. Petite victoire.
On a une application qui tourne en local sur les postes et qui se connecte à cette bd. Pour sécuriser les accès, l'application se connecte sur une autre instance en lecture seule qui ne contient que des vues qui sont en fait des liens via linked server vers la bd source.
La bd n'est pas énorme donc ce n'est pas trop problématique au niveau performance mais au moins les accès sont sécurisé !
J'espère avoir été clair.

Citation:

---

Envoyé par dorinf

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.

---

Je me réponds en me citant moi même :ptdr:

Autre possibilité, moins intrusive via les événements DDL. Vous pouvez loguer toutes les modifications qui ont été effectuées, notamment le quand ! Ainsi, lorsque le problème se reproduira vous pourrez :

• Préciser l'heure exacte de la modification. Pas par qui malheureusement puisque tout le monde utilise le même compte ;
• Présenter la facture (salée !) à votre client pour une opération sortant du cadre d'une évolution/maintenance.

S'il veut payer, tant pis pour lui, tant mieux pour vous. Argent facile. S'il refuse, qu'il fasse le nécessaire pour que cette situation ne se reproduise pas.

Citation:

---

Je me réponds en me citant moi même

---

schizophrène, tu vas trop vite :mrgreen:

Citation:

---

Présenter la facture (salée !) à votre client pour une opération sortant du cadre d'une évolution/maintenance.
S'il veut payer, tant pis pour lui, tant mieux pour vous. Argent facile. S'il refuse, qu'il fasse le nécessaire pour que cette situation ne se reproduise pas.

---

alors après tout dépend de la nature de la prestation de ricil78, si il travaille au projet/forfait. oui il peut faire douiller le client. Par contre si c'est de "l'assistance technique" (bodyshopping ou esclavagisme conviennent mieux mais on peut pas le dire officiellement en France) là, le client a payé donc il a le droit...

Ceci dit je n'arrive pas bien à comprendre pourquoi le prestataire refuse de faire un login par personne, peut-être n'en ont ils pas la capacité? @ricil78 : t'as qu'à aller les retrouver et tu dis que y a 10 mecs balaises qui ont dit que c'était de la connerie 8O et si tu veux tu nous les envoies, on saura les convaincre (ou pas) 8-)

Cordialement,

Citation:

---

Envoyé par ricil78

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 +

Citation:

---

Envoyé par ricil78

@Bernardos => C'est bien que tu puisses travailler que dans un contexte parfait

---

Si seulement on pouvait tous vivre dans le monde merveilleux des bisounours, où les choses iraient pour le mieux pour tout le monde :mouarf:

Bonjour,

Avez-vous tenté de demander la création de groupes Windows, auquel on octroie les permissions adéquates ?

Parfois il est impossible de faire changer d'avis, je parle pour ma petite paroisse, sur un petit changement de modèle de données, avec métriques à l'appui, on a souvent de la mauvaise volonté évidente quand ce n'est pas une négation de l'évidence. Quand on est employé, on fait partie des meubles, donc on finit par se taire pour ne pas se faire virer, et on prend passivement sa paie à la fin du mois.

Probablement que lorsqu'on est consultant, c'est différent, et j'aimerai être mouche pour voir une remontée de faits à une direction qui fait la sourde oreille, car il n'y a plus sourd que celui qui ne veut pas entendre ... :ptdr: Sans plaisanter, j'ai de gros doutes là-dessus. Prendre la décision de partir est délicat, car le monde est petit et une réputation peut être vite faite ... Mais je serais heureux de me tromper !

@++ ;)