La plupart des serveurs SQL compromis ne le sont pas via des attaques sophistiquées. Ils le sont parce qu’un compte administrateur par défaut n’a jamais été supprimé, parce que les droits d’accès n’ont pas été revus depuis le déploiement initial, ou parce qu’un port est resté ouvert sans raison. Ce sont des configurations laissées telles quelles, parfois depuis des années.
Le contexte 2024-2025 rend ce statu quo plus risqué qu’avant. En France, 67 % des entreprises ont subi une cyberattaque en 2024, contre 53 % l’année précédente. La CNIL a enregistré 5 629 notifications de violations de données sur la même période, soit 20 % de plus qu’en 2023. Et quand une compromission a lieu, le délai moyen pour la détecter est de 194 jours à l’échelle mondiale – ce qui signifie qu’un attaquant peut se déplacer librement dans votre infrastructure pendant plus de six mois avant d’être repéré. Le coût moyen d’une violation atteint 4,44 millions de dollars en 2025 selon IBM, et cette moyenne masque des situations bien plus graves pour les structures sans capacité de réponse rapide.
Ce que cet article propose, c’est un ordre de traitement : commencer par ce qui ferme les portes les plus grandes, puis construire des couches de détection et de résilience. Aucune de ces mesures ne nécessite de repartir de zéro.
1. L’authentification : fermer la porte d’entrée principale
C’est le point de départ non négociable. Toutes les autres mesures de sécurité perdent leur valeur si n’importe qui peut se connecter avec des identifiants par défaut ou un mot de passe trivial.
La première vérification à faire : recenser tous les comptes existants sur le serveur et identifier ceux qui n’ont pas de propriétaire clairement défini. Les comptes créés lors de l’installation (souvent nommés sa sur SQL Server, ou root sur MySQL) doivent soit être désactivés, soit voir leur mot de passe changé immédiatement s’ils ne peuvent pas être supprimés. Sur un serveur en production depuis plusieurs années, il est fréquent de trouver des comptes de test ou de migration jamais nettoyés.
Sur la politique de mots de passe : les critères à vérifier sont la longueur minimale, la complexité requise et l’expiration. Ces paramètres varient selon le moteur SQL utilisé – SQL Server expose ces réglages via les propriétés de connexion, PostgreSQL délègue cette responsabilité au système d’exploitation ou à des extensions, MySQL dispose de son propre plugin de validation. La méthode de vérification reste la même : consulter la documentation de votre moteur pour identifier les paramètres actifs, puis les comparer à votre politique de sécurité interne.
Sur le mode d’authentification, la distinction principale concerne SQL Server : le mode mixte (authentification SQL native + Windows) est souvent activé par défaut, alors que l’authentification Windows/Active Directory seule est plus sûre en environnement d’entreprise, car elle s’appuie sur la gestion centralisée des comptes et hérite des politiques de sécurité du domaine. Si votre organisation dispose d’un contrôleur de domaine Active Directory, basculer vers l’authentification intégrée supprime une surface d’attaque entière. Pour les autres moteurs (PostgreSQL, MySQL), la logique équivalente passe par l’authentification par certificat ou par les mécanismes d’authentification externe (LDAP, PAM).
2. Auditer les droits : qui peut faire quoi
Une fois les accès sécurisés, la question suivante est : que peuvent faire ces comptes une fois connectés ? Les droits excessifs sont le vecteur de compromission le plus fréquent sur les serveurs mal configurés, précisément parce qu’ils transforment un accès limité en capacité d’action étendue.
L’audit minimal consiste à répondre à trois questions :
- Quels comptes ont des droits d’administrateur sur le serveur ou sur des bases entières, et est-ce justifié par leur usage réel ?
- Les comptes de service applicatifs ont-ils uniquement les droits nécessaires à l’application (lecture seule si possible, écriture uniquement sur les tables concernées) ?
- Y a-t-il des comptes partagés entre plusieurs applications ou plusieurs personnes, rendant toute traçabilité impossible ?
Le principe du moindre privilège se traduit concrètement : un compte applicatif n’a pas besoin de droits de création de table, encore moins de droits sur les tables d’autres applications. Un compte de reporting n’a besoin que de la lecture. Chaque droit supplémentaire est une surface qu’un attaquant peut exploiter après une compromission initiale. La révision de ces droits doit être traitée comme un audit régulier, pas comme une action ponctuelle.
3. Réduire ce que le serveur expose au réseau
Un serveur SQL accessible depuis des segments réseau qui n’en ont pas besoin multiplie les vecteurs d’intrusion sans aucun bénéfice opérationnel. La réduction de la surface d’attaque réseau est l’une des mesures les plus efficaces et les plus simples à mettre en place.
Les étapes à suivre :
- Vérifier quels ports sont effectivement ouverts et depuis quels segments réseau. Le port d’écoute par défaut varie selon le moteur (SQL Server utilise le port 1433 par défaut, MySQL le 3306, PostgreSQL le 5432) – vérifiez si ces ports sont accessibles depuis l’extérieur du segment applicatif.
- Restreindre l’accès au serveur SQL aux seuls serveurs applicatifs qui en ont besoin, via des règles de pare-feu ou des groupes de sécurité réseau. En environnement cloud managé (RDS, Azure SQL Database), ces règles s’appliquent au niveau des security groups ou des règles de pare-feu du service.
- Désactiver les fonctionnalités non utilisées. Sur SQL Server,
xp_cmdshellest l’exemple emblématique : cette procédure stockée permet d’exécuter des commandes système depuis une requête SQL, et elle est désactivée par défaut depuis SQL Server 2005 – mais peut avoir été réactivée sans être redésactivée après. Vérifiez son état et celui des autres fonctionnalités étendues (OLE Automation, SQL Mail). Sur les autres moteurs, le même principe s’applique : tout module ou extension activé par défaut mais non utilisé doit être désactivé.
Cas particulier : si votre serveur SQL est accessible directement depuis Internet, sans VPN ni bastion d’administration, ces mesures réseau deviennent la priorité absolue avant tout autre chantier. La mise en place d’un bastion d’accès pour isoler l’administration du serveur est une architecture à envisager en urgence dans ce cas.
Sur un service SQL managé chez un hébergeur cloud, une partie de ce travail est prise en charge par le fournisseur (configuration réseau de base, isolation physique). La responsabilité du lecteur porte alors sur les règles d’accès applicatives et la configuration des utilisateurs – pas sur l’infrastructure sous-jacente.
4. Le patching : une discipline opérationnelle
Les failles non corrigées sont exploitées en masse, souvent dans les semaines qui suivent la publication d’un correctif. Avec un délai moyen de détection de 194 jours, chaque retard de patching crée une fenêtre d’exposition qui peut couvrir plusieurs cycles de mise à jour manqués.
La difficulté réelle n’est pas technique : c’est l’arbitrage entre disponibilité et sécurité. Un patch sur un serveur de production implique une maintenance, potentiellement un redémarrage, et un risque de régression applicative. Ces contraintes sont réelles, mais elles ne justifient pas l’absence de processus.
Une logique de priorisation réaliste : évaluer la criticité de chaque correctif (une faille permettant l’exécution de code à distance sans authentification n’a pas le même niveau d’urgence qu’une faille de déni de service nécessitant un accès local), tester en environnement de qualification avant déploiement en production, et documenter l’état de patching du serveur pour avoir une visibilité sur le retard accumulé. Les outils de gestion des vulnérabilités peuvent aider à prioriser ce travail sur un parc étendu.
Sur un service SQL managé (RDS, Azure SQL Database, Cloud SQL), le patching du moteur est géré par le fournisseur. La responsabilité du lecteur se concentre sur le système d’exploitation des serveurs applicatifs qui s’y connectent, et sur la configuration de sécurité du service lui-même.
5. Logs et chiffrement : détecter et limiter l’impact
Les quatre points précédents visent à empêcher une compromission. Celui-ci part du principe qu’une compromission peut arriver malgré tout, et cherche à en limiter la durée et les conséquences.
Sur les journaux d’audit, la question n’est pas de tout tracer – un volume de logs trop dense devient inexploitable. Les événements à tracer en priorité sont les connexions échouées répétées sur un même compte, les connexions réussies depuis des adresses inhabituelles, les modifications de droits ou de schéma en dehors des fenêtres de maintenance, et les requêtes portant sur des volumes de données anormalement élevés. Chaque moteur SQL dispose de mécanismes d’audit natifs (SQL Server Audit, pgAudit pour PostgreSQL, le journal général et le journal des requêtes lentes de MySQL) – l’activation et la configuration de ces mécanismes dépendent du moteur et de la version utilisée.
Sur le chiffrement, deux niveaux à traiter séparément :
- En transit : forcer TLS pour toutes les connexions entre les applications et le serveur SQL. Vérifier que les versions de TLS acceptées correspondent aux recommandations actuelles de l’ANSSI, et que les certificats sont valides et renouvelés.
- Au repos : le chiffrement des colonnes contenant des données personnelles ou financières limite l’exploitation des données même en cas d’accès non autorisé au fichier de base de données. La granularité (chiffrement de colonne, chiffrement transparent de la base entière) dépend du moteur et du niveau de sensibilité des données.
Si votre serveur stocke des données personnelles au sens du RGPD, le chiffrement au repos et en transit n’est pas une option : une violation non chiffrée doit être notifiée à la CNIL dans les 72 heures suivant sa découverte. Avec 5 629 notifications enregistrées en 2024 et une progression de 20 %, les délais de traitement CNIL s’allongent – autant éviter d’avoir à notifier.
Checklist de durcissement SQL
À utiliser comme base d’audit de votre configuration existante. Chaque point peut être traité indépendamment – commencez par les éléments non cochés dans les cinq premières catégories.
Authentification
- Comptes par défaut désactivés ou supprimés
- Politique de mots de passe activée (longueur minimale, complexité, expiration)
- Mode d’authentification revu (Windows/AD privilégié si applicable)
- Comptes sans activité récente identifiés et désactivés
Droits d’accès
- Inventaire des comptes avec droits administrateur réalisé
- Comptes de service limités aux droits strictement nécessaires
- Absence de comptes partagés entre plusieurs applications
- Droits audités et documentés pour chaque compte applicatif
Surface d’attaque réseau
- Accès au port SQL restreint aux seuls serveurs applicatifs autorisés
- Serveur SQL non accessible directement depuis Internet
- Fonctionnalités non utilisées désactivées (ex.
xp_cmdshellsur SQL Server) - Règles de pare-feu ou groupes de sécurité documentés et revus
Patching
- Version du moteur SQL à jour (ou retard documenté avec justification)
- Système d’exploitation sous-jacent à jour
- Processus de test avant déploiement en production défini
Logs et chiffrement
- Audit des connexions activé (succès et échecs)
- Alertes sur les comportements anormaux configurées
- TLS activé et forcé pour toutes les connexions
- Chiffrement au repos activé pour les colonnes ou bases contenant des données sensibles
- Rétention des logs définie et logs stockés hors du serveur SQL
La première action à engager dans les 48 heures : exporter la liste de tous les comptes existants sur votre serveur SQL et identifier ceux qui n’ont pas de propriétaire clairement défini. C’est l’audit le plus rapide à réaliser, et il révèle systématiquement des comptes oubliés avec des droits qui n’auraient jamais dû rester actifs.