Sécurité PostgreSQL - Linux

PostgreSQL est le deuxième système de gestion de base de données le plus utilisé par les professionnels selon le sondage de Stack Overflow Developer Survey 2022.

Nous vous proposons quelques points clés pour sécuriser vos bases de données PostgreSQL.

Avant de mettre le serveur PostgreSQL en production, il est primordial de s’assurer qu’un minimum de sécurité soit mis en place.

Dans cet article nous abordons quelques bonnes pratiques :

• Sauvegardes WAL
• Authentification et accès
• Journalisation
• Réplication

Le fichier postgresql.conf contient les différents paramètres de configuration du serveur PostgreSQL. Quelques paramètres peuvent être modifiés afin de renforcer la sécurité.

Adresse d’écoute

Vous pouvez utiliser le paramètre ’listen_address’ pour contrôler l’adresse IP sur laquelle le serveur va écouter, cela permet de réduire le champ des IPs qui se connecteront au serveur. C’est une bonne pratique d’écouter les connexions uniquement sur le réseau souhaité et d’éviter les valeurs générales comme ”*”, ”0.0.0.0” ou ”::”, qui indiqueront à Postgres d’écouter sur toutes les interfaces réseau disponibles et accepter les connexions de n’importe quelle IP. Si le serveur PostgreSQL ne doit pas être accessible depuis un autre service distant, il est recommandé de mettre la valeur du paramètre ’listen_address’ à ’127.0.0.1’, ’localhost’ ou simplement ’ ‘. Si le champ ’listen_address’ est vide (”), la communication Postgres s’effectuera uniquement à l’aide des sockets Unix.

Sauvegarde WAL (Write Ahead Log)

Il est important de garder une sauvegarde WAL, idéalement dans un serveur distant, destinée à sauvegarder les transactions. Cette fonctionnalité peut être activée à l’aide des deux paramètres ‘archive_mode’ et ’archive_command‘:

• ‘archive_mode’ doit avoir la valeur ’on’

• ‘archive_command’ correspond à la commande qui aura pour but d’effectuer la sauvegarde. Voici quelques exemples de commandes :

  • Copie en local dans le répertoire /opt/pg_wal/backup/

    archive_command = 'cp %p /opt/pg_wal/backup/%f'
    

  • Copie dans un serveur distant en utilisant ’rsync‘:

    archive_command = 'rsync -e ssh -a %p postgres_user@backup_host:/var/lib/pgsql/WAL_backup/%f'
    

Authentification et accès

Utilisateurs

La règle d’or de la sécurité en matière de gestion des utilisateurs est d’accorder aux utilisateurs le minimum d’accès dont ils ont besoin.

Cette gestion peut devenir très compliquée si elle n’est pas effectuée correctement dès le départ.

Un bon moyen de garder les privilèges sous contrôle est d’utiliser la stratégie rôle, groupe, utilisateur.

Dans Postgres, tout est considéré comme un rôle. Dans cette stratégie, trois types de rôles différents seront créés :

• rôle (identifié par le préfixe r_)
• groupe (identifié par le préfixe g_)
• utilisateur (généralement des noms d’utilisateurs ou d’applications)

Les rôles (rôles r) seront ceux qui auront les privilèges sur les objets. Les rôles de groupe (rôles g) seront accordés avec les rôles r, ils seront donc une collection de rôles r. Et enfin, les rôles d’utilisateurs et d’applications seront accordés avec un ou plusieurs rôles de groupe et seront ceux qui auront le privilège de connexion.

Ajouter à chaque rôle, groupe ou utilisateur une abréviation des droits accordés à la fin du nom. Par exemple, pour un rôle qui aura les droits de lecture seule, le nom ‘r_role_name_ro’ lui sera attribué (‘ro’ à la fin du nom signifiant “read only”) et sa création s’effectuera comme suit :

CREATE ROLE r_role_name_ro NOSUPERUSER NOREPLICATION NOCREATEDB NOCREATEROLE INHERIT;

Authentification

L’authentification est un élément crucial pour garantir que l’accès aux ressources soit uniquement accordé aux utilisateurs autorisés.

PostgreSQL propose différents types d’authentifications. Parmi celles-ci, on trouve ’Trust’, ’Password’, ’Certificate authentication’, ’PAM’ ou ’LDAP‘.

La première méthode, ’Trust’, est déconseillée car elle considère que chaque personne qui a accès au service Postgres est autorisée à accéder aux bases de données.

La méthode ’Password’ est une authentification basée sur un mot de passe. Pour cette méthode d’authentification, il est recommandé d’utiliser ’scram-sha-256’ qui est considéré comme la méthode la plus sécurisée pour l’authentification par mot de passe. Pour ce faire, il suffit de mettre la valeur du paramètre ’password_encryption’, dans le fichier de configuration postgresql.conf, à ’scram-sha-256’ :

password_encryption = scram-sha-256

Le maintien d’une politique de mots de passe forts est indispensable pour assurer la sécurité de vos bases de données. Privilégiez l’utilisation de caractères spéciaux, de chiffres, de majuscules et de minuscules et assurez-vous que la longueur du mot de passe soit d’au minimum 15 caractères.

Les outils d’authentification externes, comme LDAP ou PAM, peuvent aider à mettre en place une politique d’expiration et de réutilisation des mots de passe ainsi que d’assurer la gestion du verrouillage des comptes en cas d’erreur d’authentification.

La méthode ’Certificate authentication’ utilise les certificats TLS afin d’authentifier les utilsateurs, ce qui implique qu’elle sera uniquement disponible pour les connexions SSL.

Cette méthode permet d’avoir un contrôle d’accès plus strict aux bases de données mais demande davantage de temps de gestion car chaque utilisateur/application nécessite la génération d’un certificat TLS.

Nombre de connexions simultanées

Postgres offre la possibilité de limiter le nombre de connexions simultanées au service. Définir cette limite est vivement recommandé car elle permet de se protéger contre les attaques de type déni de service (DoS et DDoS).

Algorithmes de chiffrement

Dans le cas où SSL est activé pour l’authentification et la communication avec le serveur Postgres, il est recommandé de limiter les algorithmes de chiffrement utilisés.

Cela peut être configuré en modifiant le paramètre ’ssl_ciphers’ dans le fichier postgresql.conf :

ssl_ciphers='DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256::!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA:!3DES'

Journalisation

PostgreSQL fournit une large variété de paramètres de configuration pour contrôler la journalisation.

Vous pouvez surveiller toutes les actions relatives aux sessions (connexion/déconnexion), les requêtes de longue durée, la taille des fichiers temporaires, etc. Cela peut aider à avoir une bonne compréhension lors de vos développements mais aussi d’identifier les comportements ou tentatives malveillantes.

Vous trouverez plus d’informations sur les options de journalisation sur le lien suivant : https://www.postgresql.org/docs/current/runtime-config-logging.html

Row Security Policies

Les politiques de sécurité des lignes (Row Security Policies), aussi connues sous le nom de “Row-Level Security” ou “RLS”, permettent de définir des politiques qui empêchent les utilisateurs de visualiser ou de manipuler des enregistrements spécifiques de données dans une table. Ces politiques peuvent être utilisées en plus des privilèges standards SQL disponibles via GRANT. Cela peut être particulièrement utile pour bloquer l’accès à des enregistrements sensibles, comme les données clients ou financières.

Réplication

Postgres offre deux types de réplications : ‘Streaming’ et ‘Logical’. La réplication intégrée n’est disponible que dans la configuration primary-standby (une base de données primaire : “master” et une base de données de sauvegarde : “standby”).

La réplication en continu (Streaming replication), également connue sous le nom de réplication physique et binaire dans Postgres, consiste à transmettre les données en continu aux serveurs de sauvegarde (standby) byte par byte. Afin de diffuser ces données, la réplication en continu utilise les enregistrements WAL. Tout changement effectué sur le serveur primaire est d’abord écrit dans les fichiers WAL avant d’être écrit dans la base de données qui va être diffusé vers un ou plusieurs serveurs standby.

La réplication en continu est asynchrone par défaut, mais il est possible d’activer la réplication synchrone. Ce type de configuration est idéal pour obtenir un environnement de haute disponibilité (High Availability). Si le serveur principal tombe en panne, l’un des serveurs standby peut prendre sa place puisque c’est une copie presque identique.

La réplication logique (Logical replication) est plus récente que la précédente et suit un modèle “publish subscribe”. Celle-ci résout les limitations de la réplication en continu et permet de :

• Transmettre des changements incrémentiels dans une base de données unique ou un sous-ensemble d’une base de données aux abonnés (subscribers) au fur et à mesure qu’ils se produisent
• Déclencher les ‘trigger’ pour des changements individuels lorsqu’ils arrivent sur l’abonné
• Consolider plusieurs bases de données en une seule
• Répliquer entre différentes versions de Postgres
• Répliquer entre des instances Postgres sur différentes plateformes (par exemple de Linux à Windows ou l’inverse)
• Donner accès aux données répliquées à différents groupes d’utilisateurs
• Partager un sous-ensemble de la base de données entre plusieurs bases de données

Il est fortement recommandé d’activer la réplication uniquement en SSL car le trafic entre le serveur primaire et le serveur standby n’est pas chiffré par défaut. Cela pourrait avoir un impact minime sur les performances mais on peut le considérer comme négligeable. Pour ce faire, le fichier ‘pg_hba.conf’ contient toutes les règles nécessaires pour l’authentification des utilisateurs, par exemple :

## TYPE   DATABASE        USER            ADDRESS                 METHOD
hostssl    MY_DB     replicauser_ro     169.168.1.2/32        cert clientcert=1

Conclusion

En appliquant les différentes recommandations ci-dessus, votre serveur PostgreSQL répondra à une bonne partie des bonnes pratiques.

En attendant le prochain article qui concernera le monitoring et le durcissement d’un système Linux qui héberge un service PostgreSQL, n’hésitez pas à nous contacter pour des éventuelles questions ou commentaires.