Une base de données d’entreprise devient rarement exposée parce que quelqu’un choisit délibérément une architecture dangereuse. Le plus souvent, l’exposition provient d’un paramètre par défaut, d’une règle de pare-feu temporaire, d’un service de test oublié ou d’un raccourci de maintenance devenu permanent.
Les conséquences peuvent être graves. Un attaquant peut dérober des données clients, modifier des données financières, chiffrer des systèmes de production ou utiliser le serveur de base de données pour pénétrer dans d’autres infrastructures. Même lorsqu’aucune donnée n’est immédiatement volée, un service exposé crée un point d’entrée évitable qui doit être surveillé et protégé.
Les sept erreurs ci-dessous concernent les serveurs de bases de données contrôlés par une entreprise, une agence ou un administrateur informatique. Elles s’appliquent à PostgreSQL, MySQL, Microsoft SQL Server, MongoDB et d’autres plateformes. Les commandes exactes diffèrent, mais les décisions de sécurité restent les mêmes : réduire l’accessibilité, vérifier l’identité, limiter les autorisations, chiffrer les communications, surveiller l’activité et conserver une capacité de reprise indépendante du serveur protégé.
1. Lier la base de données à une interface publique
Un démon de base de données peut écouter par défaut sur toutes les interfaces réseau, ou un administrateur peut le configurer pour écouter sur une adresse IP publique afin de faciliter l’accès distant. Si le serveur possède une adresse routable, la base peut alors être accessible directement depuis Internet, à moins qu’un autre contrôle ne la bloque.
Mode d’attaque et impact pour l’entreprise
Un attaquant analyse des plages d’adresses à la recherche de ports de bases de données connus, identifie le logiciel et sa version, puis tente des attaques sur les identifiants ou exploite une vulnérabilité connue. La visibilité publique n’entraîne pas automatiquement une compromission, mais elle fournit aux attaquants une cible permanente et facile à trouver.
Un accès réussi peut exposer des données personnelles, des commandes, des identifiants, de la propriété intellectuelle et des informations opérationnelles. Un compte de base de données peut également permettre à un attaquant de modifier des enregistrements, de créer de nouveaux utilisateurs privilégiés ou d’utiliser des fonctions de la base pour atteindre le serveur sous-jacent.
Comment détecter et corriger le problème
Vérifiez la configuration de l’écouteur de la base de données ainsi que la liste des sockets du système d’exploitation. Des commandes telles que ss -lntp ou netstat -lntp peuvent indiquer si le service écoute sur 0.0.0.0, :: ou une adresse publique, plutôt que seulement sur localhost ou une interface privée. Effectuez un test depuis l’extérieur du réseau, et pas uniquement depuis le serveur. Une analyse externe des ports et un examen des groupes de sécurité cloud ou des règles du pare-feu de l’hébergeur doivent correspondre à l’architecture prévue.
Pour la plupart des applications, liez la base de données à localhost ou à une adresse de réseau privé et placez-la derrière le niveau applicatif. Si l’administration distante est nécessaire, imposez un VPN privé, un bastion ou une autre voie d’accès contrôlée. Ne considérez pas un port inhabituel comme une protection. Il peut réduire le bruit opportuniste, mais n’empêche pas la découverte.
Les administrateurs peuvent consulter des conseils fiables pour vérifier une base exposée à Internet et les modèles d’exposition sécurisés lors de la validation de l’architecture. L’objectif doit être de supprimer l’accessibilité publique partout où elle n’est pas indispensable, et pas simplement de dissimuler le service.
2. Conserver des identifiants par défaut ou une authentification faible
Les produits de bases de données, les appliances et les images de déploiement incluent parfois des noms d’utilisateur par défaut, des mots de passe temporaires ou des modes d’authentification prévus uniquement pour la configuration initiale. Une installation précipitée peut également conserver un mot de passe simple, réutiliser un secret applicatif ou autoriser des connexions locales sans mot de passe plus largement que prévu.
Mode d’attaque et impact pour l’entreprise
Après avoir découvert un port de base de données, les attaquants essaient régulièrement les identifiants publiés par défaut et les mots de passe courants. Le credential stuffing est également efficace lorsque les administrateurs réutilisent des mots de passe provenant d’autres systèmes. Une fois authentifié, l’attaquant peut disposer d’un accès bien plus large que celui requis par l’application d’origine.
Il peut en résulter une extraction discrète de données, des requêtes destructrices, des modifications frauduleuses ou un point d’appui pour un rançongiciel ultérieur. Si les mêmes identifiants sont utilisés par les scripts, les développeurs et les administrateurs, la fuite d’un seul secret peut affecter tous les environnements.
Comment détecter et corriger le problème
Examinez chaque compte de base de données, sa méthode d’authentification, ses informations de dernière utilisation et le rôle qui lui est attribué. Testez l’installation à partir d’un inventaire des comptes au lieu de supposer que les identifiants par défaut documentés ont été supprimés. Inspectez les fichiers de configuration, les manifestes de déploiement, les variables CI/CD et les scripts à la recherche de mots de passe intégrés.
Désactivez les comptes fournisseurs inutilisés, renommez ou verrouillez les comptes d’urgence lorsque cela est pertinent et imposez des identifiants longs et uniques pour les comptes qui doivent rester actifs. Privilégiez une authentification gérée de manière centralisée, l’authentification multifacteur pour les administrateurs humains et des identifiants à durée de vie courte pour l’automatisation lorsque la plateforme le permet. Stockez les secrets dans un gestionnaire dédié plutôt que dans le code source, les tickets, les feuilles de calcul ou l’historique du shell. Faites tourner les identifiants après les changements de personnel, en cas d’exposition présumée et lors des changements majeurs du système.
Les journaux d’authentification doivent enregistrer les connexions réussies et échouées, les adresses sources et le compte utilisé. Déclenchez des alertes en cas d’échecs répétés, de connexions à des heures inhabituelles, d’accès depuis des réseaux inattendus ou de création de nouveaux comptes privilégiés.
3. Autoriser un accès réseau sans restriction
Lier une base de données à une interface privée ne suffit pas si le réseau autorise chaque hôte interne, utilisateur VPN ou workload cloud à se connecter. Une règle large comme « autoriser tout le réseau du bureau » ou « autoriser tout le trafic du cloud privé virtuel » survit souvent longtemps après la disparition du besoin de dépannage initial.
Mode d’attaque et impact pour l’entreprise
Dans ce scénario, l’attaquant compromet d’abord un ordinateur portable, un serveur web, un compte développeur ou un workload sans rapport. L’accès réseau à la base est déjà disponible : il peut donc rechercher le service et l’attaquer sans franchir le périmètre Internet.
Une exposition interne excessive accroît l’ampleur des incidents d’hameçonnage, de malwares et de compromission de la chaîne d’approvisionnement. Elle peut également permettre des mouvements latéraux non autorisés entre les systèmes de production, de préproduction et de développement. Un serveur de test compromis ne devrait pas pouvoir interroger des données clients simplement parce que les deux systèmes partagent une règle réseau trop large.
Comment détecter et corriger le problème
Examinez ensemble les pare-feu des hôtes, les pare-feu réseau, les groupes de sécurité cloud, les politiques réseau Kubernetes et les règles d’accès aux hôtes au niveau de la base. Documentez les serveurs applicatifs, outils de reporting, services de sauvegarde et hôtes bastions d’administration qui ont réellement besoin de connexions. Comparez cette liste aux connexions actives et aux règles de pare-feu.
Remplacez les plages sources trop larges par des listes blanches d’adresses IP explicites ou des groupes de sécurité. N’autorisez que le port et le protocole de destination nécessaires. Refusez le trafic par défaut, séparez les réseaux de production et de non-production et supprimez les règles temporaires en leur attribuant un responsable et une date d’expiration. Si le personnel se connecte à distance, faites passer la maintenance par un VPN ou un bastion plutôt que d’autoriser directement toutes les adresses IP domestiques ou mobiles.
Réexaminez les règles après les migrations et les changements du réseau de bureaux. Une revue trimestrielle des accès est utile, mais les changements à haut risque doivent être vérifiés immédiatement. Une règle de pare-feu sans responsable métier identifié est candidate à la suppression.
4. Transmettre les données de la base sans TLS
Une base de données peut être protégée au repos tout en exposant des identifiants et des données sensibles pendant leur transmission entre une application, un poste d’administrateur, un outil de reporting ou un partenaire de réplication. Les connexions non chiffrées sont particulièrement dangereuses sur les réseaux partagés, les segments cloud, le Wi-Fi et les chemins de maintenance distants.
Mode d’attaque et impact pour l’entreprise
Un attaquant ayant accès au réseau capture le trafic ou se positionne entre le client et le serveur. Sans TLS, les noms d’utilisateur, mots de passe, requêtes et données renvoyées peuvent être lisibles. Un TLS faible ou non vérifié peut également permettre une interception, car le client ne confirme pas qu’il communique avec la base légitime.
Les conséquences comprennent le vol d’identifiants, la divulgation de données clients, la manipulation de requêtes et des problèmes de conformité. Les canaux de réplication et de transfert des sauvegardes méritent la même attention que le trafic applicatif normal.
Comment détecter et corriger le problème
Inspectez les chaînes de connexion et les paramètres du serveur afin de confirmer que TLS est obligatoire, et pas seulement disponible. Utilisez la sortie d’état du client de base de données, les journaux d’audit des connexions et une capture de paquets lors d’un test contrôlé pour vérifier le chiffrement. Contrôlez la validité des certificats, la vérification du nom d’hôte, les autorités de certification approuvées, les versions de protocole et le rejet de toute solution de repli en clair.
Installez les certificats selon un processus de renouvellement contrôlé, limitez l’accès aux clés privées et surveillez les dates d’expiration. Configurez les applications pour qu’elles refusent la connexion lorsque la validation du certificat échoue. Mettez à jour les anciens pilotes et bibliothèques incapables de prendre en charge les paramètres TLS actuels. Documentez les connexions chiffrées, y compris celles d’administration, de supervision, de réplication et de traitement ETL.
TLS protège les données en transit ; il ne décide pas qui doit être autorisé à les interroger. Associez-le à des restrictions réseau, une authentification forte et le principe du moindre privilège.
5. Accorder trop de privilèges dans la base de données
Les applications sont souvent configurées avec un compte administrateur ou propriétaire parce que cela facilite l’installation. Les développeurs peuvent aussi donner aux utilisateurs du reporting un accès en écriture ou accorder à un compte de service des autorisations sur chaque schéma « pour les besoins futurs ». Cela viole le principe du moindre privilège et transforme une compromission limitée en incident touchant toute la base.
Mode d’attaque et impact pour l’entreprise
Une faille d’injection SQL, un secret applicatif volé ou un outil de reporting compromis donne à l’attaquant les autorisations de ce compte. S’il possède les tables, peut créer des utilisateurs ou exécuter des fonctions du système d’exploitation, l’attaquant peut extraire toute la base, modifier des enregistrements ou s’échapper vers l’hôte.
Des droits excessifs rendent également les dommages accidentels plus probables. Une migration ou un script défectueux peut supprimer des données de production lorsqu’il s’exécute avec une identité très privilégiée.
Comment détecter et corriger le problème
Inventoriez les utilisateurs, groupes, rôles et autorisations. Recherchez les comptes applicatifs disposant de droits administrateur, l’accès direct à des schémas sans rapport, l’accès en lecture sans restriction aux tables sensibles et les permissions qui n’ont jamais été utilisées. Examinez les journaux d’audit de la base pour comparer les privilèges attribués à l’activité réelle.
Créez des identités distinctes pour chaque application, environnement et fonction. Accordez uniquement l’accès aux tables, vues, procédures et opérations nécessaires. Utilisez des rôles en lecture seule pour le reporting, séparez les identifiants de migration des identifiants d’exécution normaux et limitez l’accès aux données personnelles, financières ou d’authentification. Révoquez les permissions héritées inutiles et supprimez les comptes dormants.
L’accès à la production ne doit pas être la configuration par défaut pour les développeurs ou les agences qui prennent en charge plusieurs clients. Utilisez des comptes administrateur nominatifs, une validation pour les accès élevés, des permissions limitées dans le temps et une procédure de maintenance documentée. Les identifiants administrateur partagés empêchent une attribution fiable et compliquent la révocation rapide.
6. Exposer les ports et outils d’administration
Les interfaces d’administration de bases de données, les services de bureau à distance, SSH, les consoles web et les API de gestion sont des cibles fréquentes. Les exposer à Internet pour des raisons pratiques crée une seconde surface d’attaque, même lorsque l’écouteur de la base lui-même est restreint.
Mode d’attaque et impact pour l’entreprise
Les attaquants analysent les ports de gestion courants, identifient les services et tentent des attaques par mot de passe, utilisent des identifiants volés ou exploitent des vulnérabilités connues. Un service d’administration compromis peut fournir un contrôle direct du système d’exploitation, un accès à la configuration ou la possibilité de désactiver les journaux et de supprimer des données.
Pour une petite entreprise, un seul port de gestion à distance exposé peut transformer un incident de base de données en prise de contrôle complète du serveur. Pour une agence, une méthode de gestion partagée peut mettre plusieurs environnements clients en danger si les limites d’accès sont faibles.
Comment détecter et corriger le problème
Effectuez une analyse externe des adresses de votre organisation et une analyse interne depuis des segments réseau non fiables. Examinez les ports en écoute avec les outils de l’hôte et comparez-les à la politique du pare-feu. Vérifiez dans les consoles cloud les affectations d’adresses IP publiques, les écouteurs des équilibreurs de charge et les groupes de sécurité trop permissifs. Surveillez les journaux à la recherche de connexions d’administration, d’échecs d’authentification, de nouvelles sessions et de changements de configuration.
Fermez les services inutilisés. Maintenez SSH, le bureau à distance et les consoles de bases de données hors des interfaces publiques. Exigez un VPN, un bastion ou une passerelle d’accès zero trust avec authentification multifacteur, contrôle des appareils et comptes individuels. Limitez si possible l’accès administratif par adresse IP source, désactivez les connexions directes root ou administrateur partagé et enregistrez les commandes ou l’activité de session pour les opérations sensibles.
Séparez l’accès de production de l’accès de maintenance. L’application doit utiliser une voie étroitement privilégiée, tandis que les administrateurs utilisent une autre voie contrôlée, activée uniquement lorsque nécessaire. N’accordez pas à une agence externe un accès permanent et sans restriction lorsqu’une fenêtre de maintenance approuvée et journalisée suffit.
7. Retarder les correctifs et la remédiation des vulnérabilités
Les moteurs de bases de données, systèmes d’exploitation, pilotes, extensions et outils de gestion contiennent tous des vulnérabilités. Un système peut rester exposé même lorsque son code applicatif est bien maintenu si la version de la base sous-jacente n’est plus prise en charge ou si une mise à jour de sécurité critique est reportée indéfiniment.
Mode d’attaque et impact pour l’entreprise
Les attaquants identifient la version de la base grâce aux services exposés, aux messages d’erreur, à des données d’inventaire volées ou à des systèmes internes compromis. Ils utilisent ensuite un exploit public, une extension vulnérable ou une faiblesse de la couche d’administration. Certaines attaques nécessitent une authentification, d’autres non.
Une exploitation réussie peut divulguer ou modifier des données, créer un compte privilégié, exécuter du code ou perturber la disponibilité. Le retard des correctifs accroît également la complexité de la reprise, car les changements d’urgence sont effectués sous pression et sans tests suffisants.
Comment détecter et corriger le problème
Désignez clairement un responsable pour le système d’exploitation, le moteur de base de données, les extensions, les pilotes et les outils de sécurité. Tenez un inventaire comprenant les versions, l’état de prise en charge, l’exposition, le responsable métier et la fenêtre de maintenance. Abonnez-vous aux avis de sécurité des fournisseurs et utilisez l’analyse des vulnérabilités, mais validez les résultats des scanners par rapport aux versions et à la configuration réellement installées.
Définissez des délais fondés sur le risque pour les vulnérabilités critiques, testez les mises à jour sur un système de préproduction représentatif et préparez un plan de retour arrière. Appliquez rapidement les mises à jour de sécurité, supprimez les composants non pris en charge et documentez les exceptions acceptées avec une date d’expiration. Déclenchez une alerte lorsque la conformité aux correctifs passe sous le seuil défini par l’organisation. L’application d’un correctif n’est terminée que lorsque les services redémarrent correctement et que la supervision confirme un fonctionnement normal.
Détecter une base exposée avant l’attaquant
Commencez par cette question : un appareil non fiable peut-il atteindre la base de données ou son interface d’administration ? Effectuez des tests depuis Internet et depuis les réseaux internes qui ne devraient pas y avoir accès. Vérifiez les enregistrements DNS, les adresses IPv4 et IPv6, les pare-feu cloud, les pare-feu des hôtes et les équilibreurs de charge. Un service sécurisé en IPv4 peut rester exposé en IPv6.
Vérifiez ensuite ce qui se passe après l’établissement d’une connexion. Le serveur exige-t-il TLS ? L’authentification rejette-t-elle les identifiants par défaut et les mots de passe faibles ? Un compte applicatif peut-il lire ou modifier des tables qui ne relèvent pas de son rôle ? Les connexions échouées, changements de privilèges, modifications de schéma et exportations inhabituelles sont-ils journalisés de manière centralisée ?
Les journaux ne sont utiles que si une personne ou un système les examine. Envoyez les journaux de la base de données, du système d’exploitation et du pare-feu vers un système central protégé qu’un attaquant ne peut pas modifier discrètement. Créez des alertes pour les échecs répétés d’authentification, les nouveaux utilisateurs privilégiés, les accès depuis de nouveaux pays ou réseaux, les exportations volumineuses, la désactivation de l’audit, un volume de requêtes inhabituel et les redémarrages inattendus de services. Ajustez les alertes afin que les équipes puissent réagir au lieu d’ignorer un bruit constant.
Se préparer à une compromission avec des sauvegardes indépendantes
Une configuration sécurisée réduit le risque de compromission, mais elle ne peut pas garantir qu’un compte, une application ou un poste d’administrateur ne sera jamais compromis. La planification de la reprise doit partir du principe qu’un attaquant pourrait prendre le contrôle du serveur de production et tenter de chiffrer, corrompre ou supprimer les données ainsi que les sauvegardes locales.
Conservez des sauvegardes testées, chiffrées et hors site que le serveur compromis ne peut pas supprimer. Safenix propose une sauvegarde hors site pour les serveurs professionnels, avec des données stockées en Allemagne, immuables pendant toute la durée de rétention et chiffrées à l’aide d’une clé contrôlée par le client que Safenix ne détient jamais. Découvrez-en plus sur les sauvegardes chiffrées hors site avec des clés contrôlées par le client et un accès réduit depuis un serveur compromis.
La conception des sauvegardes doit correspondre aux systèmes contrôlés par le client, notamment le serveur de base de données et son infrastructure de support. Il ne s’agit pas d’un plan de sauvegarde pour un site web hébergé sur un hébergement mutualisé, et aucun forfait mutualisé ne doit être présumé. Avant de dépendre d’une sauvegarde, confirmez que la base est capturée de manière cohérente, que la durée de rétention répond aux exigences métier, que les clés de chiffrement peuvent être utilisées au moment nécessaire et que des restaurations ont été effectuées avec succès.
L’immuabilité contribue à empêcher la suppression ou la modification pendant la période de rétention, tandis que le stockage hors site protège contre une défaillance ou un incident sur le site de production. Le chiffrement contrôlé par le client signifie que le fournisseur de sauvegarde ne possède pas la clé nécessaire pour lire les données protégées. Ces contrôles réduisent l’impact d’une reprise, mais ils ne réparent pas une base de données non sécurisée. Restaurer un serveur compromis sans corriger son exposition, ses identifiants ou ses correctifs ne fait que recréer l’incident.
Accès à la production et accès de maintenance pour les petites équipes
Les petites entreprises et les agences disposent souvent d’effectifs limités, ce qui rend la séparation particulièrement importante. Gardez la voie applicative normale étroite et prévisible. La maintenance doit utiliser des comptes nominatifs, une route réseau distincte et une élévation limitée dans le temps. Un prestataire de support ne doit recevoir que l’accès nécessaire à la tâche convenue, et non un mot de passe administrateur permanent partagé entre plusieurs clients.
Tenez un registre des accès couvrant les employés, sous-traitants, agences, comptes de service et identifiants d’urgence. Réexaminez-le après les changements de personnel et les transferts de clients. Utilisez un processus sécurisé de gestion des secrets, exigez une validation pour les changements en production et enregistrez l’auteur de chaque modification. Un compte d’urgence peut exister, mais son utilisation doit déclencher une alerte et faire l’objet de tests périodiques.
Checklist de vérification de la protection de la base de données
- Accessibilité publique : Un hôte externe ou interne non fiable peut-il se connecter à la base ou à un port d’administration ? Les environnements IPv4 et IPv6 sont-ils tous deux couverts ?
- Contrôles réseau : Les règles de pare-feu et les listes blanches IP autorisent-elles uniquement les sources applicatives, de reporting et de maintenance identifiées ?
- Authentification : Les comptes par défaut, dormants et partagés ont-ils été supprimés ou contrôlés ? Des identifiants robustes et l’authentification multifacteur sont-ils utilisés pour les administrateurs ?
- Secrets : Les mots de passe et les clés sont-ils absents du code source, des scripts, des tickets et des dépôts de configuration ? La rotation est-elle testée ?
- Moindre privilège : Chaque compte applicatif et humain dispose-t-il uniquement des accès nécessaires, avec des rôles en lecture seule lorsque cela convient ?
- Chiffrement : TLS est-il obligatoire et correctement vérifié pour les connexions applicatives, d’administration, de réplication et de transfert de données ?
- Supervision : Les événements d’authentification, de privilèges, d’exportation de données, de pare-feu et de configuration sont-ils journalisés de manière centralisée avec des alertes exploitables ?
- Responsabilité des correctifs : Qui est responsable de chaque base, système d’exploitation, extension et outil de gestion ? Les vulnérabilités sont-elles suivies jusqu’à leur résolution ?
- Préparation de la restauration : Les sauvegardes sont-elles chiffrées, hors site, immuables pendant la durée de rétention et impossibles à supprimer depuis le serveur de production ? Une restauration complète a-t-elle été testée ?
Ces questions transforment la sécurité des bases de données : elle ne se limite plus à une tâche d’installation ponctuelle, mais devient une discipline opérationnelle. Réexaminez-les après les migrations, les changements majeurs d’application, les mouvements de personnel et les incidents de sécurité. Une base difficile à atteindre, dotée d’autorisations strictes, corrigée et récupérable a beaucoup moins de chances de provoquer un événement mettant fin à l’activité.