24 milliards d’identifiants exposés sont entre les mains des attaquants. Votre plan de contrôle est-il prêt ?
Le 15 juin 2026, des chercheurs de Cybernews ont révélé le retrait responsable d’un cluster Elasticsearch non sécurisé contenant 8,3 téraoctets de données – soit 24 milliards d’enregistrements de noms d’utilisateur et de mots de passe, issus de 36 sources distinctes, principalement des canaux Telegram où des ensembles d’identifiants volés circulent au sein de communautés criminelles. Environ 22,6 milliards de ces enregistrements proviennent de « collections » – ensembles d’identifiants compilés lors d’incidents de fuite de données historiques, que les équipes de sécurité de la plupart des organisations ont déjà traités via la rotation des mots de passe ou la mise hors service des systèmes concernés. Les enregistrements restants, en revanche, proviennent d’une source totalement différente : des journaux de malwares infostealers capturant des identifiants activement récoltés dans des environnements d’entreprise en production.
Cette distinction – collection historique contre extraction en temps réel par infostealer – fait la différence entre une menace de fond et un risque opérationnel immédiat. Les infostealers comme RedLine, Lumma et Vidar récupèrent les identifiants directement sur les machines où les employés s’authentifient chaque jour : navigateurs, applications de bureau, gestionnaires de mots de passe et portails SaaS d’entreprise. Les identifiants présents dans ces journaux ne proviennent pas d’une fuite vieille de cinq ans. Ils sont extraits d’endpoints actuellement en production, et les données d’authentification qu’ils contiennent restent valides tant qu’elles n’ont pas été renouvelées.
Pour les organisations soumises aux exigences de conformité HIPAA, à la CMMC 2.0, à l’autorisation FedRAMP ou à des cadres réglementaires équivalents, le constat est simple et inquiétant. Une entreprise de plusieurs milliers de collaborateurs aura, avec quasi-certitude statistique, une partie de ses identifiants présents dans cet agrégat de 24 milliards d’enregistrements. La question que doivent se poser les responsables conformité et les équipes de sécurité n’est pas de savoir si ces identifiants figurent dans la base de données. C’est : que peut faire un attaquant s’il les exploite avec succès, et votre architecture actuelle limite-t-elle réellement ce risque ?
Cet article répond directement à cette question – comment fonctionne l’exposition des identifiants par infostealer, pourquoi les secteurs réglementés font face à des conséquences asymétriques, et ce que doit proposer un plan de contrôle Kiteworks pour l’échange sécurisé de données, là où une défense périmétrique montre ses limites.
Résumé des points clés
1. Les identifiants issus d’infostealers constituent la vraie menace, pas les collections historiques
La majorité des 24 milliards d’enregistrements sont des données recyclées issues de fuites historiques. Les journaux d’infostealers sont différents : ces identifiants ont été récoltés sur des machines d’entreprise actives et peuvent toujours être valides, ce qui en fait la cible privilégiée des attaquants.
2. Les secteurs réglementés supportent une responsabilité asymétrique en cas de compromission
Un seul accès non autorisé à des informations médicales protégées, à des données non classifiées contrôlées ou à des données financières réglementées déclenche une obligation de notification d’incident et expose à des sanctions – quelle que soit la quantité de données consultées.
3. La sécurité basée sur le mot de passe a déjà échoué à l’échelle de 24 milliards d’enregistrements
Considérer que les mots de passe suffisent à protéger les données d’entreprise n’est plus défendable. L’authentification multifactorielle, les contrôles d’accès basés sur les attributs et l’audit continu ne sont plus optionnels – ils constituent le strict minimum pour les environnements manipulant des données sensibles.
4. Le plan de contrôle pour l’échange sécurisé de données est la dernière défense efficace après un vol d’identifiants
Les attaquants qui s’authentifient avec des identifiants volés ciblent les portails de transfert de fichiers, les plateformes de messagerie sécurisée et les espaces collaboratifs où résident réellement les données sensibles. Un plan de contrôle unifié – moteur de règles unique, journal d’audit unique, posture de sécurité homogène sur tous les canaux – limite ce qu’ils peuvent atteindre et ce qui est tracé.
5. Le risque de credential stuffing doit figurer dans les registres de risques conformité et les reportings au conseil d’administration
L’agrégation de 24 milliards d’enregistrements, les campagnes actives d’infostealers et la posture réglementaire dans la santé, la défense et la finance font du takeover de comptes par identifiants volés une priorité de gouvernance, et non plus un simple problème technique.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Deux populations dans ces 24 milliards d’enregistrements
Les professionnels de la sécurité qui considèrent les grands agrégats d’identifiants comme de « vieilles histoires » n’ont pas tout à fait tort – du moins pour la partie « collections ». La majorité des 24 milliards d’enregistrements identifiés par Cybernews provient d’ensembles de données issues de fuites circulant sur les marchés souterrains depuis des années. Beaucoup de ces identifiants ont déjà été renouvelés. De nombreux systèmes auxquels ils donnaient accès n’existent plus. Les équipes qui appliquent une hygiène stricte des mots de passe, surveillent les services d’alerte de fuite et imposent une rotation régulière des identifiants ont probablement déjà réduit une grande partie de cette exposition.
Les identifiants issus d’infostealers posent un problème d’une toute autre nature.
Les infostealers sont des malwares conçus pour extraire les données d’authentification des machines infectées. Ils lisent les mots de passe enregistrés dans les navigateurs, extraient les cookies de session permettant de s’authentifier sans mot de passe, capturent les frappes clavier lors des connexions et récupèrent les identifiants stockés dans les gestionnaires de mots de passe. Le résultat – un « journal » structuré contenant noms d’utilisateur, mots de passe et jetons de session, classés par site et application – est conditionné et vendu sur les marchés clandestins, généralement quelques heures ou jours après l’infection initiale.
Les conséquences pour les environnements d’entreprise sont directes. Un collaborateur dont la machine est infectée par un infostealer transmet, de fait, toute son empreinte d’authentification à un attaquant. Chaque application professionnelle qu’il utilise, chaque portail de partage de fichiers, chaque plateforme de messagerie sécurisée – tout cela figure dans le journal. L’entreprise n’a aucune visibilité sur cette compromission tant que l’appareil de l’employé ne déclenche pas une alerte EDR ou que l’attaquant n’essaie pas d’utiliser les identifiants volés.
Ce qui rend la campagne FortiBleed révélée la même semaine pertinente – 86 000 identifiants fonctionnels issus de dispositifs FortiGate dans 194 pays, agrégés et publiés – c’est qu’elle a utilisé l’intelligence artificielle pour cibler et valider automatiquement ces identifiants via du password spraying. L’association d’agrégats massifs d’identifiants et de la validation assistée par IA accélère la transformation d’identifiants volés en accès fonctionnels. Les organisations qui n’appliquent pas l’authentification multifactorielle sur l’ensemble de leurs applications s’exposent à ce risque sans protection adaptée.
Pourquoi les secteurs réglementés font face à une équation différente
Toutes les organisations sont exposées au risque de credential stuffing. Mais celles soumises à HIPAA, CMMC, FedRAMP, ITAR ou des cadres similaires présentent un profil de risque particulier, car la conséquence d’une seule authentification réussie dépend entièrement de ce que le compte compromis peut consulter – et des obligations de déclaration que cet accès déclenche.
Dans le cadre de la conformité HIPAA, un accès non autorisé à des informations médicales protégées impose une notification d’incident, même si l’attaquant n’a pas exfiltré de données. Si les identifiants d’un collaborateur servent à se connecter à un système de santé et que la session accède à des PHI – même en simple consultation – il s’agit d’une violation à déclarer selon la règle de notification HIPAA. L’entité concernée doit informer les personnes impactées, le Department of Health and Human Services, et, pour les incidents touchant 500 personnes ou plus, les médias majeurs des États concernés. Le coût de cette notification et de l’enquête qui s’ensuit peut largement dépasser celui de toute solution de firewall ou de protection des endpoints.
Pour la conformité CMMC 2.0, un compte compromis accédant à des données non classifiées contrôlées (CUI) impose une déclaration d’incident sous 72 heures selon la clause DFARS 252.204-7012. Cela peut aussi entraîner une réévaluation du statut de certification CMMC de l’organisation. Un sous-traitant de la défense victime d’une fuite de CUI suite à une compromission d’identifiants risque non seulement le coût de la réponse à incident, mais aussi la perte ou la suspension de la certification CMMC qui lui permet de répondre aux appels d’offres du DoD.
La conformité FedRAMP crée des obligations similaires pour les fournisseurs cloud et agences fédérales : tout accès non autorisé à des données fédérales impose une déclaration immédiate à l’agence concernée et à la CISA.
L’asymétrie est flagrante : un identifiant compromis dans une enseigne de distribution expose à un risque de fraude. Le même identifiant chez un acteur de la santé, de la défense ou une agence fédérale déclenche des obligations de déclaration, des risques de sanctions et des conséquences sur la certification qui dépassent de loin le coût de l’incident lui-même. Les organisations qui n’ont pas explicitement intégré les scénarios de takeover de comptes dans leurs analyses de risques pour chaque cadre réglementaire opèrent avec une faille non reconnue.
Le mode opératoire du credential stuffing contre les plateformes de contenu
Comprendre comment les attaquants exploitent ces bases d’identifiants contre les plateformes de contenu d’entreprise montre pourquoi l’architecture défensive compte autant que la couche d’authentification.
Les attaques de credential stuffing suivent un schéma prévisible. Un attaquant récupère un ensemble d’identifiants – via un agrégat comme celui documenté par Cybernews, des journaux d’infostealers achetés ou du phishing ciblé – puis lance des tests automatisés sur les plateformes visées. Les outils modernes de credential stuffing testent des dizaines de milliers de couples identifiant/mot de passe par minute sur une application web, en changeant d’adresse IP et d’agent utilisateur pour éviter le blocage ou la limitation de débit. Lorsqu’un couple fonctionne, l’accès est consigné et mis en file d’attente pour un suivi manuel ou automatisé.
C’est lors de cette seconde étape que les plateformes de contenu deviennent la cible. Un attaquant qui a un accès fonctionnel à un compte d’entreprise n’exfiltre pas tout immédiatement – cela déclencherait des alertes sur le volume. Il adopte un comportement qui imite l’utilisateur légitime. Il peut rester inactif plusieurs jours ou semaines avant de rechercher des fichiers sensibles. Il peut utiliser cet accès pour pivoter vers d’autres comptes en consultant des annuaires internes ou des plateformes de communication où circulent d’autres identifiants ou tokens. Lorsqu’il agit, il cible des documents – contrats, dossiers financiers, plans techniques, dossiers médicaux, données réglementées – monnayables ou exploitables pour du chantage. Les contrôles de classification qui étiquettent et restreignent l’accès au contenu selon sa sensibilité sont une réponse directe à ce mode opératoire.
L’attaque supply chain Klue révélée dans le même cycle médiatique – où des tokens OAuth compromis ont permis d’accéder à des environnements Salesforce de LastPass, HackerOne, Huntress, Jamf, OneTrust, Recorded Future, Snyk, Tanium, etc. – suit exactement ce schéma. Le mécanisme d’authentification différait (tokens OAuth au lieu de mots de passe), mais l’objectif restait l’accès authentifié à des dépôts de documents et à des données métier à grande échelle. Les implications pour la gestion des risques supply chain sont majeures : l’accès tiers aux environnements d’entreprise crée des vecteurs d’exposition que les programmes d’hygiène internes ne peuvent pas fermer seuls.
Pour les organisations utilisant des solutions de transfert sécurisé de fichiers, de messagerie sécurisée, de SFTP ou des plateformes collaboratives, le risque de credential stuffing est direct. Ce sont précisément les applications où résident les données réglementées sensibles, et ce sont celles dont les identifiants sont stockés dans les navigateurs et récoltés par les infostealers.
Pourquoi la couche mot de passe est déjà dépassée
Le problème de fond avec l’authentification par mot de passe comme contrôle de sécurité, c’est qu’elle suppose que le mot de passe reste secret. À l’échelle de 24 milliards d’identifiants exposés – avec un écosystème d’infostealers qui en récolte constamment de nouveaux – cette hypothèse n’est plus tenable pour les grandes organisations.
Les politiques de rotation des mots de passe aident, mais ne comblent pas la faille. Si un infostealer vole les identifiants d’un collaborateur et que la rotation est prévue tous les 90 jours, il existe une fenêtre de 90 jours durant laquelle l’attaquant peut exploiter ces identifiants. Si la rotation n’est déclenchée qu’après une alerte de fuite, il s’écoule souvent plusieurs jours ou semaines entre le vol et la prise de conscience de l’organisation. Les infostealers sont conçus pour agir dans cette faille temporelle.
La récolte des tokens de session aggrave encore la situation. Les infostealers modernes ne capturent pas seulement les mots de passe. Ils récupèrent aussi les cookies de session du navigateur, permettant de s’authentifier sans mot de passe – contournant même l’authentification multifactorielle dans certains cas, puisque le token a été émis après une authentification légitime. Le détournement de session via des cookies volés est une technique documentée qui ne nécessite même pas de connaître le mot de passe de la victime.
Conséquence architecturale : la défense doit fonctionner même en supposant la compromission des identifiants. C’est la logique des principes de sécurité Zero trust : au lieu de faire confiance à l’utilisateur authentifié sur la base de son identifiant, l’architecture applique une validation continue, une analyse comportementale et des contrôles d’accès par règles qui restent efficaces même si l’identifiant est compromis.
L’identité et la gestion des accès au niveau applicatif – et non seulement au périmètre réseau – déterminent si une compromission d’identifiants aboutit à une fuite ou à une tentative bloquée et tracée. La différence entre une organisation qui détecte une attaque de credential stuffing en quelques heures et une autre qui la découvre des mois plus tard réside dans la profondeur et la cohérence des contrôles d’accès et du monitoring appliqués sur le plan de contrôle pour l’échange sécurisé de données. Une visibilité temps réel via un tableau de bord RSSI qui fait remonter les comportements d’accès anormaux sur tous les canaux de contenu transforme l’audit log d’un outil forensique en capacité opérationnelle de détection.
Construire une défense au niveau du plan de contrôle
Les conséquences réglementaires du takeover de comptes – notamment dans la santé, la défense et la finance – imposent une exigence architecturale précise : les contrôles doivent s’appliquer là où circulent réellement les données sensibles, et pas seulement au périmètre réseau ou au niveau du fournisseur d’identité.
Les contrôles périmétriques restent utiles mais insuffisants face à ce modèle de menace. Un identifiant compromis passe les contrôles périmétriques par définition. L’attaquant présente un token valide depuis une IP cohérente avec la localisation de l’utilisateur, à une heure habituelle. La détection basée sur le périmètre ne peut pas distinguer de façon fiable une session compromise d’une session légitime sans contexte supplémentaire.
Ce que fournit l’architecture Zero trust, c’est justement ce contexte additionnel. En appliquant des contrôles d’accès basés sur les attributs (ABAC) au niveau du plan de contrôle, l’architecture impose des règles fines selon la sensibilité des données, le rôle utilisateur, la conformité de l’appareil et le contexte comportemental – et non plus seulement sur la validité du token. Un utilisateur dont l’identifiant est compromis peut s’authentifier, mais si son comportement sort de la norme ou s’il tente d’accéder à des données hors de son périmètre, la règle ABAC bloque l’accès et génère une alerte.
L’audit log continu est l’élément de preuve qui rend cette architecture défendable face à la conformité. Quand un régulateur ou un plaignant demande « qu’a consulté le compte compromis, et quand ? », il faut pouvoir fournir un enregistrement précis, horodaté, immuable – et non une simple déclaration que des contrôles existaient. Les organisations incapables de produire cette preuve se retrouvent dans la même impasse que celle identifiée par les régulateurs lors de sanctions – comme l’action de la FTC contre Illuminate Education : la conscience du risque sans contrôle vérifiable constitue en soi un échec de conformité.
La DLP intégrée au plan de contrôle offre une dernière couche de confinement : des règles qui inspectent les sorties de données réglementées – PHI, CUI, PII, dossiers financiers – et bloquent, mettent en quarantaine ou alertent sur toute transmission hors des canaux autorisés. Même si un compte compromis accède à des données sensibles, la DLP peut empêcher l’exfiltration. L’application du principe de minimisation des données au niveau du plan de contrôle réduit encore le rayon d’action en veillant à ce que chaque compte n’ait accès qu’aux données nécessaires à son rôle – et non à toutes celles que ses autorisations pourraient permettre.
Kiteworks agit comme plan de contrôle pour l’échange sécurisé de données – combinant ABAC, chiffrement de bout en bout, audit log immuable et DLP dans une couche de gouvernance unifiée sur tous les canaux où circulent des données sensibles : messagerie, partage de fichiers, SFTP, MFT, API et intégrations IA. C’est l’architecture qui permet aux organisations réglementées de répondre à la question : « Si un identifiant est compromis et qu’un attaquant s’authentifie, que peut-il réellement consulter, quels contrôles empêchent l’exfiltration, et quelle trace existe de ce qui s’est passé ? »
Ce que doivent faire les équipes conformité dès maintenant
L’agrégat de 24 milliards d’enregistrements est un catalyseur utile pour une réflexion que les équipes conformité, juridiques et sécurité devraient mener indépendamment de toute révélation ponctuelle.
Premièrement, la surveillance de l’exposition des identifiants doit être considérée comme une fonction d’évaluation continue des risques, et non comme une réaction ponctuelle aux révélations. Les services d’alerte de fuite commerciale peuvent fournir des notifications quasi temps réel lorsque des identifiants d’employés apparaissent dans des agrégats connus. Cette information doit déclencher une rotation immédiate des mots de passe et une revue des comptes – sans attendre le prochain cycle programmé.
Deuxièmement, l’application de l’authentification multifactorielle doit être vérifiée sur chaque application accédant à des données réglementées, et pas seulement sur le fournisseur d’identité principal. De nombreuses organisations appliquent la MFA à la frontière réseau, mais pas sur toutes les applications utilisées par leurs collaborateurs. Les portails de transfert de fichiers, plateformes de messagerie et espaces collaboratifs sont des angles morts fréquents.
Troisièmement, les programmes de conformité HIPAA, CMMC 2.0 et FedRAMP doivent inclure explicitement le risque de credential stuffing dans leurs analyses de risques. La question standard – « quelles sont les menaces pesant sur nos données réglementées ? » – doit intégrer une analyse spécifique de ce qui se passe si les identifiants d’un collaborateur sont compromis, à quelles données ils donnent accès, et si les contrôles d’accès et l’audit log en place suffisent à détecter et contenir l’incident.
Enfin, l’infrastructure de journalisation et de monitoring des environnements réglementés doit être revue à l’aune de la menace des sessions authentifiées mais malveillantes. Cela diffère du monitoring des échecs de connexion. Il s’agit d’analyser le comportement des sessions authentifiées pour détecter des schémas d’accès inhabituels – une capacité qui relève du plan de contrôle pour l’échange sécurisé de données, et non du périmètre réseau. Les organisations doivent aussi s’assurer que leur plan de réponse à incident couvre explicitement les scénarios de takeover de comptes, avec des procédures documentées pour chaque cadre réglementaire applicable.
L’agrégat de 24 milliards d’enregistrements sera dépassé par un plus gros dans quelques mois. L’écosystème infostealer, qui alimente les enregistrements les plus dangereux de ces collections, ne ralentit pas. La bonne réponse n’est pas la panique face à une révélation ponctuelle – c’est la construction d’une architecture qui transforme la compromission d’identifiants en incident contenu, et non en fuite de données.
Pour en savoir plus sur la façon dont Kiteworks réduit le risque de takeover de comptes par identifiants dans les environnements réglementés, réservez votre démo personnalisée dès maintenant.
Foire aux questions
Une « collection » d’identifiants est un ensemble compilé de couples identifiant/mot de passe issus de multiples fuites de données historiques – généralement des incidents survenus il y a plusieurs mois ou années. Les identifiants d’une collection ont souvent déjà été renouvelés ou les systèmes associés mis hors service. Les journaux d’infostealer sont d’une nature différente : ils résultent de malwares actifs sur des machines infectées, capturant les identifiants au moment même où ils sont utilisés. Ces journaux contiennent des identifiants fraîchement récoltés, donc plus susceptibles d’être encore valides. Pour les équipes de sécurité qui évaluent les agrégats de fuites, la part « collection » représente une exposition historique, tandis que la part « infostealer » correspond à un risque opérationnel immédiat. Les principes Zero trust ont été conçus pour des environnements où la validité des identifiants ne peut être présumée, en assurant une validation continue indépendante du seul identifiant. Les organisations doivent intégrer les scénarios spécifiques aux infostealers dans leur gestion des risques pour garantir que leurs capacités de détection et de réponse sont adaptées à la rapidité de cette menace.
Le credential stuffing est une attaque automatisée qui teste des couples identifiant/mot de passe issus d’agrégats de fuites sur des applications web cibles. Les outils modernes de credential stuffing changent d’adresse IP et varient les schémas de requêtes pour éviter la limitation de débit ou le blocage IP, rendant la détection basée sur le volume peu fiable. L’attaque réussit lorsqu’un couple volé est encore valide sur l’application cible – généralement parce que l’utilisateur réutilise ses mots de passe sur plusieurs services ou n’a pas renouvelé son identifiant depuis la fuite initiale. La détection nécessite une analyse comportementale des sessions authentifiées, et pas seulement la surveillance des échecs de connexion. Les journaux d’audit qui enregistrent chaque accès avec le contexte appareil, localisation et comportement sont essentiels pour identifier les sessions compromises a posteriori. L’intégration de ces journaux dans un SIEM avec analyse comportementale permet aux équipes sécurité de recevoir des alertes en temps réel avant qu’une session de credential stuffing ne débouche sur une exfiltration de données.
L’authentification multifactorielle complique fortement les attaques de credential stuffing et bloque la majorité des tentatives reposant sur des couples identifiant/mot de passe statiques. Cependant, la MFA n’est pas une défense absolue. Les infostealers modernes capturent les cookies de session du navigateur émis après une authentification MFA légitime – permettant ainsi le détournement de session sans repasser par la MFA. De plus, certaines implémentations MFA peuvent être contournées via des attaques SIM-swapping, des frameworks de phishing en temps réel ou l’ingénierie sociale. L’application de la MFA reste un contrôle essentiel, mais elle doit s’inscrire dans une architecture de défense en profondeur, et non être vue comme une solution complète. Les contrôles ABAC au niveau du plan de contrôle restent efficaces même si l’authentification est compromise, en imposant des règles sur ce qu’une session compromise peut atteindre. Associer la MFA à des règles de gouvernance des données qui limitent l’accès de chaque rôle réduit l’impact d’un contournement de la MFA.
Les obligations dépendent des données réglementées auxquelles le compte compromis a accédé. Dans le cadre de la conformité HIPAA, tout accès non autorisé à des informations médicales protégées (PHI) par une personne non autorisée est présumé constituer une fuite, nécessitant une notification aux personnes concernées et au Department of Health and Human Services, sauf si l’entité prouve une faible probabilité de compromission via une analyse de risque en quatre étapes. Pour la conformité CMMC 2.0, tout accès non autorisé à des CUI impose une déclaration d’incident sous 72 heures au DoD selon la clause DFARS 252.204-7012. Pour FedRAMP, tout accès non autorisé à des données fédérales impose une notification à l’agence concernée et à la CISA. Les programmes de conformité HIPAA et CMMC 2.0 doivent explicitement couvrir le takeover de comptes dans leurs plans de réponse à incident. Les organisations soumises au RGPD doivent également notifier l’autorité de contrôle compétente sous 72 heures en cas d’implication de données personnelles.
La réponse doit être hiérarchisée selon le profil de risque des identifiants exposés. Les collaborateurs ayant accès à des données réglementées – PHI, CUI, PII, dossiers financiers – doivent être prioritaires pour une rotation immédiate de leurs identifiants et une revue de compte dès qu’un service d’alerte signale leurs identifiants. La priorité suivante est d’appliquer la MFA sur toutes les applications utilisées pour accéder à ces contenus, et pas seulement sur le fournisseur d’identité principal. À moyen terme, il faut vérifier que les contrôles d’accès et le monitoring au niveau du contenu – et non seulement au périmètre réseau – permettent de détecter et contenir les sessions compromises avant toute exfiltration. Pour les organisations soumises à HIPAA ou CMMC, cette vérification doit être documentée dans le processus d’évaluation des risques imposé par ces cadres. Un audit de gestion des risques tiers pour les fournisseurs ayant accès à des environnements réglementés doit être mené en parallèle, car une infection infostealer sur un endpoint fournisseur expose autant qu’une infection interne.
Ressources complémentaires
- Article de blog Zero Trust Architecture : Never Trust, Always Verify
- Vidéo Microsoft GCC High : Les inconvénients qui poussent les sous-traitants de la défense vers des solutions plus intelligentes
- Article de blog Sécuriser les données classifiées après détection par DSPM
- Article de blog Instaurer la confiance dans l’IA générative grâce à une approche Zero Trust
- Vidéo Guide ultime pour le stockage sécurisé des données sensibles à destination des responsables IT