Pourquoi les fuites de données persistent malgré la sécurité

Éditorial

Enquête sur les causes techniques, organisationnelles et économiques des fuites de données massives malgré des décennies d’investissement en sécurité.

~11 min de lecture8 sections

Pourquoi les fuites de données persistent malgré la sécurité

Les fuites massives ne persistent pas parce que le chiffrement serait faible ou parce que les équipes ignoreraient les règles de base. Elles persistent parce que la prévention coûte maintenant, ralentit certains usages, et se mesure mal, tandis que le coût réel d’une fuite est souvent différé, mutualisé ou reporté sur les personnes concernées.

Explication de la marmotte

Protéger des informations sensibles ressemble à fermer une réserve remplie de dossiers : la serrure compte, mais aussi le nombre de personnes qui possèdent une clé, les copies laissées dans d’autres pièces et la capacité à savoir qui est entré. Une fuite survient quand l’ensemble est traité comme une seule serrure.

→ Lire l’explication complète de la marmotte

Le compromis central : réduire l’exposition ou préserver la friction zéro

La cause principale est un compromis assumé trop rarement : réduire la surface d’exposition diminue la disponibilité immédiate, l’autonomie locale et la vitesse de livraison. Conserver ces trois propriétés augmente mécaniquement le nombre de copies, d’identités, d’interfaces et de chemins d’exfiltration. Il faut trancher : pour les données à impact élevé, la minimisation de l’exposition prime sur la fluidité opérationnelle.

Le marché récompense souvent l’ajout de fonctionnalités, pas la suppression de données. Une donnée collectée peut servir à l’analyse, à la personnalisation, au support ou à un futur produit encore à l’état de slide. Sa conservation crée pourtant une dette : chaque index, export, sauvegarde, environnement de test et intégration partenaire devient un objet à protéger ou à détruire correctement.

Le coût de prévention est visible dans un budget et dans une feuille de route. Le coût d’une fuite est incertain, parfois assuré, parfois absorbé par les personnes exposées, parfois réduit à une ligne de communication de crise. Cette asymétrie d’incitation explique davantage de fuites que l’absence de produits de sécurité. Un tableau de bord rassurant ne change rien à une base contenant dix ans d’historique sans justification actuelle.

La recommandation est donc brutale : attribuer un propriétaire métier à chaque catégorie de données, une finalité, une durée de conservation et une décision d’effacement vérifiable. Sans ces quatre éléments, chiffrer la donnée revient à emballer un entrepôt inutile dans du papier cadeau cryptographique.

Cette position ne vaut pas pour toute information. Les journaux de sécurité, les preuves comptables ou les données nécessaires à la reprise exigent parfois une rétention longue. Le choix dépend alors du coût d’une indisponibilité, de la fraude détectable grâce à l’historique et des obligations applicables. La réponse ne consiste jamais à conserver par défaut, ce réflexe ayant la robustesse intellectuelle d’un aquarium sur une moto.

Surface d’attaque : identités, copies et chemins d’exfiltration

Une fuite commence rarement par le déchiffrement d’un disque. Elle passe plus souvent par une identité légitime compromise, une autorisation excessive, une interface de programmation applicative exposée, un export oublié ou une sauvegarde accessible depuis le même plan d’administration que la production.

La première contre-mesure est l’inventaire des flux, pas l’inventaire des outils. Il faut identifier, pour chaque donnée sensible, sa source, ses transformations, ses stockages, ses destinataires, ses sauvegardes et ses sorties réseau. Une classification sans cartographie de flux est une étiquette sur un carton dont personne ne sait où il est entreposé.

L’IAM (Identity and Access Management) doit appliquer le moindre privilège sur des rôles distincts : lecture applicative, administration de schéma, exploitation, extraction analytique et restauration. Un compte capable de lire toutes les données et de modifier les journaux de sécurité concentre la confidentialité et l’impunité. Cette combinaison doit être interdite par conception.

Les attaques connues suivent des chemins prévisibles :

• Le hameçonnage vole une session ou un secret. Imposer une authentification multifacteur résistante au hameçonnage, limiter la durée des sessions et contrôler le contexte d’accès réduisent l’impact. L’authentification multifacteur ne corrige pas une autorisation trop large.
• L’injection SQL (Structured Query Language) transforme une entrée applicative en requête arbitraire. Utiliser des requêtes paramétrées, supprimer les privilèges de modification du compte applicatif et journaliser les requêtes anormales sont des contrôles complémentaires.
• L’exposition d’un stockage objet ou d’une sauvegarde contourne l’application entière. Bloquer l’accès public au niveau de l’organisation, imposer des politiques de ressource explicites et tester les restaurations sous identité séparée évitent la fuite par le chemin de traverse.
• L’exfiltration par interface de programmation applicative exploite des pages trop larges, des filtres contournables ou des jetons d’accès réutilisables. Borner les résultats, limiter le débit, exiger une autorisation au niveau de chaque objet et détecter les volumes inhabituels ferment ce robinet.

Les pages Identités et Réseaux complètent ce sujet : l’autorisation applicative et la sortie réseau doivent être contrôlées ensemble. Filtrer l’egress sans surveiller les comptes de service laisse une porte entrouverte. Surveiller les comptes sans limiter l’egress laisse une porte avec une caméra.

Chiffrement et contrôle d’accès : garanties réelles, garanties fantasmées

Le chiffrement protège une donnée au repos ou en transit contre un accès qui ne possède pas la clé. Il ne protège pas contre l’application autorisée qui lit puis exporte la donnée, contre un administrateur ayant accès à la clé et au contenu, ni contre une copie déchiffrée dans un environnement analytique.

L’enveloppe cryptographique sépare la DEK (Data Encryption Key), qui chiffre une donnée ou un lot, de la KEK (Key Encryption Key), qui protège la DEK. La KEK doit résider dans un service de gestion de clés ou dans un HSM (Hardware Security Module) lorsque l’extraction de clé constitue un risque majeur. Cette architecture réduit l’exposition d’une clé racine, mais ne remplace pas l’autorisation applicative.

Un HSM ne détecte ni une requête légitime mais malveillante, ni une extraction autorisée par un rôle surdimensionné. Il rend certaines opérations de clé non exportables et auditables. C’est beaucoup, mais ce n’est pas un exorcisme pour architecture permissive.

Le contrôle d’accès doit être placé au plus près de la donnée. Une passerelle applicative peut filtrer des routes, mais elle ne doit pas être l’unique frontière si plusieurs services accèdent au même stockage. Les politiques de lignes, de colonnes ou d’objets évitent qu’une erreur dans une couche transforme une lecture ciblée en export global.

La révocation mérite un traitement précis. Désactiver une identité ne retire pas automatiquement les données déjà téléchargées, les exports asynchrones lancés avant la révocation ni les sessions établies selon leur durée de vie. Une réponse à incident doit donc inclure l’invalidation des sessions, la révocation des jetons, la suspension des tâches d’export et l’examen des sorties réalisées avant détection.

Exemple reproductible : limiter un export PostgreSQL par rôle

PostgreSQL permet d’appliquer une sécurité au niveau des lignes. Le prérequis est PostgreSQL 14 ou supérieur, une connexion d’administration et une application capable de définir l’identité métier de la session. Le rôle applicatif ne doit jamais posséder les tables, sinon il contourne les politiques.

-- Exécuter avec un rôle d'administration PostgreSQL.
CREATE ROLE app_reader LOGIN PASSWORD 'remplacer-ce-secret';
CREATE TABLE dossier_client (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  tenant_id uuid NOT NULL,
  email text NOT NULL,
  secret_metier text NOT NULL
);

-- Le propriétaire de table ne doit pas être app_reader.
ALTER TABLE dossier_client ENABLE ROW LEVEL SECURITY;
ALTER TABLE dossier_client FORCE ROW LEVEL SECURITY;

-- L'application fixe le tenant après authentification contrôlée.
CREATE POLICY lecture_par_tenant ON dossier_client
  FOR SELECT TO app_reader
  USING (tenant_id = current_setting('app.tenant_id', true)::uuid);

GRANT SELECT (id, email) ON dossier_client TO app_reader;
REVOKE ALL (secret_metier) ON dossier_client FROM app_reader;

-- Test sous le rôle applicatif, avant toute requête métier.
SET ROLE app_reader;
SET app.tenant_id = '11111111-1111-1111-1111-111111111111';
SELECT id, email FROM dossier_client;

Cette politique limite une lecture accidentelle entre locataires, mais elle ne garantit pas que l’application fixe une valeur fiable dans app.tenant_id. Cette valeur doit provenir d’un jeton vérifié côté serveur, jamais d’un en-tête transmis par le client. Il faut aussi tester l’absence de réglage, les requêtes jointes, les exports et les accès d’administration.

Exploitation : rotation, sauvegardes et détection de l’exfiltration

Les secrets de base de données, clés d’interface et certificats doivent être émis pour un usage précis, stockés hors du code source et rotés. Une rotation qui exige un arrêt global est une dette d’architecture : prévoir deux versions actives pendant une période limitée, basculer les consommateurs, puis révoquer l’ancienne.

Les sauvegardes sont le point où les bonnes intentions vont prendre l’air. Elles doivent être chiffrées avec des clés séparées de la production, soumises à une rétention définie et restaurées régulièrement dans un environnement isolé. Une sauvegarde non restaurée n’est pas une stratégie de reprise, c’est une croyance.

La supervision doit corréler identité, objet consulté, volume lu, destination et résultat de l’opération. Un SIEM (Security Information and Event Management) peut agréger ces événements, mais il ne crée pas les journaux absents. Produire un événement d’audit lors d’un export, conserver son identité de déclenchement et rendre l’événement difficile à altérer sont les prérequis.

Les seuils de volume seuls échouent contre l’exfiltration lente. Détecter aussi les accès hors horaires attendus, les changements de périmètre, les requêtes balayant des identifiants séquentiels et les destinations nouvelles. La détection doit déclencher une capacité de suspension immédiate, pas seulement un ticket dont la gravité sera discutée jusqu’à la prochaine lune.

Pour arbitrer ces contrôles, relier les exigences à la gouvernance et aux mécanismes de cryptographie. Le premier sujet attribue la décision et le risque résiduel. Le second borne ce que la clé protège réellement. Confondre les deux produit des politiques pleines de verbes et des incidents pleins de données.

Incitations économiques : rendre le risque non transférable

Une organisation corrige ce qu’elle mesure et ce qu’elle paie. Les indicateurs doivent donc suivre la quantité de données sans finalité active, le nombre d’identités capables d’exporter, les accès dormants, les sauvegardes restaurables et le délai de révocation effectif. Compter seulement les vulnérabilités corrigées mesure l’atelier, pas la fuite.

La responsabilité doit être distribuée sans être diluée : le métier décide de la nécessité de conserver, l’architecture impose les frontières, l’exploitation prouve la restauration et la sécurité vérifie les chemins d’attaque. Aucun comité ne remplace cette répartition. Un comité peut toutefois produire un compte rendu d’une élégance redoutable pendant que l’export reste public.

La priorité est de financer la réduction durable de l’exposition avant d’acheter une couche de détection supplémentaire. La détection reste indispensable, car une compromission est toujours possible. Mais elle ne doit pas devenir l’alibi qui autorise une conservation illimitée et des privilèges massifs. Le compromis est net : moins de données exploitables immédiatement, contre beaucoup moins de données exploitables après compromission. Pour les données sensibles, ce n’est pas un compromis controversé. C’est la seule position défendable.

🐝 Ce qui arrive si on s’en passe

Sans traiter la protection des données comme un ensemble plutôt qu’une serrure unique, les fuites persistent par les chemins que personne ne mesure. Le chiffrement du coffre ne sert à rien si trop d’identités détiennent une clé, si des copies traînent dans d’autres environnements et si nul ne sait qui est entré. L’absence de réduction du nombre d’accès laisse une surface large où une seule compromission suffit. L’absence de journalisation exploitable retire la capacité de savoir qu’une extraction a eu lieu, quand et par qui, ce qui repousse la détection bien après les faits. L’absence d’inventaire des copies transforme chaque duplicata oublié en fuite potentielle. Le coût de cette négligence étant différé et reporté sur les personnes concernées, rien ne le rend visible tant que la donnée n’a pas déjà quitté la réserve.

🦫 Explication de la marmotte 🍫

Une fuite de données arrive lorsqu’une personne ou un programme obtient des informations qu’il ne devrait pas pouvoir lire, copier ou envoyer ailleurs. Cela peut commencer par le vol d’un mot de passe, une erreur dans une application, un accès laissé ouvert ou une sauvegarde mal protégée. Le problème ne vient donc pas toujours d’un pirate qui casse un système de chiffrement.

La protection fonctionne en plusieurs couches. Il faut d’abord décider quelles informations sont réellement nécessaires et supprimer celles qui ne le sont plus. Ensuite, chaque personne et chaque programme reçoit seulement les droits nécessaires à sa tâche. Les informations sensibles peuvent être chiffrées, ce qui les rend illisibles sans une clé secrète. Cette clé doit être protégée séparément des données.

Des journaux enregistrent aussi qui a accédé aux informations, à quel moment et en quelle quantité. Ils servent à repérer un téléchargement inhabituel et à arrêter un accès compromis. Si ces journaux n’existent pas ou peuvent être effacés par la même personne qui lit les données, ils ne permettent plus d’enquêter.

Les sauvegardes doivent recevoir les mêmes protections que les données originales. Sinon, supprimer ou protéger le système principal ne suffit pas. Enfin, la sécurité dépend de décisions économiques : conserver beaucoup d’informations paraît pratique, mais chaque copie supplémentaire augmente ce qui peut être volé.

À lire aussi

• Gouvernance d'un data lake et copie des donnéesGouverner un data lake exige de contrôler les copies, les identités, les métadonnées, les clés et le cycle de vie des données.
• Effacement des données dans une architecture distribuéeLe droit à l'effacement confronte les architectures distribuées aux réplicas, sauvegardes, caches et mécanismes cryptographiques.
• Cycle de vie de la donnée de la collecte à la destruction prouvéeConcevoir le cycle de vie d’une donnée, depuis sa collecte contrôlée jusqu’à sa destruction vérifiable et prouvée.
• Classifier les données avant de les protégerLa classification des données permet de décider quelles protections appliquer, où les appliquer et ce qu’elles ne couvrent pas.

Pages voisines

La citent

• Pourquoi le RGPD produit des rituels de consentement
• Protéger les données au repos : disque, base, sauvegarde

Pourquoi les fuites de données persistent malgré la sécurité

Elle cite

• Assurance cyber couverture et exclusions de contrat
• Installer et sécuriser PostgreSQL auto-hébergé sur Debian
• Prévenir les BOLA dans une API métier