Système d’authentification de sauvegarde de Microsoft Entra ID

Les organisations du monde entier dépendent de la haute disponibilité de l’authentification de Microsoft Entra des utilisateurs et des services 24 heures sur 24, sept jours sur sept. Nous promettons une disponibilité de niveau de service de 99,99 % de l’authentification, et nous cherchons continuellement à l’améliorer en renforçant la résilience de notre service d’authentification. Pour améliorer davantage la résilience lors des pannes, nous avons implémenté en 2021un système de sauvegarde.

Le système d’authentification de sauvegarde de Microsoft Entra est constitué de plusieurs services de sauvegarde qui fonctionnent ensemble pour augmenter la résilience de l’authentification en cas de panne. Ce système gère de manière transparente et automatique les authentifications des applications et services pris en charge si le service Microsoft Entra principal n’est pas disponible ou est détérioré. Il ajoute une couche supplémentaire de résilience au-dessus des différents niveaux de redondance existante. Cette résilience est décrite dans le billet de blog Avancement de la résilience du service dans Microsoft Entra ID avec son service d’authentification de sauvegarde. Ce système synchronise les métadonnées d’authentification lorsque le système est sain et les utilise pour permettre aux utilisateurs de continuer à accéder aux applications pendant les pannes du service principal tout en appliquant des contrôles de stratégie.

Lors d’une panne du service principal, les utilisateurs peuvent continuer à utiliser leurs applications, s’ils y ont accédé au cours des trois derniers jours depuis le même appareil, et s’il n’existe aucune stratégie de blocage qui limiterait leur accès :

En plus des applications Microsoft, nous prenons en charge les applications suivantes :

• Clients natifs de messagerie sur iOS et Android.
• Applications SaaS (software as a service) disponibles dans la galerie d’applications, comme ADP, Atlassian, AWS, GoToMeeting, Kronos, Marketo, SAP, Trello, Workday, etc.
• Applications métier sélectionnées, en fonction de leurs modèles d’authentification.

L’authentification de service à service qui s’appuie sur des identités managées pour les ressources Azure ou qui repose sur des services Azure reçoit une résilience accrue du système d’authentification de sauvegarde.

Microsoft augmente continuellement le nombre de scénarios pris en charge.

Quelles charges de travail non-Microsoft sont prises en charge ?

Le système d’authentification de sauvegarde fournit automatiquement une résilience incrémentielle à des dizaines de milliers d’applications non-Microsoft prises en charge en fonction de leurs modèles d’authentification. Consultez l’annexe pour obtenir une liste des plus courantes applications non Microsoft et l’état de leur couverture. Pour une explication détaillée des modèles d’authentification pris en charge, consultez l’article Compréhension de la prise en charge des applications par le système d’authentification de sauvegarde.

• Applications natives utilisant le protocole OAuth (Open Authorization) 2.0 pour accéder aux applications de ressources, telles que les clients populaires de messagerie électronique et de messagerie instantanée non Microsoft comme Apple Mail, Aqua Mail, Gmail, Samsung Email et Spark.
• Applications web métier configurées pour s’authentifier avec OpenID Connect à l’aide de jetons d’ID uniquement.
• Applications web s’authentifiant avec le protocole SAML (Security Assertion Markup Language), lorsqu’elles sont configurées pour une authentification unique lancée par le fournisseur d’identité, telles que ADP, Atlassian Cloud, AWS, GoToMeeting, Kronos, Marketo, Palo Alto Networks, SAP Cloud Identity Services, Trello, Workday et Zscaler.

Types d’applications non-Microsoft non protégés

Les modèles d’authentification suivants ne sont pas pris en charge :

• Applications web qui s’authentifient à l’aide d’Open ID Connect et qui requièrent des jetons d’accès
• Applications web qui utilisent le protocole SAML pour une authentification, lorsqu’elles sont configurées pour une authentification unique initiée par le fournisseur de services

Dans quels cas un utilisateur est-il pris en charge par le système d’authentification de sauvegarde ?

Lors d’une panne, un utilisateur peut s’authentifier à l’aide du système d’authentification de sauvegarde si les conditions suivantes sont remplies :

1. L’utilisateur s’est correctement authentifié à l’aide de la même application et du même appareil au cours des trois derniers jours.
2. L’utilisateur n’est pas tenu de s’authentifier de manière interactive
3. L’utilisateur accède à une ressource en tant que membre de son locataire de base, plutôt qu’en exerçant un scénario B2B ou B2C.
4. L’utilisateur n’est pas soumis à des stratégies d’accès conditionnel qui limitent le système d’authentification de sauvegarde, comme la désactivation des paramètres de résilience par défaut.
5. L’utilisateur n’a pas été soumis à un événement de révocation, tel qu’une modification des informations d’identification depuis sa dernière authentification réussie.

Comment l’authentification interactive et l’activité de l’utilisateur affectent-elles la résilience ?

Le système d’authentification de sauvegarde repose sur les métadonnées d’une authentification antérieure pour réauthentifier l’utilisateur lors d’une panne. Un utilisateur doit avoir authentifié au cours des trois derniers jours à l’aide de la même application sur le même appareil pour que le service de sauvegarde soit efficace. Les utilisateurs inactifs ou qui ne se sont pas authentifiés auprès d’une application donnée ne peuvent pas utiliser le système d’authentification de sauvegarde pour cette application.

Comment les stratégies d’accès conditionnel affectent-elles la résilience ?

Certaines stratégies ne peuvent pas être évaluées en temps réel par le système d’authentification de sauvegarde et doivent s’appuyer sur des évaluations antérieures de ces stratégies. En cas de panne, le service utilise une évaluation antérieure par défaut pour optimiser la résilience. Par exemple, un accès conditionné à un utilisateur disposant d’un rôle particulier (comme administrateur d’application) se poursuit pendant une panne en fonction du rôle que l’utilisateur a eu lors de cette dernière authentification. Si l’utilisation en panne uniquement d’une évaluation précédente doit être limitée, les administrateurs de locataire peuvent choisir une évaluation stricte de toutes les stratégies d’accès conditionnel, même en cas de panne, en désactivant les paramètres de résilience par défaut. Cette décision doit être prise avec précaution, car la désactivation des valeurs de résilience par défaut d’une stratégie donnée empêche ces utilisateurs d’utiliser l’authentification de sauvegarde. Les paramètres de résilience par défaut doivent être réactivés avant qu’une panne ne se produise pour que le système de secours assure la résilience.

Certains autres types de stratégies ne prennent pas en charge l’utilisation du système d’authentification de sauvegarde. L’utilisation des stratégies suivantes réduit la résilience :

• Utilisation du contrôle de fréquence de connexion dans le cadre d’une stratégie d’accès conditionnel.
• Utilisation de la stratégie des méthodes d’authentification.
• Utilisation des stratégies d’accès conditionnel classiques.

Évaluation des stratégies d’accès conditionnel uniquement aux rapports

Si une demande est traitée par le système d’authentification de secours, les stratégies d’accès conditionnel configurées en mode Rapport uniquement apparaîtront sous l’onglet Accès conditionnel dans les journaux de connexion de surveillance de Entra ID Intégrité & surveillance pour cet événement de connexion, plutôt que dans l’onglet Rapport uniquement. Notez que même dans cette vue, les stratégies configurées en mode Rapport uniquement ne sont jamais appliquées. Pour voir si des jetons ont été émis via le système d’authentification secondaire au sein de votre environnement, vous pouvez utiliser les journaux des connexions. Dans Entra ID>Monitoring &health>Sign-in Logs, ajoutez le filtre Token issuer type == Microsoft Entra Backup Auth pour afficher les journaux traités par le système d’authentification de sauvegarde.

Révocation de certificats et système d’authentification de sauvegarde

Pour améliorer sa posture de résilience, le système d’authentification de sauvegarde ne peut pas effectuer de nouvelles vérifications de révocation. Au lieu de cela, elle s’appuie sur l’état de la vérification de la liste de révocation de certificats (CRL) qui a été effectuée lors de la dernière sauvegarde de la session. Si vous devez révoquer avant l'expiration de cette sauvegarde, il est recommandé de révoquer explicitement la session plutôt que d'attendre le CRL.

Résilience des identités de charge de travail dans le système d’authentification de sauvegarde

En plus de l’authentification utilisateur, le système d’authentification de sauvegarde assure la résilience des identités managées et d’autres infrastructures clés Azure en offrant un service d’authentification isolé régionalement redondant avec le service d’authentification principal. Ce système permet à l’authentification d’infrastructure au sein d’une région Azure d’être résiliente aux problèmes qui peuvent se produire dans une autre région ou dans le service Microsoft Entra plus large. Ce système complète l’architecture inter-région d’Azure. La création de vos propres applications à l’aide de MI et le respect des meilleures pratiques en matière de résilience et de disponibilité d’Azure garantissent que vos applications sont hautement résilientes. En plus de MI, ce système de sauvegarde résilient au niveau régional protège l’infrastructure et les services clés Azure qui maintiennent le cloud fonctionnel.

Résumé de la prise en charge de l’authentification de l’infrastructure

• Vos services basés sur l’infrastructure Azure utilisant des identités managées sont protégés par le système d’authentification de sauvegarde.
• Les services Azure qui s’authentifient entre eux sont protégés par le système d’authentification de sauvegarde.
• Vos services basés ou non sur Azure dont les identités sont inscrites en tant que principaux de service et non en tant qu’« identités managées » ne sont pas protégés par le système d’authentification de secours.

Environnements cloud qui prennent en charge le système d’authentification de sauvegarde

Le système d’authentification de sauvegarde est pris en charge dans tous les environnements cloud, à l’exception de Microsoft Azure géré par 21Vianet. Les types d’identités pris en charge varient selon le cloud et ont des points de terminaison d’authentification distincts, comme décrit dans le tableau suivant.

Annexe

Applications clientes natives non-Microsoft populaires et applications de galerie d’applications

Ressources Azure et leur état

Étapes suivantes

• Exigences d’application relatives au système d’authentification de sauvegarde
• Présentation du système d’authentification de sauvegarde
• Valeurs de résilience par défaut d’un accès conditionnel
• Rapports de performances du contrat de niveau de service (SLA) Microsoft Entra