Rendre l'authentification multifacteur (MFA) obligatoire pour sécuriser la porte d'entrée de la console d'administration

Pourquoi l'authentification multifacteur (MFA) est-elle appliquée à la console d'administration Okta ?

La console d'administration Okta est la plaque tournante centrale pour la gestion des utilisateurs Okta, des applications protégées par Okta et des politiques de sécurité Okta. Un accès non autorisé à cette console peut avoir des conséquences désastreuses qui incluent :

• Violations de données : les attaquants pourraient accéder aux informations sensibles des utilisateurs et aux données des applications.
• Compromission du système : les acteurs malveillants peuvent modifier les paramètres de sécurité, créer des comptes de porte dérobée et désactiver les fonctions de sécurité critiques.
• Interruption de service : des modifications non autorisées peuvent entraîner des pannes et une fonctionnalité altérée pour les utilisateurs finaux.
• Atteinte à la réputation : un incident de sécurité peut gravement nuire aux activités et à l'image de marque d'une organisation.

L'authentification multifacteur (MFA) réduit considérablement le risque de ces problèmes en exigeant un deuxième facteur de vérification en plus d'un mot de passe, tel qu'un mot de passe unique basé sur le temps (TOTP) provenant d'une application d'authentification mobile, une analyse d'empreinte digitale ou un jeton matériel. Bien qu'Okta n'exige l'authentification multifacteur (MFA) qu'avec deux facteurs parmi la connaissance, la possession ou l'inhérence, Okta encourage fortement les administrateurs à abandonner les mots de passe et à activer les authentificateurs les plus sécurisés disponibles, notamment les authentificateurs résistants au phishing comme Okta Verify FastPass et les authentificateurs FIDO2 WebAuthn.

Okta fournit des fonctionnalités robustes pour appliquer l’authentification MFA pour l’accès administratif. Tous les tenants Okta sont livrés avec un nombre de base de facteurs pris en charge, tels que Okta Verify TOTP, FastPass et e-mail, en plus des mots de passe. Okta fournit également une politique flexible qui permet aux administrateurs d’appliquer l’authentification MFA spécifiquement à la console d’administration Okta.

La politique d'application de la console a toujours exigé l'authentification multifacteur (MFA) par défaut. Toutefois, les administrateurs étaient autorisés à abaisser le paramètre à l'authentification à un seul facteur (1FA), ce que beaucoup ont choisi de faire pour diverses raisons. Désormais, Okta empêche que cette position de sécurité par défaut soit abaissée, et nous avons aidé tous les clients existants à améliorer leur niveau de sécurité avec l'authentification multifacteur (MFA).

Comment nous avons convaincu les clients Okta d'appliquer l'authentification multifacteur (MFA)

Voyons comment nous avons aidé les administrateurs à surmonter leur besoin réel et perçu de maintenir des politiques 1FA et à adopter l'authentification multifacteur (MFA) pour sécuriser l'accès à Okta Admin Console. En général, les clients acceptaient que l'authentification MFA était une bonne chose à instaurer. Cependant, il y avait plusieurs raisons courantes pour lesquelles ils pensaient devoir rester au niveau d'assurance 1FA :

1. Les administrateurs ne savaient pas qu'ils avaient des règles de politique qui autorisaient l'accès 1FA.
2. Les administrateurs pensaient qu'ils n'avaient pas besoin de l'authentification multifacteur (MFA) car ils protégeaient leurs mots de passe et les faisaient tourner à chaque utilisation.
3. Les administrateurs ont effectué l'authentification multifactorielle (Multi-Factor Authentication, MFA) avec un fournisseur d'identité (Identity Provider, IdP) différent d'Okta et se fédéraient dans la console d'administration Okta.
4. Les administrateurs avaient des comptes de test automatisés qui devaient se connecter à la console.
5. Les administrateurs étaient préoccupés par les opérations des agents Lightweight Directory Access Protocol (LDAP) et Active Directory (AD).

Nous avons pris soin de répondre à chacun de ces obstacles et préoccupations. Ce dernier problème a été facile à résoudre avec une simple confirmation qu’il n’y aurait aucun impact sur les opérations normales des agents.

Cependant, pour le reste, nous avons d'abord publié des avertissements aux administrateurs s'ils avaient un locataire avec des règles autorisant l'accès 1FA via notre fonctionnalité HealthInsights.

Nous avons également publié des avertissements à partir de la politique Okta Admin Console, mettant en évidence ces règles problématiques.

Pour les administrateurs qui pensaient ne pas avoir besoin de l'authentification multifacteur (MFA) car ils conservaient et faisaient régulièrement tourner leurs mots de passe, nous avons insisté sur le fait que la protection MFA est supérieure. Bien que les clients doivent continuer à conserver et à faire tourner leurs secrets, ils doivent également ajouter une exigence de facteur supplémentaire, en particulier un facteur de possession ou biométrique. Si les mots de passe conservés étaient partagés avec plusieurs utilisateurs, nous avons recommandé que chaque utilisateur ait son propre compte unique.

Quant aux autres clients, certains ont choisi d’effectuer l’AMF sur un fournisseur d’identité externe et de se fédérer dans Okta Admin Console. Jusqu’à récemment, Okta traitait cette fédération entrante comme un facteur unique. Cependant, nous avons maintenant une nouvelle fonctionnalité appelée claims sharing. Le fournisseur d’identité peut envoyer des revendications AMR basées sur des normes dans la réponse SAML ou OIDC, et Okta honorera les facteurs remplis avec l’autre fournisseur d’identité comme satisfaisants pour l’assurance MFA. Ainsi, un autre obstacle a été levé.

Pour les clients disposant de comptes de test automatisés qui se sont connectés à la console pour effectuer des tests, les administrateurs pensaient qu'il ne serait pas possible de fournir un facteur supplémentaire pour de tels comptes. Okta a résolu ce problème en recommandant que les comptes de test s'inscrivent à un facteur TOTP et conservent le secret partagé avec le mot de passe. Après avoir extrait le mot de passe, le secret partagé peut également être extrait et utilisé pour générer par programmation le TOTP au moment de la connexion.

Avec tous ces défis clients résolus, nos clients étaient prêts à passer à l'action.

Préparation du déploiement des modifications

Étant donné le grand nombre de clients Okta avec lesquels nous traitions, allant des versions d’essai gratuites et des clients développeurs aux clients ayant des mises en œuvre vastes et compliquées, il était nécessaire d’échelonner le déploiement afin de réduire au minimum les perturbations des opérations normales. Par conséquent, nous avons employé plusieurs tactiques pour appliquer soigneusement l’authentification multifacteur (MFA) à la console d’administration Okta :

1. Annonce de l'initiative : en plus des annonces publiques et des blogs indiquant l'application imminente de l'authentification multifacteur (MFA), nous avons publié des guides et des bannières intégrés au produit sur les portails de développement et d'assistance Okta, et nous avons envoyé des e-mails ciblés aux administrateurs pour les informer des changements à venir.
2. Empêcher la création de toute nouvelle politique d'accès 1FA : Dans un premier temps, Okta a déployé des modifications à tous les tenants afin qu'aucune nouvelle politique d'accès 1FA ne puisse être établie. L'idée était d'arrêter l'hémorragie avant que le correctif complet ne soit déployé.
3. Divisez les clients en cohortes pour l'application de l'authentification MFA : pour atténuer le risque d'un afflux de tickets de support à Okta et éviter les verrouillages d'administrateur inutiles, nous avons déployé cette modification par cohortes de clients. Nous avons d'abord examiné les configurations de chaque tenant et les avons regroupées en fonction des étapes de correction qu'elles nécessiteraient pour appliquer l'authentification MFA (Multi-Factor Authentication). Ensuite, nous avons sélectionné différentes dates d'application pour chaque cohorte et préparé des instructions de correction spécifiques.

Il a été demandé aux administrateurs de modifier leurs politiques Okta Admin Console de la manière suivante :

• Les règles avec une assurance basée uniquement sur le mot de passe doivent être modifiées pour exiger un mot de passe et un autre facteur.
• Les règles avec une assurance 1FA ou une assurance basée uniquement sur un facteur de possession doivent être modifiées pour exiger deux facteurs quelconques.

Une fois la modification effectuée, les administrateurs n'étaient pas autorisés à revenir à l'assurance 1FA. Si un administrateur ne prenait aucune mesure, Okta appliquait l'authentification multifacteur (MFA) à la console pour ce locataire à une date clairement communiquée.

Les clients d'Okta se sont lancés à corps perdu dans l'authentification MFA

Au cours des quatre premiers mois du déploiement, Okta a achevé l'application de l'authentification multifacteur (MFA) sur 99 % de tous les locataires applicables. Le 1 % restant était constitué de locataires qui nécessitaient une assistance supplémentaire d'Okta, soit sous la forme d'améliorations de fonctionnalités, comme le partage de revendications, soit du temps nécessaire pour mettre à jour divers processus afin de fonctionner à ce nouveau niveau de sécurité requis. Okta est resté en contact avec ce groupe de clients pour comprendre en profondeur leurs points faibles et collaborer avec eux jusqu'à ce qu'ils soient confiants quant à l'évolution dans cette nouvelle direction.

Grâce à l'application de l'authentification MFA à 100 % à la console d'administration Okta, les administrateurs utilisent désormais divers facteurs et authentificateurs pour se connecter à la console. Les trois principaux facteurs utilisés sont le mot de passe, les notifications push Okta Verify et Okta FastPass. Les combinaisons courantes de ces facteurs utilisées pour relever un défi MFA incluent le mot de passe et Okta Verify push, ainsi que le mot de passe et Okta FastPass.

Aujourd'hui, l'accès MFA (authentification multifacteur) à la console d'administration Okta est une exigence non négociable pour tous les administrateurs Okta actuels et nouvellement intégrés. En adoptant par défaut cette posture sécurisée, les clients bénéficient d'une surface d'attaque réduite et d'une meilleure protection de l'infrastructure d'identité critique.

Apprenez-en davantage sur le produit d'authentification MFA d'Okta en visitant la page Web Adaptive MFA. Gardez un œil sur ce qu'Okta fait pour lutter contre les attaques basées sur l'identité en vous informant sur l'engagement d'Okta en matière de sécurité des identités.