La portée de Purview s'arrête à M365. Vos données, elles, non.

Entrez dans n'importe quelle entreprise de taille moyenne et vous y trouverez la même configuration de sécurité : Microsoft 365 avec un certain niveau de couverture Purview, peut-être Defender, et une case à cocher à côté de « protection des données » sur le dernier questionnaire d’audit. 

Examinez ensuite l’empreinte SaaS réelle. 

Confluence. Salesforce. Box. GitHub. Jira. Slack. Workday. Notion. Zendesk. DocuSign. Asana. Une poignée d’outils départementaux dont personne au service informatique ne se souvient avoir approuvé l’utilisation. 

C’est là que se trouvent réellement les données sensibles aujourd’hui. Et, pour la plupart des équipes de sécurité des entreprises de taille moyenne, c’est un véritable trou noir. 

Ce que couvre réellement Purview 

Purview est un outil raisonnable pour ce qu’il est : une couche de gouvernance des données et de prévention des fuites de données (DLP) pour Microsoft 365. Si vous disposez du niveau de licence approprié — généralement E5 ou le module complémentaire de conformité autonome —, vous pouvez classer les données dans SharePoint, OneDrive, Exchange et Teams. Vous pouvez rédiger des politiques DLP. Vous pouvez voir certaines étiquettes de sensibilité se propager. 

Purview ne couvre pas votre pipeline Salesforce. Il ne peut pas vous indiquer qui dispose d’un accès permanent au dossier Box dans lequel le service financier dépose ses prévisions trimestrielles. Il ne voit pas l’outil RH, l’outil de recrutement, l’outil d’assistance, ni la douzaine d’autres endroits où se trouvent des données sensibles. 

Si vos données se trouvaient uniquement chez Microsoft, cela suffirait. Vos données ne se trouvent pas uniquement dans Microsoft 365. 

La véritable pile technologique des PME 

Une entreprise type comptant entre 500 et 3 000 collaborateurs utilise entre 50 et 200 applications SaaS. Une part non négligeable d’entre elles contient des données sensibles : informations personnelles identifiables (PII) des clients, données financières, code source, dossiers RH, informations de santé, contrats, identifiants. 

La plupart de ces données sont : 

• Largement partagées par défaut (les applications SaaS sont optimisées pour la collaboration, et non pour le principe du privilège minimal) 
• Accessibles à bien plus de personnes qu’on ne le pense 
• Invisibles pour les outils de sécurité dont dispose déjà l’entreprise 
• Dont le volume et la sensibilité augmentent chaque trimestre 

Personne n’avait prévu cela. Cela s’est produit parce que les équipes métier ont acheté des outils plus rapidement que les équipes de sécurité ne pouvaient les recenser, et parce que la question de la gouvernance des solutions SaaS non Microsoft a toujours été considérée comme le problème de quelqu’un d’autre. 

Pourquoi les solutions DSPM existantes ne résolvent pas ce problème 

La réponse évidente est le DSPM. Ces plateformes existent spécifiquement pour détecter, classer et gouverner les données dans les environnements SaaS, IaaS et les référentiels non structurés. 

Voici le problème : aucune d’entre elles n’a été conçue pour les PME. 

Elles ont été conçues pour les acheteurs du classement Fortune 500 disposant de budgets à six chiffres, d’équipes dédiées à la sécurité des données et d’une marge de manœuvre suffisante pour mener à bien de longs déploiements. Demandez à une entreprise de 400 personnes de mettre en place une solution DSPM d’entreprise, et vous obtiendrez généralement trois réactions, dans l’ordre : le devis, le silence, puis un refus poli. 

Les obstacles spécifiques : 

• Le coût. La plupart des plateformes DSPM commencent à un montant annuel de l’ordre de 500 000 à 1 000 000. Pour les budgets de sécurité des entreprises de taille moyenne, cela représente la totalité du poste budgétaire consacré aux outils. 
• Complexité du déploiement. Chaque application SaaS nécessite une intégration, chaque intégration nécessite des identifiants et des périmètres d’accès, et chaque périmètre d’accès nécessite un contrôle de sécurité. Une équipe réduite ne peut pas passer un trimestre à configurer des connecteurs. 
• Frais généraux opérationnels. Le DSPM génère des résultats. Ces résultats nécessitent un triage. Le triage nécessite des analystes. Les équipes des entreprises de taille moyenne ne disposent pas d’analystes : elles comptent un seul responsable de la sécurité qui gère également l’IAM, applique les correctifs sur les serveurs et est en charge du programme de formation à la lutte contre le phishing. 
• Un parti pris en faveur des grandes entreprises intégré au produit. L’interface utilisateur part du principe qu’un analyste en sécurité des données l’interprète. Les politiques partent du principe que vous disposez d’une équipe pour les paramétrer. Les alertes partent du principe que quelqu’un a le temps de mener une enquête. 

Résultat : les entreprises de taille moyenne soit paient pour des outils destinés aux grandes entreprises qu’elles ne peuvent pas mettre en œuvre, soit s’en passent et croisent les doigts. 

Le risque n’est pas théorique 

J’ai observé ce schéma à maintes reprises 

• Un prestataire conserve l’accès à Salesforce 90 jours après son départ, car personne n’est responsable de la liste de contrôle de désactivation des applications non-IdP. 
• Un ingénieur exporte une liste de clients depuis HubSpot vers son Google Drive personnel « simplement pour pouvoir travailler hors ligne ». 
• Un commercial sur le point de quitter l’entreprise télécharge trois ans de données clients depuis Gong avant son dernier jour. 
• Un dossier Box mal configuré contenant des preuves SOC 2 est partagé avec « toute personne disposant du lien » pendant 14 mois. 

Aucun de ces incidents n’apparaîtrait dans Purview. Aucun ne serait détecté dans un SIEM sans un travail de personnalisation que personne n’a le temps de réaliser. Et la plupart ne seraient pas non plus détectés dans les solutions DSPM existantes, car le client n’avait tout simplement pas les moyens de les déployer sur cette application SaaS. 

Il ne s’agit pas d’attaques hypothétiques. Ce sont les incidents réels auxquels les entreprises de taille moyenne font face en silence — ceux qui apparaissent dans une analyse rétrospective plutôt que sur un tableau de bord. 

Pourquoi cela reste-t-il sans solution 

Cette lacune persiste car le modèle économique ne tient pas la route dans le cadre du modèle DSPM traditionnel. Mettre en place un scanner pour chaque application SaaS, la maintenance des connecteurs, la gestion des limites de débit des API, la classification des données à grande échelle : tout cela représente un travail d’ingénierie coûteux, et les fournisseurs fixent leurs prix en conséquence. Les acheteurs du marché intermédiaire sont écartés en raison des prix, et les fournisseurs se tournent vers le haut de gamme pour décrocher des contrats plus importants. Le cycle se poursuit. 

Pendant ce temps, l’empreinte du SaaS ne cesse de s’étendre. Chaque nouvel outil de service, chaque acquisition, chaque achat du type « nous en avons juste besoin pour l’équipe » ajoute un nouveau réservoir de données sensibles que personne ne surveille. Le fossé ne se comble pas. Il ne fait que s’élargir. 

Les équipes de sécurité des entreprises de taille moyenne le savent bien. Elles ne sont pas naïves. Elles sont coincées entre des outils dont les prix sont fixés pour d’autres et un problème qui ne cesse de s’aggraver. La plupart s’en sont accommodées, comme on s’accommode de tout risque que l’on n’a pas les moyens de résoudre : on le documente, on espère, puis on passe à autre chose. 

Telle est la réalité de la gestion de la sécurité des données en dehors de Microsoft 365 pour la plupart des entreprises de taille moyenne. Le problème n’est pas résolu. Loin de là. Et ce n’est pas quelque chose que Purview va régler.