Certaines questions n'exigent qu'une réponse par oui ou par non. Si vous appelez un restaurant et demandez : « Puis-je réserver pour 14 heures ? », des réponses raisonnables seraient « Oui », « Non » ou « Nous n'avons que des places à l'extérieur. » Est-ce que cela vous convient ?
Vous seriez probablement surpris d'entendre : « Oui, mais un groupe de nombres impairs devrait réserver une place à l'avant du restaurant, tandis qu'un groupe de nombres pairs devrait en réserver une à l'arrière. De plus, veuillez porter des vêtements blancs et utiliser votre pied gauche pour entrer dans le restaurant ; sinon, vous serez refusé.
La surprise serait double ici : premièrement, vous ne vous attendiez pas à une réponse aussi longue, et deuxièmement, il… ne semble pas que ces conditions devraient exister en premier lieu.
Il s'avère que l'application de l'authentification multifacteur (MFA) agit de la même manière. Alors que vous vous attendez à ce que la question « Ce compte est-il protégé par MFA ? » ait une simple réponse par oui ou par non, la réalité est souvent beaucoup plus compliquée que cela. Souvent, certains scénarios appliqueront la MFA pour l'accès à l'application, tandis que différents scénarios autoriseront l'accès sans MFA, parfois intentionnellement, mais souvent pas.
Le problème de la fragmentation
L'une des principales fonctionnalités à rechercher dans une solution comme Okta Identity Security Posture Management est la capacité de suivre tous les scénarios d'authentification qui mènent à chaque compte dans vos applications SaaS et de comprendre l'état de protection que chacun implique.
C'est une tâche facile lorsque vous n'autorisez qu'un seul fournisseur d'identité à authentifier une application. Mais cela devient beaucoup plus complexe lorsque vous ajoutez des politiques d'authentification variables, des migrations depuis des solutions d'identité précédentes, des modèles hub-and-spoke et différentes applications SaaS appliquant des règles différentes pour les connexions directes et l'application de l'authentification multifacteur (MFA). Tous ces éléments entraînent de multiples scénarios de connexion, ce qui rend plus difficile le suivi - et la protection - de tous ces scénarios.
Dans cet article de blog, nous allons approfondir bon nombre de ces sources de fragmentation et explorer leur impact potentiel.
Politiques d’authentification
Les politiques d'authentification, souvent appelées politiques d'accès conditionnel, sont utilisées pour appliquer les exigences de facteur lorsque les utilisateurs se connectent à des applications ou effectuent certaines actions.
Il existe de nombreuses raisons d’autoriser différents types de facteurs (ou même d’autoriser la connexion sans MFA) :
- Différentes plates-formes permettent d'utiliser divers facteurs (et, par conséquent, certaines plates-formes peuvent être accessibles uniquement à certaines applications).
- Différenciation des appareils appartenant à l’entreprise et du BYOD
- Exemption pour les comptes de service et les identités non humaines
- Ne pas exiger l’authentification multifacteur (MFA) lors de l’accès à des ressources non sensibles afin de réduire la fatigue liée à la MFA
Naturellement, ces différences d'exigences doivent être prises en compte lors de l'affichage de l'état d'application d'un compte.
Lacunes accidentelles dans la configuration des stratégies
Différents fournisseurs d’identité vous permettront de configurer les stratégies d’authentification de différentes manières.
Alors qu'Okta utilise un modèle basé sur la priorité pour configurer les politiques d'authentification, d'autres fournisseurs configureront des politiques « globales » avec l'action « la plus sévère » prenant effet.
Bien que les deux méthodes semblent équivalentes en apparence, la deuxième méthode rend beaucoup plus difficile l’exclusion d’exceptions de toutes les stratégies, ce qui entraîne souvent des failles de sécurité.
Bien que cet exemple soit simpliste et peu probable lors de la configuration de quelques stratégies seulement, il vaut la peine de s'en souvenir :
- Les grandes organisations ont souvent des dizaines de politiques en place, ce qui augmente la probabilité de passer à côté de tels cas (nous rencontrons fréquemment ces lacunes dans la pratique lors de l’analyse des politiques d’accès conditionnel mises en place dans d’autres fournisseurs d’identité).
- Bien qu'il soit peu probable que quelqu'un utilise des plateformes inhabituelles lors de la connexion, les conditions de la plateforme sont évaluées à l'aide de l'User Agent, qui est facilement et communément falsifié lors des campagnes de credential stuffing.
Méthodes de connexion alternatives
Bien que le principe de l'authentification unique (SSO) soit que l'accès à toutes les applications peut être géré depuis un emplacement unique, il existe souvent plusieurs façons d'accéder à un compte donné dans une application donnée. Examinons quelques-uns de ces cas.
Connexion directe
Souvent, les comptes qui peuvent accéder à une application via l'authentification unique (SSO) peuvent également se connecter directement à l'application (soit en utilisant une combinaison nom d'utilisateur-mot de passe, soit en utilisant des clés d'accès).
Bien qu’il s’agisse souvent d’un choix délibéré (par exemple, pour autoriser l’accès d’un administrateur en cas d’urgence ou lors de la configuration de l’application), cela peut parfois se produire involontairement. Dans certains services, l’accès par mot de passe peut devoir être désactivé par utilisateur, même si le SSO est configuré. Dans d’autres services, les comptes administrateur peuvent toujours être connectés directement sans possibilité de désactiver cette option.
L'essentiel à comprendre est que chaque application se comporte différemment et qu'il n'existe pas de comportement universel sur lequel s'appuyer. Si l'authentification multifacteur (MFA) est configurée pour un compte, certaines applications continueront à la demander, même si l'utilisateur se connecte via l'authentification unique (SSO), tandis que d'autres ne demanderont l'authentification multifacteur (MFA) que si l'utilisateur s'est connecté directement. D'autres services peuvent même permettre de configurer lequel des deux comportements se produira.
Fournisseurs SSO multiples
Dans de nombreux cas, certains comptes d’une application sont accessibles à l’aide de plusieurs fournisseurs d’identité. De tels cas peuvent se produire en raison de :
- Différentes filiales ou différents services utilisant différents fournisseurs d'identité, avec un potentiel de chevauchements entre eux
- Restes d’anciennes solutions d’identité, où une migration a permis au nouveau fournisseur d’identité, mais n’a jamais désactivé l’ancien
- Tester les configurations utilisées pour des comptes spécifiques ou avant d’inscrire l’ensemble de l’organisation
Parfois, ces multiples fournisseurs sont connus et pris en compte ; d'autres fois, ces paramètres sont cachés et faciles à manquer.
Force du facteur
Jusqu’à présent, tout ce dont nous avons parlé a considéré « MFA/Pas de MFA » comme une question binaire, mais la réalité est plus compliquée que cela.
Étant donné que les messages SMS sont susceptibles d'être piratés et que les attaques de phishing sont monnaie courante, votre organisation peut préférer n'appliquer que des facteurs résistants au phishing, voire abandonner complètement l'authentification multifacteur traditionnelle au profit d'une approche sans mot de passe.
Une telle entreprise nécessite de passer au crible ces différents scénarios d'authentification, car elle implique de comprendre la force de l'authentification dans chacun d'eux.
Dans cet article de blog, nous avons découvert les complexités de l’application de l’authentification multifactorielle (MFA). Des facteurs tels que les stratégies d’authentification, les fournisseurs SSO multiples et les différences de comportement des applications en font tout sauf un simple statut oui/non.
Pour surmonter les défis que présente cette complexité, nous vous recommandons d'adopter une stratégie globale pour maintenir la norme d'authentification de votre organisation et de vérifier régulièrement que tous les comptes sont correctement protégés. Okta Identity Security Posture Management vous aide à gagner en visibilité sur les flux d'authentification inattendus, garantissant ainsi une norme cohérente pour l'authentification dans toute votre organisation.
Vous avez des questions sur cet article de blog ? Contactez-nous à l'adresse eng_blogs@okta.com.
Découvrez d'autres blogs techniques d'Okta pour enrichir vos connaissances.
Prêt à rejoindre notre équipe passionnée d'ingénieurs exceptionnels ? Consultez notre page carrière.
Libérez le potentiel d'une gestion des identités moderne et sophistiquée pour votre organisation. Contactez le service commercial pour plus d'informations.
Ce blog et toutes les recommandations qu'il contient ne constituent pas des conseils juridiques, de confidentialité, de sécurité, de conformité ou commerciaux. Ce blog est destiné à des fins d'information générale uniquement et peut ne pas refléter les développements juridiques, de confidentialité et de sécurité les plus récents, ni tous les problèmes pertinents. Pour obtenir de tels conseils, il vous revient de vous adresser à votre conseiller juridique ou à tout autre conseiller professionnel en matière de sécurité, confidentialité ou conformité, et de ne pas vous en remettre aux recommandations formulées dans le présent document. Okta décline toute responsabilité quant aux pertes ou dommages pouvant résulter de la mise en œuvre des recommandations fournies dans le présent document. Okta ne formule aucune déclaration, garantie ou autre assurance concernant le contenu de ce document.
