Auditer la sécurité d'une org Salesforce : les huit points à contrôler, dans l'ordre

Les droits effectifs des comptes non humains

Commencez par eux, pas par les utilisateurs. Un compte d'intégration porte souvent les droits les plus larges de l'org et les contrôles les plus faibles : pas de MFA, pas de restriction d'adresse IP, un mot de passe qui n'expire pas.

Le droit à mesurer est le droit effectif — la somme du profil et de tous les ensembles d'autorisations attribués. Lire le profil seul sous-estime systématiquement.

Où le vérifier : Configuration › Utilisateurs, filtrer sur la licence « Salesforce Integration » et les profils d'API, puis lire les droits cumulés (profil + ensembles d'autorisations) de chaque compte — Utilisateur d'intégration (aide Salesforce)

Détecteur PrivilegedAccountHygieneCollector · constat Security:PrivHygiene:OverScoped · seuil : un compte technique portant ModifyAllData, ViewAllData ou AuthorApex

L'état d'authentification, croisé aux droits

La question utile n'est pas « combien de comptes sans MFA ? » mais « quels comptes sans MFA portent des droits larges ? ». Le croisement est ce qui transforme une liste en priorité.

Où le vérifier : Configuration › Ensembles d'autorisations et Profils, permission « Authentification multifacteur pour les connexions à l'interface utilisateur », croisée avec les permissions d'administration du même compte — MFA (aide Salesforce)

Détecteur MfaGapCollector · constat Security:MfaGap · seuil : tout compte actif à droits élevés sans MFA obligatoire ; listé jusqu'à 50 comptes, au-delà le constat le dit

Les applications connectées et leurs portées OAuth

Chaque application autorisée détient un jeton qui survit au départ de la personne qui l'a autorisée. Trois questions : quelles portées ont été accordées, quand l'application a-t-elle servi pour la dernière fois, et qui l'a autorisée. Une application dormante avec une portée full est un accès permanent que personne ne surveille.

Où le vérifier : Configuration › Applications connectées – Utilisation OAuth : colonne de dernier usage, nombre de jetons actifs, portées accordées — Gérer l'accès OAuth (aide Salesforce)

Détecteur ConnectedAppRiskCollector · constat Security:OAuthApp · seuil : dormance à 90 jours, score de risque à partir de 40 (portée full ou refresh_token = 30 points), élevé à 70

Les accès invités et les communautés

Les profils invités des sites Experience Cloud héritent parfois de droits objet non voulus. La donnée exposée l'est alors à un visiteur non authentifié. Ce point est rapide à contrôler et produit régulièrement des surprises.

Où le vérifier : Configuration › Sites numériques, puis le profil invité de chaque site › Autorisations d'objet et Paramètres de partage pour les utilisateurs invités — Profil utilisateur invité (aide Salesforce)

Détecteur GuestExposureCollector · constat Security:GuestExposure · seuil : tout objet en lecture ou écriture pour un profil invité

Les certificats et les communications sortantes

Un certificat expiré ne provoque pas une alerte de sécurité : il provoque une panne d'intégration, un vendredi soir. Relevez les échéances, et l'état des points de terminaison sortants — un endpoint qui échoue silencieusement est un flux métier qui ne passe plus.

Où le vérifier : Configuration › Gestion des certificats et des clés (échéances), et Configuration › Identifiants nommés pour l'inventaire des destinations sortantes — Certificats et clés (aide Salesforce)

Détecteur CertExpiryService · constat CertExpiry:OrgCert · seuil : certificat expirant sous 30 jours, endpoint sortant en échec répété — palier PME & ETI, désactivé à l'installation

La marge sur les limites de la plateforme

Les limites Salesforce — appels API par jour, stockage, traitements asynchrones simultanés, lots Bulk — se consomment progressivement. On ne les découvre qu'au plafond, c'est-à-dire au pire moment. La mesure utile est la marge restante et sa tendance, pas la valeur instantanée.

Où le vérifier : Configuration › Informations sur la société (stockage), Configuration › Utilisation des API, et l'API REST /limits pour le reste — Limites et allocations des requêtes API (documentation Salesforce)

Détecteur OrgLimitsCollector · constat Limits:DailyApiRequests · seuil : marge restante et tendance sur 24 h, pas la valeur instantanée — palier Découverte, actif à l'installation

Le code déployé et la dérive de configuration

Le dernier point est le plus coûteux à instruire : qualité du code Apex et LWC exécuté dans l'org, et écart entre la configuration actuelle et un état de référence. Le gain est réel mais diffus — c'est ce qu'on regarde quand les six premiers points sont tenus.

Où le vérifier : Configuration › Classes Apex et Composants Lightning pour le code de votre org (le corps des classes de paquets managés revient masqué) ; Configuration › Piste d'audit de configuration pour la dérive — Piste d'audit de configuration (aide Salesforce)

Détecteur TechDebtCollector · constat CodeQuality:TechDebt · seuil : dette technique par fichier et écart à l'état de référence — palier TPE

Le partage par défaut, les règles et la hiérarchie de rôles

Les droits ne sont qu'une moitié de l'accès. L'autre moitié est le partage : un objet en lecture publique par défaut expose tous ses enregistrements sans qu'aucune permission ne l'ait décidé, et un rôle placé haut dans la hiérarchie voit tout ce qui se trouve en dessous. Ce point était longtemps absent des audits de configuration parce qu'il se lit dans un tableau que personne n'ouvre. Il se lit pourtant par simple requête.

Où le vérifier : Configuration › Paramètres de partage, tableau des valeurs par défaut, colonnes interne et externe ; Configuration › Rôles pour la hiérarchie — Valeurs par défaut à l'échelle de l'organisation (aide Salesforce)

Détecteur SharingExposureCollector · constat Security:Sharing:OWD · seuil : lecture ou lecture/écriture publique, interne ou externe — quatre cas, l'interne en écriture sort en sévérité Élevée

Pourquoi un audit annuel ne suffit pas

Ces huit points ont un défaut commun : leur résultat est périmé le lendemain. Un ensemble d'autorisations attribué, une application connectée autorisée, un certificat qui approche de son échéance — chacun change l'état sans rien déclencher.

C'est pourquoi un audit annuel mesure surtout le moment où il a eu lieu. Ce qui protège, c'est la mesure répétée et la comparaison à l'état précédent.

Faut-il un outil pour faire cet audit ?

Non pour la première passe : les huit points ci-dessus se contrôlent à la main, avec du temps. Oui pour la répétition : c'est la fréquence, pas la profondeur, qui demande de l'outillage.

Que doit produire un audit exploitable ?

Un constat exploitable nomme sa cible — le profil, l'application, le certificat —, dit pourquoi c'est grave, et propose une remédiation que quelqu'un peut exécuter. Une liste de scores sans cible nommée ne se transforme pas en action.