Prévention des fuites de données en ETI sans SOC : plan en 5 étapes

Dans une ETI sans SOC ni RSSI dédié, la prévention des fuites de données repose sur un principe simple : protéger d’abord le périmètre le plus exposé, puis prouver que les contrôles fonctionnent avant d’en ajouter d’autres. Il ne s’agit pas de tout surveiller, mais de fermer les chemins de sortie les plus probables et de vérifier régulièrement qu’ils restent fermés. Un DSI peut mener ce plan en quelques mois, avec les outils déjà en place.

Pourquoi l’approche « grand groupe » échoue dans une ETI

Les méthodes DLP classiques supposent une équipe qui trie les alertes tous les jours. Sans SOC, ces alertes s’accumulent et personne ne les lit. Résultat : des règles en mode audit pendant des années, un tableau de bord rempli de faux positifs, et aucune certitude sur ce qui sort réellement.

Étape 1 : identifier le périmètre le plus exposé

Commencez par deux questions, pas par un inventaire complet. Quelles données feraient le plus de dégâts si elles sortaient ? Par où sortent-elles le plus facilement aujourd’hui ?

Les données qui comptent vraiment

Dans la plupart des ETI, la liste est courte :

• fichiers clients et données personnelles (RH, paie, CRM) ;
• tarifs, marges, offres commerciales en cours ;
• plans, formules, code source ou savoir-faire industriel ;
• documents juridiques et financiers sensibles (contrats, opérations en préparation).

Inutile de lancer un grand projet de classification. Repérez les trois ou quatre emplacements où ces données vivent (un partage réseau, un espace SharePoint, l’ERP, un bucket cloud) et notez qui y accède. La classification des données viendra ensuite, de façon ciblée.

Les canaux de sortie les plus probables

Le tableau ci-dessous aide à prioriser. L’exposition dépend de votre contexte, mais l’ordre est souvent proche.

Faites défiler le tableau →

Choisissez un seul périmètre pour démarrer : en général la messagerie et le cloud collaboratif, car c’est là que se produisent la majorité des fuites du quotidien. Le sujet est détaillé dans notre article sur les fuites via cloud personnel, Teams et Slack.

Étape 2 : activer ce que vous possédez déjà

Beaucoup d’ETI paient des licences qui incluent des fonctions DLP inutilisées. Avant tout achat, vérifiez :

• les stratégies DLP de votre suite bureautique (Microsoft 365 ou Google Workspace) ;
• les options de partage externe sur SharePoint, OneDrive ou Drive ;
• les catégories de filtrage web de votre pare-feu ou proxy ;
• les politiques de contrôle des périphériques de votre EDR.

Configurez peu de règles, ciblées sur les données identifiées à l’étape 1. Passez-les en mode bloquant dès que possible pour les cas évidents (exemple : envoi d’un export RH vers une adresse externe).

Étape 3 : prouver que les contrôles bloquent

C’est l’étape que presque toutes les ETI sautent. Une règle configurée n’est pas une règle efficace. Les écarts sont fréquents : un format de fichier non inspecté, une archive compressée qui passe, une exception ajoutée pour un service puis oubliée. Ces faux négatifs sont silencieux par nature.

La seule façon de savoir est de tester activement : tenter, avec des données factices qui ressemblent aux vraies, de faire sortir l’information par chaque canal du périmètre choisi. On observe ensuite ce qui a été bloqué, ce qui a été seulement journalisé et ce qui est passé sans rien laisser. La méthode générale est décrite dans notre page sur le test d’exfiltration de données.

Scénario concret

Une ETI industrielle de 600 personnes active une stratégie DLP sur les fichiers contenant des numéros de sécurité sociale. Le DSI prépare un faux export de paie, rempli d’identités fictives. Il tente quatre envois : pièce jointe directe, fichier zippé, lien de partage externe, téléversement sur un service de stockage grand public depuis le navigateur. Le premier est bloqué. Les trois autres posent question. En une demi-journée, il dispose d’une liste précise de corrections, au lieu d’une impression de sécurité.

Ce type de test doit se faire en production, sur les vrais postes et les vrais flux, sinon il ne prouve rien. D’où l’importance d’utiliser exclusivement des leurres : voir tester en production grâce aux données factices.

Étape 4 : hiérarchiser et corriger

Sans équipe dédiée, vous ne corrigerez pas tout en même temps. Classez chaque constat selon deux critères : la sensibilité de la donnée concernée et la facilité du chemin de sortie. Un canal ouvert, utilisable par n’importe quel salarié, sur des données clients passe avant un scénario technique complexe sur des données peu sensibles.

Pour chaque correction, notez le responsable, le délai et le test qui confirmera qu’elle fonctionne. Cette dernière colonne change tout : elle transforme une action en preuve.

Étape 5 : élargir et mesurer dans le temps

Une fois le premier périmètre fermé et vérifié, passez au suivant : navigateur et IA générative, puis poste de travail, puis réseau sortant. Rejouez les tests à intervalles réguliers et après chaque changement majeur (migration, nouvel outil SaaS, mise à jour de stratégie). Une posture se dégrade sans bruit.

Routine mensuelle du DSI

1. Rejouer les scénarios d’exfiltration du périmètre couvert.
2. Comparer avec le mois précédent : nouveaux passages, régressions.
3. Vérifier les exceptions ajoutées aux règles DLP et au pare-feu.
4. Traiter les deux ou trois actions prioritaires.
5. Rapporter un indicateur simple à la direction : part des scénarios bloqués.

Ce dernier point compte. Un dirigeant comprend « sept chemins de sortie sur dix sont bloqués, voici les trois restants » bien mieux qu’un volume d’alertes.

FAQ