Comment sécuriser votre base de données PostgreSQL - 10 conseils

Une fois que vous avez terminé le processus d'installation de votre serveur de base de données PostgreSQL, il est nécessaire de le protéger avant de passer en production. Dans cet article, nous vous montrerons comment renforcer la sécurité autour de votre base de données pour assurer la sécurité de vos données.

1. Contrôle de l'authentification client

Lors de l'installation de PostgreSQL, un fichier nommé pg_hba.conf est créé dans le répertoire de données du cluster de bases de données. Ce fichier contrôle l'authentification du client.

À partir de la documentation officielle de postgresql, nous pouvons définir le fichier pg_hba.conf comme un ensemble d'enregistrements, un par ligne, où chaque enregistrement spécifie un type de connexion, une plage d'adresses IP client (si pertinent pour le type de connexion), un nom de base de données, un le nom d'utilisateur et la méthode d'authentification à utiliser pour les connexions correspondant à ces paramètres. Le premier enregistrement avec un type de connexion, une adresse client, une base de données demandée et un nom d'utilisateur correspondants est utilisé pour effectuer l'authentification.

Le format général ressemblera donc à ceci :

# TYPE  DATABASE        USER            ADDRESS                 METHOD

Un exemple de configuration peut être le suivant :

# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     postgres              all             192.168.93.0/24         ident
# Reject any user from any host with IP address 192.168.94.x to connect
# to database "postgres
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     postgres              all             192.168.94.0/24         reject

Il existe de nombreuses combinaisons que vous pouvez faire pour affiner les règles (la documentation officielle décrit chaque option en détail et contient de très bons exemples), mais n'oubliez pas d'éviter les règles trop permissives, comme autoriser l'accès aux lignes en utilisant DATABASE all ou ADDRESS 0.0.0.0/0.

Pour garantir la sécurité, même si vous oubliez d'ajouter une règle, vous pouvez ajouter la ligne suivante en bas :

# TYPE  DATABASE        USER            ADDRESS                 METHOD
 host     all              all             0.0.0.0/0         reject

Comme le fichier est lu de haut en bas pour trouver les règles correspondantes, vous vous assurez ainsi que pour autoriser l'autorisation, vous devrez ajouter explicitement la règle correspondante ci-dessus.

2. Configuration du serveur

Il y a quelques paramètres sur le postgresql.conf que nous pouvons modifier pour améliorer la sécurité.

Vous pouvez utiliser le paramètre listen_address pour contrôler quelles ips seront autorisées à se connecter au serveur. Voici une bonne pratique pour autoriser les connexions uniquement à partir des adresses IP connues ou de votre réseau, et éviter les valeurs générales telles que "*", "0.0.0.0:0" ou "::", qui indiqueront à PostgreSQL d'accepter la connexion à partir de n'importe quelle adresse IP.

Changer le port sur lequel postgresql écoutera (par défaut 5432) est également une option. Vous pouvez le faire en modifiant la valeur du paramètre port.

Des paramètres tels que work_mem, maintenance_work_mem, temp_buffer , max_prepared_transactions, temp_file_limit sont importants à garder à l'esprit en cas d'attaque par déni de service. Il s'agit de paramètres d'instruction/session qui peuvent être définis à différents niveaux (base de données, utilisateur, session). Par conséquent, les gérer judicieusement peut nous aider à minimiser l'impact de l'attaque.

3. Gestion des utilisateurs et des rôles

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

Gérer cela n'est pas toujours facile et cela peut devenir vraiment désordonné s'il n'est pas bien fait dès le début.

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

Dans postgresql, tout est considéré comme un rôle, mais nous allons y apporter quelques modifications.

Dans cette stratégie, vous allez créer trois types ou rôles différents :

• rôle rôle (identifié par le préfixe r_)
• rôle de groupe (identifié par le préfixe g_)
• rôle d'utilisateur (généralement des noms personnels ou d'application)

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

Montrons un exemple de ceci. Nous allons créer un groupe en lecture seule pour example_schema, puis l'accorder à un utilisateur :

Nous créons le rôle en lecture seule et lui accordons les privilèges d'objet

CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT USAGE ON SCHEMA example to r_example_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;

Nous créons le groupe en lecture seule et accordons le rôle à ce groupe

CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';
GRANT r_example_ro to g_example_ro;

Nous créons le rôle app_user et le faisons "rejoindre" le groupe en lecture seule

CREATE ROLE app_user WITH LOGIN ;
ALTER ROLE app_user WITH PASSWORD 'somePassword' ;
ALTER ROLE app_user VALID UNTIL 'infinity' ;
GRANT g_example_ro TO app_user;

En utilisant cette méthode, vous pouvez gérer la granularité des privilèges et vous pouvez facilement accorder et révoquer des groupes d'accès aux utilisateurs. N'oubliez pas de n'accorder des privilèges d'objet qu'aux rôles au lieu de le faire directement pour les utilisateurs et d'accorder le privilège de connexion uniquement aux utilisateurs.

Il s'agit d'une bonne pratique pour révoquer explicitement les privilèges publics sur les objets, comme révoquer l'accès public à une base de données spécifique et ne l'accorder qu'à travers un rôle.

REVOKE CONNECT ON my_database FROM PUBLIC;
GRANT CONNECT ON my_database TO r_example_ro;

Restreindre l'accès SUPERUTILISATEUR, autoriser les connexions superutilisateur uniquement à partir du domaine localhost/unix.

Utilisez des utilisateurs spécifiques à des fins différentes, comme des utilisateurs d'applications spécifiques ou des utilisateurs de sauvegarde, et limitez les connexions pour cet utilisateur uniquement à partir des adresses IP requises.

4. Gestion des super utilisateurs

Maintenir une politique de mots de passe forte est indispensable pour protéger vos bases de données et éviter les piratages de mots de passe. Pour une politique forte utilisez préférentiellement les caractères spéciaux, les chiffres, les caractères majuscules et minuscules et ayez au moins 10 caractères.

Il existe également des outils d'authentification externes, tels que LDAP ou PAM, qui peuvent vous aider à garantir l'expiration et la politique de réutilisation de votre mot de passe, ainsi qu'à gérer le verrouillage de compte en cas d'erreur d'authentification.

5. Cryptage des données (sur connexion ssl)

PostgreSQL prend en charge nativement l'utilisation de connexions SSL pour chiffrer les communications client/serveur pour une sécurité accrue. SSL (Secure Sockets Layer) est la technologie de sécurité standard permettant d'établir un lien crypté entre un serveur Web et un navigateur. Ce lien garantit que toutes les données transmises entre le serveur Web et les navigateurs restent privées et intégrales.

Comme les clients postgresql envoient des requêtes en texte brut et que les données sont également envoyées non chiffrées, elles sont vulnérables à l'usurpation de réseau.

Vous pouvez activer SSL en définissant le paramètre ssl sur on dans postgresql.conf.

Le serveur écoutera à la fois les connexions normales et SSL sur le même port TCP et négociera avec tout client qui se connecte pour savoir s'il faut utiliser SSL. Par défaut, c'est au choix du client, mais vous avez la possibilité de configurer le serveur pour exiger l'utilisation de SSL pour certaines ou toutes les connexions à l'aide du fichier de configuration pg_hba décrit ci-dessus.

6. Chiffrement des données au repos (pg_crypto)

Il existe deux types de cryptage de base, à sens unique et à double sens. D'une certaine manière, vous ne vous souciez jamais de déchiffrer les données sous une forme lisible, mais vous voulez simplement vérifier que l'utilisateur sait quel est le texte secret sous-jacent. Ceci est normalement utilisé pour les mots de passe. Dans le cryptage bidirectionnel, vous souhaitez pouvoir crypter les données et permettre aux utilisateurs autorisés de les décrypter sous une forme significative. Les données telles que les cartes de crédit et les SSN entreraient dans cette catégorie.

Pour le cryptage unidirectionnel, la fonction crypt fournie dans pgcrypto fournit un niveau de sécurité supplémentaire au-dessus de la méthode md5. La raison en est qu'avec md5, vous pouvez dire qui a le même mot de passe car il n'y a pas de sel (en cryptographie, un sel est une donnée aléatoire qui est utilisée comme entrée supplémentaire dans une fonction à sens unique qui "hache" les données, un mot de passe ou mot de passe), ainsi toutes les personnes ayant le même mot de passe auront la même chaîne md5 encodée. Avec crypt, ils seront différents.

Pour les données que vous souhaitez récupérer, vous ne voulez pas savoir si les deux informations sont identiques, mais vous ne connaissez pas ces informations et vous souhaitez que seuls les utilisateurs autorisés puissent les récupérer. Pgcrypto propose plusieurs façons d'y parvenir, donc pour en savoir plus sur son utilisation, vous pouvez consulter la documentation officielle de postgresql sur https://www.postgresql.org/docs/current/static/pgcrypto.html.

7. Journalisation

Postgresql fournit une grande variété de paramètres de configuration pour contrôler quoi, quand et où se connecter.

Vous pouvez activer les connexions/déconnexions de session, les requêtes longues, la taille des fichiers temporaires, etc. Cela peut vous aider à mieux connaître votre charge de travail afin d'identifier les comportements étranges. Vous pouvez obtenir toutes les options de connexion sur le lien suivant https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html

Pour des informations plus détaillées sur votre charge de travail, vous pouvez activer le module pg_stat_statements, qui fournit un moyen de suivre les statistiques d'exécution de toutes les instructions SQL exécutées par un serveur. Certains outils de sécurité peuvent ingérer les données de cette table et généreront une liste blanche sql, afin de vous aider à identifier les requêtes ne suivant pas les modèles attendus.

Pour plus d'informations https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.

8. Audit

L'extension d'audit PostgreSQL (pgAudit) fournit une journalisation d'audit détaillée de session et/ou d'objet via la fonction de journalisation PostgreSQL standard.

La journalisation des instructions de base peut être fournie par la fonction de journalisation standard avec log_statement =all. Ceci est acceptable pour la surveillance et d'autres utilisations, mais ne fournit pas le niveau de détail généralement requis pour un audit. Il ne suffit pas d'avoir une liste de toutes les opérations effectuées sur la base de données. Il doit également être possible de trouver des déclarations particulières qui intéressent un auditeur. La fonction de journalisation standard montre ce que l'utilisateur a demandé, tandis que pgAudit se concentre sur les détails de ce qui s'est passé pendant que la base de données satisfaisait la demande.

9. Correction

Consultez régulièrement et fréquemment la page d'informations sur la sécurité de PostgreSQL pour les mises à jour et les correctifs de sécurité critiques.

Gardez à l'esprit que les bogues de sécurité du système d'exploitation ou des bibliothèques peuvent également entraîner une fuite de base de données, alors assurez-vous de garder à jour les correctifs pour ceux-ci.

ClusterControl fournit un rapport opérationnel qui vous donne ces informations et exécutera les correctifs et les mises à niveau pour vous.

10. Sécurité au niveau de la ligne

En plus du système de privilèges standard SQL disponible via GRANT, les tables peuvent avoir des politiques de sécurité des lignes qui restreignent, pour chaque utilisateur, quelles lignes peuvent être renvoyées par des requêtes normales ou insérées, mises à jour ou supprimées par des commandes de modification de données. Cette fonctionnalité est également connue sous le nom de sécurité au niveau de la ligne.

Lorsque la sécurité des lignes est activée sur une table, tous les accès normaux à la table pour sélectionner des lignes ou modifier des lignes doivent être autorisés par une politique de sécurité des lignes.

Voici un exemple simple de création d'une stratégie sur la relation de compte pour autoriser uniquement les membres du rôle de gestionnaire à accéder aux lignes, et uniquement aux lignes de leurs comptes :

CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);

Vous pouvez obtenir plus d'informations sur cette fonctionnalité sur la documentation officielle de postgresql https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html

Si vous souhaitez en savoir plus, voici quelques ressources qui peuvent vous aider à mieux renforcer la sécurité de votre base de données…

• https://www.postgresql.org/docs/9.6/static/auth-pg-hba-conf.html
• https://www.postgresql.org/docs/9.6/static/ssl-tcp.html
• https://www.postgresql.org/docs/current/static/pgcrypto.html
• http://www.postgresonline.com/journal/archives/165-Encrypting-data-with-pgcrypto.html
• https://github.com/pgaudit/pgaudit
• https://www.postgresql.org/docs/9.6/static/pgstatstatements.html

Conclusion

Si vous suivez les conseils ci-dessus, votre serveur sera plus sûr, mais cela ne signifie pas qu'il sera incassable.

Pour votre propre sécurité, nous vous recommandons d'utiliser un outil de test de sécurité comme Nessus, pour connaître vos principales vulnérabilités et essayer de les résoudre.

Vous pouvez également surveiller votre base de données avec ClusterControl. Avec cela, vous pouvez voir en temps réel ce qui se passe dans votre base de données et l'analyser.