Mesures de sécurité à prendre en compte dans Salesforce
Salesforce est devenu en quelques années l’un des leaders incontournables des solutions CRM (Customer Relationship Management) en mode SaaS. Utilisé par des milliers d’entreprises à travers le monde, cet outil centralise des données critiques : contacts clients, opportunités commerciales, historiques d’échanges et bien d’autres informations sensibles. Dans un contexte où la protection des données est au cœur des préoccupations des organisations, il est essentiel de comprendre comment sécuriser efficacement un environnement Salesforce.
Contrairement à une solution on-premise où l’entreprise maîtrise l’ensemble de la stack technique, Salesforce repose sur un modèle de responsabilité partagée. Cela signifie que si Salesforce assure la sécurité de l’infrastructure sous-jacente et le développement sécurisé du logiciel, l’organisation reste responsable de la configuration et de la gouvernance de sa propre instance. Dans cet article, nous allons explorer les différents leviers de sécurité sur lesquels vous avez la main pour protéger votre environnement Salesforce.
Le modèle de responsabilité partagée
Lorsque vous utilisez un logiciel SaaS comme Salesforce, il est important de comprendre que vous ne contrôlez pas tout. Le modèle de responsabilité partagée définit clairement les rôles de chacun :
Ce que Salesforce gère :
- La sécurité physique des datacenters
- La disponibilité de la plateforme
- Les sauvegardes de l’infrastructure
- Les correctifs de sécurité de la plateforme
- La conformité aux standards de sécurité (ISO 27001, SOC 2, etc.)
Ce que votre organisation gère :
- La gestion des accès et des authentifications
- La configuration des profils et des permissions
- La surveillance des activités et des logs
- L’intégration avec des applications tierces
- La sensibilisation des utilisateurs
On ne peut donc pas faire grand-chose avec un logiciel natif au niveau de la sécurité infrastructure. C’est Salesforce qui maîtrise cette couche. En revanche, la configuration de votre instance est entièrement sous votre responsabilité. C’est là que se jouent la plupart des incidents de sécurité : mauvaise gestion des droits, authentification faible, ou intégrations mal sécurisées.
Les profils et les permission sets
La gestion des droits d’accès est le pilier de la sécurité dans Salesforce. Le modèle de permissions repose sur deux concepts principaux : les profils et les permission sets.
Les profils
Un profil définit les permissions de base d’un utilisateur. Il contrôle :
- L’accès aux objets (lecture, création, modification, suppression)
- Les permissions applicatives
- Les paramètres de sécurité (changement de mot de passe, restrictions IP)
- Les heures de connexion autorisées
Chaque utilisateur doit obligatoirement avoir un profil. Salesforce fournit des profils standards (System Administrator, Standard User, etc.), mais il est recommandé de créer des profils personnalisés adaptés aux besoins de votre organisation.
Les permission sets
Les permission sets permettent d’ajouter des permissions supplémentaires à un utilisateur sans modifier son profil. Ils offrent une flexibilité importante pour gérer des cas particuliers. Par exemple, un utilisateur avec un profil “Standard User” peut recevoir temporairement un permission set lui donnant accès à certains rapports confidentiels.
Bonnes pratiques :
- Appliquer le principe du moindre privilège : donner uniquement les accès nécessaires
- Réviser régulièrement les permissions attribuées
- Utiliser les permission sets pour les besoins temporaires ou spécifiques
- Documenter la logique de chaque profil et permission set créé
L’authentification OAuth et les intégrations
Salesforce permet de s’intégrer avec de nombreuses applications tierces, que ce soit pour synchroniser des données, automatiser des processus ou enrichir les fonctionnalités. Ces intégrations reposent majoritairement sur le protocole OAuth 2.0.
Le protocole OAuth 2.0
OAuth permet à une application tierce d’accéder à votre instance Salesforce sans que vous ayez à partager vos identifiants. Le principe est simple : l’utilisateur autorise l’application, et Salesforce génère un jeton d’accès (token) qui sera utilisé pour les échanges futurs.
Il existe plusieurs flux OAuth selon le contexte :
- Web Server Flow : pour les applications web avec un backend sécurisé
- User-Agent Flow : pour les applications JavaScript côté client
- Username-Password Flow : déconseillé car il nécessite de partager les identifiants
- JWT Bearer Flow : pour les intégrations server-to-server
Sécuriser vos intégrations OAuth
Les applications connectées (Connected Apps) sont le point d’entrée des intégrations OAuth. Voici quelques recommandations :
- Limiter les scopes : ne donner que les permissions strictement nécessaires à l’application tierce
- Utiliser des certificats : pour les flux JWT, utilisez des certificats pour authentifier les intégrations
- Mettre en place des IP restrictions : limitez les adresses IP autorisées pour les connexions OAuth
- Auditer régulièrement : vérifiez les applications connectées actives et révoquez celles qui ne sont plus utilisées
Il est crucial de comprendre que chaque application tierce représente un vecteur d’attaque potentiel. Une application compromise pourrait accéder aux données de votre Salesforce si les permissions sont trop larges.
Attention aux secrets OAuth dans le code source
Un point critique souvent négligé : le protocole OAuth repose sur des secrets (client secrets, tokens, clés privées) qui doivent rester confidentiels. Malheureusement, ces secrets se retrouvent régulièrement exposés dans le code source développé en interne, par des consultants externes ou même par des stagiaires.
Un secret OAuth compromis permet à un attaquant d’accéder à votre instance Salesforce avec les mêmes droits que l’application légitime. Il est donc impératif de :
- Monitorer vos dépôts de code : mettez en place des outils de scan automatique pour détecter les secrets exposés (GitHub Advanced Security, GitGuardian, TruffleHog, etc.)
- Intégrer cette surveillance dans votre processus DevSecOps : la détection de secrets doit faire partie intégrante de votre chaîne CI/CD
- Former les développeurs : sensibilisez vos équipes internes, consultants et stagiaires aux risques liés à l’exposition de secrets
- Utiliser des gestionnaires de secrets : stockez les credentials dans des coffres-forts dédiés (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Révoquer immédiatement : en cas de découverte d’un secret exposé, régénérez-le sans délai
Les applications tierces : un risque à maîtriser
L’écosystème Salesforce propose des milliers d’applications disponibles sur l’AppExchange. Ces applications peuvent enrichir considérablement les fonctionnalités de votre CRM, mais elles représentent également un risque de sécurité.
Évaluer une application tierce
Avant d’installer une application, posez-vous les questions suivantes :
- Quelles données l’application va-t-elle manipuler ?
- Quelles permissions demande-t-elle ?
- Le fournisseur est-il certifié par Salesforce ?
- L’application dispose-t-elle d’une politique de sécurité claire ?
- Y a-t-il eu des incidents de sécurité connus ?
Salesforce propose un programme AppExchange Security Review qui évalue la sécurité des applications. Privilégiez les applications qui ont passé ce processus.
Surveiller les applications installées
Une fois installées, les applications doivent être surveillées :
- Vérifiez régulièrement les permissions accordées
- Surveillez les logs d’accès des applications
- Mettez en place des alertes en cas d’activité suspecte
- Désinstallez les applications non utilisées
N’oubliez pas que chaque application tierce a accès à votre base de données Salesforce selon les permissions que vous lui avez accordées. Une fuite de données chez un fournisseur tiers pourrait impacter votre organisation.
Extraire les logs d’audit : une astuce méconnue
Salesforce propose différents types de logs pour surveiller l’activité de votre instance. Les principaux sont :
- Setup Audit Trail : enregistre les modifications de configuration
- Login History : trace les connexions utilisateurs
- Field History Tracking : suit les modifications sur certains champs
Le développeur : un tiers critique à superviser
Il est essentiel de considérer le développeur ou l’éditeur de l’application comme un tiers critique dans votre chaîne de sécurité. En effet, dès lors qu’une application tierce accède à votre CRM, son fournisseur dispose potentiellement d’un accès à vos données sensibles. Cette relation doit donc être intégrée dans votre processus de supervision des tiers (Third-Party Risk Management).
Concrètement, cela implique :
- Évaluer la maturité sécurité du fournisseur : demandez des audits de sécurité, des certifications (ISO 27001, SOC 2), et une politique de gestion des incidents
- Formaliser la relation contractuelle : incluez des clauses de confidentialité, de traitement des données (RGPD), et de notification en cas de faille de sécurité
- Mettre en place une surveillance continue : intégrez le fournisseur dans vos revues périodiques de risques tiers et suivez les incidents de sécurité publics le concernant
- Prévoir une stratégie de sortie : documentez comment désinstaller l’application et récupérer vos données en cas de rupture ou de compromission
N’oubliez pas qu’une faille chez un fournisseur tiers peut avoir un impact direct sur votre organisation. Traitez ces relations avec le même niveau de rigueur que vos autres prestataires critiques.
L’extraction des Security Events
Salesforce commercialise un module appelé Event Monitoring qui permet d’accéder à des logs détaillés sur les événements de sécurité. Cependant, ce module est payant et n’est pas accessible à toutes les organisations.
Il existe une astuce peu connue pour extraire certains logs d’audit sans avoir à payer le module Event Monitoring. Il suffit d’accéder à l’URL suivante dans votre instance Salesforce :
/setup/org/orgsetupaudit.jsp?setupid=SecurityEvents&retURL=%2Fui%2Fsetup%2FSetup%3Fsetupid%3DSecurity
Cette URL vous permet d’accéder à l’interface des Security Events qui enregistre les événements critiques tels que :
- Les modifications de permissions
- Les changements de profils utilisateurs
- Les créations ou suppressions d’utilisateurs
- Les modifications des paramètres de sécurité
Comment y accéder :
- Connectez-vous à votre instance Salesforce
- Dans la barre d’adresse, après le nom de votre instance (par exemple
https://votreinstance.my.salesforce.com), ajoutez l’URL ci-dessus - Vous accédez directement à la page des Security Events
Cette fonctionnalité est particulièrement utile pour les organisations qui n’ont pas les moyens d’investir dans Event Monitoring mais qui souhaitent tout de même maintenir un niveau de traçabilité acceptable sur les événements de sécurité.
Bonnes pratiques d’utilisation des logs :
- Exportez régulièrement les logs pour analyse
- Mettez en place des alertes sur les événements critiques
- Conservez les logs pendant une durée conforme à votre politique de sécurité
- Intégrez les logs Salesforce dans votre SIEM si vous en avez un
Conclusion
La sécurité d’un environnement Salesforce ne se limite pas aux fonctionnalités natives de la plateforme. Elle repose sur une combinaison de bonnes pratiques de configuration, de gouvernance des accès et de surveillance continue. Le modèle de responsabilité partagée implique que votre organisation joue un rôle actif dans la protection de ses données.
Les leviers présentés dans cet article – gestion des profils et permission sets, sécurisation des authentifications OAuth, maîtrise des applications tierces et exploitation des logs d’audit – constituent les fondamentaux d’une stratégie de sécurité efficace sur Salesforce.
N’oubliez pas que la sécurité est un processus continu. Les menaces évoluent, les configurations changent, et de nouvelles applications sont installées. Il est donc essentiel de mettre en place une démarche d’amélioration continue, en réalisant des audits réguliers de votre instance et en sensibilisant vos utilisateurs aux bonnes pratiques.
La sécurité de votre Salesforce est entre vos mains. À vous de jouer !