L’essentiel en 30 secondes
- Sans déchiffrement, la DLP réseau ne voit qu’un domaine et un volume. Le contenu lui échappe.
- Exclusions, applications épinglées, catégories exemptées et trafic hors proxy créent des angles morts silencieux.
- Pour mesurer votre couverture, nous envoyons des fichiers leurres sur chaque chemin configuré et nous regardons ce que la DLP en fait.
Prenons un scénario type : toutes les tentatives d’exfiltration de fichiers leurres vers GitHub réussissent. 100 %. Aucune faille exotique là-dedans. GitHub est une destination légitime pour les équipes de développement, donc souvent exclue de l’inspection TLS, et les flux git push ne sont couverts par aucune règle DLP. Le proxy ne voit alors que du trafic chiffré vers github.com sur le port 443, ou du SSH sur le port 22, qu’il ne déchiffre de toute façon jamais.
L’inspection TLS permet à une DLP réseau de lire le contenu des flux HTTPS sortants pour y appliquer ses règles. Ses angles morts, nous les trouvons rarement dans une faille technique. Ils viennent de vos listes d’exclusion, des applications qui refusent le déchiffrement, des catégories de sites volontairement non inspectées et des postes qui contournent le proxy.
Pourquoi l’inspection TLS ne voit pas tout
La quasi-totalité du trafic web sortant est chiffrée. Sans déchiffrement, votre DLP réseau voit un nom de domaine (via le SNI ou la résolution DNS), un volume et une destination. Le contenu, non. Avec Encrypted Client Hello (ECH), une extension de TLS 1.3 normalisée à part par l’IETF que Chrome et Firefox activent depuis 2023, même le SNI peut disparaître. C’est pourquoi vos équipes activent l’inspection sur le proxy, le pare-feu ou la passerelle SSE. MITRE ATT&CK range d’ailleurs l’envoi sur un canal chiffré sous T1048.002.
Seulement, l’inspection TLS est un compromis permanent. Chaque fois qu’une application casse, qu’un service juridique s’inquiète ou qu’un directeur se plaint de lenteurs un lundi matin, une exception est ajoutée. Cumulées sur 3 ans, ces exceptions dessinent un tunnel. Et un attaquant, ou un collaborateur pressé, n’a besoin que d’un tunnel.
Schéma · ce que voit la DLP
Les quatre familles d’angles morts
1. Les listes d’exclusion qui ont grossi
Vos exclusions se rangent dans 3 tiroirs (domaine, catégorie, adresse IP ou plage). Les dérives classiques :
- Jokers trop larges : exclure *.exemple.com entier pour un seul sous-domaine qui posait problème. Tout ce qui est hébergé dessous (stockage, partage, API) sort alors sans que votre DLP lise rien.
- Exclusions d’hébergeurs et de CDN : une exception posée sur une infrastructure mutualisée, ou sur les plages Microsoft 365 que l’éditeur recommande de ne pas inspecter, couvre aussi des contenus que vous n’aviez pas en tête.
- Exceptions temporaires devenues permanentes : posées un vendredi soir pendant un incident de production, il y a 2 ans, jamais retirées, sans propriétaire ni date d’expiration.
- Exclusions par utilisateur ou par groupe : direction, équipes de développement, prestataires. Ces équipes-là ont souvent accès aux données les plus sensibles.
2. Les applications à certificat épinglé
Certaines applications vérifient qu’elles parlent au certificat attendu (épinglage de certificat, ou certificate pinning). Votre proxy présente le sien, l’application le refuse, et votre équipe réseau l’ajoute à la liste de contournement. C’est fréquent avec les clients de synchronisation, la visioconférence, les agents de mise à jour, les applications mobiles et certains outils de développement, dont le client git quand il ignore votre autorité de certification interne.
3. Les catégories volontairement non inspectées
Santé, banque en ligne, services publics : ne pas déchiffrer un rendez-vous Doctolib ou un relevé bancaire répond à de vraies préoccupations de vie privée de vos salariés, et relève souvent d’un accord avec les représentants du personnel. Posez-vous quand même 2 questions :
- La classification de votre fournisseur est-elle fiable pour les sites de niche, où un service de partage mal catégorisé peut finir exempté ?
- Avez-vous un contrôle compensatoire (limites de volume, alerte sur un téléversement de plus de 50 Mo vers une catégorie exemptée, contrôle endpoint) ?
4. Le trafic qui ne passe pas par l’inspection
Points à vérifier : vos postes nomades hors VPN ou avec tunnel scindé, vos serveurs et charges cloud, sur Azure ou ailleurs, qui sortent directement sur Internet, protocoles qui échappent au proxy explicite (QUIC et HTTP/3 sur UDP 443, RFC 9000 et 9114, si votre équipement ne les gère pas), et résolution DNS chiffrée côté navigateur qui court-circuite vos contrôles DNS. Ce dernier point est traité dans notre article sur l’exfiltration via DNS.
Tableau de synthèse : angle mort, symptôme, compensation
| Angle mort | Ce que voit la DLP | Contrôle compensatoire possible |
|---|---|---|
| Exclusion par domaine trop large | Domaine et volume, pas le contenu | Réduire au sous-domaine précis, propriétaire et date d’expiration |
| Application épinglée en contournement | Rien au niveau contenu | DLP endpoint, restriction aux comptes d’entreprise, blocage |
| Catégorie exemptée (vie privée) | Catégorie et volume | Seuils de volume, alertes de téléversement, contrôle endpoint |
| Poste nomade hors tunnel | Rien | Client SSE toujours actif, DLP endpoint |
| QUIC non pris en charge | Selon l’équipement : rien | Bloquer UDP 443 pour forcer le repli sur TCP 443, inspecté |
Comment vérifier votre couverture réelle
Relisez la configuration, bien sûr : elle décrit l’intention. Pour voir ce qui se passe sur le réseau, nous procédons en 5 étapes.
- Inventorier les exceptions. Exportez toutes vos règles de non-déchiffrement (domaines, catégories, IP, utilisateurs, applications). Pour chacune, notez qui l’a demandée, pourquoi et depuis quand. Une exception sans propriétaire passe en tête de liste.
- Construire des données synthétiques détectables. Des documents leurres qui déclenchent à coup sûr vos règles DLP (faux numéros de sécurité sociale au format valide, faux IBAN de 27 caractères, marqueurs de classification). La méthode est détaillée dans tester l’exfiltration en production avec des données synthétiques.
- Rejouer l’envoi sur chaque chemin. Même fichier leurre, même poste type sous Windows ou Linux, vers une destination inspectée (le contrôle témoin), puis vers une destination par famille d’exception : un dépôt de code, un stockage cloud comme Dropbox, Box ou Google Drive, une catégorie exemptée. Variez vos profils : poste au bureau, poste nomade, compte standard, compte d’un groupe exempté.
- Comparer 3 résultats par scénario. La session a-t-elle été déchiffrée ? La règle DLP s’est-elle déclenchée ? Votre SOC a-t-il reçu une alerte exploitable ? Un « oui » à la première question et un « non » à la troisième, situation fréquente, et tout aussi problématique. Enforcis classe chaque scénario testé dans l’un des 3 états (Bloqué, Détecté sans blocage, Non détecté), avec un résultat daté et traçable.
- Rejouer après chaque changement. Une mise à jour du proxy, une exception, une migration SSE : chacun de ces changements déplace la couverture. Un test isolé vous donne l’état d’un jour. Rejoué chaque semaine, il vous montre si elle se dégrade.
Scénario concret
Reprenons le cas GitHub du début. Bloquer GitHub ? Mauvaise réponse : vos développeurs en ont besoin, et ils trouveront un contournement. Distinguez plutôt l’espace GitHub de l’entreprise d’un dépôt tiers arbitraire. Votre organisation GitHub reste autorisée, avec une mesure compensatoire comme la MFA, sur arbitrage du RSSI. Un dépôt tiers, ou un gist public créé avec un compte personnel, ne devrait jamais être joignable. Côté réseau, cela consiste à restreindre l’exclusion de déchiffrement aux seuls usages nécessaires et compenser par un contrôle endpoint sur les flux git push. Ensuite, nous rejouons le même fichier leurre pour vérifier que la correction tient sur ce scénario. MITRE ATT&CK range ce chemin sous T1567.001, exfiltration vers un dépôt de code.
Étape suivante
Que voit vraiment votre inspection TLS ?
Une démo de 30 minutes : une campagne complète sur les 8 canaux que nous testons, sur notre environnement de démonstration. Le POC montre in situ, sur un scénario simple en environnement synthétique, comment la solution se comporte chez vous. Ce qui sort réellement de vos canaux, c’est le pilote qui vous le montre.
Checklist rapide pour le RSSI
- Chacune de vos exceptions de déchiffrement a un propriétaire, une justification et une date de revue, tous les 6 mois par exemple.
- Chaque application en contournement a un contrôle compensatoire identifié.
- Votre comportement face à QUIC (UDP 443) est connu et testé.
- Les flux git push vers des dépôts hors de votre organisation sont bloqués ou alertés.
- Un test actif vérifie, au moins après chaque changement majeur, que vos règles DLP se déclenchent sur le trafic HTTPS.
Le cadre général est sur notre page de référence, test d’exfiltration de données.
FAQ
Faut-il déchiffrer 100 % du trafic HTTPS ?
Non. C’est irréaliste, et parfois contraire à vos obligations envers vos salariés. Ce qui compte, c’est de savoir ce qui n’est pas déchiffré et de compenser chaque trou par un autre contrôle.
L’inspection TLS suffit-elle pour une DLP efficace ?
Elle est nécessaire pour votre DLP réseau. Elle ne couvre pourtant ni les applications épinglées, ni les postes hors tunnel, ni le SSH sur le port 22. Gardez la DLP endpoint et le CASB à côté.
Comment savoir si une session a été déchiffrée ?
Les journaux du proxy ou de la passerelle indiquent en général l’action de déchiffrement par session. Croisez-les avec les journaux DLP pendant un test : une session sans trace d’inspection, sur une destination censée l’être, vous montre un angle mort.
Faut-il bloquer GitHub ?
Non. Distinguez votre organisation GitHub, autorisée avec une mesure compensatoire comme la MFA sur arbitrage du RSSI, d’un dépôt tiers arbitraire, qui ne devrait jamais être joignable. Nous vérifions ensuite par un test que cette frontière tient.