Classer N'Est Pas la Voie vers le Moindre Privilège

Ce qu'un scan DSPM vous dit réellement (et ce qu'il ne dit pas)

Cet écart vaut la peine d'être gardé à l'esprit à mesure que la gestion de la posture de sécurité des données, ou DSPM, devient l'une des catégories de sécurité à la croissance la plus rapide. Gartner évaluait l'adoption du DSPM à moins de 1 % des organisations en 2022 et prévoit qu'elle dépassera 20 % d'ici 2026, une progression abrupte pour une catégorie encore jeune. La définition de Gartner explique cet attrait : les outils DSPM détectent, classent et cataloguent les données sensibles à travers les stockages on-premises, le cloud et le SaaS, afin qu'une équipe de sécurité puisse enfin voir où résident ses informations réglementées et confidentielles et, dans le meilleur des cas, qui y a accès.

C'est en le voyant que les problèmes commencent.

Considérez ce qu'un RSSI reçoit réellement à l'issue d'un scan : un chiffre. Une certaine quantité de fichiers sensibles répartis dans un certain ensemble de dépôts est signalée et étiquetée. Le constat est réel, et il affecte l'anxiété de l'équipe de sécurité bien plus qu'il n'affecte son exposition réelle. L'outil s'est contenté de signaler où se trouve la donnée. Il peut dire quelque chose sur qui peut y accéder, mais si ces personnes étaient réellement censées disposer de cet accès, ou ce qu'il convient de faire ensuite, cela échappe au DSPM. Ce qui arrive sur le bureau du RSSI est un inventaire de l'exposition, pas un plan pour la réduire.

Pourquoi la classification ne peut pas vous mener au moindre privilège

Voici la distinction que la catégorie brouille. Le risque associé à un fichier sensible provient de trois éléments à la fois : le degré de sensibilité de la donnée, qui peut y accéder, et si ces personnes ont une raison légitime de le faire. La classification traite le premier élément. Même lorsqu'elle le fait avec précision, elle en dit peu sur la légitimité de l'accès et sur le terrain où réside l'exposition. C'est pourquoi une équipe de sécurité ne peut pas classer son chemin vers le moindre privilège.

Trois mécanismes expliquent ce silence.

Commençons par l'écart entre l'accès effectif et la liste de contrôle d'accès (ACL). Ce que disent les permissions d'un fichier et qui peut réellement l'ouvrir divergent au moment où la réalité s'en mêle : groupes Active Directory imbriqués, héritage des permissions, héritage rompu quelque part dans l'arborescence, une entrée « Everyone » ou « Authenticated Users » présente sur un partage, un lien SharePoint oublié mais toujours actif dans la boîte de réception de quelqu'un. Un outil qui lit l'étiquette de sensibilité voit les permissions déclarées. Il ne résout pas le graphe réel d'accessibilité, et c'est dans l'écart entre les deux que voyage une violation.

Vient ensuite l'origine du chemin d'accès, qui se situe dans le tissu identitaire bien avant d'atteindre la donnée. Le groupe disposant de permissions excessives, le groupe de sécurité comptant plusieurs milliers de membres que personne n'a élagué depuis des années, le compte de service ou l'agent IA disposant d'un accès en lecture permanent, l'identité invitée dans Entra qui porte encore un lien actif : voilà ce qui ouvre la porte, et cela se situe dans la couche identitaire. Un scanner qui ne lit que le stockage de données ne peut voir l'intégralité du chemin, car la moitié de celui-ci n'a jamais résidé dans le stockage de données.

Enfin, la découverte et la remédiation sont deux métiers distincts. Un scan produit un constat. Le risque ne diminue que lorsque quelqu'un supprime le groupe global, met le dossier en quarantaine, redéfinit ses permissions selon les besoins réels de l'activité, et peut ensuite démontrer le moindre privilège. C'est un acte de gouvernance des accès, et aucun volume de classification ne l'accomplit.

Supposons qu'un scan signale un dossier de bulletins de paie comme hautement sensible. D'un côté, l'équipe de sécurité sait désormais que le dossier existe et qu'il compte, ce qui constitue la première étape nécessaire. De l'autre, le dossier se trouve derrière une attribution héritée à « Domain Users », appliquée il y a des années pour un projet clos depuis longtemps, si bien que plusieurs milliers de personnes peuvent l'ouvrir cet après-midi même, et l'étiquette de classification n'a rien changé à cela. L'étiquette indique à l'équipe que le dossier mérite d'être protégé ; seul le modèle d'accès lui indique qu'il n'est actuellement pas protégé, et seule la remédiation referme cette faille.

Comment Netwrix Access Analyzer comble l'écart

C'est la direction dans laquelle travaille Netwrix Access Analyzer. Il part du modèle d'accès et arrive à la donnée à travers lui, alors que les scanners cloud-native fonctionnent dans le sens inverse, cartographiant d'abord la donnée et déduisant l'accès ensuite. Il résout l'accès effectif à travers des environnements hybrides et non structurés, démêle la prolifération des permissions Active Directory et Entra que les scanners traitent comme opaque, met en lumière ce qui est surexposé et obsolète, et pilote la remédiation via une étape de simulation puis d'exécution, avec des revues adressées au propriétaire métier, seul à savoir si telle personne devrait réellement disposer de cet accès.

La classification trouve le risque. L'accès l'élimine.

Rien de tout cela ne rend la classification inutile. Une équipe ne peut pas gouverner l'accès à des données qu'elle n'a jamais localisées, donc la découverte doit venir en premier. Son rôle est de localiser le risque ; le refermer relève d'une discipline différente. Le positionnement défendable est étroit : la classification montre à une équipe de sécurité où son risque se concentre, et l'accès est ce qui permet de l'éliminer. Il faut faire les deux si l'objectif est une gestion équilibrée du risque.

Ce qui nous ramène au dossier de l'inspecteur. Il a une valeur réelle, car il indique au propriétaire où envoyer l'entrepreneur. Mais personne ne confond le dossier avec une maison réparée, et une carte de données classifiées mérite le même scepticisme. N'importe quel outil DSPM du marché peut dire où résident les données sensibles. La question qui décide si cette donnée est à risque est de savoir qui peut l'ouvrir, et cette réponse n'a jamais figuré dans la carte des données. Elle se trouve dans le modèle d'accès.