Salesforce et le MFA : comment ça marche ?

L’échéance approche : le 1^er février 2022, l’authentification multifacteur (MFA) deviendra une obligation contractuelle sur une bonne partie de l’offre Salesforce.

L’éditeur américain avait officialisé la démarche début 2021. Depuis, il a multiplié les ressources, du guide administrateur à la communauté Trailblazer. En passant par une FAQ qui témoigne de l’ampleur du chantier.

L’exigence MFA s’appliquera à tous les utilisateurs internes qui accèdent à l’UI d’un produit Salesforce – solutions partenaires comprises – par connexion directe ou SSO. En tout cas dans les grandes lignes : les cas particuliers ne manquent pas.

Trois éléments majeurs ressortent pour déterminer si on tombe ou non sous le coup de cette exigence. Nommément, les catégories d’utilisateurs, les méthodes de connexion et les types d’organisations.

Les utilisateurs externes ont le choix

Si on examine la situation par type d’utilisateur, cela donne :

– MFA obligatoire pour toute personne détentrice d’une licence utilisateur standard ayant accès à l’UI de votre organisation Salesforce. On parle là des admins, des devs, des utilisateurs privilégiés, des utilisateurs standard et de ceux autorisés à agir au nom de votre entreprise.
Illustration d’un cas particulier sur ce point : aux dernières nouvelles, Salesforce doit résoudre un problème d’attribution de l’autorisation MFA pour les détenteurs de la licence Free Limited Access.

– MFA facultatif pour les utilisateurs externes. C’est-à-dire ceux qui peuvent, par exemple, accéder uniquement aux sites Experience Cloud, aux sites ou boutiques e-commerce, aux portails d’aide, aux communautés d’employés, etc. de votre entreprise.

Dans les produits élaborés sur la plate-forme Salesforce, tout détenteur d’une licence Community, Employee Community ou External Identity est un « utilisateur externe ».
Sur Tableau Online, le MFA facultatif concerne plus précisément les utilisateurs externes qui consomment des visualisations dans des contextes incorporés. Ainsi que ceux qui accèdent au site Tableau Online d’un client Salesforce.

– Sur Chatter, cela dépend des licences. Le MFA n’est pas obligatoire avec Chatter External et Chatter Free. Elle l’est pour Chatter Only / Chatter Plus.

Confirmation d’identité : pas forcément compatible MFA

Passé les catégories d’utilisateurs, il y a une autre variable : les types de connexion et les méthodes d’authentification.

L’exigence MFA s’applique principalement :

– Aux connexions directes à l’interface utilisateur
{Notamment aux apps mobiles et aux apps clientes comme Data Loader.}

– Aux connexions SSO (SAML, OpenID Connect)

– À l’authentification déléguée

– À la procédure de confirmation d’identité avec activation d’appareil
{Intégrée dans certains produits Salesforce, elle demande un facteur d’authentification supplémentaire en cas de connexion depuis un navigateur ou un appareil non reconnu. Ou bien si l’IP est hors plage de confiance. Parmi les méthodes de vérification prises en charge figurent e-mail et SMS… qui ne répondent pas à l’exigence MFA. Tout comme – c’est important à noter si on est en SSO – les questions de sécurité. }

RPA, certificats, réseaux de confiance… Pour qui le MFA ?

Le MFA n’est, au contraire, pas obligatoire pour :

– Les connexions API/intégration

– Les connexions de comptes RPA et tests automatisés sur l’interface utilisateur
Mais Salesforce recommande, si ces outils le permettent, d’activer l’automatisation MFA avec codes secrets temporels à usage unique (TOTP)

Il y a aussi les cas où « ça dépend ». Il s’agit essentiellement :

– Appareils d’entreprise / certificats d’entreprise de confiance
Utilisés seuls, ces appareils dotés de certificats émis par des services comme Active Directory ou des MDM ne répondent pas à l’exigence MFA.

Motif : lesdits certificats peuvent être compromis par quiconque a accès aux appareils. La solution ? Activer le MFA chez votre fournisseur d’identité SSO ou opter pour celle de Salesforce… dans les produits où elle est disponible.

À défaut, on peut associer deux conditions. D’une part, que les utilisateurs se connectent à partir de tels appareils. Et de l’autre, que ces appareils se trouvent sur la plage IP du réseau d’entreprise (connectés soit depuis le bureau, soit sur un VPN).

– Réseaux de confiance
Seuls, ils ne conviennent pas, en raison des risques associés à l’usurpation d’IP. Ils peuvent satisfaire si on y couple les certificats d’entreprise de confiance. Ou, comme évoqué ci-dessus, qu’on active le MFA sur SSO – ou sur Salesforce, à condition que les produits prennent en charge les listes d’autorisations d’IP, de plages IP de confiance ou de plages IP de connexion.

– Certificats utilisateur
L’authentification par ce biais ne suffit pas, que ce soit en connexion directe ou en SSO. Une solution peut consister à configurer le service de certificat de sorte que celui-ci demande un PIN.

MFA obligatoire en prod

Troisième plan à étudier pour déterminer si l’exigence MFA s’applique : les types d’organisations et de locataires. Sur les environnements de production, c’est obligatoire. Ça ne l’est pas, en revanche, sur :

– Les ressources à destination des utilisateurs externes (sites Experience Cloud, portails d’aide et autres mentionnés plus haut)
– Les environnements sandbox (Partial, Full, Developer, Pro), mais Salesforce le recommande
– Trailhead Playground
– Les organisations tests
– Les environnements Partner Developer Edition et Developer Edition (mais c’est là aussi recommandé)

Pour les versions d’évaluation, il existe une période de grâce de 45 jours avant application de l’exigence MFA.

Le MFA de Salesforce…mais pas que

On peut tout à fait utiliser à la fois la MFA de Salesforce et celle d’un fournisseur SSO. On préférera la première solution pour les admins, afin de leur permettre de se connecter en cas de défaillance de la seconde.

De manière générale, on s’assurera que ces utilisateurs enregistrent au moins deux méthodes de vérification. Mais aussi de conserver une clé de sécurité de secours dans un endroit sûr. Et de définir au moins deux comptes dotés d’autorisation de gestion des paramètres MFA.

En cas de déploiement progressif, on priorisera les comptes admin. En sachant toutefois que sur certains produits (notamment Quip et des composantes de Marketing Cloud), c’est « tout ou rien ».

Pour les accès SSO, Salesforce recommande d’enclencher la vérification à chaque connexion. C’est la règle sur son MFA natif.

Recommandation pour limiter l’impact sur les utilisateurs finaux : se servir de l’app mobile Salesforce Authenticator et y activer l’option d’automatisation des connexions depuis les emplacements de confiance. Un emplacement est considéré comme tel à partir de la troisième connexion.

Le MFA de Salesforce priorise cette app mobile si jamais on a enregistré d’autres méthodes de vérification. Il donne ensuite la priorité aux solutions d’authentification intégrées (Touch ID, Face ID, Windows Hello…), puis aux clés physiques (U2F ou WebAuthn) et aux apps TOTP (Google Authenticator, Microsoft Authenticator…).

Plusieurs exceptions à noter :

– Quip ne permet pour l’instant d’enregistrer qu’une méthode de vérification
– Les produits élaborés sur la plate-forme Salesforce ne gèrent ni les clés WebAuthn ni les clés NFC
– Tableau Online n’accepte pas les clés
– Les solutions d’authentification intégrées ne sont actuellement disponibles que sur Heroku, Marketing Cloud-Datorama et Mulesoft Anypoint Platform. Avec l’édition Winter’22, ils arrivent en bêta dans les produits élaborés sur la plate-forme Salesforce.

MFA : certaines applications hors-champ

Quelques produits on-prem sont exclus de l’exigence MFA. MuleSoft en fait partie. Même chose pour Tableau Server et Tableau Public. Ainsi que les composantes Tableau Desktop, Prep, Content Migration Tool et Resource Monitoring Tool, sauf si connectés à Tableau Online.

Que va-t-il se passer pour qui ne serait pas en règle au 1^er février 2022 ? Pas de coupure d’accès à prévoir. Mais une non-conformité contractuelle.

Pour les clients non conformes à la date d’échéance, Salesforce va procéder en deux temps. Il activera d’abord automatiquement le MFA natif pour les connexions directes à ses produits. Puis il forcera sa mise en œuvre, sans possibilité de le désactiver.
La feuille de route en témoigne : cette logique ne sera pas tout à fait respectée pour certains produits. On en retiendra les éléments suivants :

– Pour les produits élaborés sur la plate-forme Salesforce, enclenchement de la première phase entre septembre et octobre 2022. La deuxième démarrera entre mai et juin 2023.

– Une seule phase pour Heroku (1^er juin 2022) comme pour Tableau Online (entre mars et mai 2022 pour les utilisateurs privilégiés ; entre juillet et septembre pour les autres)

– Quip sera le premier à faire la transition (début de la phase 1 le 1^er février 2022 ; phase 2 le 1^er mai)

– Sur chaque produit, une notification au moins 6 mois avant le début de la phase 2

Ce calendrier n’englobe pas les connexions SSO. Chez les utilisateurs concernés, Salesforce aura une visibilité limitée sur l’implémentation MFA. Il prévoit cependant un mécanisme de contrôle, fondé sur les attributs amr (Référence de la méthode d’authentification) d’OpenID Connect et AuthnContext (contexte d’authentification) de SAML. En l’état, on nous promet qu’il n’y aura aucun blocage pour les contrevenants. Mais cette politique « pourrait changer à l’avenir »…

Illustration principale © Salesforce