Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
notre société est à 2 semaines de son démarrage en production et je me pose des questions existentielles sur la sécurité de la base.
Voici mon pg_hba.conf :
local all postgres peer
local all all md5
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
host replication replic xx.xx.xx.xx/32 md5
host xxxxxxxxx postgres xx.xx.xx.xx/32 md5
Est-ce que c'est assez blindé pour un site Internet ?
Est-il conseillé de changer le port par défaut de postgres ?
La base est propriété de postgres, mais j'ai laissé les tables propriété du rôle d'accès public à la base.
Est-ce une erreur ?
Toutes les tables sont dans le schéma public, pas de pb ?
Quelles sont les erreurs classiques des débutants sur Pg niveau sécurité ?
Quelles sont les attaques classiques sur pg , au delà de l'injection sql ? Il n'y a ni phppgadmin, ni pgadmin en prod.
Merci pour votre patience et vos conseils, je fais des cauchemars où la base est piratée au bout d'une semaine...
Hors ligne
Est-ce que c'est assez blindé pour un site Internet ?
En terme de méthode d'authentification, c'est toujours mieux que trust et password. Maintenant si vos mots de passe sont faciles à deviner et ne changent jamais...
Est-il conseillé de changer le port par défaut de postgres ?
Ça n'a aucun intérêt en terme de sécurité.
La base est propriété de postgres, mais j'ai laissé les tables propriété du rôle d'accès public à la base. Est-ce une erreur ?
Non. Mais ça ne veut pas dire que ça soit sécurisé pour autant (surtout si l'utilisateur que vous utilisez est superutilisateur.
Toutes les tables sont dans le schéma public, pas de pb ?
Pas en soi, non.
Quelles sont les erreurs classiques des débutants sur Pg niveau sécurité ?
Utiliser la méthode trust, mettre des mots de passe bidons.
Quelles sont les attaques classiques sur pg , au delà de l'injection sql ? Il n'y a ni phppgadmin, ni pgadmin en prod.
Relatives aux erreurs classiques 
Guillaume.
Hors ligne
Les mots de passe sont assez compliqués(lettres et chiffres), et l'utilisateur public n'est pas superutilisateur.
Je vais dormir (un peu) plus tranquille.
Merci
Hors ligne
Quelles sont les attaques classiques sur pg , au delà de l'injection sql ?
Les attaques par deni de service (DOS), voire les attaques silencieuses (par exemple utilisant la fonction sleep pour générer une attente en cas de recherche positive). Toutes sont généralement liées à du code SQL dynamique.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Les mots de passe sont assez compliqués(lettres et chiffres), et l'utilisateur public n'est pas superutilisateur.
Je vais dormir (un peu) plus tranquille.
Merci
comment savoir que l'utilisateur public n'est pas superutilisateur ? Je n'ai pas un tel utilisateur recensé (vu depuis pgadmin , arborescence "roles de connexion")
Hors ligne
Bonjour,
Si vous lancez "\du" depuis psql, il devrait vous indiquer si l'utilisateur est superutilisateur ou non, postgres par exemple est superutilisateur.
Hors ligne
Ou alors
select rolname from pg_roles where rolsuper;pour ne récupérer que la liste des super-utilisateurs.
Guillaume.
Hors ligne
Pages : 1