Et si votre DBA était votre meilleur atout cyber ?

Quand on parle cybersécurité, tout le monde pense firewall, EDR, SOC. Personne ne pense DBA. C'est une erreur. La base de données est la cible numéro un des attaquants — parce que c'est là que sont les données qui ont de la valeur.

L'injection SQL est toujours vivante

En 2025, l'injection SQL reste dans le top 3 des vulnérabilités OWASP. Pourquoi ? Parce que les développeurs font encore confiance aux concaténations de chaînes. Un paramètre non sanitizé, une requête dynamique, et l'attaquant a accès à toute votre base.

Le DBA voit ces requêtes. Il peut identifier les patterns suspects dans les logs. Il peut mettre en place des contraintes qui limitent les dégâts. Mais pour ça, il faut qu'il soit impliqué dans la sécurité — pas juste dans la performance.

Le principe du moindre privilège que personne n'applique

Dans 90% des bases que j'audite, l'application se connecte avec un compte qui a db_owner. C'est-à-dire qu'elle peut tout faire : créer, modifier, supprimer des tables, voire la base entière. Si l'application est compromise, l'attaquant a les clés du royaume.

La règle : l'application ne doit avoir que les droits strictement nécessaires. SELECT sur les tables de lecture. INSERT/UPDATE sur les tables d'écriture. DELETE seulement si nécessaire. Jamais DDL.

TDE et Always Encrypted : les outils que vous n'utilisez pas

Transparent Data Encryption (TDE) chiffre les données au repos. Si quelqu'un vole votre fichier .mdf, il ne peut rien en faire sans la clé. C'est une fonctionnalité native de SQL Server, activable en quelques minutes. Et pourtant, moins de 20% des bases l'utilisent.

Always Encrypted va plus loin : les données sont chiffrées côté application, et la base ne voit que des données chiffrées. Même le DBA ne peut pas lire les données en clair. C'est la protection ultime contre l'insider threat.

Les audit logs que personne ne lit

SQL Server Audit permet de tracer chaque accès aux données sensibles. Qui a lu quoi, quand, depuis quelle IP. C'est obligatoire pour le RGPD et pour la plupart des normes de conformité. Mais configurer l'audit, c'est une chose. Lire les logs, c'en est une autre.

Un bon DBA met en place des alertes sur les patterns suspects : un SELECT * sur la table des clients à 3h du matin, une connexion depuis une IP inhabituelle, un volume de données exporté anormal.

Le DBA dans la réponse à incident

Quand un incident arrive, le DBA est souvent le premier à le détecter — avant le SOC. Une requête anormale, un pic de CPU inexpliqué, une connexion suspecte. Le DBA qui connaît sa base sait immédiatement quand quelque chose ne va pas.

Mais pour ça, il faut que le DBA soit formé à la sécurité. Pas juste à l'optimisation. Pas juste à la haute disponibilité. À la détection d'intrusion, à l'analyse forensique, à la réponse à incident.

Votre DBA n'est pas un gardien de données. C'est votre dernier rempart. Traitez-le comme tel.