Une équipe affirme : « la base de données est chiffrée au repos, donc nous sommes sécurisés ». En tant qu'architecte, quelle est la faille ?
Réponse courte
Le chiffrement au repos ne défend qu'une seule menace — le vol physique ou de disque — et n'apporte rien contre une application compromise, des identifiants volés ou un trafic intercepté, car la base déchiffre de façon transparente pour toute requête autorisée. Une conception saine exige aussi du TLS en transit, une authentification et une autorisation fortes, et une gestion des clés avec séparation des tâches. Doubler le chiffrement au repos ajoute du coût sans changer le modèle de menace, et ne chiffrer que les sauvegardes laisse les données en production et leurs chemins d'accès exposés.
Quand une équipe assimile « chiffré au repos » à « sécurisé », elle confond un contrôle isolé avec une posture de sécurité complète. Le rôle de l'architecte est de relier le contrôle aux menaces qu'il atténue réellement et d'exposer ce qu'il laisse ouvert.
Ce que fait réellement le chiffrement au repos
Le chiffrement au repos — au niveau du disque, du système de fichiers ou via le chiffrement transparent (TDE) — protège les données sur des supports volés ou mis au rebut. Si quelqu'un emporte un disque ou une bande de sauvegarde, les octets sont illisibles. C'est une valeur réelle, mais une valeur étroite.
L'intuition décisive : la base déchiffre les données de façon transparente pour toute connexion autorisée. Une requête SQL de l'application voit du texte clair. Le chiffrement au repos n'apporte donc rien contre les menaces qui dominent les vraies violations.
Les failles qui subsistent
- Compromission applicative. Une injection SQL, une API vulnérable ou un compte de service compromis interroge la base et reçoit du texte clair. Le chiffrement ne s'active jamais.
- Identifiants volés. Des identifiants de base hameçonnés ou fuités permettent à un attaquant de s'authentifier et de tout lire en clair.
- Données en transit. Sans TLS, le trafic entre l'application et la base peut être intercepté ou altéré sur le réseau.
- Gestion des clés. Si les clés sont mal stockées ou co-localisées avec les données, le chiffrement n'est qu'un décor.
Pourquoi les mauvaises réponses sont fausses
« Rien — le chiffrement au repos suffit » est le piège du candidat faible : il accepte un contrôle unique comme réponse complète. « Ajouter une seconde couche de chiffrement au repos » double le coût et la complexité tout en défendant exactement la même menace — du mouvement sans progrès. « Ne chiffrer que les sauvegardes » est encore plus restreint, laissant les données de production et chaque chemin d'accès sans protection.
Ce que sonde l'examinateur
Il veut voir un raisonnement par modèle de menace : quelle menace chaque contrôle traite-t-il, et où sont les risques résiduels ? Un bon architecte répond par la défense en profondeur — TLS en transit, contrôle d'accès au moindre privilège, requêtes paramétrées contre l'injection, et clés gérées dans un KMS/HSM séparé des données — plutôt que de traiter une seule case cochée comme la ligne d'arrivée.
Questions de suivi probables
- Si l'application est compromise, le chiffrement au repos aide-t-il en quoi que ce soit ? Pourquoi ?
- Où stockeriez-vous et feriez-vous tourner les clés de cette base, et qui devrait y avoir accès ?
- Comment protégeriez-vous ces mêmes données en transit entre l'application et la base ?