Sécuriser une application WinDev de bout en bout (base, réseau, postes)

13 min de lecture
Rédigé par Laurent Glesner - Consultant PC SOFT chez EloNeva
windev sécurité infra
#windev #sécurité applicative
Sécuriser une application WinDev de bout en bout (base, réseau, postes)

En bref

  • Pourquoi et comment sécuriser une application WinDev existante sans tout réécrire, dans un contexte Windows et mobilité.
  • Prioriser les mesures concrètes sur la base de données, le réseau, les postes clients, les identités et les sauvegardes.
  • Fournir à la DSI une check-list actionnable pour piloter la sécurisation progressive d'un parc WinDev.

Introduction

Beaucoup de SI reposent encore sur des applications WinDev “historiques” : client lourd Windows, HFSQL Client/Serveur ou base SQL, accès distants parfois bricolés pour les commerciaux et techniciens nomades. La valeur métier est là, mais la surface d’attaque aussi.

Du point de vue DSI, la question devient : comment sécuriser une appli WinDev existante, en environnement Windows et mobilité, sans tout réécrire et sans bloquer l’activité ? Du point de vue dev, il faut des mesures applicatives concrètes, pas seulement des grandes lignes “ISO 27001”.

Dans cet article, on prend une approche bout en bout :

  • base de données (HFSQL ou SQL externe)
  • réseau (on-prem, VPN, exposition internet éventuelle)
  • postes clients Windows (bureaux, portables)
  • identités et droits applicatifs
  • sauvegardes et gestion d’incident.

Avec une contrainte forte : rester réaliste pour un DSI de PME/ETI et une équipe WinDev qui doit continuer à livrer des features.

Résumé : sécuriser une appli WinDev en 7 points

Pour fixer le cadre, voici la version “exécutive” de la sécurité WinDev en 7 points, à décliner ensuite plus en détail :

  1. Réduire la surface d’exposition de la base

    • Aucune base accessible directement depuis internet.
    • Ports ouverts uniquement vers les sous-réseaux attendus (LAN, VPN).
    • Comptes DB dédiés, droits minimum.

  2. Chiffrer les données sensibles et les secrets

    • Chiffrement au repos de la base ou des disques.
    • Mots de passe et clés jamais en clair dans le code ou les .INI.
    • Utilisation de coffres-forts (DPAPI Windows, Docker secrets côté Linux, coffre-fort d’entreprise).

  3. Segmenter le réseau

    • Serveurs de base de données dans un VLAN “backend”.
    • Accès distants uniquement via VPN ou bastion.
    • Éventuels services web WinDev derrière un reverse-proxy type Traefik avec TLS.

  4. Durcir les postes clients

    • Postes Windows sans droits admin locaux.
    • Chiffrement disque (BitLocker) et EDR.
    • Politique claire sur les périphériques USB et le travail hors-ligne.

  5. Gérer sérieusement les identités et les rôles

    • Authentification via AD/Azure AD dès que possible.
    • Rôles applicatifs explicites (lecture, saisie, admin fonctionnel, etc.).
    • Traçabilité : qui a fait quoi, quand.

  6. Industrialiser les sauvegardes

    • Sauvegardes régulières, testées, hors-ligne.
    • RPO/RTO définis avec la direction.
    • Procédures claires de restauration et d’exercice de reprise.

  7. Surveiller et réagir

    • Logs applicatifs et serveurs centralisés.
    • Scénarios d’incident (compromission compte, ransomware, fuite de données).
    • Revue régulière de la configuration et des droits.

Le reste de l’article détaille comment appliquer ces principes à une appli WinDev dans un contexte EloNeva typique.

Menaces réelles sur une application WinDev

Connexion directe client lourd ↔ base

Le schéma le plus courant en WinDev “legacy” :

  • appli client lourd sur le poste
  • connexion directe à HFSQL Client/Serveur ou SQL Server/PostgreSQL
  • chaîne de connexion stockée en clair dans un .INI ou en dur dans le code.

Risques :

  • un attaquant qui récupère le poste ou le fichier .INI récupère les identifiants de la base
  • si la base est exposée sur internet (mauvaise pratique mais très vu), on tombe dans le scénario “scan de port + brute-force + exfiltration”.

Accès distants improvisés

Pour les commerciaux, techniciens, télétravail, on trouve souvent :

  • ports RDP (3389) ouverts sur internet, parfois sans MFA
  • port HFSQL directement ouvert sur internet “temporairement”
  • box opérateur faisant office de pare-feu “par défaut”.

On obtient :

  • une surface d’attaque énorme (RDP, SMB, HFSQL, SQL Server, etc.)
  • aucun cloisonnement : si un poste est compromis, le reste du réseau est à portée de scan.

Mots de passe en clair et code difficile à auditer

Dans les applis WinDev, on voit régulièrement :

  • des constantes du type gsMotDePasseAdmin = "Admin2020"
  • des chaînes de connexion avec login/mot de passe dans les paramètres du projet
  • des identifiants stockés en clair dans des fichiers HFSQL Classic sur les postes.

Même si le code est compilé, un attaquant motivé peut analyser les binaires ou simplement fouiller les fichiers de configuration et de données.

Ransomware et disponibilité

Les bases HFSQL ou les fichiers d’une appli WinDev sont souvent sur des partages SMB classiques, avec des sauvegardes incomplètes ou lentes. Un ransomware sur un poste bien connecté peut :

  • chiffrer les fichiers HFSQL ou les données SQL locales
  • chiffrer les partages réseau et les sauvegardes accessibles
  • rendre la production impossible pendant plusieurs jours.

La sécurité WinDev, ce n’est donc pas que la “confidentialité” : c’est aussi la disponibilité.

Sécurité de la base de données

Architecture cible simple

Pour une DSI, une architecture cible raisonnable ressemble à :

  • serveurs de base (HFSQL CS, PostgreSQL, SQL Server…) sur un réseau serveur dédié

  • port de la base non exposé directement depuis internet

  • accès depuis :

    • le LAN via des segments autorisés
    • des sous-réseaux VPN pour les nomades.

Et surtout : pas d’accès direct aux comptes administrateurs depuis les postes utilisateurs.

Durcir HFSQL Client/Serveur (ou SQL externe)

Quelques règles transposables à la plupart des moteurs :

  • Comptes dédiés par type d’usage

    • un compte applicatif en lecture/écriture
    • éventuellement un compte “reporting” en lecture seule
    • comptes d’admin réservés à l’équipe IT.

  • Droits minimum

    • l’appli n’a pas besoin de créer, supprimer ou modifier la structure des tables en production
    • limiter aux opérations nécessaires (SELECT, INSERT, UPDATE, DELETE sur les tables cibles).

  • Chiffrement au repos

    • si le moteur le permet : activer le chiffrement de la base ou des fichiers
    • sinon : au minimum, disques chiffrés côté OS (LUKS sous Linux, BitLocker sous Windows).

  • Journalisation

    • activer les logs de connexion et d’erreur
    • conserver l’historique dans un espace central ou sauvegardé.

Exemple de déploiement DB sous Ubuntu + Docker secrets

Même si l’appli WinDev tourne sur Windows, la base peut être hébergée sur un Linux Ubuntu 24.02 avec Docker, par exemple PostgreSQL. On évite d’écrire le mot de passe en clair dans le docker-compose.yml en utilisant un Docker secret :

# docker-compose.db.yml
version: '3.9'

services:
  db:
    image: postgres:16
    container_name: pg-app-windev
    environment:
      POSTGRES_USER: "app_windev"
      POSTGRES_DB: "app_windev"
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    ports:
      - "5432:5432"
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password

Création du secret :

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

mkdir -p secrets
openssl rand -base64 32 > secrets/db_password
chmod 600 secrets/db_password

docker compose -f docker-compose.db.yml up -d

Le mot de passe n’apparaît plus dans les logs ni dans le dépôt Git. L’appli WinDev reçoit uniquement la chaîne de connexion (par exemple via un fichier de config chiffré), jamais le mot de passe en clair pour un utilisateur humain.

Côté WinDev : connexion sans secret en clair

Côté code WinDev, l’idée est de ne jamais stocker en clair la chaîne de connexion sur le disque. Une approche pragmatique :

  1. Stocker la chaîne de connexion dans un fichier INI chiffré.
  2. Utiliser les API Windows (DPAPI) ou un mécanisme d’entreprise (coffre-fort) pour protéger la clé.
  3. Ne laisser visible que le strict nécessaire (nom du serveur, base, port).

Pseudo-code WinDev simplifié :

// Lecture d'un paramètre chiffré dans un INI
sChaineConnCryptee est une chaîne = INILit("BD", "Connexion", "", "config.sec")
SI sChaineConnCryptee = "" ALORS
   Info("Configuration de la base manquante.")
   FinProgramme()
FIN

sCleDPAPI est une chaîne = ObtenirCleDepuisDPAPI()
sChaineConn est une chaîne = Décrypte(sChaineConnCryptee, sCleDPAPI, cryptAES256)

// Exemple : sChaineConn = "SERVER=pg-app-windev;DATABASE=app_windev;UID=app_windev;PWD=********"

SI NOT HOpenConnection("cnApp", sChaineConn) ALORS
   Erreur("Impossible de se connecter à la base.", HErreurInfo())
   FinProgramme()
FIN

Le point clé côté DSI : le mot de passe n’est pas lisible par un utilisateur en fouillant le disque, et sa rotation reste maîtrisable.

Sécurité réseau

Cloisonner le serveur de base

Sur Ubuntu 24.02, un minimal “correct” avec ufw :

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

# Politique par défaut
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Autoriser SSH depuis l'admin VPN
sudo ufw allow from 10.0.10.0/24 to any port 22 proto tcp

# Autoriser la base uniquement depuis le LAN applicatif ou le VPN
sudo ufw allow from 10.0.20.0/24 to any port 5432 proto tcp   # LAN applicatif
sudo ufw allow from 10.0.30.0/24 to any port 5432 proto tcp   # réseau VPN

# Activer le pare-feu
sudo ufw enable
sudo ufw status verbose

Pour HFSQL, même principe avec le port correspondant (par défaut 4900 ou autre configuration).

Accès mobiles : VPN plutôt que port ouvert

Pour les utilisateurs nomades :

  • un VPN obligatoire (WireGuard, IPsec, SSL VPN…) pour atteindre la base ou les services WinDev
  • accès restreint aux seuls ports nécessaires (HFSQL/SQL, éventuelle API).

La DSI garde ainsi le contrôle :

  • pas de port RDP ou HFSQL ouvert “en brut” sur internet
  • possibilité de couper un utilisateur en révoquant son accès VPN.

Exposer une API WinDev derrière Traefik

Si l’application WinDev est complétée par une API REST ou des pages AWP exposées sur internet, on les publie derrière un reverse-proxy comme Traefik pour :

  • forcer le HTTPS
  • centraliser les certificats (Let’s Encrypt)
  • ajouter des protections (rate limiting, headers de sécurité).

Exemple minimal avec Docker :

# docker-compose.api.yml
version: '3.9'

services:
  traefik:
    image: traefik:v3.0
    command:
      - "--providers.docker=true"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.httpchallenge=true"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=websecure"
      - "--certificatesresolvers.le.acme.email=admin@entreprise.fr"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

  api-windev:
    image: registry.local/api-windev:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api.rule=Host(`api.app-entreprise.fr`)"
      - "traefik.http.routers.api.entrypoints=websecure"
      - "traefik.http.routers.api.tls.certresolver=le"

Même si la logique métier reste dans un exécutable WinDev, on bénéficie d’une couche réseau standardisée et durcie.

Sécurité des postes clients

Contexte réel : Windows, bureautique, legacy

Une DSI ne part pas d’une feuille blanche. Typiquement :

  • des PC de bureau et des portables sous Windows 10/11
  • des utilisateurs avec des droits parfois trop élevés “pour installer tel outil”
  • des applis WinDev, Office, des navigateurs, des outils métiers divers.

Le but n’est pas de transformer chaque poste en bunker, mais d’appliquer un socle minimum cohérent avec les besoins de l’appli WinDev.

Socle de durcissement recommandé

Pour les postes qui accèdent à l’appli WinDev :

  • Chiffrement disque systématique

    • BitLocker activé sur tous les postes portables
    • clé de récupération stockée dans l’annuaire (AD/Azure AD).

  • Pas de droits admin pour les utilisateurs

    • compte admin local réservé à la DSI
    • installation/mise à jour de l’appli WinDev via package MSI, GPO ou outil de déploiement.

  • EDR/antivirus d’entreprise

    • solution gérée centralement (Defender for Endpoint, autre)
    • politiques de blocage sur les exécutables inconnus ou non signés.

  • Politique USB

    • au minimum, journalisation
    • sur les postes sensibles (administration, finance) : restrictions fortes.

  • Mises à jour régulières

    • Windows Update géré (WSUS, Intune…)
    • version de WinDev et de ses dépendances (ODBC, .NET) suivies et mises à jour.

  • Séparation usage perso / pro

    • éviter l’installation d’outils non validés sur les postes accédant aux bases.

Côté développeurs WinDev, il est important de tenir compte de ces contraintes : éviter les chemins en écriture dans C:\Program Files, préférer %PROGRAMDATA% ou %APPDATA%, etc.

Gestion des identités

Authentification : tirer parti d’AD/Azure AD

Dès que l’appli WinDev fonctionne dans un domaine Active Directory, la bonne pratique est de réutiliser l’identité Windows :

  • l’utilisateur s’authentifie sur son poste
  • l’appli WinDev récupère son login (ex : UTILISATEUR = ReseauUtilisateur() ou équivalent)
  • la correspondance avec les droits applicatifs se fait via une table “Utilisateurs” en base.

Avantages :

  • pas de second mot de passe à gérer, moins de post-it
  • possibilité d’appliquer les politiques de sécurité Windows (MFA, verrouillage de compte, etc.)
  • gestion centralisée des entrées/sorties (départ d’un salarié).

Sur des architectures plus modernes (API WinDev derrière un backend web), on peut aller vers :

  • OpenID Connect / SAML via Azure AD ou un IdP
  • l’appli WinDev consomme l’API avec un jeton.

Autorisation : rôles et droits applicatifs

La gestion des droits ne doit pas reposer sur :

  • “profil par défaut” + exceptions dans le code
  • tests dispersés type SI gsUserProfil = "ADMIN" ALORS.

On vise :

  • une table ROLE (code, libellé)
  • une table UTILISATEUR_ROLE (id utilisateur, id rôle)
  • éventuellement une table ROLE_DROIT (droit fin : accès menu, écriture sur une fonction, etc.).

L’appli WinDev :

  • charge les rôles de l’utilisateur à la connexion
  • masque les boutons/menus non autorisés
  • vérifie côté serveur les droits lors des opérations critiques (suppression, export massif…).

En pratique, ce modèle rend aussi la DSI plus à l’aise pour auditer : “qui a le rôle ADMIN_FONCTIONNEL ?”.

Comptes techniques et secrets

Les comptes techniques (compte DB, compte pour une API, etc.) doivent :

  • avoir des droits strictement nécessaires
  • être documentés (propriétaire, usage, rotation)
  • ne jamais être réutilisés pour une connexion interactive.

Sur les serveurs Linux dans l’architecture, on peut stocker ces secrets dans :

  • Docker secrets (comme vu pour la DB)
  • un coffre-fort d’entreprise (HashiCorp Vault, Azure Key Vault, etc.)
  • à défaut, des fichiers sur disque chiffrés et protégés par l’OS.

Sauvegardes & incidents

Stratégie de sauvegarde réaliste

Pour une appli WinDev, il faut au minimum :

  • Sauvegarde de la base

    • dump logique pour SQL (pg_dump, SQL Server backup)
    • copie cohérente des fichiers HFSQL (en s’appuyant sur les outils PC Soft si possible).

  • Sauvegarde des fichiers applicatifs

    • exécutables, modèles, scripts, fichiers de paramétrage.

  • Sauvegarde de la configuration

    • fichiers .ini, scripts de déploiement, définitions de tâches planifiées, etc.

Avec une stratégie 3-2-1 :

  • 3 copies (prod + sauvegarde locale + sauvegarde externe)
  • 2 types de supports
  • 1 copie hors-ligne ou immuable.

Exemple de script de sauvegarde sous Ubuntu 24.02

Supposons une base PostgreSQL pour l’appli WinDev et un répertoire /srv/app-windev pour les fichiers :

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

BACKUP_ROOT="/srv/backups/app-windev"
DATE="$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_ROOT"

# Sauvegarde base PostgreSQL
PGURI="postgresql://app_windev:$(cat /run/secrets/db_password)@localhost:5432/app_windev"
PG_DUMP_FILE="${BACKUP_ROOT}/pgdump-${DATE}.sql.gz"

pg_dump "$PGURI" | gzip > "$PG_DUMP_FILE"

# Sauvegarde fichiers applicatifs
tar czf "${BACKUP_ROOT}/files-${DATE}.tar.gz" /srv/app-windev

# Rotation : garder 30 jours
find "$BACKUP_ROOT" -type f -mtime +30 -delete

Ce script peut être planifié via systemd timer ou cron. L’idée est la même avec HFSQL : utiliser les mécanismes de sauvegarde appropriés, puis archiver le résultat.

Tester la restauration

Point souvent oublié : tester la restauration.

  • Au moins une fois par trimestre :

    • restaurer une sauvegarde sur un environnement de test
    • démarrer l’appli WinDev contre cette base
    • vérifier l’intégrité fonctionnelle (login, quelques écrans, quelques exports).

  • Documenter la procédure de restauration :

    • qui fait quoi (DSI, support, dev)
    • durée estimée (RTO)
    • données perdues acceptables (RPO).

Gestion des incidents de sécurité

Quelques réflexes à formaliser :

  • En cas de suspicion de ransomware :

    • isoler rapidement les postes et serveurs compromis du réseau
    • ne pas redémarrer systématiquement les machines tant que les journaux n’ont pas été collectés
    • basculer sur les procédures de reprise.

  • En cas de fuite potentielle de données :

    • identifier les tables et types de données concernés (clients, salariés, secrets…)
    • informer la direction et, si nécessaire, le DPO
    • préparer la communication (interne, clients, autorités).

Une appli WinDev “bien tenue” facilite ces étapes : journaux lisibles, architecture claire, sauvegardes fiables.

Check-list finale DSI / WinDev

Une check-list minimaliste à adapter à votre contexte EloNeva :

  • La base (HFSQL/SQL) n’est pas directement exposée sur internet.
  • Les ports de la base ne sont ouverts que vers les sous-réseaux LAN/VPN nécessaires.
  • Les comptes DB applicatifs ont des droits minimaux et sont distincts des comptes d’administration.
  • Aucun mot de passe en clair dans le code WinDev, les .INI ou les fichiers HFSQL Classic.
  • Les postes accédant à l’appli sont chiffrés (BitLocker) et sans droits admin pour les utilisateurs.
  • L’authentification applicative est alignée sur l’annuaire (AD/Azure AD) ou un SSO d’entreprise.
  • Les rôles applicatifs sont clairement définis et documentés.
  • Il existe une procédure écrite et testée de sauvegarde et restauration de la base et des fichiers.
  • Un VPN est obligatoire pour les accès distants, aucun RDP ou HFSQL/SQL “ouvert” sur internet.
  • Les journaux (appli + serveurs) sont conservés et consultables en cas d’incident.

Conclusion

Sécuriser une application WinDev de bout en bout ne nécessite pas forcément une refonte complète. En combinant quelques principes solides (surface d’attaque réduite, secrets maîtrisés, réseau segmenté, postes durcis, identités gérées, sauvegardes testées), une DSI peut significativement améliorer le niveau de sécurité d’un parc WinDev existant, sans bloquer le business.

Pour une société comme EloNeva, l’enjeu est de transformer ces bonnes pratiques en standards de projet : modèles d’architecture réutilisables, scripts prêts à l’emploi, modèles de configuration WinDev, procédures de sauvegarde et de restauration partagées. Chaque nouveau projet WinDev n’est alors plus un cas particulier, mais une déclinaison maîtrisée d’un socle de sécurité éprouvé.

Liens utiles

Articles similaires

← Retour aux articles