CASB et DLP SaaS : tester la couverture de vos contrôles cloud

Un CASB (Cloud Access Security Broker) applique des règles DLP aux applications SaaS, soit par API (analyse des données déjà stockées), soit en mode inline (contrôle du flux au moment de l’envoi). Tester un CASB DLP consiste à vérifier, avec des données factices, que chaque application, chaque mode et chaque action utilisateur déclenche bien le blocage ou l’alerte attendus. Sans ce test, vous savez ce qui est configuré, pas ce qui est réellement couvert.

Deux modes, deux promesses différentes

La plupart des déceptions autour du CASB viennent d’une confusion entre ses modes de déploiement. Ils ne protègent pas la même chose, et ils ne se testent pas de la même façon.

Faites défiler le tableau →

Ce que la console ne vous dit pas

Une politique CASB affichée « active » dans la console repose sur une chaîne de conditions. Il suffit qu’un maillon cède pour que la règle ne s’applique jamais. Les ruptures les plus courantes :

• Le connecteur API a perdu ses droits après un renouvellement de jeton ou un changement d’administrateur côté SaaS.
• L’instance n’est pas la bonne : l’entreprise protège son tenant officiel, mais pas l’instance personnelle ou celle d’un partenaire ouverte dans le même navigateur.
• Le proxy inline ne voit pas tout : un poste nomade hors tunnel, une application de bureau qui ignore les paramètres de proxy, un téléphone personnel.
• Le moteur de détection ne reconnaît pas le contenu : fichier compressé, document protégé par mot de passe, image contenant du texte, format métier propriétaire.
• L’action n’est pas couverte : la règle vise le téléversement, mais pas le copier-coller dans un formulaire web, ni la création d’un lien de partage externe.

Ces défaillances relèvent de la même famille que celles décrites dans notre article sur les faux négatifs DLP : la règle existe, elle ne se déclenche pas, et personne n’est prévenu.

Construire une matrice de couverture SaaS

Tester un CASB, ce n’est pas lancer un fichier de test et regarder si une alerte remonte. C’est croiser méthodiquement trois dimensions.

1. Les applications

Partez de l’inventaire réel, pas de la liste contractuelle. Classez les SaaS en trois groupes : sanctionnés (messagerie, stockage, CRM, outils collaboratifs), tolérés (applications utilisées sans validation formelle) et non autorisés. Le CASB doit traiter chaque groupe différemment, et chaque traitement doit être vérifié. Pour les usages que la DSI ne voit pas, l’article sur le shadow IT et le navigateur détaille les chemins à inventorier.

2. Les actions utilisateur

• téléversement d’un fichier ;
• collage de texte dans un champ ou un message ;
• création d’un lien de partage public ou externe ;
• synchronisation par un client lourd ;
• téléchargement vers un terminal non géré.

3. Les contextes

Poste géré au bureau, poste géré en télétravail, terminal personnel, navigateur alternatif, tenant personnel de la même application. Une règle qui fonctionne dans un seul contexte n’en couvre qu’une fraction.

Le produit de ces trois dimensions donne vite plusieurs centaines de cas. C’est normal. Priorisez par sensibilité des données réellement présentes dans chaque application et par probabilité d’usage.

Scénario concret : un tableur clients vers un stockage cloud

Prenons une ETI dont la politique interdit la sortie de fichiers contenant des données clients vers un stockage non sanctionné. Le test se déroule ainsi :

1. Préparer un leurre : un tableur de données factices, réalistes dans leur format (noms, IBAN fictifs au format valide, numéros de contrat), marqué par une empreinte que vous seul reconnaissez. La méthode est décrite dans l’article sur les données factices en production.
2. Rejouer l’action sur le tenant sanctionné, puis sur une instance personnelle de la même application, puis sur une application non autorisée.
3. Varier le contexte : depuis le réseau d’entreprise, puis hors tunnel.
4. Varier la forme : fichier brut, fichier compressé, contenu collé.
5. Relever trois résultats par cas : bloqué ou non, alerte générée ou non, délai entre l’action et la réaction.

Le résultat le plus instructif est rarement « tout est bloqué » ou « rien n’est bloqué ». C’est la ligne où le tenant officiel est protégé et l’instance personnelle ne l’est pas. Ou celle où l’alerte existe, mais arrive au SOC des heures plus tard, sans que personne ne la traite. Le lien avec la chaîne de détection est développé dans l’article détecter l’exfiltration côté SOC.

Checklist avant de déclarer un SaaS « couvert »

• Le mode de contrôle (API, inline, les deux) est documenté pour cette application.
• Le connecteur API a été vérifié fonctionnel récemment, pas seulement à l’installation.
• Les instances non officielles de la même application sont distinguées et traitées.
• Les cinq actions utilisateur listées plus haut ont été testées.
• Au moins un contexte hors réseau d’entreprise a été testé.
• Le délai de remédiation en mode API est mesuré et jugé acceptable.
• Les alertes arrivent dans l’outil où le SOC travaille réellement.
• Le test est rejoué après chaque changement majeur (nouvelle application, mise à jour du CASB, évolution du tenant).

Pourquoi un test ponctuel ne suffit pas

Le SaaS bouge sans vous. L’éditeur ajoute une fonction de partage, modifie une API, lance une fonction d’assistant IA qui ouvre un nouveau canal (voir IA générative et fuite de données). Votre CASB n’en est pas forcément informé, ou pas au même rythme. Une couverture vérifiée en janvier peut s’être dégradée en avril sans qu’aucune configuration n’ait changé chez vous. Seul un rejeu régulier rend cette dérive visible, et permet de suivre une posture dans le temps plutôt qu’une photo.

Ce test s’inscrit dans une démarche plus large de test d’exfiltration de données, qui couvre aussi l’endpoint, le réseau et la messagerie.

Questions fréquentes