Comment garder une org Salesforce securisee quand l'equipe grandit

Reponse courte : les orgs Salesforce ne deviennent presque jamais vulnerables parce que quelqu'un les a attaquees. Elles le deviennent parce que les permissions s'accumulent plus vite que personne ne les retire, et parce que les utilisateurs d'integration recoivent bien plus d'acces que l'integration n'en a besoin. Les deux problemes sont silencieux, les deux grandissent avec les effectifs, et les deux se corrigent par des decisions de conception plutot que par des produits de securite.

Qu'est-ce qui degrade vraiment la securite Salesforce quand l'equipe grandit ?

Deux mecanismes, et aucun ne ressemble a une intrusion le jour ou il se produit.

• La proliferation de permissions. L'acces est accorde sous forme d'exceptions. Quelqu'un a besoin d'un rapport un vendredi, recoit un permission set, et le garde trois ans. Multipliez par chaque recrutement, chaque projet, chaque depart dont l'acces n'a jamais ete repris.
• Des utilisateurs d'integration surdotes. Le middleware doit ecrire sur deux objets, il recoit 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 acces de lui-meme. Cette asymetrie, facile a accorder et responsabilite de personne a revoquer, resume comment une org bien concue devient un probleme d'audit en deux ans.

Pourquoi la proliferation arrive-t-elle meme dans des equipes disciplinees ?

Parce que le chemin rapide et le chemin correct pointent dans des directions opposees :

• Cloner est plus facile que modeliser. Cloner un profil prend une minute, construire un vrai permission set group prend un apres-midi : les orgs finissent avec des dizaines de profils presque identiques que personne n'ose consolider.
• L'acces temporaire n'a pas d'echeance. Salesforce ne le reprendra pas pour vous, et aucun ticket ne le rappelle a personne.
• Personne ne possede la revocation. Une attribution a un demandeur. Une revocation n'a personne, et c'est pour cela que les revues d'acces sont planifiees puis discretement sautees.
• Les permissions sensibles se cachent dans l'agregat. Deux permission sets anodins peuvent se combiner en une capacite qu'aucun des deux ne voulait accorder.

Quel modele de permissions survit a la croissance ?

Le modele qui passe a l'echelle est ennuyeux et bien documente. Ce qui compte, c'est de s'y engager avant d'avoir 200 utilisateurs, pas apres.

1. Profil de base minimal. Ne donnez au profil que ce dont chaque utilisateur de ce type de licence a besoin. Aucun acces objet qui releve d'une fonction.
2. Des permission sets pour des capacites, pas pour des personnes. Un permission set decrit une tache : son nom doit survivre a la personne qui en a eu besoin la premiere.
3. Des permission set groups pour les roles, avec du muting quand un groupe accorde un peu trop. C'est le mecanisme qui permet d'assembler un role sans cloner encore un profil.
4. Automatisez l'attribution avec les User Access Policies pour que les arrivees et les mobilites recoivent leurs acces par critere et non de memoire.
5. Tenez la liste nommee des permissions dangereuses. Modify All Data, View All Data, API Enabled, l'export et Manage Users meritent un proprietaire et une justification ecrite par detenteur. Si cette liste est plus longue que votre comite de direction, vous tenez votre premier chantier.

Le guide du moindre privilege de Salesforce Ben est un bon complement si vous voulez le detail clic par clic. La decision de conception ci-dessus, elle, doit venir de vous.

Pourquoi les utilisateurs d'integration sont-ils le plus grand angle mort ?

Parce qu'ils sont invisibles dans toutes les conversations sur la securite. Ils ne passent pas d'onboarding, ils ne quittent jamais l'entreprise, et personne ne les revoit a la fin d'un projet. Pendant ce temps, ils detiennent souvent un acces aux donnees plus large que n'importe quel humain de l'org et s'authentifient sans invite MFA.

Quatre regles qui tiennent quand le nombre d'integrations augmente :

• Un utilisateur d'integration par integration. Les utilisateurs partages rendent impossible de savoir qui a ecrit un enregistrement, et impossible de revoquer un systeme sans en casser un autre.
• Utilisez la licence d'integration API-only quand vous le pouvez. Salesforce fournit cinq licences Salesforce Integration gratuites sur les editions Enterprise, Unlimited et Performance, sans aucun acces a l'interface, ce qui supprime toute une classe de mauvais usages.
• Cadrez par objets et par champs, pas par profils. Ecrivez ce que l'integration a le droit de toucher et imposez-le avec un permission set construit pour cette integration seule.
• Restreignez par IP et surveillez le volume. Le comportement d'un utilisateur d'integration est previsible, donc ses anomalies sont exceptionnellement parlantes par rapport a l'activite humaine.

Quels controles survivent reellement a l'echelle ?

Voici ceux qui continuent de fonctionner quand l'equipe double, classes par retour sur effort :

1. Deployez les permissions par le pipeline, pas a la main en production. Si les changements d'acces sont en controle de version, chaque attribution a un auteur, une revue et une date. Ce seul controle rend les quatre suivants possibles.
2. Tenez une revue d'acces recurrente avec un proprietaire nomme et un ordre du jour fixe : la liste des permissions dangereuses, les utilisateurs d'integration, et toute personne dont le role a change le trimestre passe.
3. Fixez une convention d'expiration pour les acces d'exception, quitte a l'imposer par un rappel d'agenda. Un acces sans date de fin est un acces permanent.
4. Suivez Health Check et le Setup Audit Trail comme une tendance, pas comme une capture d'ecran avant un audit.
5. Faites entrer les permissions dans la revue de code. Un diff de profil ou de permission set merite la meme attention qu'Apex, car il peut faire plus de degats plus vite.

Comment savoir que cela fonctionne ?

Choisissez des indicateurs qui doivent baisser. Comptez les detenteurs de chaque permission dangereuse. Comptez les permissions accordees hors d'un permission set group. Comptez les utilisateurs d'integration ayant un acces UI. Comptez les profils. Si ces quatre chiffres ne baissent pas de trimestre en trimestre, votre posture derive meme si rien n'a encore mal tourne.

FAQ

Les profils sont-ils obsoletes dans Salesforce ?

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

A quelle frequence revoir les acces ?

Chaque trimestre pour les permissions dangereuses et les utilisateurs d'integration, et immediatement a chaque changement de role ou depart. Une revue annuelle est un exercice d'audit, pas un controle.

Les utilisateurs d'integration ont-ils besoin de la MFA ?

Les utilisateurs d'integration API-only s'authentifient de systeme a systeme : les controles utiles sont les restrictions IP, des permissions cadrees et la surveillance, pas une invite MFA qu'aucun humain ne verra.

Est-ce un probleme d'outillage de securite ?

Les outils vous aident a voir la proliferation. Ils ne decident pas qui doit avoir acces. Les decisions sont architecturales, et c'est pourquoi la correction appartient a votre processus de livraison plutot qu'a un achat.

Nous construisons sur Salesforce en tant que SI, ISV et PDO certifies, et nous avons fait passer des packages par la revue de securite AppExchange dans la sante, la logistique et l'industrie : le modele de permissions est donc quelque chose que nous concevons plutot que d'heriter. Si votre org a grandi plus vite que son modele d'acces, parlons-en.