Version imprimable
Bonjour
Est-il possible de protéger le code plpgsql?
Voici mon produit de gestion d'école.
Je compte faire passer mes données à PostgreSQL tout en gardant ACCESS comme interface.
Ma question est de savoir s'il est possible d'empêcher tout autre accès à PostgreSQL qu'à partir de mon appli ACCESS? (même si je dois y passer aussi!!!)
Merci d'avance
@+
En modifiant le fichier pg_hba.conf ça doit être assez simple, avec un utilisateur spécifique à Access :
http://www.postgresql.org/docs/9.3/s...-hba-conf.html
Salut et grand merci de la réponse.
Le fichier pg_hba.conf est en faite le problème pour ce genre de situation.
Toute utilisateur avec droit d'administrateur sur le pc peut alors modifier le fichier et entrer dans ma base.
Souvent, quand on présente un produit 100% ACCESS on vous balance des trucs du genre: on nous dit que c'est pas fiable; c'est lent.
Moi je sais ce que ACCESS est capable de faire, mais il est souvent très difficile de briser ce mur construit par des soit disant ingénieur ne sachant faire que "Hello word" avec C ou C++.
L’intérêt de PostgreSQL serait d'avoir la confiance des gros clients (réseau local avec souvent jusqu'à 100 utilisateurs connectés) quant à la rapidité et la fiabilité. Je pourrais alors transférer tous les traitements lourds directement sur le serveur.
Avec le ph_hba c'est la concurrence qui va se frotter les mains.
enterprisedb propose une solution payante (pl/secure) qui crypte le code plpgsql. Je voudrais savoir s'il y a une solution free ou une astuce pour fermer hermétiquement mes objets (vues, procédure et triggers).
Merci d'avance.
@+
Salut
J'ai trouvé une solution. Il reste à savoir les avantages et inconvénients.
- créer un compte admin avec mot de passe
- installer postgresql avec ce compte
- chiffrer le dossier data avec le chiffrement de win7
- configurer le service de postgresql pour démarrer avec le compte admin créé
- créer une tache de sauvegarde des données uniquement avec pgagent
- au démarrage du serveur aucun compte ne sera ouvert.
Si vous avez des remarques je suis à l'écoute.
@+
Bonjour,
Je pense qu'il est important de recadrer un peu les choses si vous me le permettez.
Il n'y a aucun problème à ce niveau là. Le problème de fond ici est la protection des gestions des accès sur la machine faisant tourner votre serveur postgresql. Ainsi sous linux, si quelqu'un hack votre accès root, votre machine ne vous appartient plus, et le problème de pg_hba.conf ne se posera même plus, puisque dans l'absolu, même un formatage peut être opéré, effaçant toutes vos données et applications. De la même manière, il est important sous Windows, de contrôler votre stratégie des profils d'accès d'une manière précise et pertinente.Citation:
Le fichier pg_hba.conf est en faite le problème pour ce genre de situation.
Toute utilisateur avec droit d'administrateur sur le pc peut alors modifier le fichier et entrer dans ma base.
Access peut très bien être approprié pour certains usages de production et d'exploitation, et largement inapproprié pour d'autres. Ensuite si vous avez jusqu'à 100 utilisateurs connectés et souvent, la question ne se pose pas, Access n'est pas taillé pour cela, car il ne saura pas gérer la concurrence sur autant de connections avec la rigueur qui s'impose, et même si votre base est exploitée en lecture seule, à cette echelle, votre bande passante réseau risque très fortement d'être monopolisée par votre base Access, pour ne pas dire qu'elle va créer un blocage réseau.Citation:
Souvent, quand on présente un produit 100% ACCESS on vous balance des trucs du genre: on nous dit que c'est pas fiable; c'est lent.
(...)
L’intérêt de PostgreSQL serait d'avoir la confiance des gros clients (réseau local avec souvent jusqu'à 100 utilisateurs connectés) quant à la rapidité et la fiabilité. Je pourrais alors transférer tous les traitements lourds directement sur le serveur.
Choisir postgresql dans ce contexte me paraît donc être une condition minimale d'exploitation au niveau de votre Base données, car MySQL ne sera pas approprié également pour des raisons d'inaptidudes à gérer votre concurrence efficacement dans ce contexte.
Excusez-moi mais crypter le code, c'est vraiment de la paranoïa mal placée qui va de plus créer un overhead non négligeable sur les performances globales de votre solution alors que cela n'est pas justifié.Citation:
Avec le ph_hba c'est la concurrence qui va se frotter les mains.
enterprisedb propose une solution payante (pl/secure) qui crypte le code plpgsql. Je voudrais savoir s'il y a une solution free ou une astuce pour fermer hermétiquement mes objets (vues, procédure et triggers).
Si vous ne savez pas gérer un contrôle d'accès efficacement via les rôles sous postgresql ou toute base de données relationnelles qui se respecte, je vous invite à vous documenter sur le sujet en commençant par la documentation officielle de votre produit.
Cordialement et bonne année :)
Salut
Bonne année à toi.