Sécuriser MariaDB et WinDev avec mTLS et Docker secrets

Introduction

De nombreuses applications WinDev s’appuient sur MariaDB pour stocker des données critiques : pièces comptables, données RH, dossiers clients, santé, etc. Quand on regarde la réalité du terrain, la base est souvent protégée par… un simple mot de passe et un VPN vaguement documenté. En 2025, ce n’est plus défendable.

L’objectif de cet article est de partir d’une stack MariaDB chiffrée + backups GPG + Docker secrets pour aboutir à une connexion WinDev en authentification mutuelle TLS (mTLS), avec une vraie réflexion sur :

l’architecture de sécurité côté MariaDB (chiffrement, réseau, secrets) ;
la préparation d’un poste Windows pour consommer ce service sécurisé ;
la configuration du connecteur MySQL natif dans WinDev pour parler mTLS ;
la gestion des certificats sur la durée.

L’idée n’est pas de noyer le lecteur sous le code, mais de donner des repères structurants qu’une DSI ou une équipe projet peut reprendre dans un contexte similaire à ce qu’on déploie chez EloNeva.

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

Avant de parler WinDev, il faut clarifier ce que l’on attend de la couche base de données. Dans la stack décrite par le README, l’architecture MariaDB repose sur quatre piliers.

1.1 Chiffrement au repos : InnoDB + file_key_management

Le premier objectif est de s’assurer que voler le disque ne suffit pas à lire les données :

MariaDB active le chiffrement du tablespace InnoDB ;
les clés de chiffrement sont gérées via le mécanisme file_key_management ;
le fichier des clés est monté comme secret Docker, dans /run/secrets/mariadb_file_keys.

En pratique :

le moteur InnoDB chiffre les pages de données avant de les écrire sur disque ;
les logs (redo log, fichiers temporaires) peuvent eux aussi être chiffrés ;
si un attaquant copie le volume Docker ou le disque, il obtient des données illisibles sans le fichier de clés.

Ce chiffrement n’exonère pas d’un contrôle d’accès, mais il réduit l’impact d’un vol de support ou d’une mauvaise suppression de disque.

1.2 Chiffrement en transit : TLS 1.3 et mTLS

Deuxième pilier : toutes les communications entre MariaDB et ses clients sont chiffrées, et idéalement mutuellement authentifiées.

Dans la stack :

le serveur MariaDB est configuré avec :
- un certificat serveur (server.crt / server.key) signé par une CA interne (ca.crt) ;
- require_secure_transport=ON pour interdire les connexions non chiffrées ;
- tls_version=TLSv1.3 pour imposer une version moderne de TLS.
chaque client (WinDev, conteneur de backup, outil d’admin) dispose d’un certificat client (<client>.crt / <client>.key) signé par cette même CA.

L’authentification mTLS fonctionne alors dans les deux sens :

le client vérifie l’identité du serveur (comme en HTTPS) ;
le serveur vérifie que le client présente un certificat valide, et que le CN du certificat correspond à l’utilisateur SQL attendu.

On se retrouve avec un modèle proche d’une authentification par carte à puce, mais pour les connexions MariaDB.

1.3 Isolation réseau et durcissement des services

Le troisième pilier est réseau :

les services sont placés sur un réseau Docker dédié (par exemple dbnet) ;
MariaDB n’est pas exposé sauvagement sur 0.0.0.0:3306 ;
idéalement, seul un reverse-proxy ou un bastion contrôle l’accès au port MariaDB.

En pratique, plusieurs scénarios existent :

accès uniquement interne à Docker : aucune directive ports: dans docker-compose.yml. Seuls d’autres conteneurs sur dbnet peuvent joindre la base ;
exposition sur un port spécifique (ex : 3307) filtré par pare-feu (UFW, firewall Windows, firewall réseau) ;
exposition derrière un tunnel (VPN, bastion SSH, proxy TLS) pour maîtriser le chemin réseau.

À cela s’ajoutent :

des healthchecks (ping MariaDB, contrôle des backups) ;
des limits CPU/RAM pour éviter qu’un backup ou une requête gourmande ne fasse tomber la machine.

1.4 Gestion des secrets et des identités

Dernier pilier : la gestion des secrets et des identités.

Dans la stack décrite :

les mots de passe (root, app_user, backup_user) sont stockés dans des Docker secrets ;
le fichier mariadb_file_keys.txt est lui aussi un secret ;
l’URL de webhook, le mot de passe SMTP et la clé publique GPG du DPO sont externalisés.

Côté MariaDB :

chaque utilisateur SQL correspond à un profil métier (admin, application, backup) ;
la configuration SQL peut exiger un certificat client particulier (via le SUBJECT du certificat) pour se connecter.

On obtient une séparation claire des rôles :

l’équipe Ops gère les secrets et la PKI ;
les développeurs WinDev manipulent des identifiants applicatifs, pas des mots de passe infra.

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

Avant même d’ouvrir WinDev, il faut que le poste Windows soit prêt à manipuler des certificats et à établir des connexions TLS vers la base.

2.1 Pré-requis techniques

On vérifie quelques points de base :

version de Windows supportée et à jour (TLS 1.2/1.3 activé, mise à jour des certificats racines) ;
présence d’un antivirus/EDR qui ne bloque pas systématiquement les connexions sortantes vers le port MariaDB ;
synchronisation de l’horloge (NTP ou AD) — des certificats avec des dates de validité strictes et une horloge décalée donnent des erreurs difficiles à diagnostiquer.

Côté réseau :

le port MariaDB exposé par la stack (par ex. 3307) doit être joignable depuis le poste ;
si un VPN est utilisé, on documente clairement le contexte (réseau de dev, de recette, de prod).

2.2 Organisation des certificats sur le poste

On conseille de séparer clairement :

les certificats racine/intermédiaires de l’entreprise (CA) ;
les certificats clients liés aux utilisateurs ou aux applications.

Un modèle simple :

C:\secrets\mariadb\ca\ca.crt : certificat de la CA MariaDB ;
C:\secrets\mariadb\clients\<nom_utilisateur>\client.crt ;
C:\secrets\mariadb\clients\<nom_utilisateur>\client.key.

Bonnes pratiques :

droits NTFS restreints : seules les personnes/identités de service autorisées peuvent lire ces fichiers ;
pas de certifiats client stockés sur un partage réseau ouvert à tout le monde ;
si possible, stockage chiffré (BitLocker sur le poste, voire dossier chiffré).

2.3 Tests de connectivité

Avant d’accuser WinDev, on vérifie que le poste peut joindre MariaDB :

ping / résolution DNS du serveur ;
test de port avec Test-NetConnection ou un outil équivalent ;
idéalement, test de connexion mTLS via un client MariaDB en ligne de commande (installé sur le poste ou sur une VM proche).

L’idée est de séparer les problèmes de :

connectivité réseau (firewall, DNS, NAT) ;
TLS (certificats, versions) ;
authentification SQL (droits, mapping certificat ↔ utilisateur).

3. Configurer le connecteur MySQL natif dans WinDev

Une fois le poste préparé, on peut enchaîner sur la configuration du connecteur MySQL natif de WinDev en mTLS.

3.1 Comprendre ce que fait WinDev

Côté WinDev, une connexion MySQL/MariaDB repose principalement sur :

un objet Connexion en WLanguage ;
un provider "MySQL" ou "MariaDB" selon la version ;
des options supplémentaires pour la couche TLS (chemins des certificats, mode SSL…).

WinDev ne gère pas directement Docker, GPG ou la rotation des backups. Il « voit » juste :

serveur:port ;
un utilisateur SQL/mot de passe ;
éventuellement des options SSL.

L’objectif est donc de refléter dans WinDev ce qui est exigé côté MariaDB :

port 3307 (ou autre) ;
utilisateur app_user ;
certificat client correspondant (app_user.crt / app_user.key) signé par la CA (ca.crt).

3.2 Options TLS importantes

Le provider MySQL de WinDev expose généralement des options de ce type :

SSL_CA : chemin vers le certificat de la CA ;
SSL_CERT : certificat client au format PEM ;
SSL_KEY : clé privée du certificat client ;
SSL_MODE : exigence SSL (par ex. REQUIRED).

Concrètement, la différence entre un MySQL « classique » et un MySQL mTLS dans WinDev se joue surtout sur cette couche d’options, pas sur le code métier.

Un pseudocode typique (simplifié) :

MaConnexion est une Connexion
MaConnexion..Provider    = "MySQL"
MaConnexion..Serveur     = "db.mondomaine.local"
MaConnexion..Port        = 3307
MaConnexion..Utilisateur = "app_user"
MaConnexion..MotDePasse  = "AppPwd123!"
MaConnexion..BaseDeDonnees = "appdb"

// Options mTLS
MaConnexion..Option["SSL_CA"]   = "C:\secrets\mariadb\ca\ca.crt"
MaConnexion..Option["SSL_CERT"] = "C:\secrets\mariadb\clients\app_user\client.crt"
MaConnexion..Option["SSL_KEY"]  = "C:\secrets\mariadb\clients\app_user\client.key"
MaConnexion..Option["SSL_MODE"] = "REQUIRED"

Ce qui change d’un environnement à l’autre (dev, recette, prod) :

l’hôte (Serveur) ;
le port ;
les chemins de certificats (voire les certificats eux-mêmes) ;
éventuellement l’utilisateur SQL (par exemple app_user_dev vs app_user).

On évite de coder ces différences en dur : on externalise dans un fichier de configuration ou une table dédiée.

3.3 Gestion des erreurs côté WinDev

En pratique, les erreurs mTLS ne sont pas toujours parlantes côté WLanguage :

certificat invalide ou non signé par la bonne CA ;
certificat expiré ;
horloge système décalée ;
CN du certificat ne correspondant pas à l’utilisateur SQL attendu.

Bon réflexe :

loguer le message complet de HErreurInfo() ;
prévoir un mode « debug » où l’application affiche des détails supplémentaires (uniquement en dev/recette) ;
disposer d’un environnement de test où l’on peut rejouer les erreurs (certificats volontairement expirés, CN erroné, etc.).

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

Mettre du mTLS en place une fois, c’est facile. Le vrai sujet, c’est de le maintenir dans le temps sans bloquer la production.

4.1 Durée de vie et renouvellement

Les certificats clients ne doivent pas être valables dix ans. Typiquement :

1 à 3 ans pour un certificat client (dev ou prod) ;
un renouvellement planifié plusieurs semaines avant l’expiration :
- génération d’un nouveau certificat ;
- déploiement silencieux sur les postes ;
- fenêtre de bascule (avec parfois acceptation temporaire des deux certificats côté MariaDB).

Côté SQL, on peut par exemple :

autoriser temporairement deux sujets (SUBJECT) différents pour le même utilisateur ;
ou créer un utilisateur app_user_new et maintenir les droits en parallèle le temps de migrer.

4.2 Distribution des certificats

Plusieurs approches sont possibles pour distribuer les certificats clients aux postes WinDev :

Installation manuelle (acceptable en dev ou pour quelques postes seulement) :
- l’Ops fournit un zip sécurisé avec ca.crt, client.crt, client.key ;
- l’utilisateur suit une procédure pour le placer dans C:\secrets\....
Script de déploiement automatisé (PowerShell, GPO, outil d’inventaire) :
- les certificats sont déposés dans un dossier standard ;
- les droits NTFS sont appliqués automatiquement ;
- on peut gérer le renouvellement en déclenchant le script.
Coffre-fort applicatif (plus avancé) :
- WinDev va chercher au démarrage ses secrets et certificats auprès d’un service sécurisé ;
- les fichiers ne sont jamais stockés en clair sur le disque (ou uniquement en cache chiffré).

Le choix dépend du niveau de maturité de l’entreprise et du périmètre (application interne ou vendue à des clients).

4.3 Multi-environnements (dev / recette / prod)

Pour éviter les erreurs classiques (utiliser un certificat de dev sur une base de prod, par exemple), on conseille :

une CA distincte par environnement (ou au minimum une hiérarchie claire de sous-CA) ;
un schéma de nommage explicite des certificats :
- CN=app_user-dev, CN=app_user-recette, CN=app_user-prod ;
une organisation des dossiers côté Windows reflétant ces environnements :
- C:\secrets\mariadb\dev\..., C:\secrets\mariadb\prod\....

Côté WinDev, on sélectionne l’environnement via un paramètre :

variable globale ;
fichier INI/JSON ;
table de configuration SQL.

Le code WLanguage, lui, reste identique ; seuls les paramètres changent.

4.4 Révocation et gestion des incidents

En cas de fuite de certificat client (poste perdu, compromis) :

côté PKI, on révoque le certificat (CRL, OCSP…) si l’infrastructure le permet ;
côté MariaDB, on peut :
- désactiver l’utilisateur SQL correspondant ;
- restreindre les adresses IP autorisées ;
- déployer un nouveau certificat pour l’utilisateur et l’application.

Une procédure écrite est indispensable :

qui déclenche quoi (SecOps, DSI, chef de projet) ;
dans quel délai ;
quelles vérifications et logs à conserver.

5. Sauvegardes compressées et chiffrées GPG

Revenons à la stack Docker : la partie backup est un angle mort dans de nombreux projets, alors que c’est souvent la première chose qu’un auditeur demande.

5.1 Conteneur de backup dédié

Le projet prévoit un service mariadb-backup distinct :

il contient :
- le client MariaDB ;
- GPG ;
- cron pour la planification ;
- un utilitaire SMTP (msmtp) pour les mails ;
il lit :
- le mot de passe de backup_user dans /run/secrets/mariadb_backup_password ;
- la clé publique GPG du DPO dans /run/secrets/dpo_pubkey.

Ce conteneur :

se connecte à MariaDB via mTLS (il a lui aussi son certificat client) ;
exécute un mysqldump avec les bonnes options (transactionnel, triggers, routines) ;
compresse en gzip ;
chiffre le flux avec la clé publique GPG ;
stocke le résultat dans backups/ avec un sha256 associé.

5.2 Gains de cette approche

Par rapport au script mysqldump lancé depuis un serveur random :

les identifiants sont gérés en secrets, pas dans des fichiers .sh ou .bat ;
la compression avant chiffrement réduit la taille des sauvegardes ;
la clé privée GPG reste chez le DPO : même si le dépôt de backups est compromis, l’attaquant ne lit pas les données ;
la rotation et le calcul d’empreintes sont automatisés ;
le conteneur est supervisé (logs, healthcheck).

Pour WinDev, rien ne change directement : l’application continue à dialoguer avec une base « normale ». Mais côté DSI, on a une histoire cohérente sur la sauvegarde/restauration.

6. Monitoring de la fraîcheur des backups

La stack inclut un script check_backup.sh utilisé comme :

commande de supervision (via make monitor, scripts Nagios, Prometheus, etc.) ;
healthcheck Docker du conteneur mariadb-backup.

Il vérifie :

l’existence d’au moins un fichier mariadb_*.sql.gz.gpg ;
l’âge du dernier fichier par rapport à un seuil configurable (ex : 30 heures).

Les codes de retour permettent d’intégrer facilement le contrôle dans un outil de supervision :

0 : OK ;
1 : dernier backup trop ancien ;
2 : aucun backup détecté.

C’est une brique très simple mais redoutablement efficace pour ne pas découvrir six mois plus tard que plus personne n’a de sauvegarde valide.

7. Procédures de restauration : point de vue DPO / exploitation

Le README détaille une procédure pas à pas de restauration :

Identifier le bon fichier mariadb_YYYY-MM-DD_HHMMSS.sql.gz.gpg ;
Sur une machine DPO qui possède la clé privée GPG :
- déchiffrer et décompresser le fichier ;
Transférer le dump en clair vers le serveur MariaDB (ou une instance de test) ;
Lancer la commande de restauration dans le conteneur MariaDB ;
Effacer toutes les copies en clair dès que les vérifications sont terminées.

Cette procédure a plusieurs intérêts :

elle force à documenter qui peut restaurer, où et comment ;
elle distingue clairement :
- la phase GPG (domaine du DPO) ;
- la phase MariaDB (domaine de l’équipe infra/applicative).

Dans un contexte WinDev, on peut même aller jusqu’à fournir :

des scripts pour restaurer une base de recette et rebrancher les connexions WinDev dessus ;
des jeux de données réalistes mais anonymisés à partir des backups réels.

8. Bonnes pratiques et erreurs classiques

En synthèse, quelques anti-patterns vus sur le terrain :

MariaDB exposé en clair sur le LAN, accessible sans TLS depuis des postes WinDev en mobilité ;
backups réalisés par un batch .bat avec le mot de passe root en clair ;
absence de stratégie de renouvellement des certificats (on découvre l’expiration en production) ;
aucune séparation entre certificats de dev et prod ;
base chiffrée, mais fichiers de clés stockés sur le même disque dans un répertoire world-readable.

À l’inverse, la stack MariaDB « durcie » donne une trajectoire claire :

chiffrement au repos et en transit ;
séparation stricte des secrets ;
mTLS systématique ;
backups chiffrés, supervisés, avec une histoire de restauration crédible ;
intégration propre dans WinDev via le connecteur MySQL natif.

Conclusion

En combinant MariaDB chiffré, Docker secrets, backups GPG et mTLS de bout en bout jusqu’à WinDev, on passe d’une simple base de données à un service de données sécurisé :

les données restent lisibles uniquement pour les acteurs légitimes, même en cas de vol de disque ou de fuite de backups ;
chaque client WinDev prouve son identité par certificat, pas seulement par mot de passe ;
la DSI dispose de procédures de backup/restauration documentées et testables ;
les projets peuvent réutiliser ce socle d’une application à l’autre.

Pour une société comme EloNeva, ce type d’architecture apporte un avantage concret :

côté métier, les développeurs WinDev continuent à coder avec leurs outils habituels, tout en répondant à des exigences réglementaires élevées (RGPD, santé, finance, etc.) ;
côté technique, l’architecture est industrialisable : Docker, scripts Bash Ubuntu 24.02, supervision intégrable, bonnes pratiques reproductibles.

La prochaine étape naturelle consiste à intégrer ce socle dans une chaîne CI/CD, à ajouter des tests automatiques (connexion mTLS, scénario de restauration), et à en faire un modèle standard pour tous les projets WinDev/MariaDB nécessitant un haut niveau de sécurité.