PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → Diificulté d'un Editeur d'une application windev sur SQL Server, Problème : Windev
Diificulté d'un Editeur d'une application windev sur SQL Server, Problème : Windev
Débuté par Ralph IGCI, 05 juil. 2024 13:29 - 3 réponses
Membre enregistré
446 messages
Posté le 05 juillet 2024 - 13:29
Bonjour,
On a installé une application sur un serveur SQL Server. Elle fonctionne bien. Le problème c'est que un informaticien interne , employé de notre client a modifié des données sur le serveur, parce l'application a son dispositif qui l'empêche.
On ne peut pas prendre le contrôle les serveurs du client. Comment faisons nous pour garder une cohérence de donnée chez le client ?(Eviter que les informaticiens accès aux données en dur)
Deuxième chose, à supposer que nous puissions le leur empêcher, comment informer la hiérarchie de la modification des données en dur ?
Il a déjà été suspendu et nous sommes en discussion sur les responsabilités.
Qu'aurions nous dû exiger auprès du client pour éviter ce genre de déconvenue ?
Le problème se poserait pas si j'étais dans HFCS par exemple.
Le Mouchard que nous avons mis en place est lié aux actions dans l'application, pas si la BDD est modifié seule.
Merci
Membre enregistré
1 635 messages
Posté le 08 juillet 2024 - 09:43
Hello,

Il est possible de mettre un mot de passe sur les fichier HFSQL :
https://doc.pcsoft.fr/fr-FR/?1000018781&name=hchangemotdepasse_fonction
https://doc.pcsoft.fr/fr-FR/?3044108
Membre enregistré
2 676 messages
Posté le 08 juillet 2024 - 12:06
Bonjour,

- Lors de l'installation de SQL Server, il est possible de n'autoriser la connexion à la base qu'à partir d'un nom d'utilisateur et mdp, donc supprimer la connexion avec l'authentification Windows.
- Mettre un mdp fort pour la connexion en "sa" et non communiqué au client.
- Si le client a besoin d'un accès, lui créer un utilisateur qui n'aura en accès qu'en lecture
- Si besoin de plus, créer des trigger sur les tables sensibles qui vont stocker les modifications dans une table de log avec l'utilisateur concerné, la requête exécutée...
- SQL Server autorise aussi l'anonymisation des données qu'il est judicieux de mettre en place : RGPD oblige

Tout cela va demander certainement des modifs niveau applicatif, mais ça sécurise tout.
--
Cordialement,

Philippe SAINT-BERTIN
Message modifié, 08 juillet 2024 - 12:07
Membre enregistré
123 messages
Posté le 08 juillet 2024 - 14:01
bonjour,

Je suis d'accord avec Philippe SB pour tou excepté pour ne pas donner le mot de passe "sa" au client.
Ca va être compliqué s'il a un SI interne; à part si vous demandez à ce que le serveur vous soit totalement dédié, donc aucune autre base sur l'instance et que vous en garantissez la maintenance et les sauvegardes, ce que je doute.
Et je ne parle pas du fait que si l'on respecte le RGPD il est préconisé que le client ne divulge pas les mots de passe donc pas celui du "sa" non plus.