- Uber (2022) : l\'attaquant de 18 ans a accédé à des secrets stockés en clair dans des scripts PowerShell internes après avoir contourné le MFA par fatigue. Les données sensibles accessibles étaient en clair — sans chiffrement au niveau des secrets applicatifs, la compromission du compte d\'accès initial se transforme en accès total à l\'infrastructure.
- Le chiffrement au repos est inutile si les clés de déchiffrement sont accessibles depuis le même système compromis — le threat model doit explicitement couvrir le scénario où l\'attaquant a les privilèges suffisants pour accéder aux clés.
- Dans les architectures zero-trust, le chiffrement des données sensibles reste critique même après authentification forte : il limite l\'impact d\'un mouvement latéral en réduisant ce qu\'un attaquant peut exploiter depuis un segment compromis.
- Les données de sauvegarde non chiffrées constituent un vecteur d\'exfiltration systématiquement sous-protégé — elles contiennent souvent les mêmes données sensibles que les systèmes de production avec moins de contrôles d\'accès.
- Le chiffrement E2E (end-to-end) est la seule protection efficace contre les prestataires cloud compromis : si le prestataire ne détient pas les clés, l\'exposition de son infrastructure ne donne pas accès aux données en clair.
- Les logs non chiffrés sont une cible fréquente des attaquants — ils contiennent souvent des credentials, des tokens d\'API et des données personnelles collectées lors des debug sessions.
Le chiffrement est souvent présenté comme une mesure de sécurité parmi d\'autres dans les frameworks de sécurité. Cette caractérisation sous-estime son rôle dans les architectures modernes où le périmètre réseau est perméable et où la compromission d\'un compte privilégié est un scénario que les équipes doivent traiter comme probable plutôt qu\'hypothétique. Dans ce contexte, le chiffrement des données sensibles est effectivement la dernière ligne de défense — la mesure qui détermine si une compromission de périmètre se traduit ou non en exfiltration exploitable.
La distinction critique est entre le chiffrement défensif (protéger contre les accès non autorisés de l\'extérieur) et le chiffrement de résilience (limiter l\'impact d\'une compromission interne). Les équipes qui n\'ont configuré leur chiffrement qu\'en mode défensif découvrent lors des incidents que leurs données sensibles étaient accessibles en clair à quiconque ayant compromis un compte avec les niveaux de privilèges appropriés.
Le threat model du chiffrement comme dernière défense
Le threat model qui justifie le chiffrement comme dernière ligne de défense part du postulat que l\'attaquant a déjà passé les contrôles d\'authentification et d\'autorisation. Ce postulat est réaliste dans plusieurs scénarios documentés : compromission d\'un compte à privilèges par phishing ou MFA fatigue, insider threat, compromission d\'un prestataire avec accès légitime, ou mouvement latéral depuis un système compromis.
Dans ce threat model, le chiffrement est efficace uniquement si les clés de déchiffrement ne sont pas accessibles depuis le même contexte d\'exécution que l\'attaquant. Un chiffrement AES-256 dont la clé est stockée dans le même fichier de configuration que la connexion à la base de données ne résiste pas à une compromission des droits d\'accès au système de fichiers. Le modèle de protection est circulaire : si l\'attaquant peut lire la clé, il peut déchiffrer les données.
La sanction de Morgan Stanley par la SEC en 2022 (35 millions de dollars) pour des serveurs de data centers revendus sans effacement adéquat illustre un scénario où le chiffrement des données au repos aurait été la dernière ligne de défense. Les serveurs contenaient des données clients qui n\'avaient pas été effacées avant la revente. Si ces données avaient été chiffrées avec des clés gérées séparément — dans un HSM ou un service de gestion de clés dont l\'accès avait été révoqué avant la revente des serveurs — l\'exposition des données physiques sur les disques n\'aurait pas constitué une violation exploitable. Morgan Stanley avait des politiques de destruction des données mais pas de chiffrement systématique au repos qui aurait rendu les données inutilisables sans les clés.
Architectures de chiffrement dans un contexte de compromission interne
La conception d\'une architecture de chiffrement résistante à la compromission interne requiert une séparation claire entre les données chiffrées et les mécanismes de déchiffrement. Les pratiques qui réalisent cette séparation incluent : les HSM (Hardware Security Modules) qui exécutent les opérations cryptographiques dans un enclave matériel inaccessible même aux administrateurs système, les KMS (Key Management Services) cloud avec politiques d\'accès finement granulaires qui permettent de limiter les opérations de déchiffrement aux seuls services autorisés, et le chiffrement côté client dans lequel l\'application cliente gère les clés sans les exposer au serveur.
L\'enveloppe cryptographique (key wrapping) permet une hiérarchie de clés qui limite l\'impact d\'une compromission : les data encryption keys (DEK) chiffrent les données, les key encryption keys (KEK) chiffrent les DEK, et les KEK sont protégées dans des environnements à haute sécurité. La compromission d\'un système qui accède aux données chiffrées expose les DEK chiffrées — pas les KEK nécessaires pour les déchiffrer.
Les données de sauvegarde : le vecteur oublié
Les sauvegardes sont une cible fréquente des attaquants précisément parce qu\'elles contiennent les mêmes données sensibles que les systèmes de production avec des contrôles d\'accès souvent moins rigoureux. Les sauvegardes stockées sur des partages réseau accessibles avec les droits d\'administrateur de domaine, ou dans des buckets S3 dont les politiques d\'accès sont moins restrictives que les bases de données de production, constituent un chemin d\'exfiltration que beaucoup d\'organisations n\'ont pas intégré dans leur modèle de chiffrement.
La violation Target de 2013 (40 millions de cartes bancaires via les credentials d\'un prestataire HVAC) illustre le rôle du chiffrement comme dernière défense. Les données de carte bancaire transitaient par les terminaux de point de vente en clair — l\'absence de chiffrement end-to-end (P2PE — Point-to-Point Encryption) entre les terminaux et le processeur de paiement a permis à un RAM scraper installé sur les terminaux de capturer les données en clair pendant les transactions. Si un chiffrement P2PE avait été déployé, les données capturées par le RAM scraper auraient été du ciphertext inutilisable. Target a par la suite investi dans la technologie P2PE et les cartes à puce EMV, réduisant structurellement ce vecteur d\'attaque.
La violation British Airways de 2018 (500 000 clients, données de paiement compromises via script malveillant sur le site de réservation) illustre un scénario de formjacking où le chiffrement TLS du transport ne protège pas contre l\'injection d\'un script qui capture les données avant leur chiffrement. L\'attaquant (groupe Magecart) avait injecté du JavaScript dans le processus de paiement qui envoyait les données de carte en clair vers un serveur externe. La protection pertinente ici n\'était pas le chiffrement des données stockées mais la protection de l\'intégrité des scripts de paiement — via Subresource Integrity (SRI), Content Security Policy (CSP) et monitoring des modifications de scripts tiers.
La violation Cathay Pacific de 2018 (9,4 millions de passagers, présence de l\'attaquant pendant deux mois) a exposé des données de passeports et des informations de cartes bancaires. L\'enquête post-incident a révélé que certaines données n\'étaient pas chiffrées au repos dans les bases de données affectées. Dans un contexte où l\'attaquant disposait d\'un accès persistant aux systèmes pendant deux mois, l\'absence de chiffrement au niveau des champs sensibles dans les bases de données a permis une exfiltration complète. Le chiffrement au niveau des colonnes (column-level encryption) pour les catégories de données les plus sensibles — données de passeport, données de paiement — aurait limité l\'exploitabilité des données même en cas d\'accès aux tables.