Passer au contenu principal

Sécuriser l'authentification PostgreSQL

Le service managé PostgreSQL intègre des mécanismes de sécurité pour protéger les connexions et les données. Cette page présente les bonnes pratiques pour sécuriser l'authentification, notamment dans un contexte de conformité SecNumCloud.

Connexions sécurisées SSL/TLS

Toutes les connexions au cluster PostgreSQL sont chiffrées avec TLS (Transport Layer Security). Le protocole SSL est obligatoire pour toutes les connexions externes.

Vérifier le chiffrement TLS

Connectez-vous avec le mode sslmode=require pour garantir une connexion chiffrée :

psql "host=<hôte> port=5432 dbname=<base_de_données> user=<utilisateur> sslmode=require"

Niveaux de vérification SSL

ModeDescription
sslmode=requireConnexion chiffrée sans vérification du certificat serveur
sslmode=verify-caVérifie que le certificat serveur est signé par une autorité de confiance
sslmode=verify-fullVérifie le certificat et le nom d'hôte

Pour une sécurité maximale :

psql "host=<hôte> port=5432 dbname=<base_de_données> user=<utilisateur> sslmode=verify-full"

Chiffrement des mots de passe

Le service PostgreSQL utilise le chiffrement SCRAM-SHA-256 pour les mots de passe. Ce mécanisme offre une meilleure sécurité que l'ancien chiffrement MD5.

Caractéristiques de SCRAM-SHA-256

  • Les mots de passe ne sont jamais transmis en clair sur le réseau ;
  • Protection contre les attaques par rejeu (replay attacks) ;
  • Résistance aux attaques par dictionnaire.

Le chiffrement SCRAM-SHA-256 est activé par défaut sur tous les clusters PostgreSQL managés.

Authentification forte et conformité SecNumCloud

Pour répondre aux exigences SecNumCloud en matière d'authentification forte, combinez plusieurs couches de sécurité.

Architecture multi-facteurs recommandée

FacteurMécanismeProtection
Ce que vous savezMot de passe (SCRAM-SHA-256)Authentification PostgreSQL
Ce que vous possédezCertificat client ou accès VPNCouche réseau
Ce que vous êtesContrôle d'accès réseau (IP, VPC)Périmètre de sécurité

Configuration recommandée pour environnements sensibles

  1. Accès via réseau privé : Connectez vos applications via un VPN ou un VPC (Virtual Private Cloud) pour limiter l'exposition du cluster ;

  2. Restriction des IP : Limitez l'accès aux plages d'adresses IP autorisées ;

  3. Rotation des identifiants : Changez régulièrement les mots de passe applicatifs (voir Gérer les utilisateurs et les rôles).

Authentification multi-facteurs (MFA)

PostgreSQL ne dispose pas de MFA natif. Pour implémenter une authentification multi-facteurs, utilisez une architecture en couches.

Approche MFA recommandée

CoucheMécanismeFacteur
Couche 1Mot de passe PostgreSQLCe que vous savez
Couche 2VPN avec MFACe que vous possédez
Couche 3Certificat clientCe que vous possédez
Couche 4Restriction IP/VPCCe que vous êtes

Configuration MFA via bastion

Pour implémenter le MFA, installez un bastion avec authentification forte :

  1. Bastion SSH avec MFA :

    • Déployez un bastion SSH avec support MFA (TOTP, clé hardware) ;
    • Configurez la connexion PostgreSQL uniquement via le bastion.
  2. Accès via VPN avec MFA :

    • Configurez un VPN avec authentification MFA ;
    • Limitez l'accès au cluster PostgreSQL aux clients connectés au VPN.

Architecture MFA type

[Utilisateur]
→ [VPN avec MFA]
→ [Bastion SSH]
→ [Cluster PostgreSQL]

Certificats clients (authentification mutuelle TLS)

PostgreSQL supporte l'authentification par certificat client. Cette fonctionnalité n'est pas configurable via l'API Numspot pour le moment. Contactez le support pour activer cette option sur les clusters critiques.

note

L'authentification multi-facteurs native PostgreSQL (certificats clients) n'est pas actuellement configurable via l'API Numspot. Pour une authentification forte, utilisez le contrôle d'accès au niveau réseau (VPN, bastion).

Politique de mots de passe

Bonnes pratiques

Appliquez ces règles pour les mots de passe PostgreSQL :

  • Longueur minimale de 12 caractères ;
  • Combinaison de lettres majuscules, minuscules, chiffres et caractères spéciaux ;
  • Exclusion des mots du dictionnaire et des informations personnelles ;
  • Rotation régulière (tous les 90 jours pour les comptes privilégiés).

Créer un mot de passe robuste

CREATE USER <utilisateur> WITH PASSWORD '<mot_de_passe_complexe>';

Exemple de mot de passe robuste (à adapter) :

Kj7#mP9$vL3@nQ2xWz5!

Définir une expiration

Pour les comptes temporaires ou à risque :

ALTER USER <utilisateur> WITH VALID UNTIL '2026-06-30 23:59:59';

Audit des connexions

Le cluster PostgreSQL journalise les événements d'authentification pour permettre l'audit et la détection d'anomalies.

Événements journalisés

ÉvénementDescription
Connexion réussieEnregistrement de chaque connexion
Échec d'authentificationTentatives de connexion avec identifiants invalides
DéconnexionFin de session

Consulter les logs de connexion

Les logs PostgreSQL sont disponibles via les outils d'observabilité de votre cluster. Contactez le support pour accéder aux logs d'audit.

Protection contre les attaques

Limitation des tentatives

Le service applique un délai de 5 secondes après chaque échec d'authentification pour ralentir les attaques par force brute.

note

Le service PostgreSQL managé n'applique pas de blocage automatique après un nombre défini d'échecs de connexion. La protection repose sur le délai entre les tentatives et la surveillance des logs. Pour un blocage automatique basé sur le nombre de tentatives, utilisez un outil externe comme fail2ban ou un pare-feu applicatif.

Détection des anomalies

Surveillez les comportements suspects dans les logs :

  • Multiples échecs de connexion depuis une même IP ;
  • Tentatives de connexion à des heures inhabituelles ;
  • Accès depuis des plages d'IP non autorisées.

Bloquer un utilisateur en cas d'utilisation abusive

Si vous détectez une activité suspecte ou un compte compromis, vous pouvez bloquer immédiatement l'accès d'un utilisateur.

Bloquer temporairement un compte

Utilisez l'attribut NOLOGIN pour empêcher toute connexion :

ALTER USER <utilisateur> WITH NOLOGIN;

L'utilisateur ne peut plus se connecter, mais ses permissions et ses données sont conservées.

Débloquer un compte

Pour réactiver l'accès :

ALTER USER <utilisateur> WITH LOGIN;

Vérifier le statut d'un utilisateur

SELECT rolname, rolcanlogin FROM pg_roles WHERE rolname = '<utilisateur>';
rolcanloginSignification
t (true)L'utilisateur peut se connecter
f (false)L'utilisateur est bloqué

Supprimer définitivement un compte

Si le compte n'est plus nécessaire ou si la compromission est confirmée :

-- Révoquer d'abord les permissions
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM <utilisateur>;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM <utilisateur>;
REVOKE USAGE ON SCHEMA public FROM <utilisateur>;

-- Supprimer l'utilisateur
DROP USER <utilisateur>;
avertissement

La suppression est irréversible. Vérifiez qu'aucun objet n'appartient à cet utilisateur avant la suppression.

Procédure de réponse à un incident

En cas de détection d'utilisation abusive (multiples échecs de connexion, activité suspecte) :

  1. Bloquer immédiatement le compte avec ALTER USER ... NOLOGIN ;
  2. Réinitialiser le mot de passe si vous souhaitez réactiver le compte ;
  3. Analyser les logs pour identifier l'origine de l'attaque ;
  4. Restreindre l'accès réseau via les groupes de sécurité ou le VPN ;
  5. Supprimer le compte si nécessaire.

Révoquer ou renouveler un mot de passe compromis

Si vous suspectez une compromission, réinitialisez immédiatement le mot de passe.

Pour l'utilisateur principal

Utilisez l'API pour réinitialiser le mot de passe de l'utilisateur principal :

PUT /postgresql/spaces/{spaceId}/clusters/{clusterId}/password/reset

Consultez Réinitialiser le mot de passe pour plus de détails.

Pour les utilisateurs supplémentaires

ALTER USER <utilisateur> WITH PASSWORD '<nouveau_mot_de_passe>';

Résumé des bonnes pratiques SecNumCloud

ExigenceImplémentation recommandée
Chiffrement des connexionsTLS obligatoire (sslmode=require minimum)
Authentification forteRéseau privé (VPN/VPC) + mot de passe
Politique de mots de passeSCRAM-SHA-256, rotation régulière, complexité
Audit des accèsLogs de connexion activés
Contrôle d'accèsPrincipe du moindre privilège
Blocage de compteALTER USER ... NOLOGIN en cas d'activité suspecte
RévocationRéinitialisation immédiate en cas de compromission
astuce

Pour les architectures critiques, installez un bastion SSH ou un proxy d'accès pour centraliser et auditer toutes les connexions aux bases de données.