Aussi fondamentales que le choix du modèle de données ou le design des processus métiers, les perm sets et la gestion des habilitations sont pourtant incontournables.
Par habilitations, j’entends la gestion des droits et permissions accordés à un utilisateur pour accéder aux applications, objets, champs, actions spécifiques, présentations de page, et pages Lightning, pour ne citer que ceux-là.
Elles sont une composante clé de la gestion des accès et de la sécurité des données dans les projets Salesforce.
Chers consultants et administrateurs, quand en parlez-vous avec vos clients ? Dès le début du projet ? Tout au long ? Ou seulement en toute fin, au moment de créer les utilisateurs, lorsque vous réalisez qu’ils ont impérativement besoin d’un profil ?
Dans cet article, explorons ensemble comment aborder de manière pragmatique et efficace la gestion des droits dans Salesforce, et découvrons quelques bonnes pratiques que vous pourrez immédiatement mettre en œuvre.
Ainsi, deux notions essentielles sont au cœur de ce billet : les profils et les ensembles de permissions.
Dit simplement, les deux contrôlent les autorisations des utilisateurs, mais voici comment cela s’articule :
- D’une part, les profils établissent les autorisations de base d’un utilisateur,
- D’autre part, les ensembles de permissions sont utilisés pour accorder des permissions supplémentaires qui ne figurent pas dans le profil de l’utilisateur.
En définitive, les deux ne se chevauchent pas ; un ensemble de permissions n’écrase ni ne supprime pas un droit accordé via le profil. Ils fonctionnent selon une logique d’exclusion mutuelle.
A ce jour, un profil doit être attribué à chaque utilisateur lors de sa création sur la plateforme et il ne peut y avoir qu’un seul profil par utilisateur. Cependant, les utilisateurs peuvent se voir attribuer plusieurs ensembles d’autorisations, voire aucun, ce qui en fait un modèle beaucoup plus flexible et évolutif que les profils.
Leur relation univoque avec l’objet utilisateur empêche d’attribuer des permissions évolutives sans multiplier les profils, d’autant que les responsabilités des utilisateurs évoluent, nécessitant souvent de cloner et modifier les profils.
Dans certaines instances matures de Salesforce, des utilisateurs conservent souvent des autorisations obsolètes, créant un risque de sécurité, et des profils inutilisés nécessitent un nettoyage supplémentaire.
Que doit porter un profil versus un ensemble de perm sets ?
En tenant compte des trois principaux atouts des ensembles de permissions, que sont : leur caractère cumulable et réutilisable, leur flexibilité et enfin leur facilité d’assignation.
Voici la recommandation de Salesforce :
Autorisations et fonctionnalités gérées avec les ensembles d’autorisations
- Classes Apex et pages Visualforce
- Accès aux applications connectées
- Autorisations personnalisées
- Autorisations sur les champs (lecture, écriture)
- Autorisations sur les objets (lecture, écriture, modification, suppression, voir tout, modifier tout)
- Autorisations utilisateur (application et système)
- Accès aux onglets des objets
- Attribution d’applications et types d’enregistrement (pas ceux par défaut)
Fonctionnalités gérées avec les profils
- Attribution d’applications et types d’enregistrement par défaut
- Définition des plages de connexion IP et heures de connexion
- Attribution de présentation de page
Comment aborder ce chantier dans un projet d’implémentation ?
S’il y a un fondement essentiel à considérer dans la conception des ensembles de permissions, c’est le principe du moindre privilège. Connue sous l’acronyme PoLP (Principle of Least Privilege en anglais), cette approche largement répandue en sécurité informatique consiste à accorder aux utilisateurs uniquement les droits d’accès et privilèges nécessaires à l’accomplissement de leurs tâches professionnelles.
Pour illustrer ce principe, on peut le comparer à une clé « passe-partout » qui ouvre toutes sortes de portes, en contraste avec une clé qui n’ouvre que des portes bien spécifiques.
Ainsi, pour les administrateurs Salesforce, appliquer le principe du moindre privilège en contrôlant les accès selon les rôles des utilisateurs et leur fonction dans l’entreprise est une approche efficace pour créer les ensembles de permissions, et, si nécessaire, les groupes d’ensembles de permissions.
Voici le top 10 des meilleures pratiques à suivre dans la gestion des habilitations :
- Identification des personas : selon votre connaissance des utilisateurs du CRM, commencez par lister les différents personas qui se dégagent afin de définir leur périmètre fonctionnel et les tâches qu’ils doivent accomplir. Un persona représente un groupe d’utilisateurs regroupés sur la base d’un comportement, de motivations, d’objectifs, de points de friction ou d’autres caractéristiques communes.
- Décomposition des ensembles d’autorisations : un découpage en unités logiques s’impose lorsque vous y voyez plus clair sur les besoins fonctionnels de vos personas. Au lieu d’un grand ensemble d’autorisations pour plusieurs fonctionnalités, créez des ensembles d’autorisations plus petits et plus ciblés.
- Regroupement et attribution des permissions : regroupez ensuite ces ensembles de permissions dans des groupes d’ensembles de permissions correspondant aux personas identifiés plus haut. Si différents personas effectuent les mêmes tâches, vous pouvez réutiliser les mêmes ensembles de permissions dans différents groupes d’ensemble de permissions. Et si un utilisateur a plus d’un persona, vous pouvez lui assigner plusieurs groupes d’ensemble d’autorisations.
- Précaution avec les autorisations “Modifier Tout” et “Voir Tout” : soyez prudent avec les autorisations “Modifier tout” et “Voir tout” : elles permettent un accès très large à la donnée. Ne les accordez qu’en cas d’absolue nécessité et après mûre réflexion.
- Convention de nommage : utilisez une convention de nommage pour vos ensembles de permissions et les groupes d’ensemble de permissions afin de faciliter la compréhension de leur finalité aux autres administrateurs et/ou développeurs. Incluez des descriptions détaillées expliquant l’objectif et toutes les conditions ou considérations spécifiques à l’ensemble de permissions. Vous pouvez par exemple utiliser ce format : “Nom du client-Nom de l’objet-CLMS” ce qui donnerait ACME-Compte-CLM pour l’entreprise ‘ACME’ l’objet standard ‘compte’ et les droits de création, lecture et modification.
- Définition de la sécurité au niveau du champ : pour définir la sécurité au niveau du champ sur les ensembles de permissions plutôt que sur les profils, l’activation de la fonctionnalité associée est requise ; fonctionnalité disponible pour tous depuis la release Summer ‘23. Pour ce faire, allez en configuration > recherchez “Paramètres de gestion des utilisateurs” > topez le toggle “Sécurité au niveau du champ pour les ensembles d’autorisations pendant la création de champs”.
- Usage du profil standard “Minimum Access” : dans la mesure du possible, attribuez à vos utilisateurs le profil standard “Minimum access”.
- Politiques d’accès utilisateurs automatisées : les politiques d’accès des utilisateurs (disponible pour tous depuis la Release Summer ‘24), vous offrent un gain de temps considérable pour identifier les utilisateurs ayant un certain profil ou d’autres critères dans le but de leur assigner ou révoquer des ensembles de permissions, des groupes d’ensembles de permissions, des groupes publics, des files d’attente, des licences d’ensembles d’autorisations et ce, automatiquement chaque fois que des utilisateurs sont créés et/ou mis à jour.
- Révocation d’accès temporaire : limitez l’attribution des ensembles d’autorisation dans le temps en définissant dessus une période de validité. Une fois la période écoulée, automatiquement et sans intervention de votre part, l’ensemble d’autorisation attribué n’est plus effectif. Un indicateur visuel permet aux administrateurs d’identifier facilement les ensembles de permissions arrivant à expiration sur un court délai.
- Ensembles de perm sets de mise en sourdine : faites en usage pour désactiver des ensembles de permissions spécifiques au sein d’un groupe d’ensemble de permissions. Ainsi, il n’est pas nécessaire de créer des ensembles de permissions presque identiques avec seulement les quelques permissions mises en sourdine.
En conclusion, la volonté de Salesforce de se défaire des profils est manifeste !
Certes, la transition complète n’est pas imminente. Néanmoins, nous constatons les efforts considérables de l’éditeur pour faciliter l’adoption des ensembles de permissions comme outil de gestion des habilitations dans Salesforce. D’ailleurs, vous devriez envisager pour vos nouveaux projets d’implémentation (et les orgs que vous maintenez) d’utiliser les ensembles de permissions pour accorder des permissions aux utilisateurs plutôt que les profils.
Conservez les profils pour donner un accès minimal et accorder des autorisations différentes de l’ensembles de permissions.
Toutefois, au-delà de ces 10 bonnes pratiques, le contexte de vos clients et les contraintes de vos projets peuvent nécessiter un design spécifique, des ensembles de permissions, différent de nos recommandations.
Quoi qu’il en soit, la clé d’une gestion réussie de vos habilitations réside dans une approche modulaire, flexible et évolutive fidèle au principe du moindre privilège (PoLP) et tenant compte sur la durée des changements de périmètres fonctionnel et applicatif du côté des utilisateurs finaux du CRM.
Si vous souhaitez consulter d’autres articles sur le même sujet, voici une sélection :
Et si vous souhaitez être en relation suivre les actualités de Texeï sur Linkedin, c’est ici.
