Sécuriser PostgreSQL 17 avec mTLS dans une application WinDev

Introduction

De plus en plus de projets Windev doivent manipuler des données sensibles : facturation, santé, RH, données clients… Dans ce contexte, exposer un PostgreSQL « en clair » sur le réseau n’est plus acceptable. On veut un serveur chiffré au repos, chiffré en transit et ségrégé par rôles, tout en restant exploitable depuis une application Windev classique via le connecteur natif.

Dans cet article, on part d’une instance PostgreSQL 17 durcie (distribution Percona avec TDE et authentification par certificats) et on se concentre sur la mise en œuvre côté WinDev :

• comprendre ce que la plate-forme PostgreSQL sécurisée impose,
• préparer les certificats sur les postes Windows,
• configurer le connecteur natif PostgreSQL en mTLS (SSL Mode=verify-full),
• industrialiser la gestion des rôles et des certificats dans les applications EloNeva.

Aucune couche d’orchestration n’est abordée ici : on considère le serveur PostgreSQL déjà en production, et on se place strictement du côté client Windev.

1. Rappels sur l’architecture de sécurité PostgreSQL

1.1 Chiffrement TDE : ce que voit (ou ne voit pas) Windev

L’instance PostgreSQL 17 décrite repose sur l’extension pg_tde de Percona. Quelques points clés :

• les données sont chiffrées au niveau du moteur avant d’atteindre le disque,
• chaque table chiffrée est associée à une clé, elle-même protégée par une master key,
• un Global Key Provider permet de restaurer des sauvegardes chiffrées dans une autre base tout en conservant la cohérence des clés.

Pour Windev, c’est totalement transparent : l’application voit des tables et des colonnes classiques. Le TDE est géré par le DBA et l’infrastructure. Côté code, rien de spécifique à implémenter pour « parler » à une table pg_tde.

En revanche, cela a deux implications importantes :

• une fuite de disque ou de backup brut ne suffit plus à lire les données sans les clés TDE ;
• la restauration d’une base dans un autre environnement doit impérativement respecter la configuration du Key Provider, mais cela reste côté serveur, pas côté Windev.

1.2 Chiffrement en transit et authentification par certificats (mTLS)

Le vrai sujet pour Windev est la couche réseau :

• TLS 1.3 imposé, chiffrements forts (AES-256-GCM, ChaCha20-Poly1305),
• certificat serveur signé par une autorité interne (CA) dédiée à PostgreSQL,
• authentification par certificat client obligatoire,
• correspondance stricte CN du certificat ↔ rôle PostgreSQL via pg_ident.conf,
• configuration sslmode=verify-full du côté des clients.

Concrètement :

• le poste client doit faire confiance à la CA (installation de ca.crt) ;
• le poste client doit disposer d’un certificat client_xxx contenant la clé privée correspondant à un utilisateur PostgreSQL (admin, app_user, backup_user, app_developer, etc.) ;
• Windev doit présenter ce certificat lors du handshake TLS, sinon la connexion est refusée avant même de parler authentification SQL.

L’authentification ne dépend donc plus d’un mot de passe transmis sur le réseau, mais du couple certificat + clé privée stocké sur le poste, ce qui change complètement la façon dont on gère la « connexion » dans une appli cliente.

1.3 Rôles, permissions et mapping certificats

La sécurisation PostgreSQL repose également sur une convention de rôles :

Les certificats clients sont créés avec un Common Name (CN) correspondant à ces utilisateurs ou à des variantes par poste (ex. app_pc_bureau mappé vers app_user).

Le fichier pg_ident.conf côté serveur assure le lien :

cert_map    admin               admin
cert_map    app_user            app_user
cert_map    app_pc_bureau       app_user
cert_map    app_laptop_jean     app_user
cert_map    backup_nas          backup_user

Pour Windev, cela signifie que :

• la valeur de CN dans le certificat client doit être connue par le DBA et déclarée dans pg_ident.conf ;
• le code Windev n’a plus à porter la granularité des droits : il choisit simplement « quel utilisateur PostgreSQL » doit être utilisé pour l’écran donné.

2. Préparer le poste Windows pour une connexion Windev mTLS

Avant même d’ouvrir une connexion dans le code, il faut préparer le poste Windows qui héberge l’application Windev.

2.1 Fichiers fournis par l’équipe infra

Pour chaque poste, l’équipe infra fournit au minimum :

• ca.crt : certificat de l’autorité de certification PostgreSQL (CA),

• client_<nom>.pfx : certificat + clé privée pour l’utilisateur PostgreSQL cible,

• éventuellement les versions PEM :

  • client_<nom>.crt (certificat),
  • client_<nom>.key (clé privée).

Un nommage clair facilite l’exploitation :

• client_admin.* pour l’ADMIN,
• client_app_user.* pour les utilisateurs applicatifs,
• client_backup_user.* pour les jobs de sauvegarde côté client,
• client_app_developer.* pour les outils techniques.

L’application Windev n’a généralement besoin que de client_app_user.* (front métier) et éventuellement de client_app_developer.* pour des utilitaires d’administration internes.

2.2 Importer la CA et le certificat client sous Windows

Deux options sont possibles :

1. Utiliser le magasin de certificats Windows (pratique pour les tests, intégration avec d’autres outils).
2. Utiliser des fichiers .crt/.key sur le disque, ce qui reste le mode le plus simple pour le connecteur natif PostgreSQL.

Une procédure typique pour préparer un poste de production :

1. Importer la CA dans les autorités de certification racines de confiance :

   • double-cliquer sur ca.crt,
   • choisir « Ordinateur local » ou « Utilisateur actuel » selon la politique,
   • cibler le magasin « Autorités de certification racines de confiance ».

2. Déposer les fichiers nécessaires dans un répertoire applicatif dédié, par exemple :

   C:\ProgramData\EloNeva\PostgreSQL\
      ├── ca.crt
      ├── client_app_user.crt
      └── client_app_user.key
   

3. Restreindre les droits d’accès à ce dossier (administrateurs + compte de service de l’application).

Sous Windows, on vise l’équivalent d’un chmod 600 Linux : seuls les comptes techniques qui exécutent l’application doivent pouvoir lire la clé privée.

3. Configurer le connecteur PostgreSQL natif dans WinDev

Une fois les certificats en place, il faut expliquer à WinDev comment se connecter en mTLS. Tout se joue dans la définition de la connexion via les « informations étendues ».

3.1 Paramètres de base

Les paramètres classiques d’une connexion PostgreSQL via le connecteur natif sont :

• serveur : FQDN de l’instance sécurisée (ex. myserver.domain.tld),
• port : 5434 (port personnalisé côté serveur),
• base : secure_db,
• utilisateur : app_user (ou un alias mappé),
• mot de passe : vide lorsque l’on utilise uniquement l’authentification par certificat.

Ce sont les informations étendues qui activent la couche SSL/TLS.

3.2 Exemple complet avec HDécritConnexion

// Chemin des certificats sur le poste
gsCheminCerts est une chaîne = "C:\ProgramData\EloNeva\PostgreSQL\"

// Construction de la chaîne d'informations étendues
sInfosEtendues est une chaîne = [
Server Port=5434;
SSL Mode=verify-full;
SSL CA=%1ca.crt;
SSL Cert=%1client_app_user.crt;
SSL Key=%1client_app_user.key
]

// Remplace %1 par le chemin
sInfosEtendues = ChaîneConstruit(sInfosEtendues, gsCheminCerts)

// Déclaration de la connexion PostgreSQL sécurisée
HDécritConnexion(
    "cnxSecurePG",                // Nom logique de la connexion
    "app_user",                   // Utilisateur PostgreSQL
    "",                           // Mot de passe (vide : certif)
    "myserver.domain.tld",        // Serveur (doit matcher le certificat)
    "secure_db",                  // Base
    hAccèsNatifPostgreSQL,        // Connecteur natif
    hOLectureEcriture,            // Mode d'accès
    sInfosEtendues                // Infos SSL/mTLS
)

// Ouverture
SI HOuvreConnexion("cnxSecurePG") = Faux ALORS
    Erreur("Connexion PostgreSQL sécurisée impossible : " + HErreurInfo(hErrComplet))
    RETOUR
FIN

Info("Connexion PostgreSQL mTLS OK via cnxSecurePG")

Points importants :

• SSL Mode=verify-full impose la vérification du certificat serveur et du FQDN ; myserver.domain.tld doit donc être présent dans le SAN du certificat serveur.
• les chemins SSL CA, SSL Cert, SSL Key sont des chemins absolus, accessibles en lecture par l’exécutable Windev.
• ne pas mélanger mot de passe et certificat pour un même rôle sauf cas particulier ; pour un front métier, l’authentification par certificat suffit.

3.3 Variante avec HOuvreConnexion direct

Pour les utilitaires techniques (petit outil Windev d’admin par exemple), on peut se passer de HDécritConnexion et tout faire en une instruction :

sInfosEtendues est une chaîne = [
Server Port=5434;
SSL Mode=verify-full;
SSL CA=C:\ProgramData\EloNeva\PostgreSQL\ca.crt;
SSL Cert=C:\ProgramData\EloNeva\PostgreSQL\client_admin.crt;
SSL Key=C:\ProgramData\EloNeva\PostgreSQL\client_admin.key
]

SI HOuvreConnexion("cnxAdminPG", "admin", "", "myserver.domain.tld", ...
                   "secure_db", hAccèsNatifPostgreSQL, hOLectureEcriture, sInfosEtendues) = Faux ALORS
   Erreur("Connexion ADMIN impossible : " + HErreurInfo(hErrComplet))
   RETOUR
FIN

A réserver à des outils internes, car l’utilisation du rôle admin expose beaucoup plus de surface d’attaque en cas de compromission de poste.

3.4 Gestion d’erreurs et diagnostics mTLS

En cas de problème, HOuvreConnexion renvoie Faux et HErreurInfo(hErrComplet) contient le message libpq remonté par PostgreSQL (échec SSL, certificat invalide, utilisateur inconnu, etc.).

On peut factoriser le diagnostic :

PROCEDURE LogErreurConnexionPG()
sMsg est une chaîne = HErreurInfo(hErrComplet)

SI sMsg ~= "*certificate*" ALORS
    Trace("Erreur de certificat PostgreSQL : " + sMsg)
SINON SI sMsg ~= "*SSL*" ALORS
    Trace("Erreur SSL/TLS PostgreSQL : " + sMsg)
SINON
    Trace("Erreur de connexion PostgreSQL : " + sMsg)
FIN

Et l’utiliser systématiquement :

SI HOuvreConnexion("cnxSecurePG") = Faux ALORS
    LogErreurConnexionPG()
    Erreur("Impossible de se connecter au serveur PostgreSQL sécurisé.")
    RETOUR
FIN

Cela facilite énormément le support : la cause réelle (certificat expiré, CN non mappé, nom de serveur incorrect…) remonte immédiatement dans les traces.

4. Stratégies de gestion des certificats côté Windev

La force de l’architecture mTLS décrite est de permettre plusieurs certificats pour un même rôle PostgreSQL. C’est particulièrement utile pour les postes Windev.

4.1 Un certificat par poste, même rôle applicatif

Plutôt que de partager un seul client_app_user.pfx entre tous les postes :

• on génère un certificat par machine, par exemple :

  • client_app_pc_bureau.pfx,
  • client_app_laptop_marie.pfx,
  • client_app_serveur_tse.pfx.

• tous ces certificats sont mappés côté serveur vers le rôle app_user.

On y gagne :

• traçabilité : chaque connexion est associée à un CN précis,
• possibilité de révoquer un certificat compromis sans casser toute la production,
• pas de partage de fichier sensible sur un partage réseau.

Côté Windev, la seule différence est le nom des fichiers dans les informations étendues :

SSL Cert=C:\ProgramData\EloNeva\PostgreSQL\client_app_pc_bureau.crt;
SSL Key=C:\ProgramData\EloNeva\PostgreSQL\client_app_pc_bureau.key

Le reste de l’application ne change pas.

4.2 Rotation des certificats sans recompilation

Pour éviter de recompiler l’exécutable à chaque fois qu’on renouvelle les certificats, on peut externaliser les paramètres SSL dans une table de configuration ou un fichier .ini.

Exemple simple avec un fichier .ini :

// Exemple de contenu C:\ProgramData\EloNeva\pg_secure.ini
// [SSL]
// Port=5434
// CA=C:\ProgramData\EloNeva\PostgreSQL\ca.crt
// Cert=C:\ProgramData\EloNeva\PostgreSQL\client_app_pc_bureau.crt
// Key=C:\ProgramData\EloNeva\PostgreSQL\client_app_pc_bureau.key

Chargement dans l’appli :

sFicIni est une chaîne = "C:\ProgramData\EloNeva\pg_secure.ini"

sPort est une chaîne = INILit("Port", "SSL", "5434", sFicIni)
sCA   est une chaîne = INILit("CA",   "SSL", "", sFicIni)
sCert est une chaîne = INILit("Cert", "SSL", "", sFicIni)
sKey  est une chaîne = INILit("Key",  "SSL", "", sFicIni)

sInfosEtendues est une chaîne = ChaîneConstruit([
Server Port=%1;
SSL Mode=verify-full;
SSL CA=%2;
SSL Cert=%3;
SSL Key=%4
], sPort, sCA, sCert, sKey)

La rotation des certificats devient une simple mise à jour de fichiers côté poste, sans changement de code.

4.3 Automatiser la distribution depuis Linux (Ubuntu 24.02)

Du côté des équipes infra, il est fréquent de devoir préparer des « bundles » de certificats pour plusieurs postes Windows. Un petit script Bash compatible Ubuntu 24.02 permet de générer ces bundles sans exposer plus de fichiers que nécessaire :

#!/usr/bin/env bash
set -euo pipefail

# Répertoire où sont stockés les certificats sur le serveur
SRC_DIR="/opt/postgresql/certs"
DEST_DIR="$HOME/pg-client-bundles"

CLIENT_NAME="${1:-app_pc_bureau}"

mkdir -p "$DEST_DIR"

tar -C "$SRC_DIR" -czf "$DEST_DIR/${CLIENT_NAME}_bundle.tgz" \
  "ca.crt" \
  "client_${CLIENT_NAME}.crt" \
  "client_${CLIENT_NAME}.key"

echo "Bundle généré : $DEST_DIR/${CLIENT_NAME}_bundle.tgz"

Chaque bundle est ensuite transféré par canal sécurisé vers le poste cible, puis décompressé dans C:\ProgramData\EloNeva\PostgreSQL\.

5. Vérifier côté Windev que la connexion est bien sécurisée

Il ne suffit pas d’activer SSL dans la chaîne de connexion : il faut vérifier que PostgreSQL a bien établi une session chiffrée avec certificat client.

5.1 Requête de contrôle SQL

PostgreSQL expose plusieurs fonctions utiles :

SELECT
  current_user,
  inet_client_addr(),
  ssl_is_used()   AS ssl_active,
  ssl_version()   AS ssl_version,
  ssl_cipher()    AS ssl_cipher;

Intégration dans Windev :

PROCEDURE PG_VerifieTLS()
rq_CheckSSL est une Source de Données
sRequeteSQL est une chaîne = [
SELECT
  current_user,
  inet_client_addr(),
  ssl_is_used()   AS ssl_active,
  ssl_version()   AS ssl_version,
  ssl_cipher()    AS ssl_cipher
]

SI PAS HExecuteRequêteSQL(rq_CheckSSL, "cnxSecurePG", sRequeteSQL) ALORS
   Erreur("Impossible d'exécuter la requête de contrôle TLS : " + HErreurInfo(hErrComplet))
   RETOUR
FIN

SI HLitPremier(rq_CheckSSL) = Faux ALORS
   Erreur("Aucun résultat retourné pour la vérification TLS.")
   RETOUR
FIN

SI rq_CheckSSL.ssl_active = Faux ALORS
   Erreur("Attention : la connexion PostgreSQL n'est pas chiffrée (ssl_is_used() = false).")
SINON
   Info(
      "Utilisateur : " + rq_CheckSSL.current_user + RC +
      "Client : " + rq_CheckSSL.inet_client_addr + RC +
      "SSL : " + rq_CheckSSL.ssl_version + " (" + rq_CheckSSL.ssl_cipher + ")"
   )
FIN

Ce genre de procédure peut être appelé depuis un écran « Diagnostic technique » réservé aux administrateurs, ou depuis un bouton caché à l’intérieur de l’application.

5.2 Tests automatisés pour les installations EloNeva

Dans un contexte EloNeva, il est pertinent d’ajouter à votre script d’installation :

• un test de ping vers le FQDN,
• un test de port (ex. TestTCP sur 5434),
• un test de connexion PostgreSQL via WinDev avec affichage de ssl_is_used().

Si l’un de ces tests échoue, l’installation du module métier peut être bloquée ou marquée comme partiellement configurée, ce qui évite des tickets support ultérieurs difficiles à diagnostiquer.

6. Bonnes pratiques d’architecture et de sécurité pour EloNeva

6.1 Séparer les rôles dans Windev

Chaque module Windev doit utiliser le rôle le plus adapté :

• UI métier → app_user avec certificats spécifiques par poste ou par groupe,
• batchs de synchronisation → rôle dédié (type app_batch) avec certificats différents,
• outils techniques internes → app_developer ou admin, distribués uniquement aux équipes techniques.

Eviter absolument :

• d’utiliser un seul certificat « admin » pour toute la chaîne,
• de stocker un mot de passe postgres en dur dans l’exécutable.

6.2 Ne jamais embarquer les certificats dans l’exécutable

Les certificats et clés privées doivent rester hors de l’exécutable :

• dans un répertoire sécurisé (ProgramData, dossier protégé),
• avec des ACL appropriées,
• éventuellement chiffrés sur disque si l’on veut ajouter une couche de défense (BitLocker, EFS, etc.).

L’exécutable ne contient que des chemins et éventuellement des noms de fichiers, jamais de contenu clé.

6.3 Surveiller et tracer depuis PostgreSQL

Côté serveur, les logs d’authentification permettent de remonter :

• quel CN (donc quel poste) s’est connecté,
• à quel moment,
• depuis quelle IP.

En cas de comportement suspect d’une appli Windev, il est alors possible de révoquer uniquement le certificat correspondant, sans couper les autres applications.

6.4 Sauvegardes chiffrées : impact pour Windev

Les scripts de sauvegarde utilisent un rôle backup_user et chiffrent les dumps avec AES-256 via OpenSSL. L’application Windev n’a pas à exécuter ces scripts directement, mais :

• certains modules d’admin peuvent déclencher une sauvegarde côté serveur (via une API ou un job),
• un retour d’information à l’utilisateur (date de dernière sauvegarde, statut OK/KO) peut être affiché dans l’interface.

L’important est que Windev considère la base comme entièrement externalisée du point de vue sauvegardes : aucun export CSV « maison » ne doit remplacer des sauvegardes officielles chiffrées.

Conclusion

En combinant TDE côté PostgreSQL, mTLS sur toutes les connexions réseau et une gestion fine des rôles, on passe d’un simple « serveur SQL » à une brique de sécurité à part entière dans l’architecture.

Pour Windev, cela se traduit essentiellement par :

• la gestion rigoureuse des certificats sur les postes Windows,
• une configuration précise du connecteur natif (SSL Mode=verify-full, certificats explicitement déclarés),
• des procédures de vérification intégrées dans les écrans d’administration.

Pour une entreprise comme EloNeva, ce type d’intégration permet de proposer des applications Windev qui s’alignent sur les exigences modernes (confidentialité, traçabilité, conformité) sans sacrifier l’ergonomie côté utilisateur. La base PostgreSQL devient un service sécurisé, consommé proprement par les clients Windev, avec une séparation claire entre responsabilités applicatives et responsabilités d’infrastructure.