Le DSPM a vu le jour parce que les données sensibles ne restent plus immobiles.
Au-delà de la base de données, les données sensibles se trouvent dans les journaux, les files d’attente, les outils SaaS, les systèmes d’assistance, les pipelines d’analyse, les entrepôts de données, les sauvegardes, et désormais dans les invites d’IA et les magasins de vecteurs. Elles se déplacent parce que l’application les déplace. L’adresse e-mail d’un client peut provenir d’un formulaire d’inscription, transiter par une API, être enregistrée dans Postgres, apparaître dans un journal d’application, être copiée dans Snowflake, être transférée vers un outil d’assistance, être envoyée à Stripe, puis éventuellement être intégrée ultérieurement dans un workflow d’IA. Et ce workflow est considéré comme tout à fait normal.
Ainsi, lorsque l'on parle de DSPM, c'est-à-dire de « Data Security Posture Management » (gestion de la posture de sécurité des données), le principe de base est assez simple. Il s'agit d'aider les équipes à comprendre où se trouvent les données sensibles, de quel type de données il s'agit, qui ou quoi peut y accéder, comment elles sont protégées et où elles pourraient être exposées.
La plupart des entreprises ne disposent pas d’une vue d’ensemble précise de l’emplacement de leurs données sensibles. Elles savent qu’elles possèdent des données clients, des informations de paiement, des jetons, des données sur leurs salariés et, désormais, toutes sortes de données contextuelles liées à l’IA. Ce qu’elles ne savent pas toujours, c’est où toutes ces données se trouvent exactement, qui y a accès, ni si elles sont traitées conformément à leurs exigences en matière de sécurité et de conformité.
La visibilité est le problème que le DSPM traditionnel tente de résoudre.
Le DSPM traditionnel commence là où les données ont été stockées
Une approche DSPM traditionnelle commence généralement par l'inventaire des données. Cela implique généralement d'analyser les systèmes de stockage et les plateformes connectées : compartiments S3, bases de données, entrepôts de données, applications SaaS et sauvegardes.
Cet outil recherche les données sensibles, les classe, vérifie les autorisations d'accès et leur exposition, et aide l'équipe de sécurité à hiérarchiser les priorités. Il peut par exemple vous signaler qu'un compartiment S3 contient des données à caractère personnel, qu'une table de l'entrepôt de données contient des informations relatives aux paiements, qu'un partage de fichiers est accessible à un trop grand nombre de personnes, ou encore qu'une sauvegarde contient des dossiers clients de production stockés dans un emplacement que personne n'a consulté depuis un an.
C'est évidemment très utile. Les environnements modernes regorgent de données sensibles, dont une grande partie est copiée, répliquée, exportée, enregistrée, synchronisée, archivée, puis oubliée. Les solutions DSPM traditionnelles aident les équipes à identifier ces données. Elles offrent à l'équipe de sécurité une meilleure visibilité sur l'ensemble du patrimoine de données, au-delà des seules cloud qui l'entourent.
Mais pour les développeurs et AppSec , ce n'est souvent que la deuxième partie de l'histoire.
La première partie explique comment ces données ont été obtenues.
La question qui manque concerne le chemin d'exécution
Un outil DSPM classique pourrait indiquer : « Des données à caractère personnel ont été détectées dans ce référentiel de journaux. »
Mais le développeur doit encore déterminer pourquoi ces données à caractère personnel se trouvent là, quelle partie de l'application les a enregistrées, si cela était intentionnel et quelle modification permettrait réellement de corriger le problème. Et pour cela, il faut examiner le code.
L'application a collecté les données, les a traitées, puis a déterminé les champs à renvoyer depuis une API. Elle a ensuite enregistré le corps de la requête, transmis un jeton à un processeur de tâches, envoyé les métadonnées du client à un fournisseur et généré la demande contenant des informations sensibles.
Ainsi, la question la plus pertinente pour les développeurs devrait aller au-delà de « Où sont stockées les données sensibles ? » pour s’orienter davantage vers « Quel chemin de code a entraîné cette exposition ? ». C’est la version « shift-left » du DSPM.
La gestion de la protection des données (DSPM) basée sur le code commence au niveau de l'application plutôt qu'au niveau de la couche de stockage. Elle examine les API, les modèles ORM, les appels de journalisation, les consommateurs de files d'attente, les workflows CI/CD, les intégrations d'IA, etc. L'objectif est de comprendre comment les données sensibles entrent dans le système, comment elles circulent, où elles sont stockées, par où elles sortent et à quel stade elles sont susceptibles d'être mal gérées.
Audits des mesures de protection des données (DSPM) basés sur le code et des risques d'exposition des données
En ce qui concerne Aikido, je pense que la meilleure façon de décrire notre DSPM basé sur le code est de parler d'« audit d'exposition des données »: il s'agit d'utiliser l'IA pour identifier les flux de données sensibles et les risques de sécurité présents dans le code.
Un audit de fuite de données est différent. Il examine le code et cherche à déterminer comment les données sensibles circulent au sein de cette application et à quel endroit ce flux génère des risques. Il couvre les informations personnelles identifiables (PII), les informations médicales protégées (PHI), les données PCI, les secrets, les jetons, le contenu des clients et le traitement des données liées à l'IA. Chaque résultat s'accompagne de preuves et d'une mesure corrective au niveau du code, sans qu'il soit nécessaire de se connecter directement aux bases de données.
L'analyse du code permet également de détecter des failles en matière de protection des données. Elle peut mettre en évidence un champ sensible stocké sans chiffrement, une clé codée en dur dans le code source, l'utilisation de MD5, SHA-1 ou Base64 comme s'il s'agissait d'un chiffrement, un secret enregistré dans le dépôt, ainsi que des données sensibles transmises via un canal non sécurisé.
On peut également présenter les choses sous un autre angle. Les solutions DSPM traditionnelles nécessitent un accès à vos données réelles : elles se connectent aux compartiments S3, aux bases de données et aux entrepôts de données pour analyser leur contenu. À l’inverse, les solutions DSPM basées sur le code analysent directement le code qui crée et transfère ces données ; elles ne demandent donc jamais d’accès et ne téléchargent rien. Cette approche, qui repose sur l’analyse du code, facilite grandement la mise en place de la solution, puisqu’il n’est pas nécessaire d’accorder de nouveaux accès à l’environnement de production.
Cela permet également d'accélérer le processus, puisqu'il n'y a rien à parcourir. La méthode est également plus précise, car elle analyse l'utilisation d'un champ plutôt que de partir du principe que tout numéro à neuf chiffres correspond à un numéro de Sécurité sociale. Le résultat est une cartographie de l'emplacement des données sensibles au sein de votre architecture et de la manière dont elles sont protégées, entièrement générée à partir du code.
En Aikido, cela s'inscrit dans le cadre de l' analyse de code par IA; ainsi, l’audit d’exposition des données s’inscrit dans le cadre de code review globale code review que de constituer une intégration distincte de l’accès aux données.
En quoi la qualité des résultats diffère-t-elle ?
Prenons l'exploitation forestière comme exemple simple.
Un produit DSPM classique pourrait éventuellement vous signaler que des données à caractère personnel (PII) sont présentes dans les journaux d'application. Là encore, c'est utile. Mais il faut alors que quelqu'un se charge de rechercher la source.
Un audit d'exposition des données basé sur le code permet d'obtenir une vue d'ensemble plus complète en établissant des liens entre les données, le chemin d'exécution du code, la destination, le risque d'exposition et la solution. Cela le rend plus utile pour les développeurs.
Par exemple, le contrôleur de paiement enregistre l'objet « billingDetails » complet lorsque l'autorisation de paiement échoue. Cet objet comprend l'adresse e-mail, le numéro de téléphone, l'adresse de facturation et les quatre derniers chiffres de la carte. Les journaux sont transmis à Datadog. La solution consiste à masquer ces champs avant l'enregistrement et à ne conserver que l'identifiant du client, l'identifiant de l'intention de paiement et le code d'erreur.
Ces informations sont très différentes de celles que l'on obtient avec un DSPM traditionnel.
Il en va de même pour les secrets et les jetons. Prenons l'exemple d'un jeton SCM utilisé pour lire du code sur GitHub, GitLab ou Bitbucket. Une approche axée sur le stockage pourrait amener à se demander si ce jeton est chiffré dans la base de données. Mais ce n'est pas tout.
Par où le jeton entre-t-il dans la plateforme ? S'agit-il d'un jeton OAuth, d'un jeton d'application GitHub ou d'un PAT fourni par l'utilisateur ? Quelles sont ses autorisations ? Comment est-il validé ? Où est-il chiffré ? Où est-il stocké ? Quand est-il déchiffré ? Est-il mis en cache ? Est-il intégré dans une URL de clonage ? Est-il transmis à un worker ? Pourrait-il faire l'objet d'une fuite via les journaux, les traces, les erreurs, les arguments de processus ou la télémétrie ? Il s’agit d’un problème de sécurité des données, mais c’est le code qui nous fournit les informations nécessaires sur son parcours.
Du tableau de bord à la résolution
C'est là que, selon moi, le DSPM basé sur du code devient intéressant.
La meilleure approche ne consiste pas à proposer un énième tableau de bord indiquant simplement : « Vous disposez de données sensibles. » Tout le monde le sait déjà. Une expérience plus efficace consiste à présenter l'inventaire des données sensibles, le flux de ces données, le risque d'exposition, les contrôles pertinents, ainsi que la modification du code permettant de réduire ce risque.
Si c'est le code qui est à l'origine de la vulnérabilité, la solution se trouve probablement dans le code.
Le déroulement typique du travail d'un développeur devrait donc être le suivant :
- Masquer les champs sensibles avant l'enregistrement.
- Renvoie un objet de réponse API plus petit.
- Ajouter une vérification du statut de propriétaire du locataire.
- Cessez de transmettre des jetons dans les URL.
- Mascarez les données de production avant de les restaurer dans l'environnement de préproduction.
- Chiffrer les données avant leur stockage.
- Supprimer les données clients d'une requête adressée à un modèle de langage de grande envergure (LLM).
- Corriger la logique de suppression afin que les enregistrements en aval soient effectivement supprimés.
L'ingénieur souhaite savoir quel chemin d'exécution précis entraîne un risque spécifique de fuite de données et comment y remédier.
Cela rend également le lien avec les cadres de sécurité et de conformité beaucoup plus concret. Si un jeton est mal géré, cela peut avoir des implications en matière de gestion des authentificateurs, de protection des transmissions, du principe du privilège minimal et de protection des journaux d’audit. Si des informations personnelles identifiables (PII) sont enregistrées sans être masquées, cela peut avoir des implications en matière de confidentialité, de conservation, de minimisation des données et de contrôles de surveillance. Si les données clients sont copiées dans un environnement de transit sans être masquées, cela peut affecter le contrôle d’accès, la séparation des environnements et les obligations de conformité. Si des enregistrements survivent à une demande de suppression, ou si des données sont conservées au-delà de leur délai de conservation, cela est directement lié aux obligations du RGPD et du CCPA, et cela doit être corrigé au niveau même de la logique de suppression et de conservation.
Une constatation qui se limite à indiquer « Modèle de journalisation non sécurisé » n'est guère utile. En revanche, une formulation telle que « Les données personnelles des clients qui apparaissent dans les journaux via ce chemin de code créent un risque d'exposition des données, affectent ces contrôles et peuvent être corrigées en masquant ces champs avant la journalisation » est exploitable.
C'est une bien meilleure façon d'intégrer l'ingénierie, AppSec et la conformité dans un même débat.
La version simplifiée
La gestion traditionnelle des données sensibles (DSPM) reste importante. Elle aide les équipes à comprendre où se trouvent les données sensibles dans l'environnement réel. Elle permet de détecter les compartiments oubliés, les bases de données exposées, les données fantômes et les référentiels dotés de droits d'accès excessifs.
Mais le DSPM basé sur le code apporte la couche applicative qui faisait défaut. Il permet de comprendre comment les données sensibles parviennent à cet endroit, comment elles circulent, où se situe le mécanisme d'exposition et ce que les développeurs peuvent faire pour y remédier.
La version simplifiée se présente donc comme suit :
La méthode DSPM traditionnelle identifie les données sensibles là où elles se trouvent.
Le DSPM basé sur le code identifie comment les données sensibles sont exposées.
Un audit de fuite de données permet de relier ce flux au code, à la faille de contrôle et à la solution apportée.
C'est la version « shift-left » du DSPM. Et pour les développeurs et AppSec , c'est sans doute celle qui leur est la plus utile.
Aikido une solution DSPM basée sur du code, unique en son genre. Protégez et suivez vos données, sans même avoir à connecter vos bases de données.
