L’essentiel en 30 secondes
- Une règle au statut actif dans la console n’est pas une preuve : périmètre, détecteurs, seuils et mode audit la font échouer en silence.
- La DLP Workspace protège Workspace : navigateur non géré, synchronisation personnelle et messagerie tierce relèvent d’autres contrôles.
- La vérification consiste à rejouer chaque règle avec des données factices, format par format, puis à comparer attendu et observé.
La DLP Google Workspace est l’ensemble des règles de protection des données configurées dans la console d’administration pour détecter des contenus sensibles et bloquer, avertir ou journaliser leur partage dans Drive, Gmail et le navigateur Chrome géré. Une règle active ne prouve pas qu’une fuite est bloquée : seule une vérification par test actif, avec des données factices, montre ce qui passe réellement.
Cet article s’adresse aux RSSI et aux équipes SecOps qui ont déployé des règles DLP dans Google Workspace et veulent savoir, preuves à l’appui, ce qu’elles arrêtent vraiment.
Ce que couvre la DLP Google Workspace, et ce qu’elle ne couvre pas
Les règles DLP de Google Workspace s’appliquent à plusieurs surfaces, selon votre édition et vos licences. Le périmètre exact dépend du contrat : vérifiez-le avant de tirer la moindre conclusion.
| Surface | Ce que la règle peut faire | Angle mort fréquent |
|---|---|---|
| Drive (partage de fichiers) | Bloquer ou avertir lors d’un partage externe, journaliser | Analyse différée après dépôt, formats non inspectés, fichiers chiffrés ou archivés |
| Gmail (messages sortants) | Bloquer, mettre en quarantaine, avertir l’expéditeur | Pièces jointes protégées par mot de passe, contenu dans une image, liens vers un stockage tiers |
| Chrome géré (Chrome Enterprise) | Contrôler téléversement, copier-coller, impression sur des sites définis | Navigateur non géré, profil personnel, autre navigateur installé |
| Chat et autres services | Variable selon l’édition | Couverture partielle ou absente selon la licence |
Schéma · la frontière du contrôle
Pourquoi une règle « active » n’est pas une règle qui bloque
La console affiche des règles au statut actif. C’est une information de configuration, pas une preuve d’efficacité. Plusieurs mécanismes font échouer une règle sans aucune alerte :
- Le périmètre d’application. Une règle limitée à une unité organisationnelle ou à un groupe ignore les comptes déplacés, les nouveaux arrivants mal rattachés et les comptes de service.
- Les détecteurs. Un détecteur prédéfini calibré pour un format étranger reconnaît mal un identifiant français. Un détecteur personnalisé à base d’expression régulière trop stricte rate les variantes de saisie (espaces, tirets, retours à la ligne).
- Les seuils. Un seuil de déclenchement à plusieurs occurrences laisse passer un document qui en contient moins.
- L’action choisie. Une règle en mode audit ou avertissement est souvent restée ainsi après la phase pilote. L’utilisateur clique sur « continuer » et le fichier part.
- Le délai d’analyse. Sur Drive, l’analyse du contenu n’est pas toujours instantanée : un partage effectué juste après le dépôt peut précéder la détection.
Ces échecs silencieux sont détaillés dans notre article sur les faux négatifs DLP. Ils ont un point commun : rien dans la console ne les signale.
Méthode : vérifier vos règles canal par canal
Le principe est simple. Pour chaque règle, vous fabriquez un contenu factice qui devrait la déclencher, vous tentez l’action interdite depuis un compte de test représentatif, puis vous comparez le résultat attendu au résultat observé. Les leurres doivent ressembler aux vraies données (même format, même structure de document) sans jamais en être. La méthode générale est décrite dans notre guide sur les données factices en production.
Drive : le partage externe
- Créez un document contenant des numéros factices au format attendu (IBAN, numéros de sécurité sociale, références internes classifiées).
- Déposez-le avec un compte utilisateur standard, dans l’unité organisationnelle visée par la règle.
- Tentez un partage vers une adresse externe, puis la création d’un lien public.
- Répétez avec des variantes : PDF, tableur, archive compressée, image scannée, document renommé.
- Notez pour chaque variante : bloqué, averti, journalisé, ou rien.
Gmail : la messagerie sortante
Envoyez vers une boîte de test externe que vous contrôlez des messages portant le leurre dans le corps, en pièce jointe, puis dans une pièce jointe imbriquée. Vérifiez le comportement réel côté destinataire : un message réputé bloqué qui arrive quand même est le constat le plus important de la journée. Les spécificités de ce canal sont traitées dans notre article sur la DLP e-mail.
Chrome : le téléversement et le copier-coller
Depuis un poste avec Chrome géré et le profil professionnel, tentez de téléverser le fichier factice vers un service de stockage non autorisé, puis de coller son contenu dans un formulaire web. Refaites ensuite le test depuis un profil personnel, puis depuis un autre navigateur du même poste. Si seul le premier essai est bloqué, vous savez exactement où se situe la frontière de votre contrôle.
Un scénario concret
Une ETI déploie une règle Drive qui bloque le partage externe des documents contenant des numéros de sécurité sociale. La console l’affiche active depuis des mois. Un test avec un tableur factice montre que le partage est bien bloqué. Le même contenu exporté en PDF scanné passe sans alerte, faute de reconnaissance de texte sur ce format dans la configuration retenue. Et un compte rattaché à une unité organisationnelle créée après le déploiement n’est couvert par aucune règle.
Deux corrections, très différentes en effort : étendre le périmètre de la règle (quelques minutes), traiter le cas des documents scannés (décision d’architecture). C’est précisément ce que doit produire une vérification : une liste d’actions hiérarchisées, pas un constat global.
Et chez vous ?
Que laissent passer vos règles Google Workspace ?
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
- Chaque règle a un scénario de test écrit, avec un résultat attendu.
- Les tests couvrent toutes les unités organisationnelles, y compris les plus récentes.
- Les variantes de format sont testées, pas seulement le format nominal.
- Les règles en mode audit ou avertissement sont recensées et justifiées.
- Les journaux DLP produisent bien un événement exploitable par le SOC.
- Les chemins hors Workspace (navigateur non géré, synchronisation personnelle) sont testés séparément.
- Les tests sont rejoués après chaque modification de règle, de licence ou d’organisation.
Ce dernier point compte plus qu’il n’y paraît. Une posture DLP se dégrade avec le temps, au fil des réorganisations et des changements de configuration. Un test ponctuel donne une photo, le rejeu régulier donne une tendance. Pour une vue d’ensemble de la démarche, consultez notre page sur le test d’exfiltration de données.
FAQ
La DLP Google Workspace est-elle incluse dans toutes les éditions ?
Non. Les fonctions DLP et leur couverture (Drive, Gmail, Chrome, Chat) dépendent de l’édition et des licences souscrites. Vérifiez le périmètre dans la documentation Google à jour et dans votre contrat avant de bâtir votre plan de test.
Peut-on tester avec de vraies données pour être sûr ?
Ce n’est pas nécessaire et c’est risqué. Des données factices au bon format déclenchent les mêmes détecteurs, sans exposer la moindre donnée réelle en cas d’échec du contrôle.
Le mode avertissement suffit-il ?
Il sensibilise, il ne protège pas. Un utilisateur pressé ou malveillant poursuit l’action. Réservez-le aux cas où le blocage gênerait un usage métier légitime, et documentez ce choix.
À quelle fréquence retester ?
Au minimum après chaque changement de règle, de structure organisationnelle ou de licence. Idéalement en continu, pour détecter une régression avant qu’un incident ne la révèle.