Les axes d’amélioration des solutions MFA et SSO

Les garanties de privacy associées à FIDO sont-elles un obstacle à la mise en œuvre du MFA en entreprise ? Elles peuvent en tout cas engendrer une forme de tension, estiment la CISA et la NSA.

Les deux agences américaines dressent ce constat dans un document relatif aux « défis de l’IAM pour les développeurs et les fournisseurs ». Elles n’y citent aucun offreur, mais pointent une multitude d’axes d’amélioration potentiels de leurs solutions.

Sur le volet de l’authentification multifacteur, il y a d’abord un enjeu de terminologie. L’usage souvent indifférencié de termes comme 2SV (vérification à deux étapes), 2FA et MFA peut porter à confusion, même s’il « peut exister des différences techniques subtiles ».

CISA et NSA déplorent plus globalement un manque de clarté susceptible de compliquer la compréhension des mécanismes d’authentification effectivement disponibles dans une solution. Mais aussi, entre autres, la compatibilité d’une brique MFA avec d’autres systèmes.

Problème lié, selon les deux agences : une terminologie trop générique qui ne permet pas d’appréhender le réel niveau de sécurité. La recommandation : s’aligner sur le référentiel NIST SP 800-63 (Digital Identity Guidelines), qui catégorise la robustesse des systèmes d’authentification en fonction de propriétés techniques.

Consolider, protéger et valoriser vos données : RDV au Silicon Day le 30 novembre !

Silicon.fr vous invite pour une matinée d’échanges autour des projets d’analyse de données et de services cloud.
Au programme :  des retours d’expérience de migrations d’applications vers le cloud, des interactions avec des bâtisseurs et les intégrateurs de solutions pour consolider, protéger et valoriser vos données numériques.
Venez partager vos réflexions et vos retours d’expérience, rendez-vous le le 30 novembre en matinée, à la maison des Polytechniciens (Paris 7e).

Inscrivez-vous gratuitement ici

MFA : ce n’est pas qu’une question de terminologie

Pour accompagner l’adoption du MFA, il convient que les offreurs prennent en charge ses formes les plus robustes, poursuit le tandem CISA-NSA (et de mentionner les standards PKI et FIDO2). Et, lorsque c’est le cas, que cette prise en charge soit complète. Cela signifie, entre autres, pas de restrictions sur les types d’authentifiants exploitables. Mais aussi, notamment, la possibilité de définir des stratégies basées sur l’attestation.

Autre levier d’adoption : des configurations par défaut, prévalidées pour divers cas d’usage. Pour ce qui est du maintien en condition opérationnelle et de la gouvernance, les solutions MFA gagneraient à embarquer des briques (plus) robustes de gestion des authentifiants, estiment les deux agences. En particulier au niveau de l’enregistrement, encore souvent fondé sur un processus porté par l’utilisateur final avec une forme de code à usage unique.

CISA et NSA appellent, en parallèle, à renforcer les outils de découverte et de révocation automatique des facteurs d’authentification. Ainsi que, côté FIDO, à des améliorations sur le support de l’attestation. Par exemple, sur la capacité à déterminer vers quelle personne ou organisation un authentifiant a été émis. C’est là que se pose la question de privacy sus-évoquée…

Un appel à simplifier…

Sur le volet SSO, il existe un enjeu de simplification des outils. Qui, à l’heure actuelle, exigent des compétences non négligeables pour être opérés de manière sécurisée… à moins d’accepter des compromis fonctionnels, affirment la CISA et la NSA. Les offres SaaS ont certes facilité le déploiement, mais elles ne sont pas disponibles sur tous les segments de marché. Parmi eux, l’OT.

Il y a de la marge pour développer des systèmes SSO à la fois simples à prendre en main et sécurisés, concluent les deux agences. Il y en a aussi pour :

– Les éditeurs d’applications compatibles – invités, en l’occurrence, à recommander des configurations
– L’outillage destiné à interpréter les relations de confiance dans ces environnements
– L’aide à la détection des implémentations non sécurisées de protocoles

… et à standardiser

Du chemin, il y en a également à faire en matière de standardisation. Par exemple, au niveau de la communication, entre fournisseurs d’identités et applications compatibles, d’informations relatives à la robustesse de l’authentification multifacteur. En première ligne, les cas « complexes » qui exigent différents types de MFA pour différentes populations d’utilisateurs.

Autre perspective : la standardisation des configurations de fédération. À ce sujet, on nous cite le protocole FastFed de l’OpenID Foundation, qui couvre l’échange de métadonnées. La CISA et la NSA soulignent, en outre, l’existence de travaux sur le partage d’indicateurs de risque au cours des sessions. Ces travaux se matérialisent dans les protocoles RISC et CAEP. OAuth2 a aussi droit à une mention, pour son usage d’un canal dédié entre fournisseur d’identité et application.

Les deux agences regrettent que dans beaucoup d’applications compatibles, le SSO exige un certain niveau de contractualisation. Ce qui le met hors de portée des plus petites entreprises. SAML est, par ailleurs, souvent la seule option.
Autre regret : la gestion du cycle de vie des identités se fait encore souvent par l’intermédiaire d’API propriétaires plutôt que via des standards ouverts comme SCIM.

À consulter en complément :

Identités et accès : comment l’IAG est portée par la vague du cloud
MFA obligatoire sur la console AWS : la roadmap se précise
SSO et passwordless à l’expérimentation sur Azure Virtual Desktop
SIEM ou XDR ? De la concurrence à la « confusion »

Illustration © the_ligthwriter – Adobe Stock