DLP prévention des pertes de données : détection et limites

Une DLP (Data Loss Prevention, prévention des pertes de données) repère des données sensibles et surveille ou bloque leur sortie du périmètre de l’organisation. C’est un outil efficace contre l’accident : la pièce jointe envoyée au mauvais destinataire, le fichier client déposé sur un partage personnel. Contre un initié patient et déterminé, c’est surtout un ralentisseur, et la page explique pourquoi.

→ Lire l’explication complète de la marmotte

Ce que fait une DLP : identifier, surveiller, bloquer

Une DLP enchaîne trois opérations. Elle inspecte un contenu en mouvement (courriel, téléversement, copie vers une clé) ou au repos (partage de fichiers, stockage cloud). Elle qualifie ce contenu à l’aide de détecteurs. Elle applique une action : journaliser, avertir l’utilisateur, exiger une justification, chiffrer, mettre en quarantaine ou bloquer.

Le compromis central tient en une phrase. Chaque point de contrôle ajouté et chaque règle rendue bloquante réduisent les fuites accidentelles, et augmentent d’autant trois coûts : la friction métier, le volume d’alertes à trier et l’intrusion dans l’activité des salariés. La position défendue ici est la suivante. On bloque uniquement sur des détecteurs à faible taux de faux positifs, c’est-à-dire les correspondances exactes, les validations mathématiques et les étiquettes posées par un humain. Tout le reste reste en observation ou en avertissement. Une DLP qui bloque sur des expressions régulières nues finit contournée ou désactivée, et en général les deux.

Les points de contrôle d’une DLP, du poste au cloud

Une DLP n’est pas un boîtier unique. C’est un ensemble de capteurs placés sur les chemins de sortie, et chaque capteur ne voit que son chemin :

Poste de travail (agent) : copie vers un périphérique USB (Universal Serial Bus), impression, presse-papiers, téléversement par navigateur, parfois capture d’écran. C’est le seul point qui voit le contenu avant chiffrement réseau. C’est aussi le plus intrusif et le plus fragile, puisque l’agent doit tourner sur chaque poste et chaque version d’OS (Operating System).
Messagerie : inspection à la passerelle SMTP (Simple Mail Transfer Protocol) ou par l’API (Application Programming Interface) du service de messagerie. On y place historiquement le premier contrôle, parce que l’erreur de destinataire reste la fuite la plus banale.
Passerelle web et proxy : téléversements HTTP (Hypertext Transfer Protocol) et formulaires web. Sans inspection TLS (Transport Layer Security), le proxy ne voit que des noms de domaine.
Stockage et partage cloud via CASB (Cloud Access Security Broker) : en mode API, le CASB analyse au repos les fichiers déjà présents dans le service, et donc après coup ; en mode proxy, il intercepte en ligne. Le mode API voit aussi les partages par lien public, c’est-à-dire la fuite qui ne « sort » jamais au sens réseau.
Impression : contrôle par l’agent ou par le serveur d’impression. Le papier reste le canal d’exfiltration qu’aucun journal réseau ne trace.

Le schéma ci-dessous montre ces capteurs entre l’utilisateur et l’extérieur. Chaque flèche correspond à un chemin distinct, et un chemin sans capteur est un chemin non surveillé.

Les capteurs doivent remonter vers une console unique, avec un jeu de règles commun. Sans cela, une même donnée est bloquée par courriel et autorisée par téléversement web, et les utilisateurs l’apprennent vite.

Méthodes de détection DLP et leurs taux d’erreur

La qualité d’une DLP se joue entièrement dans ses détecteurs. On les présente du moins fiable au plus fiable.

Motifs et validations. Une expression régulière seule produit des faux positifs en masse : une suite de seize chiffres peut être un numéro de commande, un horodatage ou un identifiant de colis. La validation réduit le bruit sans l’éliminer. Un numéro de carte de paiement compte de 13 à 19 chiffres et passe l’algorithme de Luhn. Mais Luhn est une somme de contrôle contre les fautes de frappe, et une suite aléatoire de bonne longueur la passe environ une fois sur dix. Un IBAN (International Bank Account Number) se vérifie par un calcul modulo 97, qu’une chaîne aléatoire ne passe qu’environ une fois sur 97. On ajoute des conditions de proximité (mots-clés comme « carte », « expiration », « CVV (Card Verification Value, le cryptogramme visuel) » à quelques caractères) et des seuils de quantité. Un numéro isolé alerte, cinquante numéros dans un fichier bloquent.

Dictionnaires. Ce sont des listes de termes métier, de noms de projets ou de vocabulaire juridique. Le bruit reste élevé, car le mot « confidentiel » apparaît surtout dans les pieds de page de modèles de documents que personne ne relit. Les dictionnaires servent à pondérer un score, pas à décider seuls.

Empreintes de documents. On calcule des empreintes sur des fragments chevauchants de documents de référence (contrats types, code source, plans). La DLP repère alors une copie partielle ou légèrement modifiée. La méthode fonctionne bien sur des documents stables. Il faut en revanche réenregistrer les empreintes à chaque nouvelle version du corpus, faute de quoi la détection vieillit sans bruit.

Correspondance exacte de données, dite EDM (Exact Data Match). On extrait de la base source des valeurs réelles (numéros de client, noms associés à un identifiant), on les hache, et la DLP ne compare que des hachés. La règle peut exiger une combinaison, par exemple nom ET numéro de dossier présents ensemble. C’est le détecteur le plus fiable pour les données structurées. Deux contraintes l’accompagnent. Les hachés de valeurs à faible entropie, comme un numéro sur huit chiffres, se retrouvent par force brute, si bien que l’export haché reste sensible et se protège comme la donnée. Et l’extraction doit être rafraîchie, faute de quoi les nouveaux clients ne sont pas protégés.

Étiquettes de classification. Une métadonnée posée sur le document, automatiquement ou par son auteur, indique son niveau de sensibilité. La DLP n’a plus à deviner : elle lit l’étiquette et applique la règle associée. C’est le détecteur le moins coûteux à l’exécution, et sa fiabilité est exactement celle de l’étiquetage.

D’où la règle structurante : sans classification des données préalable, une DLP devine. Elle infère la sensibilité à partir du contenu, avec les taux d’erreur décrits plus haut. Vingt ans de métier apprennent que le projet DLP lancé avant la classification redécouvre la classification au troisième mois de faux positifs, en plus cher.

Ce que la DLP ne voit pas

Une DLP ne garantit pas l’absence de fuite. Plusieurs angles morts sont structurels et ne relèvent pas d’un défaut de réglage :

Flux chiffrés non inspectés. Il s’agit des connexions TLS exclues de l’inspection (épinglage de certificat dans certaines applications, catégories exclues pour raison de vie privée), des archives protégées par mot de passe, des fichiers chiffrés par l’utilisateur et des tunnels. Face à une archive illisible, la DLP n’a que trois choix : bloquer tout contenu illisible, laisser passer, ou alerter. Le choix doit être explicite dans la politique.
Capture d’écran et photo. Un smartphone braqué sur l’écran contourne toute la chaîne. La reconnaissance de caractères, ou OCR (Optical Character Recognition), sur les images téléversées attrape une partie des captures, au prix de temps de calcul et de faux positifs.
Données reformulées. Un résumé, une traduction ou une liste recopiée à la main échappent aux empreintes et à la correspondance exacte. Le sujet devient aigu avec les assistants IA, traité dans Fuite de secrets dans les prompts d’un assistant IA public sous l’angle de la DLP appliquée aux prompts. Il n’est pas repris ici.
Exfiltration volontaire et patiente. Découpage sous les seuils de quantité, encodage, changement d’extension, canal non couvert (application personnelle, service non référencé, voir le shadow IT). Un initié qui connaît les règles passe dessous.
Accès légitime abusif. Un utilisateur qui consulte des milliers de dossiers sans rien envoyer ne déclenche aucune règle de sortie.

Une DLP réduit donc surtout l’accident et l’étourderie. Pour le reste, la protection vient d’ailleurs : le contrôle d’accès au moindre privilège, le chiffrement (voir ce que protège le chiffrement au repos), la détection comportementale, et des journaux d’accès exploitables pour reconstituer une fuite, comme le décrit la page sur le journal d’accès après une fuite. Un fournisseur qui vend sa DLP « contre la menace interne » vend en réalité un très bon détecteur d’erreurs de destinataire, ce qui est déjà beaucoup mais tient moins bien sur une slide.

Surface d’attaque de l’infrastructure DLP

Une DLP concentre précisément ce qu’elle protège, et devient donc une cible.

L’autorité d’inspection TLS. Le proxy génère à la volée des certificats signés par une autorité interne déployée en confiance sur tous les postes. La clé privée de cette autorité permet d’usurper n’importe quel site pour n’importe quel poste du parc. Elle doit donc être conservée dans un module matériel ou au minimum non exportable, réservée à cet usage, et jamais réutilisée pour signer autre chose. Le proxy doit aussi revalider lui-même les certificats des serveurs d’origine, car un proxy qui accepte tout certificat amont dégrade la sécurité de tout le parc (voir Construire une autorité de certification privée interne).
La console et ses journaux. Un événement DLP contient l’extrait correspondant, par exemple le numéro de carte ou le nom du client. La console devient une base de données sensibles agrégées. Il faut la protéger par des rôles distincts (analyste, administrateur des règles, auditeur), l’authentification forte, une durée de conservation définie et, quand le produit le permet, le masquage des extraits par défaut.
L’agent du poste. Il tourne avec des privilèges élevés et analyse des fichiers non fiables, ce qui en fait une surface d’exploitation au même titre qu’un antivirus. Un utilisateur administrateur de son poste peut l’arrêter. La protection anti-altération de l’agent et la remontée de l’arrêt de l’agent comme événement de sécurité ne sont pas optionnelles.
Les exports de référence (empreintes, hachés EDM). Ils sont à protéger comme la donnée source, pour la raison de force brute déjà décrite.
L’évasion par le format. Extension renommée, document imbriqué dans une archive dans un document, encodage base64. Les contre-mesures sont la détection du type réel par signature de fichier, une profondeur de décompression bornée, et la règle explicite sur le contenu non analysable.

Déployer une DLP : observation, réglage, blocage

L’ordre compte plus que le produit. Le cycle ci-dessous se lit de haut en bas, avec un retour au réglage tant que le taux de faux positifs d’une règle n’est pas acceptable.

Quelques règles générales tirées de ce cycle :

Commencer en observation. Un premier mois en mode journalisation seule révèle les flux métier légitimes qu’aucun atelier n’a cités : l’export mensuel vers le cabinet comptable, le prestataire de paie, l’assureur. Bloquer dès le premier jour, c’est découvrir ces flux par ticket d’incident.
Choisir où bloquer. On bloque là où le détecteur est fiable et le canal peu légitime, par exemple des numéros de carte vérifiés en volume vers une messagerie personnelle. On avertit là où le flux légitime existe, par exemple des données clients vers un partenaire. L’avertissement avec justification saisie par l’utilisateur est souvent le meilleur ratio : il corrige l’étourderie, trace l’intention et ne bloque pas le métier.
Gérer les exceptions comme des droits. Chaque exception a un demandeur, un propriétaire métier, un périmètre (expéditeur, destinataire, type de donnée) et une date d’expiration. Une exception sans expiration devient une règle de contournement documentée.
Traiter les alertes. Une règle dont personne ne lit les événements n’existe pas. Le volume d’alertes doit être dimensionné sur l’effectif qui les traite, pas sur l’ambition du comité de pilotage.

Vie privée des salariés : inspection TLS, information, proportionnalité

Une DLP lit le contenu des échanges professionnels, et parfois privés. En droit français, plusieurs textes encadrent directement le déploiement :

Code du travail, article L1121-1 : les restrictions aux droits et libertés des personnes doivent être justifiées par la nature de la tâche et proportionnées au but recherché.
Code du travail, article L1222-4 : aucune information concernant personnellement un salarié ne peut être collectée par un dispositif qui n’a pas été préalablement porté à sa connaissance.
Code du travail, article L2312-38 : le CSE (Comité social et économique) est informé et consulté préalablement sur les moyens ou techniques permettant un contrôle de l’activité des salariés, dans les entreprises qui y sont soumises.
RGPD (Règlement général sur la protection des données) : base légale, minimisation, durée de conservation, information des personnes. Une AIPD (analyse d’impact relative à la protection des données) est à envisager pour un dispositif de surveillance systématique (voir la page sur l’AIPD).

Ces textes ont des conséquences d’architecture directes. Il faut exclure de l’inspection TLS des catégories de sites (banque, par exemple), restreindre l’accès aux extraits, fixer des durées de conservation courtes, et réserver l’identification nominative à des cas qualifiés plutôt que d’en faire la règle. La qualification d’un dispositif précis relève d’un juriste ou d’un avocat, pas d’une page d’architecture. Le cadre général est traité dans Surveillance des salariés : cadre légal et limites.

Exploitation : règles, secrets, supervision, reprise

Prérequis. Une classification publiée, un inventaire des canaux de sortie, une PKI (Public Key Infrastructure) interne capable de déployer et révoquer l’autorité d’inspection, un parc géré pour l’agent, l’accès API aux services cloud pour le CASB, et un circuit de traitement des alertes avec des personnes nommées.
Secrets et clés. La clé de l’autorité d’inspection doit être protégée, journalisée et renouvelée avant expiration, avec un plan de redéploiement du certificat racine sur le parc. Les jetons API du CASB sont souvent très privilégiés en lecture sur tout le service cloud : périmètre minimal et rotation.
Supervision. Il faut surveiller la couverture autant que les alertes : postes sans agent ou agent arrêté, flux non inspectés, erreurs d’analyse. Une chute brutale du nombre d’événements signale plus souvent un capteur mort qu’une organisation devenue vertueuse.
Sauvegarde et reprise. Les règles, empreintes et exceptions doivent être versionnées et sauvegardées. La politique de défaillance doit être décidée à l’avance, en fail-open ou en fail-closed. Sur la messagerie, un fail-closed arrête le courrier de toute l’entreprise, et un fail-open rend la DLP silencieuse. Les deux se défendent, mais un choix découvert pendant la panne ne se défend pas.

Exemple : règle DLP sur un courriel contenant des numéros de carte

La logique suivante combine validation, seuil, destination et justification. Elle illustre la position de la page : bloquer seulement quand le détecteur est fiable et le canal peu légitime.

Le seuil de cinq numéros est illustratif : il se fixe pendant la phase d’observation, à partir des volumes réels. La validation Luhn seule ne suffit pas pour bloquer, d’où le seuil et la condition sur le destinataire. La dernière branche rend explicite le sort d’une archive chiffrée, l’angle mort le plus souvent oublié des politiques. L’analyste reçoit un extrait masqué, conformément au principe de minimisation appliqué à la console elle-même.

DLP, classification et détection d’exfiltration

La DLP se situe entre deux autres dispositifs, et leur articulation détermine son efficacité.

En amont, la classification fournit le vocabulaire des règles. Le niveau « Confidentiel » devient une étiquette lue par la DLP, au lieu d’une heuristique sur le contenu. Les règles fondées sur l’étiquette sont stables, celles fondées sur le contenu demandent un réglage permanent. La minimisation des données agit encore plus en amont : la donnée non collectée ne fuit pas.

En aval, la détection d’exfiltration cherche des comportements plutôt que des contenus : volume anormal vers une destination nouvelle, accès massif avant un départ, connexions à des services de stockage non référencés. Elle couvre précisément ce que la DLP rate, à savoir l’initié patient, les données reformulées et les canaux chiffrés. Les événements DLP alimentent cette détection comme signaux faibles. Plusieurs avertissements contournés par justification sur une courte période valent davantage qu’un blocage isolé.

Le découpage à retenir : la classification dit quoi protéger, la DLP corrige l’erreur sur les canaux connus, et la détection comportementale cherche l’intention. Aucune des trois ne remplace les autres.

🐝 Ce qui arrive si on s’en passe

Sans DLP, une erreur de destinataire n’est connue que si le destinataire la signale. Aucun événement n’est produit et aucune quarantaine ne permet de rattraper l’envoi : le fichier client parti vers une adresse personnelle ou un domaine voisin passe inaperçu. Côté cloud, un partage par lien public peut rester ouvert pendant des mois, car aucun flux réseau ne révèle son existence. La perte se fait aussi sentir après coup. En cas de violation de données personnelles, le RGPD impose d’en évaluer la portée et, s’il existe un risque, de la notifier à l’autorité de contrôle dans les 72 heures (article 33). Faute de trace de ce qui est sorti, par quel canal et vers qui, cette évaluation repose sur des suppositions. Il devient alors impossible de déterminer avec précision les personnes à informer. Savoir ce que contenaient les fichiers partis, et qui ils concernent, relève d’une autre pièce, souvent tenue pour décorative : le registre des traitements, quand il dit où résident les données.

🦫 Explication de la marmotte 🍫

Une entreprise possède des informations qui ne doivent pas sortir : numéros de cartes bancaires, dossiers de clients, plans secrets. Le logiciel de prévention des fuites s’installe aux endroits par où ces informations peuvent partir : l’ordinateur de chaque employé, le service d’envoi des courriels, la connexion à Internet, les espaces de stockage en ligne, les clés que l’on branche, l’imprimante. À chaque envoi, il lit le contenu et cherche des indices. Ces indices peuvent être des suites de chiffres qui passent un calcul de vérification, des mots-clés, des morceaux de documents déjà connus, des valeurs recopiées depuis la base de clients, ou une étiquette posée sur le fichier par son auteur. Selon ce qu’il trouve, il laisse passer, prévient l’employé, lui demande une raison, met le message de côté ou le bloque. Ses erreurs sont fréquentes quand personne n’a d’abord indiqué quels fichiers sont sensibles, car il doit alors deviner. On commence donc par observer sans bloquer, on corrige les fausses alertes, puis on bloque seulement là où il se trompe rarement. Il ne voit pas tout : un fichier verrouillé par un mot de passe, une photo de l’écran, un texte réécrit avec d’autres mots, ou une personne qui fait sortir les données très lentement. Il évite donc surtout les erreurs d’inattention. Comme il lit des messages de salariés, la loi impose de les informer, de rester mesuré et de protéger ce qu’il enregistre.

Pages voisines

La citent

DLP prévention des pertes de données : détection et limites

Elle cite

: les deux pages se citent l’une l’autre.

DLP prévention des pertes de données : détection et limites

DLP prévention des pertes de données : détection et limites

Ce que fait une DLP : identifier, surveiller, bloquer

Les points de contrôle d’une DLP, du poste au cloud

Méthodes de détection DLP et leurs taux d’erreur

Ce que la DLP ne voit pas

Surface d’attaque de l’infrastructure DLP

Déployer une DLP : observation, réglage, blocage

Vie privée des salariés : inspection TLS, information, proportionnalité

Exploitation : règles, secrets, supervision, reprise

Exemple : règle DLP sur un courriel contenant des numéros de carte

DLP, classification et détection d’exfiltration

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines