Vous n'êtes pas identifié(e).
Bonjour à tous
N'ayant pas eu de succès sur un autre forum j'ai trouvé celui-ci qui me semble plus approprié
.
Voici ma question :
.
Je suis en phase de test de PostgreSQL pour un nouveau projet
L'objectif est de diffuser notre application avec PostgreSQL dans des points de vente. L'installation sera fera certainement en batch à partir des binaires
Dans la majorité des cas il y aura quelques postes en réseau et une volumétrie pas énorme
Bref au niveau des performances je ne me fais pas trop de soucis, les tests sont concluants
.
Ce qui me dérange c'est l'aspect sécurité, vous allez peut être me dire que je me trompe (j'espère)
Dans ce genre d'installation, il y aura rarement un serveur mais c'est un poste du magasin qui fera office de serveur
.
Donc mon souci est au niveau de la sécurité
Comment protéger l'accès aux données ?
.
D'après mes premiers tests il suffit de remplacer "md5" par "trust" dans le pg_hba.conf et il n'y a plus aucune sécurité, on peut entrer sans mot de passe avec n'importe quel compte !
.
Je sais bien que les clients ne vont pas faire ce genre de manip mais c'est possible, c'est ça qui me gêne beaucoup
Et puis dans tous les cas je dois interdire la modification de données en dehors de mon application
.
Existe-t-il un moyen de sécuriser une installation PostgreSQL "locale" ?
Hors ligne
Bonjour,
Normalement avec une installation classique d postgresql sous windows, il est nécessaire d'être administrateur de l'ordinateur pour pouvoir modifier ce fichier. Par contre, étant donné qu'il y a un accès physique possible rien n'empêche d'utiliser le disque dur depuis un autre ordinateur avec accès administrateur pour accéder à toutes les données. Je ne suis pas spécialiste windows, mais à mon avis le seul moyen d'éviter ça est d'activer le chiffrement du disque via windows.
Julien.
https://rjuju.github.io/
Hors ligne
Merci de ta réponse rjuju
.
Je ne cherche pas à empêcher ça, je ne pourrais pas car je n'aurai pas le droit de faire ce genre de manip chez le client.
De plus le client sera en général administrateur de sa machine
La question n'est là. La question c'est plutôt : existe t'il un moyen pendant l'installation de spécifier que le mode (md5 en l'occurence) ne pourra jamais être modifié, et ce, même si le fichier pg_hba.conf est modifié (car je ne peux pas empêcher sa modification) ?
.
En gros un autre fonctionnement que par pg_hba.conf
Hors ligne
Non, le pg_hba.conf sera toujours pris en compte.
Julien.
https://rjuju.github.io/
Hors ligne
Alors ça veut dire qu'on ne pourra jamais sécuriser une base PostgreSQL dans ce genre de configuration.
ça me refroidit un peu sur le fait d'utiliser PostgreSQL qui pourtant me réjouissait
.
On a déjà passé beaucoup de temps sur le modèle de données, les benchs, la reprise de données (Access), les maquettes ... changer maintenant ferait une sacré rallonge à notre planning
Et puis changer pour quelle autre base ?
.
Je vais quand même mémoriser l'horodatage du fichier pg_hba.conf pour au moins être tenu au courant si il a été modifié
.
Merci de tes réponses
Hors ligne
Si les binaires de PostgreSQL sont livrés avec l'application, il n'est pas compliqué de supprimer la fonctionnalité qui permet l'authentification "trust".
Il faut aller dans les sources, fichier src/backend/libpq/auth.c et dans la fonction ClientAuthentication(), forcer une sortie d'erreur sur le même modèle que les autre erreurs d'authentification. Par exemple:
case uaRADIUS:
status = CheckRADIUSAuth(port);
break;
case uaTrust:
ereport(FATAL,
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
errmsg("trust authentication is not supported")));
/*status = STATUS_OK;*/
break;Dans le bout de code ci-dessus, l'appel de ereport(FATAL, ...) a été ajouté et ça doit suffire à inhiber ce mode d'authentification.
Ensuite la difficulté peut être de recompiler si on ne l'a jamais fait, mais pour un développeur c'est du domaine du possible.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci pour la piste dverite
Je vais étudier la question et voir si ça vaut le coup par rapport à l'éventuel risque d'une modif du .conf
Je n'ai jamais fait de recompilation en effet
Hors ligne
Je ne vois pas en quoi ça améliore la sécurite de l'application. Il suffit d'installer un PostgreSQL non modifié sur le même poste (après tout, le client est administrateur) et hop, accès trust possible.
Guillaume.
Hors ligne
J'oubliais d'ajouter que, quelque soit l'application, si le client est administrateur du poste, vous avez perdu la partie dès le début.
Guillaume.
Hors ligne
Bonjour,
et même si vous changer de SGBDR vous aurez ce problème. Ce n'est pas à cause de postgresql, mais plutôt du au fait d'être administrateur sur la machine qui héberge postgresql.
Avec Oracle ce serait le même problème de sécurité.
Imaginez dans un système Unix/Linux que vos utilisateurs sont root.... Vous aurez les mêmes problèmes de sécurité qu'avec vos utilisateurs administrateurs sous Windows.
Et pourquoi ne pas installer postgresql sur une machine isolée et attaquer la base en client serveur ? le compte sur cette machine serait alors sécurisé et inconnu de vos utilisateurs
Cordialement,
Cordialement,
Sébastien.
Hors ligne
Merci gleu et ruizsebastien pour vos remarques
.
De toute façon c'est clair qu'en mode admin je ne peux pas protéger grand chose
Mais il faut relativiser, je suis plutôt en mode parano mais ça n'arrivera surement jamais qu'un client connaisse la manip pour passer en mode trust ou même qu'il tente de le faire
.
Au pire si ça arrive j’essaierai de le tracer.
Et concernant les données sensibles elles seront cryptées de toute façon
.
@ruizsebastien si c'est possible d'installer PostgreSQL sur un "vrai" serveur je le ferai mais malheureusement dans la plupart des cas on sera juste fournisseur de l'application et le client nous dira juste où l'installer (on fait les install à distance)
.
Merci à tous de vos lumières, je reviendrai certainement vers vous pour d'autres questions
Hors ligne
ça n'arrivera surement jamais qu'un client connaisse la manip pour passer en mode trust
Sur google si on cherche "postgresql se logger sans mot de passe" on sait immédiatement comment faire. Comme l'oubli de mot de passe est un grand classique, ce type de manip est abondamment documenté, toujours avec la même réponse: mettre provisoirement trust.
Un admin neuneu qui ferait ça alors qu'il n'est pas censé le faire, c'est un scénario réaliste, on a vu pire. C'est pourquoi rendre ça inopérant a une utilité pratique même si c'est contournable, en réinstallant postgres ou autre. Certes avec un accès physique au serveur et a fortiori avec un compte admin on peut théoriquement faire ce qu'on veut, mais ça n'empêche pas de mitiger le risque en augmentant la difficulté.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Je suis d'accord avec toi dverite il vaut mieux certainement protéger un peu plus même si c'est contournable
Je n'ai jamais fait de recompilation et j'avoue que ça me fait un peu peur
Je vais quand même me renseigner sur le sujet
Les gens qui vont utiliser l'application ne sont ni des admin, ni des développeurs, mais on ne sait jamais ...
Hors ligne