- Equifax (2017) : 147 millions de numéros de sécurité sociale exfiltrés — le trafic HTTPS interne n\'était pas inspecté, permettant à l\'exfiltration de passer au travers des contrôles de sortie pendant des mois sans détection.
- La première cause de lacunes de chiffrement est la dette technique : des systèmes déployés avant que le chiffrement ne soit une exigence standard, jamais rétrofités en raison du coût ou du risque de régression fonctionnelle.
- La deuxième cause est le shadow IT : des bases de données, des fichiers partagés et des services cloud déployés par les équipes métier en dehors du périmètre de gouvernance IT, donc en dehors du périmètre de chiffrement.
- La troisième cause est l\'exception de performance : le chiffrement est désactivé sur certains flux ou systèmes pour des raisons de latence ou de capacité de traitement, sans réévaluation régulière de la pertinence de l\'exception.
- Les environnements de développement et de test contiennent souvent des données de production non anonymisées et non chiffrées — un vecteur d\'exposition qui échappe aux audits focalisés sur les environnements de production.
- Les logs applicatifs capturent fréquemment des données sensibles (tokens, PII, données de santé) que personne ne cherche à chiffrer parce qu\'ils ne sont pas perçus comme des données.
La question n\'est généralement pas "pourquoi l\'organisation n\'a-t-elle pas de politique de chiffrement" — la plupart des organisations de taille significative en ont une. La question est "pourquoi des données sensibles restent-elles en dehors du périmètre de cette politique". La réponse révèle des mécanismes organisationnels et techniques précis qui s\'accumulent silencieusement jusqu\'à ce qu\'un incident les rende visibles.
Pour un RSSI ou un architecte sécurité, l\'identification des données sensibles non chiffrées est un exercice de découverte continue, pas de validation ponctuelle. Les nouvelles données non chiffrées apparaissent à chaque nouveau service, à chaque nouveau prestataire, à chaque nouvelle intégration. Sans processus systématique d\'inventaire et de classification, les lacunes s\'accumulent plus vite qu\'elles ne sont corrigées.
La dette technique de chiffrement
La dette technique de chiffrement est la catégorie la plus volumineuse dans les organisations établies. Elle comprend des systèmes déployés lorsque le chiffrement au repos n\'était pas une pratique standard — bases de données Oracle ou SQL Server des années 2000, systèmes de fichiers partagés legacy, applications mainframe qui stockent des données en EBCDIC non chiffré. Rétrofiter le chiffrement sur ces systèmes est complexe : il nécessite des arrêts planifiés, des migrations de données, et peut introduire des régressions de performance que les équipes opérationnelles résistent à accepter.
La gestion de cette dette requiert une approche de priorisation explicite : identifier les systèmes legacy qui stockent des données sensibles, évaluer leur exposition dans le threat model actuel, et planifier la remédiation selon une logique de risque — en commençant par les systèmes les plus exposés et les données les plus sensibles, pas nécessairement par les systèmes les plus faciles à traiter.
La violation Capital One de 2019 (100 millions de clients, mauvaise configuration d\'un rôle IAM AWS) a exposé des données stockées dans des buckets S3. L\'investigation post-incident a révélé que certains buckets contenaient des données non chiffrées côté serveur (SSE désactivé) en raison d\'une configuration par défaut qui n\'avait pas été forcée lors de la migration depuis l\'infrastructure on-premise. Les politiques de chiffrement existaient dans la documentation de Capital One mais n\'étaient pas appliquées via des SCP (Service Control Policies) AWS qui auraient rendu techniquement impossible la création de buckets non chiffrés. La lacune entre la politique documentée et l\'application technique est un mécanisme classique de données sensibles non chiffrées.
Le shadow IT comme source de données non chiffrées
Le shadow IT — l\'utilisation de services et d\'outils non approuvés par la DSI — est une source croissante de données sensibles non chiffrées. Les équipes métier qui déploient des tableurs partagés sur des services cloud grand public, des bases de données non gérées sur des VM provisionnées en libre-service, ou des intégrations entre systèmes via des API sans supervision IT créent des périmètres de données qui échappent aux contrôles de chiffrement de l\'organisation.
La détection du shadow IT stockant des données sensibles requiert des outils de découverte qui vont au-delà du périmètre IT traditionnel : analyse du trafic réseau sortant pour identifier les services cloud non approuvés utilisés par les équipes, audit des permissions dans les outils de collaboration (SharePoint, Google Drive, Dropbox) pour identifier les données sensibles mal classifiées, et monitoring des connexions OAuth des applications tierces aux systèmes d\'identité de l\'organisation.
Les environnements de développement : le périmètre oublié
Les environnements de développement et de test sont systématiquement sous-protégés par rapport aux environnements de production. Dans de nombreuses organisations, ils contiennent des dumps de bases de données de production utilisés pour reproduire des bugs — des copies complètes des données clients, parfois sans anonymisation, stockées dans des systèmes avec des contrôles d\'accès beaucoup moins rigoureux que la production. Ces environnements ne sont souvent pas couverts par les politiques de chiffrement de production et ont des journaux d\'accès moins stricts.
La violation Yahoo (3 milliards de comptes) a révélé que les mots de passe d\'une partie des comptes étaient protégés avec MD5, un algorithme de hachage depuis longtemps considéré comme insuffisant pour la protection des mots de passe. MD5 est vulnérable aux attaques rainbow table et brute force accélérées par GPU — en pratique équivalent à des mots de passe en clair pour un attaquant disposant des ressources nécessaires. Yahoo avait des algorithmes de hachage plus robustes (bcrypt) pour certains comptes mais n\'avait pas migré la totalité de sa base. Cette hétérogénéité de protection est typique de la dette technique de chiffrement dans des systèmes qui ont évolué sur plusieurs années.
L\'intégration des systèmes Starwood dans l\'infrastructure Marriott après l\'acquisition de 2016 a révélé des pratiques de chiffrement hétérogènes entre les deux organisations. Les systèmes de réservation Starwood, développés et évoluant depuis des années, avaient des niveaux de chiffrement variables selon les modules — certains chiffrés, d\'autres non, selon les décisions prises au moment du développement de chaque fonctionnalité. Sans audit exhaustif de couverture de chiffrement lors de l\'acquisition, ces lacunes ont perduré jusqu\'à la découverte de la violation. La due diligence sécurité lors des acquisitions doit inclure un audit systématique de couverture de chiffrement des données sensibles.
La violation SingHealth de 2018 (1,5 million de patients) a exposé des données de dossiers médicaux dont certaines n\'étaient pas chiffrées dans la base de données ciblée. L\'enquête du Committee of Inquiry a identifié que les systèmes de gestion des informations de santé avaient des niveaux de protection variables selon leur date de déploiement et leur type de données. Les données les plus sensibles — diagnostics, prescriptions — n\'étaient pas systématiquement chiffrées au niveau des champs dans la base de données, permettant à l\'attaquant de les exfiltrer en texte clair une fois l\'accès à la base obtenu. Le rapport a recommandé un audit exhaustif de couverture de chiffrement pour tous les systèmes de santé et un programme de remédiation priorisé par sensibilité des données.