Certaines questions n'exigent qu'une réponse par oui ou par non. Si vous appelez un restaurant et demandez : « Puis-je faire une réservation pour 14 h ? », certaines réponses raisonnables seraient « Oui », « Non » ou « Nous n'avons que des places à l'extérieur disponibles ». Est-ce correct ?"
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 : 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 multifactorielle (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 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 telle que 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 lorsqu'on n'autorise 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 d'anciennes solutions d'identité, des modèles en étoile et différentes applications SaaS appliquant des règles différentes pour les connexions directes et l'application de l'authentification multifacteur (MFA). Tout cela se traduit par 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 plateformes permettent d'utiliser divers facteurs (et, par conséquent, certaines plateformes peuvent être accessibles uniquement à certaines applications)
- Différencier les appareils appartenant à l'entreprise et les appareils personnels (BYOD).
- Exemption pour les comptes de service et les identités non humaines
- Ne pas exiger l'AMF lors de l'accès à des ressources non sensibles afin de réduire la fatigue liée à l'AMF
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 politiques
Différents fournisseurs d'identité vous permettront de configurer les politiques d'authentification de différentes manières.
Alors qu'Okta utilise un modèle basé sur les priorités pour configurer les politiques d'authentification, d'autres fournisseurs configureront des politiques « globales » avec l'action « la plus sévère » qui prend effet.
Bien que les deux méthodes semblent équivalentes en surface, la deuxième méthode rend beaucoup plus difficile la suppression des exceptions de toutes les politiques, 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 politiques seulement, il vaut la peine de s'en souvenir :
- Les grandes organisations ont souvent des dizaines de politiques en place, ce qui augmente le risque de passer à côté de tels cas (nous rencontrons fréquemment ces lacunes dans la pratique lorsque nous analysons les politiques d'accès conditionnel mises en place chez 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 plateforme sont évaluées à l'aide de l'User Agent, qui est facilement et couramment 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 puisse être géré depuis un emplacement unique, il existe souvent plusieurs façons d'accéder à un compte donné dans une application. Examinons quelques-uns de ces cas.
Connexion directe
Souvent, les comptes qui peuvent accéder à une application via 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 arriver 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 est de comprendre que chaque application se comporte différemment et qu'il n'existe pas de comportement universel sur lequel s'appuyer. Si l'AMF est configurée pour un compte, certaines applications continueront à la demander, même si l'utilisateur se connecte via SSO, tandis que d'autres ne demanderont l'AMF que si l'utilisateur s'est connecté directement. D'autres services peuvent même autoriser la configuration du comportement qui se produira.
Plusieurs fournisseurs SSO
Dans de nombreux cas, certains comptes d'une application peuvent être accessibles à l'aide de plusieurs fournisseurs d'identité. De tels cas peuvent se produire en raison de :
- Différentes filiales ou différents départements utilisant différents fournisseurs d'identité, avec des risques de chevauchements.
- Les restes d'anciennes solutions d'identité, où une migration a activé le 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 fournisseurs multiples 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 traité la question de l'authentification multifacteur (MFA) comme une question binaire, mais la réalité est plus compliquée que cela.
Les messages SMS étant susceptibles d'être piratés et les attaques de phishing étant monnaie courante, votre organisation préférera peut-être n'appliquer que des facteurs résistants au phishing, voire abandonner complètement l'authentification multifacteur (MFA) 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 multifacteur (MFA). Des facteurs tels que les politiques d'authentification, les multiples fournisseurs d'authentification unique (SSO) et les différences de comportements 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, assurant 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 d'ingénierie perspicaces d'Okta pour approfondir vos connaissances.
Prêt à rejoindre notre équipe passionnée d'ingénieurs exceptionnels ? Consultez notre page de 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 uniquement destiné à des fins d'information générale et peut ne pas refléter les développements les plus récents en matière de sécurité, de confidentialité et de droit, 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.
