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
| Mode | Description |
|---|---|
sslmode=require | Connexion chiffrée sans vérification du certificat serveur |
sslmode=verify-ca | Vérifie que le certificat serveur est signé par une autorité de confiance |
sslmode=verify-full | Vé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
| Facteur | Mécanisme | Protection |
|---|---|---|
| Ce que vous savez | Mot de passe (SCRAM-SHA-256) | Authentification PostgreSQL |
| Ce que vous possédez | Certificat client ou accès VPN | Couche réseau |
| Ce que vous êtes | Contrôle d'accès réseau (IP, VPC) | Périmètre de sécurité |
Configuration recommandée pour environnements sensibles
-
Accès via réseau privé : Connectez vos applications via un VPN ou un VPC (Virtual Private Cloud) pour limiter l'exposition du cluster ;
-
Restriction des IP : Limitez l'accès aux plages d'adresses IP autorisées ;
-
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
| Couche | Mécanisme | Facteur |
|---|---|---|
| Couche 1 | Mot de passe PostgreSQL | Ce que vous savez |
| Couche 2 | VPN avec MFA | Ce que vous possédez |
| Couche 3 | Certificat client | Ce que vous possédez |
| Couche 4 | Restriction IP/VPC | Ce que vous êtes |
Configuration MFA via bastion
Pour implémenter le MFA, installez un bastion avec authentification forte :
-
Bastion SSH avec MFA :
- Déployez un bastion SSH avec support MFA (TOTP, clé hardware) ;
- Configurez la connexion PostgreSQL uniquement via le bastion.
-
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.
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énement | Description |
|---|---|
| Connexion réussie | Enregistrement de chaque connexion |
| Échec d'authentification | Tentatives de connexion avec identifiants invalides |
| Déconnexion | Fin 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.
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>';
| rolcanlogin | Signification |
|---|---|
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>;
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) :
- Bloquer immédiatement le compte avec
ALTER USER ... NOLOGIN; - Réinitialiser le mot de passe si vous souhaitez réactiver le compte ;
- Analyser les logs pour identifier l'origine de l'attaque ;
- Restreindre l'accès réseau via les groupes de sécurité ou le VPN ;
- 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
| Exigence | Implémentation recommandée |
|---|---|
| Chiffrement des connexions | TLS obligatoire (sslmode=require minimum) |
| Authentification forte | Réseau privé (VPN/VPC) + mot de passe |
| Politique de mots de passe | SCRAM-SHA-256, rotation régulière, complexité |
| Audit des accès | Logs de connexion activés |
| Contrôle d'accès | Principe du moindre privilège |
| Blocage de compte | ALTER USER ... NOLOGIN en cas d'activité suspecte |
| Révocation | Réinitialisation immédiate en cas de compromission |
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.