Posez-vous une question simple. Si demain l’un de vos commerciaux exporte 50 000 contacts pour les emporter chez la concurrence, le saurez-vous ? Si un attaquant utilise les identifiants d’un de vos collaborateurs pour aspirer votre base via API, le verrez-vous ? Si quelqu’un consulte des dossiers sensibles auxquels il n’a aucune raison d’accéder, recevrez-vous une alerte ?
Pour 90% des entreprises qui utilisent Salesforce, la réponse honnête à ces trois questions est non. Pas non, je ne sais pas. Non, je n’ai aucun moyen de le savoir.
C’est exactement ce que résout Event Monitoring. C’est aussi l’outil le moins activé du marché, alors qu’il est devenu indispensable face à l’explosion des attaques sur les CRM.
Le faux sentiment de sécurité sur Salesforce
Salesforce est sécurisée. Cette phrase, vous l’avez entendue cent fois. Elle est même vraie. La plateforme chiffre les données en transit et au repos, applique des audits réguliers, dispose de certifications comme ISO 27001, SOC 2 ou HDS. À ce niveau, peu d’éditeurs sont au niveau.
Mais cette sécurité ne couvre que l’infrastructure. Pas votre instance. C’est le modèle de responsabilité partagée, mal compris par la majorité des dirigeants.
Salesforce protège la plateforme. Vous protégez ce que vous y mettez et ce que les utilisateurs y font. Configuration des droits, suivi des connexions, détection des comportements anormaux, blocage des actions à risque. Toute cette couche est de votre responsabilité, et elle ne s’active pas par défaut.
Concrètement, prenez votre instance Salesforce telle qu’elle est livrée. Vous avez des utilisateurs, des objets, des données. Mais vous n’avez aucune visibilité opérationnelle sur ce qui s’y passe. Aucune. Si quelqu’un fait quelque chose qu’il ne devrait pas faire, vous ne le verrez pas. C’est ce trou que comble Event Monitoring.
Ce que vous ne voyez pas aujourd’hui sur votre CRM
Voici trois scénarios réels, observés régulièrement chez des clients Salesforce qui n’ont pas activé Event Monitoring.
L’export de base client avant un départ
Un commercial senior apprend en interne qu’il sera remercié dans les semaines à venir. Pendant un mois, il prépare son départ. Il télécharge progressivement ses comptes, ses contacts, ses opportunités via des rapports personnalisés. Il fait des exports CSV depuis les list views. Il prend même des captures d’écran pour les données qu’il ne peut pas exporter directement.
Le jour de son départ, il rejoint un concurrent direct avec votre base de données la plus stratégique. Personne n’a vu une alerte. Aucun système n’a flaggué le volume anormal d’exports. Vous l’apprendrez six mois plus tard, quand vos meilleurs clients commenceront à signer ailleurs.
L’accès inhabituel à des dossiers sensibles
Un membre de votre équipe interne consulte régulièrement les dossiers d’opportunités auxquels il n’a pas de raison fonctionnelle d’accéder. Pas une fois, pas deux fois. Quotidiennement. Il ne télécharge rien. Il regarde. Il copie peut-être manuellement des informations dans un document local.
Sans Event Monitoring, ce comportement est invisible. Le système enregistre techniquement l’accès, mais l’information n’est exploitée nulle part. Aucun manager n’a de tableau de bord qui dit : cet utilisateur consulte 40 fois plus de dossiers que la moyenne de son équipe.
L’usage anormal des API
Une intégration entre votre Salesforce et un outil tiers utilise un compte de service. Du jour au lendemain, le volume d’appels API issus de ce compte explose. Multiplié par dix. Il se passe potentiellement deux choses. Soit l’intégration est buggée et risque de saturer vos limites quotidiennes. Soit le compte a été compromis et un attaquant utilise ses droits pour aspirer votre base.
Sans Event Monitoring, vous ne le verrez ni dans un cas, ni dans l’autre. Vous découvrirez le problème quand vos limites API seront atteintes en pleine journée et que votre activité plantera, ou quand votre base aura été extraite.
Comment fonctionnent réellement les attaques
Pour comprendre l’urgence, il faut sortir du fantasme du hacker à capuche qui exploite une faille zero-day. Les attaques modernes sur Salesforce ne ressemblent pas à ça. Elles sont infiniment plus simples, et c’est ce qui les rend si efficaces.
La campagne UNC6040 : l’industrialisation du vishing
Le groupe que Google Threat Intelligence suit sous le nom UNC6040 (et que les médias relient à ShinyHunters) est devenu en 2025 le cauchemar des équipes sécurité Salesforce. Leur mode opératoire ne repose sur aucune vulnérabilité de la plateforme. Il repose sur le téléphone.
Le scénario est rodé. Un attaquant identifie un admin Salesforce ou un utilisateur clé via LinkedIn. Il l’appelle en se faisant passer pour le support IT interne ou pour Salesforce. Il l’amène progressivement, étape par étape, à valider l’installation d’une fausse application Data Loader connectée via OAuth. Une fois le token obtenu, l’attaquant exfiltre des volumes massifs de données depuis l’extérieur, sans jamais avoir besoin de se connecter au compte de l’utilisateur.
Le bilan public, tel que rapporté par la presse spécialisée, donne le vertige. Google a confirmé en août 2025 (TechCrunch) qu’une de ses propres instances Salesforce avait été compromise via cette même méthode. Selon les enquêtes de BleepingComputer, plusieurs marques du groupe LVMH (incluant Louis Vuitton, Dior et Tiffany) ainsi que Allianz Life et Qantas figurent parmi les victimes confirmées. Adidas, Pandora et Cisco ont également communiqué publiquement sur des incidents liés à cette campagne. Le scénario commun, c’est que les victimes n’ont rien vu venir. Elles ont reçu une demande de rançon, parfois plusieurs mois après l’exfiltration.
Le phishing vocal IA : l’accélération de 2025
Le clonage de voix par IA a changé la donne. Quelques secondes d’audio public suffisent pour cloner la voix de votre CEO ou de votre DSI. Et ces secondes sont disponibles partout : interviews, conférences, podcasts, vidéos LinkedIn.
L’attaque type se déroule comme ceci. L’attaquant identifie votre admin Salesforce. Il appelle depuis un numéro qui ressemble à un poste interne. La voix au bout du fil est celle de votre CEO. Le ton est pressé. Le scénario est crédible : conseil d’administration imminent, besoin urgent d’un rapport client, exfiltration vers un email externe. La pression sociale fait le reste.
Le cas le plus médiatisé reste celui rapporté par CNN en février 2024 : un employé de la branche hongkongaise du cabinet d’ingénierie britannique Arup a transféré environ 25 millions de dollars après une visioconférence où plusieurs participants, dont un faux CFO, étaient en réalité des deepfakes générés par IA. Aucune faille technique. Une simple confiance humaine, exploitée par une vidéo synthétique.
Aucun de ces scénarios n’exploite une faille technique de la plateforme. Tous reposent sur la confiance humaine et sur l’absence de garde-fou côté plateforme.
Event Monitoring expliqué simplement
Event Monitoring est un module additionnel de Salesforce, disponible via la suite Salesforce Shield ou en achat séparé. Si je devais le décrire en une image, je dirais que c’est la caméra de surveillance numérique de votre CRM.
Ce que ça fait concrètement
Event Monitoring capture, en quasi temps réel, l’ensemble des événements significatifs qui se produisent dans votre instance. Connexions, exports de rapports, requêtes API, accès à des list views, modifications de permissions, exécution d’Apex, téléchargements de fichiers. Tout est tracé, horodaté, attribué à un utilisateur.
Ces événements sont accessibles de plusieurs manières. Via des fichiers de log téléchargeables, via des objets Salesforce (les Big Objects), ou en streaming temps réel via la Platform Events API. Cela signifie que vous pouvez les consommer directement dans Salesforce, ou les exporter vers un SIEM externe (Splunk, Datadog, Sentinel) pour les corréler avec le reste de votre télémétrie sécurité.
Comment ça marche
L’outil ne se contente pas de logger. Il propose deux couches d’analyse.
La première, c’est la visualisation. Les fichiers de log peuvent être rapatriés dans CRM Analytics avec des dashboards préconçus. Qui consulte le plus de données ? Quels sont les exports anormaux de la semaine ? Quelles intégrations consomment le plus d’API ?
La deuxième, c’est la détection comportementale. Salesforce intègre des modèles de machine learning qui apprennent le comportement moyen de vos utilisateurs. Volume d’accès, géolocalisation, plages horaires, types de rapports. Quand un utilisateur sort significativement de ce comportement moyen, l’événement est flaggé. Un commercial qui consulte habituellement 30 comptes par jour et qui en consulte 800 du jour au lendemain ? Vous serez averti.
Pourquoi c’est devenu essentiel
Sans Event Monitoring, votre équipe sécurité est aveugle sur Salesforce. C’est aussi simple que ça. Si vous avez investi dans un SOC, dans des outils de détection sur votre infrastructure, sur vos endpoints, sur votre messagerie, mais que votre CRM (qui contient vos données les plus stratégiques) reste hors radar, vous avez une faille structurelle dans votre dispositif.
Et cette faille devient un risque opérationnel majeur dès lors que les attaquants ciblent explicitement les CRM, ce qui est désormais le cas. Pour creuser le sujet, la rubrique Security de Salesforce Ben publie régulièrement des analyses techniques pour les admins.
Les Transaction Security Policies : passer de la détection à la prévention
Event Monitoring vous donne la visibilité. Mais voir ne suffit pas. Il faut pouvoir agir. C’est le rôle des Transaction Security Policies, ou TSP, fournies par Real-Time Event Monitoring.
Les TSP sont des règles automatiques que vous configurez sur des événements spécifiques, avec une action associée. Trois types d’actions sont possibles : bloquer l’événement, exiger une authentification multi-facteurs, ou envoyer une notification.
Voici quelques exemples concrets d’usage.
Bloquer les exports de rapports volumineux. Vous configurez une règle sur l’événement ReportEvent : si un utilisateur exporte plus de 1 000 lignes, l’export est bloqué et un email est envoyé à l’admin. Cette règle seule aurait évité plusieurs des fuites massives observées en 2025.
Exiger une MFA sur des actions sensibles. Téléchargement d’une vue de liste contenant des données personnelles, accès à un objet contenant des informations financières. La MFA est demandée à l’utilisateur même s’il est déjà connecté. C’est une seconde barrière qui complique très significativement le travail d’un attaquant qui aurait obtenu des identifiants.
Détecter les connexions géographiquement impossibles. Un utilisateur se connecte depuis Paris à 14h, puis depuis Moscou à 14h05. C’est physiquement impossible. La règle bloque la seconde connexion et alerte l’équipe sécurité.
Plafonner les volumes API par utilisateur. Une intégration qui dépasse soudainement son volume normal d’appels est automatiquement bloquée. Ce qui transforme une compromission de token API en simple incident technique au lieu d’une exfiltration massive.
Pour les cas plus complexes, vous pouvez écrire des règles en Apex. Par exemple : bloquer les exports volumineux pour tous les utilisateurs sauf ceux du profil Data Steward. La logique métier est ainsi parfaitement adaptée à votre organisation.
C’est ce passage de la détection à la prévention automatique qui transforme Event Monitoring d’un outil de forensic en un véritable bouclier en temps réel.
Pourquoi les entreprises n’activent pas Event Monitoring
Si l’outil est si essentiel, pourquoi si peu d’entreprises l’utilisent ? Trois raisons reviennent systématiquement sur le terrain.
La première, c’est le manque de connaissance. Beaucoup de DSI et de RSSI ne savent tout simplement pas qu’Event Monitoring existe. Salesforce est perçu comme un outil métier, géré par les directions commerciales. Le sujet sécurité n’arrive pas naturellement à la direction technique.
La deuxième, c’est la perception de complexité. Event Monitoring produit une volumétrie de logs importante. Les configurer, les visualiser, les corréler demande une compétence spécifique. Beaucoup d’équipes pensent à tort qu’il faut un SIEM connecté pour en tirer parti, alors que les dashboards CRM Analytics offrent déjà une utilisation immédiate.
La troisième, c’est le coût mal compris. Event Monitoring se facture en pourcentage de votre contrat Salesforce. Lorsque ce coût apparaît seul, sans mise en perspective avec le risque qu’il couvre, il peut paraître élevé. Pour une organisation qui gère des millions de dollars de pipeline commercial dans Salesforce, c’est en réalité une assurance dont le rapport coût/protection est imbattable.
Aucune de ces trois raisons ne tient face à l’évolution du paysage des menaces. Les attaques sur Salesforce ne sont plus marginales. Elles sont systématiques, industrielles, et elles ciblent toutes les tailles d’entreprise.
Conclusion : ne pas attendre l’incident
Aujourd’hui, la question n’est plus de savoir si votre instance Salesforce sera ciblée. C’est de savoir quand. Les groupes comme UNC6040 ont industrialisé l’attaque des CRM. Les outils de deepfake vocal sont accessibles à n’importe quel attaquant motivé. Et la plupart des entreprises n’ont aucun moyen de détecter ces actions, encore moins de les bloquer.
Event Monitoring n’est pas un nice-to-have. C’est devenu le minimum syndical pour toute organisation qui traite des données commerciales sensibles, financières, personnelles ou stratégiques dans son CRM.
Chez Cloud Girafe, nous accompagnons les directions techniques et CRM dans le déploiement et la configuration d’Event Monitoring et des Transaction Security Policies. Nous commençons par un audit de votre posture sécurité actuelle, nous identifions vos zones aveugles, puis nous mettons en place les règles adaptées à vos risques réels.
Si vous lisez cet article en pensant “je n’ai aucune visibilité sur ce qui se passe dans mon CRM”, c’est probablement le bon moment pour en parler. Contactez-nous sur cloudgirafe.fr pour planifier un audit sécurité Salesforce.
