Exiger SSL, garder SELinux activé, surveiller les journaux et utiliser une version PostgreSQL actuelle .
Du côté serveur
SSL requis
Dans l' postgresql.conf
ensemble ssl=on
et assurez-vous que votre fichier de clés et votre certificat sont installés correctement (voir les documents et les commentaires dans postgresql.conf
).
Vous devrez peut-être acheter un certificat auprès d'une autorité de certification si vous souhaitez qu'il soit approuvé par les clients sans configuration spéciale sur le client.
En pg_hba.conf
utilisation quelque chose comme:
hostssl theuser thedatabase 1.2.3.4/32 md5
... éventuellement avec "all" pour l'utilisateur et / ou la base de données, et éventuellement avec un filtre d'adresse IP source plus large.
Limiter les utilisateurs pouvant se connecter, refuser la connexion du superutilisateur distant
N'autorisez pas "tous" pour les utilisateurs si possible; vous ne voulez pas autoriser les connexions de superutilisateur à distance si vous pouvez en éviter le besoin.
Limiter les droits des utilisateurs
Restreindre les droits de l'utilisateur (s) qui peut se connecter. Ne pas leur donner CREATEDB
ou CREATEUSER
droits.
REVOKE
le CONNECT
droit à partir PUBLIC
de toutes vos bases de données, puis restituez-le uniquement aux utilisateurs / rôles qui devraient pouvoir accéder à cette base de données. (Regroupez les utilisateurs en rôles et accordez des droits aux rôles, plutôt que directement aux utilisateurs individuels).
Assurez-vous que les utilisateurs avec accès à distance ne peuvent se connecter qu'aux bases de données dont ils ont besoin et ne disposent que des droits sur les schémas, les tables et les colonnes dont ils ont réellement besoin. C'est aussi une bonne pratique pour les utilisateurs locaux, c'est juste une sécurité raisonnable.
Configuration du client
Dans PgJDBC, passez le paramètressl=true
:
Pour demander au pilote JDBC d'essayer d'établir une connexion SSL, vous devez ajouter le paramètre d'URL de connexion ssl = true.
... et installez le certificat de serveur dans le magasin de clés de confiance du client, ou utilisez un certificat de serveur approuvé par l'une des autorités de certification du magasin de clés de confiance intégré de Java si vous ne voulez pas que l'utilisateur doive installer le certificat.
Action en cours
Assurez-vous maintenant de maintenir PostgreSQL à jour . PostgreSQL n'a eu que quelques failles de sécurité avant l'authentification, mais c'est plus que zéro, alors restez à jour. Vous devriez de toute façon, les corrections de bugs sont de bonnes choses à avoir.
Ajoutez un pare-feu devant s'il y a de grands réseaux / régions dont vous savez que vous n'avez jamais besoin d'accéder.
Consigner les connexions et les déconnexions (voir postgresql.conf
). Enregistrez les requêtes si possible. Exécutez un système de détection d'intrusion ou fail2ban ou similaire en façade si possible. Pour fail2ban avec postgres, il existe un guide pratique ici
Surveillez les fichiers journaux.
Paranoïa bonus
Étapes supplémentaires à considérer ...
Exiger des certificats clients
Si vous le souhaitez, vous pouvez également utiliser pg_hba.conf
pour exiger que le client présente un certificat client X.509 approuvé par le serveur. Il n'a pas besoin d'utiliser la même autorité de certification que le certificat du serveur, vous pouvez le faire avec une autorité de certification homebrew openssl. Un utilisateur JDBC doit importer le certificat client dans son keystore Java avec keytool
et éventuellement configurer certaines propriétés du système JSSE pour pointer Java vers son keystore, donc ce n'est pas totalement transparent.
Mettre l'instance en quarantaine
Si vous voulez être vraiment paranoïaque, exécutez l'instance pour le client dans un conteneur / VM séparé, ou au moins sous un autre compte utilisateur, avec uniquement la ou les bases de données dont ils ont besoin.
De cette façon, s'ils compromettent l'instance PostgreSQL, ils n'iront pas plus loin.
Utilisez SELinux
Je ne devrais pas avoir à dire cela, mais ...
Exécutez une machine avec le support SELinux comme RHEL 6 ou 7, et ne désactivez pas SELinux ou ne le mettez pas en mode permissif . Gardez-le en mode d'application.
Utiliser un port autre que celui par défaut
La sécurité par l' obscurité seulement est la bêtise. Une sécurité qui utilise un peu d'obscurité une fois que vous avez fait les choses sensées ne fera probablement pas de mal.
Exécutez Pg sur un port autre que celui par défaut pour rendre la vie un peu plus difficile aux attaquants automatisés.
Mettez un proxy devant
Vous pouvez également exécuter PgBouncer ou PgPool-II devant PostgreSQL, agissant comme un pool de connexions et un proxy. De cette façon, vous pouvez laisser le proxy gérer SSL, pas le véritable hôte de base de données. Le proxy peut se trouver sur une machine virtuelle ou une machine distincte.
L'utilisation de proxys de regroupement de connexions est généralement une bonne idée avec PostgreSQL de toute façon, à moins que l'application cliente n'ait déjà un pool intégré. La plupart des serveurs d'applications Java, Rails, etc. ont un pool intégré. Même dans ce cas, un proxy de pooling côté serveur est au pire inoffensif.