Auditer la sécurité d'une org Salesforce : les points à contrôler, dans l'ordre
L'ordre compte. Ces sept points sont classés par rendement : le premier révèle le plus de risque pour le moins d'effort, le dernier demande le plus de travail pour le gain le plus diffus.
Ce que Health Check ne dit pas
Le Health Check natif note des réglages de session et de mot de passe contre
une base de référence. Il ne regarde ni les droits effectifs, ni les applications connectées,
ni les intégrations sortantes, ni le code. Un score de 90 % au Health Check est
compatible avec un compte d'intégration qui cumule Modifier toutes les données
et une API sans MFA.
1. 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.
2. 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é.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
Une méthode, pas une campagne
Ces sept 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 sept 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.