Sécurité des bases de données : menaces, contrôles, bonnes pratiques

Qu'est-ce que la sécurité des bases de données ?

La sécurité des bases de données regroupe les contrôles qui protègent une base de données et ses données contre l'accès non autorisé, la modification, la suppression et le vol. Elle associe des mesures techniques (authentification, chiffrement, isolation réseau), des habitudes d'exploitation (correctifs, audit, sauvegardes testées) et des règles (qui peut voir quelles données et combien de temps elles sont conservées).

Les bases de données sont une cible de choix car elles concentrent au même endroit ce que cherchent les attaquants : fiches clients, identifiants et données liées aux paiements. Ces mêmes contrôles protègent aussi des erreurs de bonne foi, comme un développeur qui lance une suppression sur la production.

Menaces courantes

Les contrôles essentiels

Authentification

Donnez à chaque personne et à chaque service son propre compte, sans identifiants partagés. Quand votre plateforme le permet, préférez des identifiants éphémères liés à l'identité plutôt que des mots de passe durables. C'est la même discipline que la gestion des identités et des accès (IAM) pour le reste de votre infrastructure.

Autorisation et moindre privilège

Chaque compte reçoit uniquement les droits dont il a besoin. Le compte applicatif ne doit ni posséder le schéma ni exécuter de commandes d'administration, et les administrateurs utilisent des comptes distincts. Une liste de permissions par rôle est une forme de liste de contrôle d'accès (ACL).

Chiffrement en transit et au repos

Exigez TLS pour toutes les connexions et refusez celles en clair. Chiffrez le stockage et les sauvegardes pour qu'un disque ou un instantané volé soit inutilisable seul. Chiffrez à part les champs particulièrement sensibles si l'opérateur de la base ne doit pas les voir.

Isolation réseau

Gardez la base dans un réseau privé. Les applications y accèdent par des routes privées et les administrateurs par VPN ou bastion. Limitez les sources acceptées par le pare-feu ou le groupe de sécurité.

Audit, correctifs et sauvegardes

Journalisez les changements de privilèges, de schéma et les exports massifs, et alertez sur les cas inhabituels. Appliquez régulièrement les correctifs de la base et du système. Faites des sauvegardes chiffrées, conservez-en une copie dans un autre compte ou une autre région et testez la restauration : une sauvegarde jamais restaurée n'est qu'une hypothèse.

Injection SQL : la défaillance classique

L'injection SQL survient quand l'entrée utilisateur est intégrée à la chaîne d'une requête. Le guide OWASP SQL Injection Prevention Cheat Sheet cite les requêtes préparées (requêtes paramétrées) comme défense principale, avec une validation par liste autorisée pour les éléments non liables, comme les noms de table ou l'ordre de tri, et prévient que l'échappement est fragile. Il précise aussi que les comptes applicatifs ne doivent jamais avoir un accès DBA ou administrateur.

# Vulnérable : l'entrée est concaténée dans la requête
query = f"SELECT * FROM users WHERE email = '{user_input}'"
cursor.execute(query)

# Sûr : le pilote envoie la valeur séparément du SQL
cursor.execute("SELECT * FROM users WHERE email = %s", (user_input,))

Les ORM paramètrent par défaut, mais leurs échappatoires pour requêtes brutes sont une façon courante de réintroduire l'injection. Consultez l'aide-mémoire OWASP (en anglais) pour la liste complète. L'injection atteint la base par votre API : la sécurité de l'API fait donc partie de la sécurité de la base.

Gérer les données sensibles

• Mots de passe : stockez un hachage lent et salé (bcrypt, scrypt ou Argon2), jamais le mot de passe ni un chiffrement réversible.
• Données personnelles et de paiement : chiffrez au niveau de la colonne ou de l'application, ou tokenisez pour que la vraie valeur vive dans un coffre dédié.
• Données de test et de développement : masquez-les ou générez-les de façon synthétique plutôt que de copier la production.
• Données multi-locataires : utilisez la sécurité au niveau des lignes quand le moteur la propose. Dans PostgreSQL, une table dont la sécurité des lignes est activée sans politique n'affiche aucune ligne aux utilisateurs ordinaires, mais les propriétaires de la table et les superutilisateurs la contournent sauf si vous le forcez.

La conformité en un paragraphe

Des cadres comme le RGPD, HIPAA, PCI DSS et SOC 2 demandent chacun contrôle d'accès, chiffrement, journalisation et gestion des incidents autour des données concernées. Selon l'article 33 du RGPD, une violation de données à caractère personnel doit être notifiée à l'autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance. Confirmez avec vos conseillers en conformité quelles règles s'appliquent à vous.

Erreurs courantes

• Connecter l'application en administrateur parce que cela simplifie la mise en place.
• Copier les données de production vers le staging sans les masquer.
• Ne jamais tester une restauration.
• Laisser des identifiants dans le code, les logs de CI ou les images de conteneur au lieu d'un gestionnaire de secrets.
• Croire que le chiffrement suffit. Il n'arrête ni l'injection ni un mot de passe applicatif volé.

Sécurité des bases, tests de charge et monitoring

LoadFocus ne recherche pas les vulnérabilités, mais le travail sur la performance touche les mêmes systèmes. Un test de charge montre comment votre base se comporte quand les utilisateurs simultanés augmentent, par exemple quand les requêtes lentes s'accumulent ou que le pool de connexions s'épuise (voir how to optimize database connection pools, en anglais). Si vous le lancez contre un environnement de staging, utilisez des données masquées ou synthétiques, comme l'explique cloud testing security best practices (en anglais). Le monitoring d'API vérifie vos endpoints adossés à une base de données de façon planifiée : un endpoint lent ou en panne déclenche une alerte au lieu d'attendre le signalement d'un client.

Questions fréquentes : sécurité des bases de données

Comment éviter l'injection SQL ?

Utilisez des requêtes paramétrées ou préparées pour toute requête contenant une entrée utilisateur, validez par liste autorisée les identifiants non liables et connectez-vous avec un compte qui n'a que les droits nécessaires.

Faut-il chiffrer dans l'application ou dans la base ?

Le chiffrement dans la base est plus simple à exploiter, mais la base peut lire les données en clair. Le chiffrement dans l'application éloigne les clés de la base, au prix d'une recherche et d'un tri plus difficiles. Les champs très sensibles justifient souvent les deux.

Quelle différence entre chiffrement au repos et en transit ?

Au repos protège les données stockées, comme les disques et les sauvegardes. En transit protège les données sur le réseau entre l'application et la base. Il faut les deux.

Puis-je exposer ma base de données sur Internet ?

Presque jamais. Gardez-la dans un réseau privé et n'autorisez que vos serveurs applicatifs et un accès d'administration contrôlé.

Qu'est-ce que la sécurité au niveau des lignes ?

Une fonction de la base qui filtre, selon des politiques que vous définissez, les lignes qu'un utilisateur peut lire ou modifier. Utile pour les applications multi-locataires comme seconde ligne de défense derrière les contrôles applicatifs.

Comment repérer une intrusion dans la base ?

Journaux d'audit et alertes sur les comportements inhabituels : exports massifs, requêtes à des heures atypiques, nouveaux comptes privilégiés et changements de schéma hors fenêtre de changement planifiée.