Permissions toxiques sur Salesforce : les combinaisons qui créent le risque

Qu'est-ce qu'une 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. Sur Salesforce, la forme la plus courante associe un droit de lecture étendue, un droit d'écriture ou d'export, et l'absence d'un contrôle qui aurait dû encadrer les deux.

La difficulté n'est pas de reconnaître un droit sensible — tout administrateur sait ce que fait Modifier toutes les données. Elle est de voir qu'il coexiste, sur le même profil, avec une API activée et sans authentification multifacteur. Chaque élément a été accordé à un moment différent, par une personne différente, pour une raison légitime.

Quelles combinaisons reviennent le plus ? Détecteur par détecteur

Chaque combinaison porte ci-dessous le détecteur qui la mesure, sa clé de constat et son seuil : le même niveau de preuve que la liste complémentaire plus bas, pour qu'aucune des cinq ne soit affirmée sans être vérifiable.

Lecture totale + export en masse

Afficher toutes les données associé à un droit d'export — API de masse, export hebdomadaire, ou rapport exportable — donne à un compte la capacité d'extraire l'intégralité du référentiel client en une opération. Aucun des deux droits n'est anormal : le premier sert au support, le second au pilotage.

Détecteur DataExportRiskCollector · constat Security:DataExport:BulkExport · seuil : ViewAllData croisé avec DataExport, ExportReport ou ApiEnabled sur un même compte actif — constat Élevé dès que plus de 3 comptes actifs portent la combinaison

Modification totale + API + MFA absente

C'est la combinaison la plus citée dans les incidents Salesforce. Modifier toutes les données et l'accès API sur un compte qui n'exige pas de second facteur transforme un identifiant compromis en accès complet, sans interaction humaine et sans trace d'interface. Les comptes d'intégration y sont particulièrement exposés : on leur accorde des droits larges parce qu'ils automatisent, et on leur épargne le MFA pour la même raison.

Détecteur BlastRadiusCollector · constat Security:ToxicCombo · seuil : (ModifyAllData ou ViewAllData) + ApiEnabled sur un compte actif sans signal MFA — l'absence de signal compte contre le compte, jamais pour lui — palier TPE

Gestion des utilisateurs + attribution d'ensembles d'autorisations

Un compte qui peut créer des utilisateurs et leur attribuer des ensembles d'autorisations peut s'octroyer indirectement n'importe quel droit. C'est une escalade de privilège au sens strict, et elle ne déclenche aucune alerte native.

Détecteur SecurityPostureCollector · constat Security:OverPrivilege:ManageUsers · seuil : nombre de détenteurs de « Gérer les utilisateurs » au-delà du plafond réglé dans l'administration (5 par défaut). Le croisement avec l'attribution d'ensembles n'est pas mesuré aujourd'hui : cette combinaison figure ici parce qu'elle se vérifie à la main, pas parce qu'un détecteur la produit.

Accès invité et communautés

Les profils invités des sites Experience Cloud héritent parfois de droits objet qu'on ne leur destinait pas. Un droit de lecture accordé à un profil invité expose la donnée à un visiteur non authentifié — c'est du contrôle d'accès, pas de la configuration de site.

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

Applications connectées et jetons OAuth dormants

Une application connectée autorisée il y a deux ans conserve son jeton tant que personne ne le révoque. La question à poser n'est pas « qui a accès ? » mais « quelles portées OAuth ont été accordées, à quoi, et qui s'en sert encore ? ».

Détecteur ConnectedAppRiskCollector · constat Security:OAuthApp · seuil : dormance à 90 jours, score de risque à partir de 40 — une portée full ou refresh_token vaut 30 points à elle seule

Quelles autres combinaisons surveiller ?

• Droit total + compte dormant. Modifier toutes les données ou Afficher toutes les données accordé par un ensemble d'autorisations à un compte sans connexion depuis 90 jours. Un accès complet que personne n'utilise est un accès dont personne ne remarquera l'usage.

  Détecteur PrivilegedAccountHygieneCollector · constat Security:PrivHygiene:Inactive · seuil de dormance : 90 jours

• Licence d'intégration + droit d'administration. Un utilisateur sur licence Salesforce Integration qui détient en plus Modifier toutes les données, Afficher toutes les données ou le droit de publier du code Apex. L'identité qui automatise devient celle qui peut tout réécrire.

  Détecteur PrivilegedAccountHygieneCollector · constat Security:PrivHygiene:OverScoped

• Droit privilégié + mot de passe qui n'expire jamais. Le compte cumule un droit à haut risque et un secret sans date de péremption : un mot de passe divulgué reste valable indéfiniment.

  Détecteur PrivilegedAccountHygieneCollector · constat Security:PrivHygiene:PasswordNeverExpires

• Droit effectif + changement depuis le dernier scan. L'union du profil et des ensembles d'autorisations d'un compte a gagné ModifyAllData, ViewAllData ou AuthorApex depuis la mesure précédente. L'escalade est datée, pas seulement constatée. Réservé au palier TPE, désactivé à l'installation — les autres détecteurs de cette liste tournent sans réglage.

  Détecteur PermissionSprawlCollector · constat Security:PermDrift

• Rôle à large portée + plusieurs détenteurs. Un rôle tenu par au moins trois utilisateurs actifs, dont le sous-arbre couvre au moins 75 % de la population affectée à un rôle. Chacun voit les enregistrements de tout ce qui se trouve en dessous, sans qu'aucune permission ne l'accorde. Réservé au palier TPE, désactivé à l'installation — les autres détecteurs de cette liste tournent sans réglage.

  Détecteur RoleHierarchyExposureCollector · constat Security:RoleHierarchy:Reach · seuils : 3 détenteurs, 75 % de couverture

• Objet sensible + partage par défaut ouvert. Le détecteur signale quatre cas, et non deux : lecture publique et lecture/écriture publique, chacune côté interne et côté externe — communautés et portails. La lecture/écriture publique interne, la plus lourde des quatre, sort en sévérité Élevée. Dans tous les cas l'enregistrement est exposé sans qu'un droit ait été accordé à qui que ce soit.

  Détecteur SharingExposureCollector · constat Security:Sharing:OWD

• Flow actif + exécution en mode système sans partage. Le flux contourne la visibilité des enregistrements et la sécurité au niveau du champ de l'utilisateur qui le déclenche : l'équivalent déclaratif d'une classe Apex without sharing.

  Détecteur SharingExposureCollector · constat Security:Sharing:Flow

• Portée OAuth large + auto-autorisation. Une application cliente externe dont la portée full, api, web ou refresh_token est accordée, et dont la politique laisse chaque utilisateur s'autoriser lui-même sans validation d'un administrateur.

  Détecteur ConnectedAppRiskCollector · constat Security:OAuthApp

Pourquoi une revue manuelle les rate-t-elle ?

Une revue d'habilitation regarde les droits profil par profil. Or un utilisateur cumule un profil et un nombre quelconque d'ensembles d'autorisations, chacun apportant sa part. Le droit effectif d'un compte est la somme de ces couches, et cette somme n'est affichée nulle part sous une forme exploitable.

Une org de taille moyenne compte des dizaines de profils, des centaines d'ensembles d'autorisations et des milliers d'utilisateurs. Le produit cartésien à examiner dépasse ce qu'une revue trimestrielle peut couvrir — et il change entre deux revues.

Comment les repérer à l'échelle ?

Ce qui se lit, et où. Le droit effectif d'un compte est la réunion de son profil et de ses ensembles d'autorisations : il se reconstruit depuis trois objets — PermissionSet (qui porte aussi les profils, IsOwnedByProfile = true), PermissionSetAssignment (qui relie chaque ensemble à chaque utilisateur) et User (pour l'état actif, la licence et la dernière connexion). Les champs PermissionsModifyAllData, PermissionsViewAllData, PermissionsApiEnabled, PermissionsManageUsers se lisent directement sur PermissionSet. L'état MFA vient de l'ensemble d'autorisations qui porte « Authentification multifacteur pour les connexions à l'interface utilisateur » et des paramètres de session du profil.

Ce que l'interface native sait faire : lister les ensembles d'autorisations qui portent un droit donné (Configuration › Ensembles d'autorisations, filtre sur une permission), et lister les utilisateurs d'un ensemble. Où elle décroche : aucun écran n'affiche l'union profil + ensembles d'un utilisateur, aucun ne croise deux droits, aucun ne croise un droit avec l'état MFA. Un rapport standard sur PermissionSetAssignment rend la liste brute — plusieurs milliers de lignes sur une org de 500 utilisateurs — sans l'agréger.

La procédure, donc : (1) extraire PermissionSetAssignment joint à PermissionSet pour les seuls ensembles qui portent au moins un droit large ; (2) agréger par utilisateur pour obtenir le droit effectif ; (3) ne retenir que les combinaisons — un droit isolé n'est pas un constat ; (4) joindre l'état MFA et la licence, pour séparer le compte humain du compte d'intégration ; (5) rejouer à chaque changement d'affectation, pas à chaque audit. C'est exactement ce que fait BlastRadiusCollector, avec un plafond de 5 000 affectations par passe au-delà duquel le constat dit qu'il a tronqué plutôt que de se taire — et une ligne manquante peut faire rater une combinaison, jamais en fabriquer une.

Combien de temps faut-il pour auditer une org ?

À la main, sur une org de quelques centaines d'utilisateurs, une revue sérieuse des droits effectifs se compte en jours — et elle est périmée le lendemain. Instrumentée, la même mesure se rejoue à chaque scan, ce qui déplace l'effort de la collecte vers la décision.

Que faire d'une permission toxique une fois trouvée ?

Rarement la supprimer d'emblée : elle sert à quelque chose. L'ordre utile est de déterminer qui l'utilise réellement, de couvrir le risque par un contrôle compensatoire — MFA obligatoire, restriction d'adresse IP, réduction de portée OAuth — puis de retirer ce qui n'est plus employé. C'est pour ça qu'un outil de détection doit rester en lecture seule : la décision de retirer un droit en production appartient à l'humain qui en connaît l'usage.