Glossaire de la sécurité Salesforce

Droits et identités

Profil

Le profil est le socle d'habilitation d'un utilisateur Salesforce : chaque compte en porte un et un seul. Il est rattaché à une licence utilisateur et porte un premier jeu de droits objet, champ et système.

Salesforce le modélise lui-même comme un ensemble d'autorisations particulier — celui dont l'indicateur IsOwnedByProfile est vrai. Conséquence pratique : une lecture des attributions d'un utilisateur ramène son profil et ses ensembles d'autorisations dans la même réponse.

Ensemble d'autorisations

Un ensemble d'autorisations (permission set) est un paquet de droits attribuable à un utilisateur en plus de son profil, sans limite de nombre. Un groupe d'ensembles d'autorisations en réunit plusieurs sous une seule attribution.

Les droits s'additionnent : un ensemble d'autorisations élargit ce que le profil accorde, il ne le restreint pas — sauf neutralisation explicite à l'intérieur d'un groupe. Un ensemble d'autorisations sans aucun titulaire actif reste une surface d'octroi disponible : il ne coûte rien tant que personne ne le reçoit, et tout le jour où quelqu'un le reçoit.

Droit effectif

Le droit effectif d'un utilisateur est l'union de tout ce que lui accordent son profil et chacun de ses ensembles d'autorisations attribués. C'est la seule vue qui dise ce qu'un compte peut réellement faire.

Aucun écran natif ne l'affiche sous une forme exploitable à l'échelle d'une org. C'est pourquoi une revue d'habilitation conduite profil par profil rate structurellement les cumuls : elle examine des couches, pas des sommes.

Permission toxique

Une permission toxique est un ensemble de droits dont la réunion sur un même compte permet une action qu'aucun de ces droits ne permettait seul. Aucun des éléments n'est anormal isolément : c'est ce qui explique qu'elle survive aux revues menées droit par droit.

La forme la plus documentée sur Salesforce associe Modifier toutes les données ou Afficher toutes les données, l'accès API activé, et l'absence de second facteur. Un identifiant compromis devient alors un accès complet, sans interaction humaine et sans trace d'interface. Les combinaisons courantes, en détail.

Blast radius

Le blast radius, ou rayon d'impact, d'un compte est l'étendue de ce qu'obtiendrait un attaquant qui en prendrait le contrôle. Sur une org Salesforce il se mesure sur le droit effectif : portée des lectures et des écritures, accès API, capacité d'attribuer des droits à d'autres comptes.

La notion déplace la question de « ce droit est-il légitime ? » vers « que se passe-t-il si ce compte tombe ? ». C'est la seconde qui hiérarchise correctement une population de comptes privilégiés.

Compte d'intégration

Un compte d'intégration est un utilisateur Salesforce qui ne correspond à aucune personne : il porte l'authentification d'un système tiers, d'un ETL ou d'un middleware.

Il concentre deux tensions opposées : on lui accorde des droits larges parce qu'il automatise, et on lui épargne le second facteur pour la même raison. Un compte d'intégration qui porte aussi Modifier toutes les données amplifie le rayon d'impact de la moindre fuite d'identifiant, et il n'a personne pour signaler qu'il se comporte anormalement.

Authentification multifacteur (MFA)

Sur Salesforce, l'exigence d'authentification multifacteur est portée par une permission système attribuée via un profil ou un ensemble d'autorisations, non par un réglage global de l'org. Un utilisateur qui ne reçoit cette permission par aucune de ses attributions n'est pas couvert par elle.

La couverture MFA d'une org est donc une population à énumérer, pas une case à cocher. Réserve utile : une org qui délègue le second facteur à son fournisseur d'identité ne l'exprime pas par cette permission — l'état réel d'un compte n'est pas toujours déductible d'une seule lecture, et une mesure honnête le dit.

Visibilité des données

OWD (partage par défaut de l'organisation)

Le partage par défaut à l'échelle de l'organisation (organization-wide default, OWD) fixe, objet par objet, ce qu'un utilisateur voit des enregistrements qu'il ne possède pas. Il constitue le plancher de visibilité : règles de partage, hiérarchie des rôles et partages manuels ne peuvent que l'élargir.

Salesforce en tient deux valeurs distinctes par objet, une interne et une externe. Un objet en lecture-écriture publique côté externe est l'exposition la plus large qu'une org puisse déclarer : elle atteint les utilisateurs de communauté et de portail.

Partage

Le partage (sharing) est le mécanisme par lequel Salesforce décide, enregistrement par enregistrement, qui voit quoi au-delà du plancher fixé par l'OWD : règles de partage, hiérarchie des rôles, partage manuel, partage géré par le code.

Il se contourne par le code et par l'automatisation. Une classe Apex déclarée without sharing, ou un flux qui s'exécute en mode système sans partage, lit les enregistrements sans appliquer la visibilité de l'utilisateur courant — ni sa sécurité au niveau du champ. Ces exécutions-là sont légitimes dans certains cas et invisibles dans tous : elles se recensent, elles ne se devinent pas.

FLS (sécurité au niveau du champ)

La sécurité au niveau du champ (field-level security, FLS) détermine quels champs d'un objet un profil ou un ensemble d'autorisations peut lire et modifier. Elle est indépendante des droits objet : un utilisateur autorisé à lire un enregistrement peut être privé de l'un de ses champs.

C'est la couche où se joue l'exposition des données réglementées — numéro de sécurité sociale, IBAN, données de santé, salaire, date de naissance. Le pire cas n'est pas un champ sensible lisible par trop d'internes, mais un champ sensible lisible par un profil invité ou par un profil externe.

Profil invité

Le profil invité est le profil qu'endosse tout visiteur non authentifié d'un site Experience Cloud. Ses droits objet s'appliquent donc à quiconque atteint l'URL du site.

Un droit de lecture accordé là est une publication. Un droit de création, de modification ou de suppression permet à un visiteur anonyme d'écrire dans l'org — et un droit Afficher tout ou Modifier tout sur un objet y expose la table entière. C'est du contrôle d'accès, pas de la configuration de site ; il se relit avec les mêmes yeux qu'un profil interne privilégié.

Experience Cloud

Experience Cloud est la brique Salesforce qui publie des sites — portails clients, espaces partenaires, sites publics — adossés aux données de l'org.

Elle déplace la frontière de l'org : les mêmes objets servent alors des utilisateurs internes, des utilisateurs externes authentifiés et des visiteurs anonymes, chacun avec sa propre couche de droits. Le partage externe et le profil invité deviennent des contrôles de première ligne, et non des réglages de projet web.

Accès applicatifs et flux sortants

Application connectée

Une application connectée (connected app) est la déclaration, dans une org Salesforce, d'un système externe autorisé à s'authentifier et à appeler son API. Chaque autorisation accordée par un utilisateur produit un jeton qui reste valable jusqu'à sa révocation explicite.

Une application autorisée il y a deux ans conserve donc son accès tant que personne ne le retire. La question utile n'est pas « qui a accès ? » mais « quelles portées ont été accordées, à quoi, et lesquelles servent encore ? ». Un jeton jamais utilisé est un identifiant permanent oublié.

Portée OAuth

Une portée OAuth (scope) délimite ce qu'un jeton permet de faire : api pour l'accès aux données, web pour la session, refresh_token pour la reconduction sans réauthentification, full pour tout ce que l'utilisateur porteur peut faire. full accordé à une intégration qui n'a besoin que de lire une liste est le cas d'école du privilège excessif.

Elle n'est pas également lisible selon le modèle de déclaration. Les applications clientes externes exposent un indicateur par portée, donc la portée s'y lit. Une application connectée classique n'expose aucune portée à l'API Apex : ce qui s'en dit alors est une déduction, et un outil sérieux annonce laquelle des deux il vous montre.

Named Credential

Un Named Credential (identifiant nommé) est un objet de configuration Salesforce qui associe une URL de destination à un mode d'authentification, et que le code appelle par son nom sans jamais manipuler le secret.

Il a une seconde vertu, souvent négligée : c'est l'inventaire le plus fiable des destinations sortantes d'une org. Ce que le code appelle vraiment y est déclaré, ce qui en fait le point de départ naturel d'une cartographie des flux tiers.

Certificat

Dans une org Salesforce, « certificat » désigne deux objets différents : celui que l'org présente pour s'authentifier auprès d'un tiers, et le certificat TLS présenté par un point de terminaison qu'elle appelle. Les premiers sont stockés dans l'org avec leur date d'expiration ; les seconds appartiennent au serveur distant.

La distinction est opérationnelle : le code exécuté dans une org ne peut pas lire le certificat d'un pair distant. Surveiller ces échéances-là suppose une sonde extérieure à l'org, et les échéances internes ne se lisent pas davantage en pure lecture : elles vivent dans l'objet Tooling Certificate, atteint par un self-callout via Named Credential. Dans les deux cas, un certificat expiré fait tomber des intégrations du jour au lendemain, sans qu'aucune configuration ait changé.

Tenue de la plateforme

Limite de gouverneur

Une limite de gouverneur est un plafond que Salesforce applique à une transaction isolée : 50 000 lignes lues en SOQL, 10 000 lignes modifiées, 100 requêtes en contexte synchrone. Le dépassement lève une exception que le code ne peut pas intercepter : la transaction est annulée entière.

À ne pas confondre avec les limites d'org — appels API sur 24 heures, stockage de données et de fichiers, traitements asynchrones — qui se consomment sur une fenêtre glissante et se mesurent en pourcentage d'un quota. Les premières se dépassent brutalement et bloquent un traitement ; les secondes se remplissent lentement et se surveillent par leur marge restante.

EPT (Experienced Page Time)

L'EPT (Experienced Page Time) est la durée, en millisecondes, entre la demande d'une page Lightning et le moment où l'utilisateur peut réellement s'en servir. Salesforce la publie par vue de page dans les journaux d'Event Monitoring, et non dans un objet interrogeable en SOQL.

Deux conséquences. Sans Event Monitoring, la mesure n'existe pas dans l'org. Et une moyenne d'EPT ne dit rien d'utile : ce sont les centiles hauts qui décrivent ce que subit la queue des utilisateurs, celle qui ouvre les tickets.

Dérive de configuration

La dérive de configuration est l'écart entre l'état d'une org à un instant donné et son état de référence antérieur. Elle ne suppose ni faute ni attaque : elle constate qu'un profil, un ensemble d'autorisations ou une application connectée n'est plus ce qu'il était au dernier relevé.

Elle se détecte en comparant des empreintes plutôt que des valeurs — une empreinte cryptographique de l'état, par composant — ce qui permet de dire « ceci a changé » sans conserver le détail de ce qui a changé. Corollaire : la première mesure ne peut rien détecter, elle pose la référence.

Vocabulaire de la mesure

Constat

Un constat (finding) est l'unité de résultat d'une analyse de posture : un problème identifié, sa cible, sa sévérité et le message qui l'explique. Il porte une clé de dédoublonnage, de sorte que le même problème revu à l'analyse suivante met à jour le constat existant au lieu d'en créer un nouveau.

De là découlent deux compteurs qui valent mieux qu'un volume brut : le nombre d'occurrences, qui distingue le récurrent de l'isolé, et le nombre de régressions, qui compte les fois où le problème est revenu après avoir été refermé — c'est-à-dire les corrections qui n'ont pas tenu.

Sévérité

La sévérité classe un constat sur une échelle fermée — Info, Faible, Moyenne, Élevée, Critique — et détermine sa priorité de traitement.

Une échelle n'a de valeur que si chaque niveau pèse sur un indice mesurable : sinon c'est une étiquette, et tout finit en « élevé ». Le modèle usuel retire des points d'un indice partant de 100, davantage pour un critique que pour un moyen, rien pour une information.

Exposition en euros

L'exposition en euros traduit une population de constats ouverts en un montant unique : le nombre de constats de chaque couple sévérité-catégorie est multiplié par une pondération en euros, puis sommé. C'est un modèle d'estimation, de la famille FAIR simplifiée — pas une perte observée.

Sa valeur dépend entièrement des pondérations retenues, qui sont un paramètre de l'entreprise et non une donnée de marché. Un montant publié sans ses pondérations n'est pas contrôlable. Ce qu'il sert à faire est de hiérarchiser deux files de travail, pas à provisionner un risque.

Conformité

DORA

DORA (règlement UE 2022/2554, applicable depuis le 17 janvier 2025) impose aux entités financières de l'Union un cadre de résilience opérationnelle numérique. Le critère d'entrée est l'activité exercée, pas la taille ; la taille joue ensuite sur l'intensité des obligations.

Côté org Salesforce, cinq articles sont observables techniquement : 7 (tenue des systèmes), 8 (identification des risques), 9 (protection et prévention), 10 (détection des activités anormales) et 28 (risque lié aux prestataires tiers). Le reste relève de la gouvernance, du contrat ou de l'organisation : aucun détecteur d'org ne les voit. Le détail article par article.

NIS2

NIS2 (directive UE 2022/2555) impose des mesures de gestion des risques de cybersécurité aux entités des secteurs listés en annexes I et II, avec un seuil de principe à 50 salariés ou 10 M€ de chiffre d'affaires — le critère est alternatif. C'est la transposition nationale qui fixe le périmètre applicable, pas la directive seule.

Ses exigences techniques se concentrent à l'article 21(2), qui compte dix points. Six touchent une org Salesforce : (b), (d), (e), (f), (h) et (i). Les quatre autres restent hors de portée d'un détecteur d'org, pour deux raisons distinctes : (a), (c) et (g) sont des exigences organisationnelles ; (j) couvre aussi les communications voix, vidéo et texte sécurisées, qui ne vivent pas dans une org. Une même entreprise peut relever simultanément de NIS2 et de DORA.

Rattachement partiel

Un rattachement partiel relie une preuve technique à une exigence réglementaire dont elle n'observe qu'une facette. Il s'oppose au rattachement complet, où la preuve couvre ce que l'article nomme.

Exemple : un inventaire d'applications connectées qui compare leur nom à une liste d'outils d'export connus renseigne l'exigence de maîtrise de la chaîne d'approvisionnement — il ne dit rien des portées OAuth réellement accordées. Déclarer la portée de chaque rattachement est ce qui rend une cartographie opposable devant un auditeur ; ne pas la déclarer transforme un tableau de correspondances en décoration. Dans notre propre cartographie, 95 rattachements sur 118 sont déclarés partiels.