Comment garder une org Salesforce sécurisée quand l'équipe grandit

Réponse courte : les orgs Salesforce ne deviennent presque jamais vulnérables parce que quelqu'un les a attaquées. Elles le deviennent parce que les permissions s'accumulent plus vite que personne ne les retire, et parce que les utilisateurs d'intégration reçoivent bien plus d'accès que l'intégration n'en a besoin. Les deux problèmes sont silencieux, les deux grandissent avec les effectifs, et les deux se corrigent par des décisions de conception plutôt que par des produits de sécurité.

Qu'est-ce qui dégrade vraiment la sécurité Salesforce quand l'équipe grandit ?

Deux mécanismes, et aucun ne ressemble à une intrusion le jour où il se produit.

• La prolifération de permissions. L'accès est accordé sous forme d'exceptions. Quelqu'un a besoin d'un rapport un vendredi, reçoit un permission set, et le garde trois ans. Multipliez par chaque recrutement, chaque projet, chaque départ dont l'accès n'a jamais été repris.
• Des utilisateurs d'intégration surdotés. Le middleware doit écrire sur deux objets, il reçoit donc un profil System Administrator, parce que c'est le chemin le plus rapide pour faire fonctionner la synchronisation.

Les deux sont additifs par nature. Rien dans la plateforme ne retire un accès de lui-même. Cette asymétrie, facile à accorder et responsabilité de personne à révoquer, résume comment une org bien conçue devient un problème d'audit en deux ans.

Pourquoi la prolifération arrive-t-elle même dans des équipes disciplinées ?

Parce que le chemin rapide et le chemin correct pointent dans des directions opposées :

• Cloner est plus facile que modéliser. Cloner un profil prend une minute, construire un vrai permission set group prend un après-midi : les orgs finissent avec des dizaines de profils presque identiques que personne n'ose consolider.
• L'accès temporaire n'a pas d'échéance. Salesforce ne le reprendra pas pour vous, et aucun ticket ne le rappelle à personne.
• Personne ne possède la révocation. Une attribution a un demandeur. Une révocation n'a personne, et c'est pour cela que les revues d'accès sont planifiées puis discrètement sautées.
• Les permissions sensibles se cachent dans l'agrégat. Deux permission sets anodins peuvent se combiner en une capacité qu'aucun des deux ne voulait accorder.

Quel modèle de permissions survit à la croissance ?

Le modèle qui passe à l'échelle est ennuyeux et bien documenté. Ce qui compte, c'est de s'y engager avant d'avoir 200 utilisateurs, pas après.

1. Profil de base minimal. Ne donnez au profil que ce dont chaque utilisateur de ce type de licence a besoin. Aucun accès objet qui relève d'une fonction.
2. Des permission sets pour des capacités, pas pour des personnes. Un permission set décrit une tâche : son nom doit survivre à la personne qui en a eu besoin la première.
3. Des permission set groups pour les rôles, avec du muting quand un groupe accorde un peu trop. C'est le mécanisme qui permet d'assembler un rôle sans cloner encore un profil.
4. Automatisez l'attribution avec les User Access Policies pour que les arrivées et les mobilités reçoivent leurs accès par critère et non de mémoire.
5. Tenez la liste nommée des permissions dangereuses. Modify All Data, View All Data, API Enabled, l'export et Manage Users méritent un propriétaire et une justification écrite par détenteur. Si cette liste est plus longue que votre comité de direction, vous tenez votre premier chantier.

Le guide du moindre privilège de Salesforce Ben est un bon complément si vous voulez le détail clic par clic. La décision de conception ci-dessus, elle, doit venir de vous.

Pourquoi les utilisateurs d'intégration sont-ils le plus grand angle mort ?

Parce qu'ils sont invisibles dans toutes les conversations sur la sécurité. Ils ne passent pas d'onboarding, ils ne quittent jamais l'entreprise, et personne ne les revoit à la fin d'un projet. Pendant ce temps, ils détiennent souvent un accès aux données plus large que n'importe quel humain de l'org et s'authentifient sans invite MFA.

Quatre règles qui tiennent quand le nombre d'intégrations augmente :

• Un utilisateur d'intégration par intégration. Les utilisateurs partagés rendent impossible de savoir qui a écrit un enregistrement, et impossible de révoquer un système sans en casser un autre.
• Utilisez la licence d'intégration API-only quand vous le pouvez. Salesforce fournit cinq licences Salesforce Integration gratuites sur les éditions Enterprise, Unlimited et Performance, sans aucun accès à l'interface, ce qui supprime toute une classe de mauvais usages.
• Cadrez par objets et par champs, pas par profils. Écrivez ce que l'intégration a le droit de toucher et imposez-le avec un permission set construit pour cette intégration seule.
• Restreignez par IP et surveillez le volume. Le comportement d'un utilisateur d'intégration est prévisible, donc ses anomalies sont exceptionnellement parlantes par rapport à l'activité humaine.

Quels contrôles survivent réellement à l'échelle ?

Voici ceux qui continuent de fonctionner quand l'équipe double, classés par retour sur effort :

1. Déployez les permissions par le pipeline, pas à la main en production. Si les changements d'accès sont en contrôle de version, chaque attribution a un auteur, une revue et une date. Ce seul contrôle rend les quatre suivants possibles.
2. Tenez une revue d'accès récurrente avec un propriétaire nommé et un ordre du jour fixe : la liste des permissions dangereuses, les utilisateurs d'intégration, et toute personne dont le rôle a changé le trimestre passé.
3. Fixez une convention d'expiration pour les accès d'exception, quitte à l'imposer par un rappel d'agenda. Un accès sans date de fin est un accès permanent.
4. Suivez Health Check et le Setup Audit Trail comme une tendance, pas comme une capture d'écran avant un audit.
5. Faites entrer les permissions dans la revue de code. Un diff de profil ou de permission set mérite la même attention qu'Apex, car il peut faire plus de dégâts plus vite.

Comment savoir que cela fonctionne ?

Choisissez des indicateurs qui doivent baisser. Comptez les détenteurs de chaque permission dangereuse. Comptez les permissions accordées hors d'un permission set group. Comptez les utilisateurs d'intégration ayant un accès UI. Comptez les profils. Si ces quatre chiffres ne baissent pas de trimestre en trimestre, votre posture dérive même si rien n'a encore mal tourné.

FAQ

Les profils sont-ils obsolètes dans Salesforce ?

Non, et il en faut toujours un par utilisateur. La règle pratique est de garder les profils minimaux et d'exprimer tout ce qui est propre au rôle via des permission sets et des permission set groups.

À quelle fréquence revoir les accès ?

Chaque trimestre pour les permissions dangereuses et les utilisateurs d'intégration, et immédiatement à chaque changement de rôle ou départ. Une revue annuelle est un exercice d'audit, pas un contrôle.

Les utilisateurs d'intégration ont-ils besoin de la MFA ?

Les utilisateurs d'intégration API-only s'authentifient de système à système : les contrôles utiles sont les restrictions IP, des permissions cadrées et la surveillance, pas une invite MFA qu'aucun humain ne verra.

Est-ce un problème d'outillage de sécurité ?

Les outils vous aident à voir la prolifération. Ils ne décident pas qui doit avoir accès. Les décisions sont architecturales, et c'est pourquoi la correction appartient à votre processus de livraison plutôt qu'à un achat.

Nous construisons sur Salesforce en tant que SI, ISV et PDO certifiés, et nous avons fait passer des packages par la revue de sécurité AppExchange dans la santé, la logistique et l'industrie : le modèle de permissions est donc quelque chose que nous concevons plutôt que d'hériter. Si votre org a grandi plus vite que son modèle d'accès, parlons-en.