L’essentiel en 30 secondes
- En sortie, la pression métier élargit les règles : elles ne se resserrent presque jamais.
- La DLP réseau ne voit que ce qui passe devant elle : la vraie question est par où une donnée peut sortir sans la croiser.
- Seule la mesure, segment par segment et avec des données factices, transforme une revue de configuration en preuve.
Le filtrage sortant (ou contrôle d’egress) désigne l’ensemble des règles qui décident quels flux peuvent quitter votre réseau, vers quelles destinations, par quels protocoles et depuis quels segments. Combiné à une DLP réseau, il est la dernière barrière avant qu’une donnée sensible ne parte chez un tiers. La seule façon de savoir s’il tient, c’est de le mesurer par des tests actifs, pas de relire la configuration du pare-feu.
Beaucoup d’organisations ont investi des années dans le filtrage entrant. En sortie, la règle par défaut reste souvent la même qu’au premier jour : tout autoriser vers Internet, avec un proxy pour la navigation et l’espoir que la DLP verra le reste. Cet article vous donne une méthode pour vérifier ce qui sort vraiment, segment par segment.
Pourquoi le filtrage sortant est le parent pauvre de la sécurité réseau
Le filtrage entrant a une logique simple : on ferme tout et on ouvre au cas par cas. En sortie, la pression métier inverse la logique. Une application ne fonctionne pas, un éditeur demande d’ouvrir une plage d’adresses, une mise à jour échoue : la règle s’élargit. Elle ne se resserre presque jamais.
Résultat typique après quelques années :
- une règle « any vers Internet » héritée, placée en bas de la politique mais toujours active ;
- des exceptions de proxy accordées à des serveurs « temporairement » ;
- des segments serveurs qui sortent en direct, sans passer par le proxy ni par l’inspection ;
- des résolutions DNS autorisées vers n’importe quel résolveur externe.
Schéma · les chemins hors inspection
Les quatre zones à vérifier
1. Les proxies et leurs exceptions
Le proxy est souvent le point de passage où la DLP réseau est branchée. Vérifiez trois choses. D’abord, qu’il est réellement obligatoire : un poste qui tente une connexion directe vers Internet doit être bloqué par le pare-feu, pas seulement « configuré » pour utiliser le proxy. Ensuite, la liste des contournements (bypass) : chaque domaine exclu de l’inspection est un canal possible. Enfin, les catégories de sites autorisées sans analyse, notamment les services de stockage et de partage.
2. Les protocoles autorisés
HTTP et HTTPS ne sont pas les seuls protocoles qui sortent. Listez ce que votre politique laisse réellement passer : DNS, NTP, SMTP, SSH, ports applicatifs ouverts pour un partenaire, protocoles de visioconférence. Pour chacun, posez une question : ce flux est-il inspecté par un contrôle capable de détecter une donnée sensible ? Deux cas méritent un traitement spécifique : le canal DNS, souvent ouvert par défaut, et le trafic HTTPS non déchiffré, qui représente la majorité du trafic web.
3. Les segments réseau
Un poste utilisateur, un serveur applicatif, un bastion d’administration et un environnement de développement n’ont pas les mêmes besoins en sortie. Pourtant, les politiques sont souvent identiques. Les segments serveurs sont les plus exposés : ils détiennent les données, ils sortent fréquemment en direct pour des mises à jour, et un attaquant qui y prend pied cherchera précisément ce chemin. Un serveur de base de données n’a, en général, aucune raison de joindre Internet.
4. Les règles « tout autoriser »
Elles sont rarement écrites comme telles. Cherchez les règles avec destination « any », les objets réseau trop larges (des plages entières de fournisseurs cloud), et les règles sans date de revue ni propriétaire. Un avis tranché : une règle sortante sans propriétaire identifié devrait être considérée comme à supprimer, pas à documenter.
Ce qu’il faut mesurer
Relire la politique de pare-feu donne une vision théorique. La mesure donne une preuve. Voici les indicateurs utiles, à suivre par segment.
| Indicateur | Ce qu’il révèle | Comment l’obtenir |
|---|---|---|
| Taux de blocage des scénarios d’exfiltration | La part des tentatives de sortie de données factices effectivement arrêtées | Rejeu de scénarios d’attaque depuis chaque segment |
| Taux de détection sans blocage | Les flux vus par la DLP ou le SOC mais non stoppés | Corrélation entre tests et alertes générées |
| Canaux de sortie hors inspection | Les protocoles et destinations qui échappent à la DLP | Inventaire des flux autorisés croisé avec le périmètre d’inspection |
| Délai de détection | Le temps entre la tentative et l’alerte exploitable | Horodatage des tests comparé aux alertes du SOC |
| Dérive dans le temps | Les régressions après un changement de règle ou une migration | Répétition des mêmes scénarios à intervalle régulier |
Scénario concret : le serveur de recette
Prenons une ETI qui a durci la navigation de ses postes : proxy obligatoire, inspection TLS, DLP réseau sur les téléchargements sortants. Sur le papier, la posture est bonne.
Un test actif est lancé depuis un serveur de recette, avec un jeu de données factices imitant un extrait de fichier clients. Constat : ce segment n’est pas soumis au proxy, car une exception a été créée deux ans plus tôt pour un déploiement. Le flux sort en direct, sans inspection. Aucune alerte n’est remontée.
La correction n’est pas de réécrire les règles DLP, qui sont correctes. Elle consiste à supprimer l’exception, à forcer ce segment vers le proxy et à n’autoriser que les destinations de mise à jour nécessaires. Puis à rejouer le même scénario pour prouver que la sortie est désormais bloquée. Sans test, ce trou serait resté invisible.
Et chez vous ?
Quels segments sortent encore sans contrôle chez vous ?
Une démo guidée de 30 minutes, sur des jeux de résultats préétablis, pour voir comment une campagne restitue ce qui sort par chaque chemin de sortie.
Checklist de vérification du filtrage sortant
- Lister tous les segments et, pour chacun, les destinations Internet réellement nécessaires.
- Vérifier que la sortie directe (hors proxy) est bloquée au pare-feu pour les postes et les serveurs.
- Recenser les exceptions de proxy et d’inspection TLS, avec propriétaire et date de revue.
- Restreindre la résolution DNS aux résolveurs internes autorisés.
- Supprimer ou justifier chaque règle sortante à destination « any ».
- Rejouer des scénarios d’exfiltration avec des données factices depuis chaque segment.
- Comparer les résultats aux alertes reçues par le SOC.
- Hiérarchiser les corrections selon la sensibilité des données du segment et la facilité du canal.
- Répéter les tests après chaque changement significatif de politique.
Le point 6 est celui qui transforme une revue de configuration en preuve. L’usage de données factices en production permet de tester sur les vrais chemins réseau sans exposer de donnée réelle.
FAQ
Le filtrage sortant remplace-t-il la DLP réseau ?
Non. Le filtrage sortant réduit le nombre de chemins possibles ; la DLP analyse le contenu de ce qui emprunte les chemins autorisés. Les deux sont complémentaires, et un trou dans l’un rend l’autre inopérant sur ce canal.
Faut-il passer à une politique « tout bloquer » en sortie ?
Pour les segments serveurs, oui, c’est l’objectif raisonnable : liste d’autorisations explicite. Pour les postes utilisateurs, une approche par proxy obligatoire avec inspection est plus réaliste. L’essentiel est qu’aucun segment ne sorte sans contrôle.
À quelle fréquence tester ses contrôles d’egress ?
Après chaque modification notable de la politique réseau, et de façon régulière entre deux. Les régressions viennent surtout des exceptions ajoutées au fil de l’eau, qu’un audit annuel détecte trop tard.
Peut-on tester sans risque en production ?
Pour la donnée réelle, oui, à condition d’utiliser exclusivement des leurres et des données factices. Le risque opérationnel ne disparaît pas pour autant : alertes chez le SOC ou le MSSP, charge sur les postes testés. Nous cadrons donc les scénarios avec les équipes réseau et le SOC avant lancement, et une campagne s’arrête en moins de 5 minutes.