L’essentiel en 30 secondes
- Une migration cloud change les chemins réels de sortie des données : la DLP peut garder des règles actives sans plus voir une partie des flux.
- Les ruptures sont banales : nouveaux points de sortie, stockage SaaS, nouveaux postes et exceptions de projet jamais retirées.
- La revalidation se planifie comme un lot du projet : rejouer des scénarios avec des données factices, corriger, puis retester à chaque vague.
Une migration cloud modifie les chemins réels que prennent les données : nouveaux points de sortie, nouveaux postes, nouvelles identités, nouveaux services SaaS. Une DLP configurée pour l’ancien système d’information peut donc continuer à afficher des règles actives tout en ne voyant plus une partie des flux. Retester la DLP après une migration consiste à rejouer des scénarios d’exfiltration avec des données factices sur la nouvelle architecture, pour prouver ce qui est encore bloqué ou détecté.
Pourquoi une migration casse la DLP sans faire de bruit
La DLP n’échoue presque jamais de façon visible après une migration. Aucune alerte ne signale qu’un contrôle est devenu aveugle. Les consoles restent vertes, les stratégies apparaissent « activées », et le tableau de bord affiche toujours le même nombre de règles. Le problème est ailleurs : les règles portent sur des flux qui n’existent plus, et les nouveaux flux passent à côté.
Schéma · ce que la migration déplace
Ce qui change concrètement, et ce que cela casse
Voici les ruptures les plus fréquentes. Aucune n’est exotique. Toutes sont faciles à rater dans un planning de migration centré sur la disponibilité.
| Changement lié à la migration | Effet possible sur la DLP | Ce qu’il faut vérifier |
|---|---|---|
| Le trafic sort par un nouveau point (passerelle cloud, sortie directe Internet depuis les sites ou le domicile) | Le proxy ou la sonde réseau historique ne voit plus ce trafic | Que chaque chemin de sortie est inspecté, y compris hors VPN |
| Serveurs de fichiers remplacés par un stockage SaaS (SharePoint, OneDrive, Google Drive) | Les règles écrites pour les partages réseau ne s’appliquent plus ; le partage externe devient le canal principal | Le partage de lien public, le partage invité, la synchronisation vers un compte personnel |
| Nouveau parc de postes ou nouvelle image système | Agent DLP absent, ancienne version, ou politique non poussée | Couverture réelle de l’agent et comportement sur clé USB, impression, navigateur |
| Bascule de la messagerie | Les règles de transport sortantes ne sont pas reprises à l’identique | Pièces jointes, transferts automatiques, envoi vers domaines personnels |
| Charges applicatives déplacées vers IaaS ou conteneurs | Flux sortants des serveurs non filtrés, groupes de sécurité trop ouverts | Egress des sous-réseaux, accès direct aux stockages objets, résolution DNS sortante |
| Nouvelle gestion des identités et des accès conditionnels | Exceptions temporaires ajoutées pendant le projet et jamais retirées | Comptes de service, groupes exclus des stratégies, appareils non gérés |
| Changement d’étiquetage ou de classification | Les règles reposent sur des étiquettes qui ne sont plus posées | Que les documents migrés conservent leur étiquette et déclenchent la règle |
Le dernier point est sous-estimé. Une DLP qui s’appuie sur la classification perd sa capacité de décision si les métadonnées ne survivent pas au transfert. Le lien entre les deux est expliqué dans pourquoi la DLP dépend de la classification des données.
Le piège des exceptions de projet
Toute migration produit des dérogations. Un groupe exclu de la stratégie pour débloquer une synchronisation. Un compte de service autorisé à tout copier vers le nouveau stockage. Une règle passée en mode audit parce qu’elle bloquait la bascule. Chacune est justifiée sur le moment. Ensemble, elles forment un passage que personne ne surveille.
Le changement de modèle de responsabilité
En passant au cloud, une partie du contrôle passe chez le fournisseur, et une partie reste chez vous. La DLP du fournisseur SaaS n’est pas configurée par défaut à votre place. Les stratégies natives (Purview, Google Workspace, CASB) doivent être écrites, ciblées et testées.
Scénario concret : une ETI qui bascule vers Microsoft 365
Prenons une ETI industrielle qui quitte ses serveurs de fichiers pour SharePoint et OneDrive, généralise le télétravail et remplace son proxy sur site par une sortie Internet directe. Avant la migration, sa DLP réseau inspectait les envois web et sa DLP e-mail bloquait les plans techniques en pièce jointe.
Après la bascule, plusieurs choses ont changé sans que personne ne le décide explicitement :
- les postes en télétravail ne passent plus par l’inspection réseau ;
- un plan technique peut désormais être partagé par lien externe depuis OneDrive, sans jamais transiter par la messagerie ;
- le groupe « bureau d’études » a été exclu d’une stratégie pendant la reprise des données ;
- les nouveaux postes ont reçu l’agent, mais avec une politique par défaut.
Sur le papier, la règle « plans techniques » existe toujours. En pratique, seul un des quatre canaux est encore couvert. Seul un test actif sur le nouvel environnement permet de le constater avant un incident.
Le plan de revalidation en six étapes
La revalidation doit être planifiée comme un lot du projet de migration, pas comme un audit ultérieur. Voici l’ordre qui fonctionne.
- Cartographier les nouveaux chemins de sortie. Lister les points d’egress réels : sortie directe des sites, postes nomades, sous-réseaux cloud, services SaaS autorisés. Comparer avec la liste d’avant migration.
- Reprendre l’inventaire des règles DLP. Pour chaque règle, noter le canal qu’elle couvrait et vérifier si ce canal existe encore. Les règles orphelines sont à réécrire ou à supprimer.
- Purger les exceptions de projet. Revoir chaque exclusion, mode audit ou compte privilégié créé pendant la bascule. Retirer, ou assigner un propriétaire et une échéance.
- Préparer des données factices représentatives. Fabriquer des leurres qui ressemblent à vos données sensibles (formats, motifs, étiquettes) sans en contenir aucune. La méthode est décrite dans tester l’exfiltration en production grâce aux données factices.
- Rejouer les scénarios par canal. Endpoint, web, messagerie, partage SaaS, flux serveurs. Pour chacun, noter trois résultats distincts : bloqué, détecté sans blocage, passé sans trace.
- Hiérarchiser et corriger, puis retester. Classer les écarts par sensibilité de la donnée et facilité d’exploitation. Corriger les plus graves d’abord, puis rejouer les mêmes scénarios pour prouver la correction.
Pour la méthode générale de test, indépendamment du contexte migration, reportez-vous au guide comment tester sa DLP et savoir si elle bloque vraiment.
À vérifier avant de déclarer la migration terminée
- Chaque point de sortie identifié est couvert par au moins un contrôle testé.
- L’agent DLP est présent et à jour sur le nouveau parc, avec la bonne politique.
- Le partage externe et le partage invité des stockages SaaS sont testés avec des leurres.
- Les règles de messagerie sortante ont été rejouées après la bascule.
- Les flux sortants des charges IaaS sont filtrés et testés.
- Aucune exception de projet ne subsiste sans propriétaire et sans date.
- Le SOC reçoit bien les alertes générées par les tests, dans le nouvel outillage.
Et chez vous ?
Vos contrôles voient-ils encore vos nouveaux flux cloud ?
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.
Pourquoi un test ponctuel ne suffit pas
Une migration cloud se termine rarement à une date nette. Les vagues se succèdent, de nouveaux services SaaS arrivent, les stratégies du fournisseur évoluent. Un test réalisé le jour de la bascule finale devient obsolète à la vague suivante. La bonne pratique consiste à rejouer les mêmes scénarios à intervalle régulier et après chaque changement significatif, pour suivre la posture dans le temps plutôt que de la photographier une fois. Le choix entre validation continue, pentest et red team est discuté dans cet article dédié.
Pour replacer cette démarche dans son cadre global, la page de référence sur le test d’exfiltration de données présente la définition, la méthode et les enjeux.
FAQ
Faut-il retester la DLP si l’on reste chez le même éditeur ?
Oui. Garder le même produit ne garantit pas que les règles s’appliquent aux nouveaux canaux. Ce sont les flux qui ont changé, pas forcément l’outil.
À quel moment du projet faut-il tester ?
Une première fois sur l’environnement cible avant la bascule des utilisateurs, puis après chaque vague de migration, puis de façon récurrente. Attendre la fin du projet laisse des mois de couverture inconnue.
Peut-on tester en production sans exposer de données réelles ?
Oui, à condition d’utiliser exclusivement des données factices conçues pour déclencher les mêmes règles que les vraies données. Aucune donnée réelle ne quitte alors le système d’information.
Qui doit piloter la revalidation ?
Le RSSI ou, dans une ETI sans RSSI dédié, la DSI, avec le chef de projet migration. Le SOC doit être associé pour vérifier que les détections arrivent bien dans ses outils.