10110010011101001011001101101110101018200.devFrom Enterprise.Systems

Qu'est-ce que le DSPM ? La gestion de la posture de sécurité des données expliquée

The 8200.dev TeamLecture de 6 min

Data Security Posture Management — DSPM — est l'un de ces acronymes arrivés plus vite que leur définition. Cet article explique ce qu'il signifie réellement, pourquoi il est apparu, en quoi il diffère des acronymes voisins avec lesquels on le confond, et comment déterminer si votre organisation en a besoin.

La définition en une phrase

Le DSPM est la pratique consistant à découvrir en continu où résident vos données sensibles, qui et quoi peut y accéder, et si cet accès est approprié — puis à signaler les failles afin de pouvoir les corriger.

L'accent est mis sur les données et sur la posture. Ni le réseau, ni le poste de travail, ni le périmètre : les données elles-mêmes, et l'état permanent de leur exposition.

Pourquoi le DSPM est apparu

Pendant la majeure partie de l'histoire de la sécurité, le modèle était celui du périmètre. On traçait une frontière autour du réseau de l'entreprise, on défendait cette frontière, et on faisait confiance à ce qui se trouvait à l'intérieur. Les données résidaient sur des serveurs vous appartenant, dans un centre de données que vous contrôliez.

Ce modèle s'est dissous. Les données résident désormais dans des applications SaaS et des plateformes cloud — Google Workspace, Microsoft 365, Salesforce, stockage objet, entrepôts de données — accessibles de partout par des employés, des prestataires, des partenaires, et de plus en plus par des agents automatisés. Il n'existe plus de périmètre unique à défendre, car les données sont partout et l'accès est accordé au fil de milliers de petites décisions prises individuellement par les utilisateurs.

Dans ce monde, les questions qui comptent ont changé :

  • *Où* se trouvent nos données sensibles, à travers tous ces systèmes ?
  • *Qui* peut atteindre chaque élément de ces données — y compris les parties externes et les identités non humaines ?
  • Cet accès est-il *approprié*, ou quelque chose est-il sur-partagé, public, ou obsolète ?
  • Comment *saurions-nous* quand cela change ?

Le DSPM est la discipline conçue pour répondre à ces questions en continu, plutôt qu'une fois par an lors d'un audit.

En quoi le DSPM diffère du CSPM, du DLP et du CIEM

La soupe d'acronymes est bien réelle. Voici comment ses voisins se positionnent :

  • CSPM (Cloud Security Posture Management) se concentre sur les mauvaises configurations de l'*infrastructure* cloud — buckets de stockage ouverts, groupes de sécurité trop permissifs, volumes non chiffrés. Il pose la question « le cloud est-il configuré de manière sécurisée ? ». Le DSPM demande « les données sont-elles exposées, où qu'elles résident ? ». Ils se recoupent au niveau du stockage mais visent des objectifs différents.
  • DLP (Data Loss Prevention) cherche à *empêcher* les données sensibles de sortir — en bloquant un e-mail contenant un numéro de carte bancaire, en empêchant l'envoi d'un fichier. Le DLP concerne les données en mouvement, au moment de la sortie. Le DSPM concerne la posture permanente : il vous indique que le fichier était sur-partagé en premier lieu, avant même que quoi que ce soit ne bouge.
  • CIEM (Cloud Infrastructure Entitlement Management) se concentre sur les identités et leurs droits d'accès dans les plateformes cloud — qui peut faire quoi. Le DSPM utilise les informations sur les droits d'accès mais place les *données* au centre : il relie l'accès aux ressources qui comptent et évalue l'exposition.

Un modèle mental utile : le CSPM sécurise le cloud, le DLP surveille les sorties, le CIEM démêle les permissions, et le DSPM empêche les données elles-mêmes d'être exposées en premier lieu.

Ce que fait concrètement une démarche DSPM

Dépouillé du discours commercial des éditeurs, un flux de travail DSPM comporte quatre étapes :

  1. Découvrir. Se connecter aux systèmes où résident les données et recenser les ressources, les identités et les permissions qui les relient. On ne peut protéger ce que l'on n'a pas inventorié.
  2. Classifier. Comprendre quelles données sont sensibles — données personnelles, informations financières, secrets, contenus réglementés — afin de prioriser l'exposition en fonction de ce qui est réellement en jeu.
  3. Évaluer l'exposition. Combiner ressource, identité et permission pour identifier les risques : liens publics, partages externes, accès trop privilégiés, autorisations obsolètes, mauvaises configurations.
  4. Prioriser et remédier. Classer les constats par risque réel — sensibilité multipliée par l'étendue de l'accès multipliée par le niveau d'accès — et les mener jusqu'à résolution, puis revérifier à chaque changement.

C'est l'aspect « continu » qui distingue la *gestion* de la posture d'un simple scan ponctuel. La posture dérive constamment à mesure que les personnes partagent, accordent des droits et oublient. Un instantané est déjà obsolète au moment où il est pris.

Avez-vous besoin du DSPM ?

Vous avez probablement déjà le problème ; la question est de savoir si vous le gérez. Quelques signes indiquant qu'une démarche DSPM délibérée s'impose :

  • L'essentiel de vos données réside dans des applications SaaS et des plateformes cloud plutôt que sur une infrastructure que vous contrôlez.
  • Le partage est en libre-service — n'importe quel utilisateur peut accorder un accès — de sorte que votre inventaire des accès est incomplet.
  • Vous avez des obligations de conformité (SOC 2, ISO 27001, GDPR, HIPAA) qui exigent de démontrer un contrôle sur qui peut accéder aux données.
  • Vous ne pouvez pas actuellement répondre à la question « qui peut voir ce dossier de données sensibles ? » sans mener une enquête manuelle.
  • Des agents automatisés et des comptes de service disposent d'un accès à vos données et personne ne les gouverne.

Si plusieurs de ces points vous parlent, l'exposition existe, que vous la surveilliez ou non. Le DSPM n'est rien d'autre que la décision de la surveiller en continu et d'agir sur ce que l'on découvre.

Le DSPM en pratique pour Google Workspace

Le DSPM est agnostique vis-à-vis des plateformes en théorie, mais il se met en œuvre système par système en pratique. Pour les organisations qui fonctionnent sous Google Workspace, cela signifie découvrir en continu les ressources Drive et leur partage, cartographier les identités — humaines, externes, de service et IA — pouvant y accéder, et faire remonter les expositions : liens publics, partages externes, accès trop permissifs, applications OAuth à risque et mauvaises configurations d'administration. C'est précisément la problématique de la sécurité de Google Workspace, envisagée sous l'angle de la posture.

À quoi ressemble un bon DSPM en pratique

Il est facile de décrire le DSPM dans l'abstrait, mais plus difficile de reconnaître une bonne mise en œuvre. Quelques qualités distinguent une gestion de posture réellement utile d'un scanner bruyant :

  • Il priorise sans concession. Un outil qui renvoie dix mille constats a simplement déplacé le problème. Un bon DSPM classe par risque réel — sensibilité multipliée par l'étendue de l'accès multipliée par le niveau d'accès — de sorte que la poignée d'éléments qui comptent remonte en tête, et le reste attend son tour.
  • Il s'explique de lui-même. « Lien public sur Q3-financials.xlsx, accessible par quiconque possède l'URL, car le partage a été réglé sur « tout le monde avec le lien » le 4 mars » est exploitable. Un simple code de constat ne l'est pas. C'est cette clarté qui permet à un non-spécialiste d'agir sans devoir escalader.
  • Il est en lecture seule par défaut. La découverte ne devrait pas nécessiter un accès en écriture à vos données. Les outils les plus légers inventorient et évaluent sans possibilité de modification, ce qui évite que l'outil de sécurité lui-même ne devienne un risque.
  • Il referme la boucle. Détecter une exposition ne représente que la moitié du travail ; la suivre jusqu'à sa résolution et confirmer qu'elle reste corrigée en constitue l'autre moitié. Une posture qui est mesurée mais jamais corrigée n'est qu'une inquiétude plus détaillée.

Idées reçues courantes

Quelques mythes ralentissent les équipes :

  • « Nous avons du DLP, donc nous sommes couverts. » Le DLP surveille les sorties ; il ne vous indique pas que le fichier était sur-partagé en interne et en externe dès le départ. Les deux sont complémentaires, pas substituables.
  • « Notre fournisseur cloud sécurise nos données. » Les fournisseurs sécurisent l'infrastructure et proposent les contrôles ; la manière dont vous *configurez* le partage et les accès — et donc votre exposition — relève de votre responsabilité dans le cadre du modèle de responsabilité partagée.
  • « Nous avons fait un audit l'an dernier. » La posture n'est pas un état que l'on atteint ; c'est un état que l'on entretient. L'audit de l'an dernier décrit un monde qui n'existe plus.

Dépasser ces idées reçues est généralement le moment où une équipe réalise que l'exposition était présente depuis le début — elle ne la surveillait simplement pas en continu.

8200.dev est un DSPM conçu spécifiquement pour Google Workspace : découverte en lecture seule, explications en langage clair sur les raisons pour lesquelles chaque constat est risqué, et revérification continue afin que votre posture reflète la réalité. Pour en savoir plus, consultez comment ça fonctionne.

Curieux de savoir à quoi ressemble votre posture de données aujourd'hui ? Lancez votre audit de sécurité gratuit et obtenez une cartographie priorisée de qui et quoi peut accéder à vos données Google Workspace les plus sensibles.

PartagerX / TwitterLinkedIn

Articles connexes