Aucune mesure de sécurité ne suffit à elle seule pour protéger un système de base de données. Les pare-feu peuvent être mal configurés. Les identifiants peuvent faire l'objet d'hameçonnage. Des vulnérabilités logicielles sont découvertes dans des produits auparavant considérés comme sécurisés. Une stratégie de défense en profondeur tient compte de cette réalité en mettant en place plusieurs couches de protection qui se chevauchent. Ainsi, si une couche est défaillante, les autres prennent le relais pour limiter les dégâts. Pour les infrastructures de base de données en particulier, cette approche n'est pas seulement une bonne pratique, elle devient de plus en plus une exigence de conformité dans les secteurs réglementés.
Commencer par le périmètre du réseau
La couche la plus externe d'une stratégie de sécurité des bases de données consiste en un contrôle au niveau du réseau : il s'agit avant tout de s'assurer que seuls les systèmes autorisés puissent accéder à vos serveurs de bases de données. Cela implique de placer les serveurs de bases de données sur des segments de réseau privés qui ne sont pas directement accessibles depuis l'Internet public, d'utiliser des pare-feu pour limiter les connexions entrantes à des plages d'adresses IP connues, et d'exiger que les accès à distance passent par un VPN ou un hôte bastion plutôt que par une connexion directe.
La segmentation du réseau est particulièrement importante dans les environnements où plusieurs applications partagent la même infrastructure. Un serveur de base de données hébergeant des données clients sensibles ne doit pas être accessible depuis tous les systèmes de l'organisation, mais uniquement depuis les serveurs d'applications et les outils d'administration spécifiques qui ont besoin de s'y connecter. Limiter la surface d'attaque au niveau du réseau limite considérablement l'impact d'un système compromis ailleurs dans l'environnement.
Chiffrer les données en transit et au repos
Le chiffrement est la couche qui protège vos données même en cas de défaillance des autres mesures de sécurité. Les données en transit (requêtes, résultats et identifiants échangés entre les clients et les serveurs de bases de données) doivent impérativement être chiffrées à l'aide du protocole TLS (Transport Layer Security). Sans cela, toute personne connectée au même réseau peut intercepter et lire ce trafic, y compris les identifiants de connexion. Les données au repos — les fichiers proprement dits stockés sur disque, y compris les sauvegardes — doivent être chiffrées afin que l'accès physique aux supports de stockage n'entraîne pas la divulgation des données.
Il est essentiel de bien choisir son algorithme de chiffrement, et pas seulement d'activer le chiffrement. Les suites de chiffrement plus anciennes présentent des faiblesses connues. Configurer vos systèmes pour utiliser des algorithmes modernes et robustes, tels que les suites basées sur AES-256-GCM ou ChaCha20-Poly1305, offre une protection nettement supérieure à celle fournie par les paramètres par défaut.
Mettre en place une authentification forte
Les mots de passe seuls constituent un mécanisme d'authentification fragile, car ils peuvent être devinés, réutilisés sur différents services, obtenus par hameçonnage ou divulgués lors de violations de données chez des tiers. Une couche d'authentification robuste commence par l'application de politiques de mots de passe fortes (longueur minimale, exigences de complexité et rotation régulière pour les comptes à privilèges) et s'étend à l'authentification multifacteur chaque fois que cela est possible, en exigeant une deuxième étape de vérification même lorsque le mot de passe est correct.
Dans les environnements d’entreprise, l’intégration de l’authentification des outils de bases de données avec un fournisseur d’identité central — tel qu’un annuaire LDAP ou Active Directory — ajoute un niveau de gouvernance essentiel. Lorsque les comptes utilisateurs sont gérés de manière centralisée, l’accès d’un employé quittant l’organisation peut être révoqué en un seul endroit, plutôt que de devoir être supprimé individuellement sur chaque système auquel il avait accès.
Appliquer rigoureusement le contrôle d'accès basé sur les rôles
L'authentification détermine qui peut accéder au système. Le contrôle d'accès, quant à lui, détermine les actions possibles une fois connecté. Le contrôle d'accès basé sur les rôles (RBAC), c'est-à-dire l'attribution de droits à des rôles plutôt qu'à des individus directement, est l'approche standard pour gérer les privilèges de base de données à grande échelle. Le principe directeur est celui du privilège minimal : chaque utilisateur et chaque compte d'application ne doit disposer que des autorisations strictement nécessaires à l'accomplissement de sa fonction, et rien de plus.
En pratique, cela signifie éviter le raccourci, malheureusement courant, consistant à accorder des privilèges administratifs étendus par simple commodité. Les comptes de service des applications ne doivent disposer d'un accès en lecture/écriture qu'aux schémas et tables spécifiques qu'ils utilisent réellement. Les analystes en lecture seule doivent disposer de privilèges SELECT, mais pas de la possibilité de modifier ou de supprimer des données. Les comptes d'administration disposant de privilèges élevés ne doivent être utilisés que lorsque ces privilèges sont réellement nécessaires, et non comme comptes de travail courants.
Surveillance, audit et alerte
Les couches décrites jusqu'à présent visent toutes à empêcher les accès non autorisés. Cette couche a pour but de détecter ces accès lorsque la prévention échoue — car, tôt ou tard, cela arrivera. Une journalisation d’audit complète de l’activité de la base de données (qui s’est connecté, quand, depuis où, et quelles requêtes ont été exécutées) fournit la trace nécessaire pour enquêter sur les incidents et démontrer la conformité. Une surveillance en temps réel, avec des alertes en cas de comportement anormal — volume inhabituel de requêtes, connexion en dehors des heures de travail, augmentation soudaine des exportations de données — permet d’identifier une menace active avant que des dommages importants ne soient causés.
Les journaux d'audit n'ont de valeur que s'ils sont stockés dans un emplacement inaccessible à un serveur de base de données compromis. Enregistrer les journaux sur le même système que celui surveillé signifie qu'un attaquant qui compromet ce système peut également falsifier les journaux. Transférer les journaux vers un système distinct, dont l'accès est contrôlé, est une mesure simple mais souvent négligée.
Navicat On-Prem Server 3.1 et la défense en profondeur
Les plateformes de collaboration de bases de données font partie intégrante de votre périmètre de sécurité et ne doivent pas être considérées comme des éléments distincts. C'est pourquoi Navicat On-Prem Server 3.1 intègre plusieurs des couches de défense en profondeur décrites précédemment.
Au niveau de la couche de transport, Navicat On-Prem Server prend en charge SSL/TLS pour chiffrer les connexions entre le serveur et ses clients, et permet aux administrateurs de spécifier les suites de chiffrement utilisées. Une gamme de chiffrements modernes et robustes est prise en charge, offrant aux administrateurs un contrôle réel sur la qualité du chiffrement, plutôt que de simplement accepter les paramètres par défaut.
Au niveau de la couche d'authentification, la plateforme prend en charge la vérification en deux étapes pour les comptes utilisateurs, avec des options incluant une application d'authentification, un SMS ou un e-mail comme deuxième facteur. Pour les organisations qui gèrent les utilisateurs de manière centralisée, Navicat On-Prem Server prend également en charge l'authentification via LDAP et Active Directory, ce qui permet de relier directement l'accès utilisateur à l'infrastructure d'identité existante de l'organisation. Les exigences en matière de complexité des mots de passe sont configurables par les administrateurs, ce qui permet d'aligner les politiques sur les normes de sécurité plus larges de l'organisation.
Au niveau du contrôle d'accès, la plateforme propose des autorisations de projet basées sur les rôles — un système à trois niveaux comprenant les niveaux « Peut gérer et modifier », « Peut modifier » et « Peut consulter » — qui permet aux administrateurs de limiter l'accès de chaque membre de l'équipe aux objets de la base de données partagée à ce qui est strictement nécessaire pour l'exercice de son rôle. Étant donné que le serveur est hébergé sur l’infrastructure propre de l’organisation, et non sur un service cloud tiers, l’ensemble de cette configuration de sécurité reste sous le contrôle direct de l’organisation, sans qu’aucune partie externe n’ait accès aux données ni aux paramètres qui les régissent.
Conclusion
Une stratégie de défense en profondeur n’est ni un produit que l’on achète ni une simple liste de vérification que l’on complète une fois pour toutes. C’est une discipline continue : concevoir soigneusement chaque couche, maintenir les configurations à jour à mesure que les menaces évoluent, surveiller activement et réviser régulièrement afin de corriger les dérives qui s’installent inévitablement avec le temps. La valeur de cette approche en couches réside précisément dans le fait qu’elle ne repose pas sur la perfection d’un seul mécanisme de sécurité. Elle repose plutôt sur le fait que l'attaquant doit franchir plusieurs couches indépendantes pour atteindre son objectif. Pour la plupart des environnements de bases de données, concevoir et maintenir ces couches constitue l’un des investissements les plus importants qu’une organisation soucieuse de sa sécurité puisse réaliser.
