Pour faire suite à notre série sur la fiabilité d’Azure que nous voulons aussi transparente que possible concernant les initiatives clés en cours pour poursuivre l’amélioration de la disponibilité, nous nous penchons aujourd’hui sur Azure Active Directory. Microsoft Azure Active Directory (Azure AD) est un service d’identité cloud qui offre un accès sécurisé à plus de 250 millions utilisateurs actifs mensuels, connecte plus de 1,4 million d’applications uniques et traite plus de 30 milliards demandes d’authentification chaque jour. Azure AD est de ce fait la plus grande solution d’entreprise de gestion des identités et des accès, ainsi que l’un des plus grands services au monde. Le billet qui suit a été écrit par Nadim Abdo, directeur partenaire Ingénierie, qui supervise ce processus. » - Mark Russinovich, directeur technique, Azure

---

 

Nos clients font confiance à Azure AD pour gérer l’accès sécurisé à l’ensemble de leurs applications et services. Pour nous, cela signifie que chaque demande d’authentification est une opération stratégique. Étant donné la nature critique et l’échelle du service, la priorité la plus importante de notre équipe d’identité est la fiabilité et la sécurité du service. Azure AD est conçu pour fournir une haute disponibilité et une sécurité accrue à l’aide d’une architecture multi-locataires, hyperscale et native dans le cloud et notre équipe œuvre jour après jour à hausser le niveau de fiabilité et de sécurité.

Azure AD : principes de disponibilité de base

C’est une tâche complexe de concevoir un service avec cette échelle, cette complexité et cette importance stratégique qui soit hautement disponible dans un monde où tout ce sur quoi nous nous reposons peut subir une défaillance.

Nos efforts de résilience sont organisés autour des principes de fiabilité ci-dessous :

Notre travail sur la disponibilité adopte une approche de protection en couche pour réduire autant que possible le risque de défaillance visible par les clients. Si une défaillance se produit, notre travail est de réduire l’impact de cette défaillance autant que possible et de diminuer autant que possible le délai nécessaire à la récupération et à l’atténuation d’un incident.

Au cours des semaines et des mois à venir, nous allons explorer plus en détail la façon dont chacun des principes est conçu et vérifié en pratique, ainsi que des exemples de la façon dont ils fonctionnent pour nos clients.

Forte redondance

Azure AD est un service mondial avec plusieurs niveaux de redondance interne et de récupération automatique. Azure AD est déployé dans plus de 30 centres de données répartis dans le monde entier tirant parti de zones de disponibilité Azure, le cas échéant. Ce nombre augmente rapidement à mesure que des régions Azure supplémentaires sont déployées.

À des fins de durabilité, toute donnée écrite dans Azure AD est répliquée vers au moins 4 et jusqu’à 13 centres de données en fonction de la configuration de votre locataire. Au sein de chaque centre de données, les données sont de nouveau répliquées au moins 9 fois en vue de leur durabilité, ainsi que pour augmenter la capacité afin de servir la charge d’authentification. À titre d’illustration, cela signifie qu’à tout moment, il y a au moins 36 copies de vos données de répertoire disponibles au sein de notre service dans notre plus petite région. À des fins de durabilité, les écritures dans Azure AD ne sont pas effectuées jusqu’à la réussite de la validation vers un centre de centres en dehors de la région.

Cette approche nous offre à la fois la durabilité des données et une redondance massive : plusieurs chemins d’accès réseau et centres de données peuvent traiter une demande d’autorisation donnée, et le système effectue de nouvelles tentatives automatiquement et intelligemment et achemine les défaillances à la fois à l’intérieur d’un même centre de données et au sein de différents centres de données.

Pour valider cela, régulièrement, nous utilisons l’injection d’erreurs et validons la résilience du système à la défaillance des composants système sur lesquels Azure AD est basé. Nous allons jusqu’à mettre hors service des centres de données entiers sur une base régulière pour confirmer que le système peut tolérer la perte d’un centre de données sans aucun impact sur le client.

Aucun point de défaillance unique

Comme nous l’avons vu, Azure AD lui-même est structuré avec plusieurs niveaux de résilience interne, mais notre principe s’étend encore davantage en assurant la résilience dans toutes nos dépendances externes. Cela est exprimé dans notre propre principe de point de défaillance unique (SPOF).

Étant donné l’importance de nos services, nous n’acceptons pas les points de défaillance unique dans les systèmes externes critiques, tels que DNS, CDN ou des fournisseurs Telco qui transportent notre authentification multifacteur (MFA), notamment les SMS et la voix. Pour chacun de ces systèmes, nous utilisons plusieurs systèmes redondants configurés dans une configuration active-active complète.

La plupart de ce travail sur ce principe s’est achevé au cours de la dernière année civile. Pour illustrer cela, lorsqu’un grand fournisseur DNS a récemment expérimenté une panne, Azure AD n’a pas du tout été affecté, car nous avions un chemin actif/actif vers un autre fournisseur.

Mise à l’échelle élastique

Azure AD est déjà un système énorme s’exécutant sur plus de 300 000 cœurs de processeur qui est capable de s’appuyer sur la scalabilité massive du cloud Azure pour évoluer dynamiquement et rapidement afin de répondre à la demande. Cela peut inclure des augmentations naturelles du trafic, telles qu’un pic à 9 h 00 dans les authentifications d’une région donnée, ainsi que des pics d’activité considérables dans le nouveau trafic traité par notre instance Azure AD B2C qui alimente certains des plus grands événements au monde et voit souvent des rushes de millions de nouveaux utilisateurs.

Comme niveau de résilience supplémentaire, Azure AD sur-provisionne sa capacité et, dans sa conception, un éventuel basculement d’un centre de données entier ne nécessite pas de configuration supplémentaire de capacité pour gérer la charge redistribuée. Nous savons ainsi qu’en cas d’urgence, nous avons déjà toute la capacité dont nous avons besoin.

Déploiement sécurisé

Le déploiement sécurisé permet de faire en sorte que les modifications (de code ou de configuration) progressent graduellement de l’automatisation interne aux anneaux d’auto-hébergement Microsoft en production. Au sein de la production, nous adoptons une augmentation très graduée et lente du pourcentage d’utilisateurs exposés à une modification avec des contrôles d’intégrité automatisés contrôlant la progression d’un anneau de déploiement au suivant. Tout ce processus nécessite plus d’une semaine pour déployer entièrement une modification en production et peut à tout moment revenir rapidement au dernier état d’intégrité connu.

Ce système détecte régulièrement les défaillances potentielles dans ce que nous appelons nos « anneaux initiaux » qui sont entièrement internes à Microsoft. Le système empêche par ailleurs leur déploiement sur des anneaux qui auraient un impact sur le trafic client/en production.

Vérification moderne

Pour prendre en charge les contrôles d’intégrité qui permettent un déploiement sécurisé et donner à notre équipe d’ingénierie des insights sur l’intégrité des systèmes, Azure AD émet une quantité importante de données de télémétrie en interne, de métriques et de signaux utilisés pour surveiller l’intégrité de nos systèmes. À notre échelle, cela représente plus de 11 pétaoctets par semaine de signaux qui alimentent nos systèmes de surveillance automatique de l’état d’intégrité. Ces systèmes déclenchent à leur tour des alertes pour l’automatisation, ainsi que pour notre équipe d’ingénieurs 24h/24, 7j/7 et 365j/an qui répondent à toute détérioration potentielle de la disponibilité ou de la qualité de service (QoS).

Nous travaillons à l’enrichissement de cette télémétrie pour fournir une vue de l’intégrité des services, ainsi que des métriques qui représentent véritablement l’intégrité de bout en bout d’un scénario donné pour un locataire donné. Notre équipe est déjà en train d’alerter sur ces métriques en interne et nous évaluons actuellement comment exposer ces données d’intégrité par locataire directement aux clients dans le portail Azure.

Partitionnement et domaines d’erreur affinés

Pour mieux comprendre Azure AD, les compartiments de sous-marin sont une bonne analogie : ils sont conçus pour pouvoir être immergés sans affecter les autres compartiments ni l’intégrité de l’ensemble du sous-marin.

L’équivalent dans Azure AD est un domaine d’erreur. Les unités d’échelle qui servent un ensemble de locataires dans un domaine d’erreur sont conçues pour être complètement isolées des unités d’échelle des autres domaines d’erreur. Ces domaines d’erreur fournissent une isolation forte de nombreuses classes de défaillances, de sorte que le « rayon d’action » d’une erreur est contenu dans un domaine d’erreur donné.

Azure AD jusqu’à maintenant est constitué de 5 domaines d’erreur distincts. Depuis l’an dernier et d’ici l’été prochain, ce nombre passera à 50 domaines d’erreur, et de nombreux services, notamment Azure Multi-Factor Authentication (MFA), sont actuellement déplacés pour être totalement isolés dans ces mêmes domaines d’erreur.

Ce travail de fort partitionnement est conçu pour être un recours final qui limite toute panne ou défaillance à 1/50 ou environ 2 % de nos utilisateurs maximum. Notre objectif est d’augmenter ces chiffres jusqu’à des centaines de domaines d’erreur au cours de l’année suivante.

Un aperçu des nouveautés

Les principes ci-dessus visent à renforcer le service Azure AD de base. Étant donné la nature critique d’Azure AD, nous ne nous arrêtons pas là. Les prochaines publications couvriront les nouveaux efforts que nous déployons, notamment le déploiement en production d’un deuxième service d’identité entièrement décorrélé des erreurs qui peut fournir une prise en charge fluide de l’authentification de secours en cas de défaillance du service Azure AD principal.

Considérez cela comme l’équivalent d’un générateur de sauvegarde ou d’un onduleur qui peut fournir une couverture et une protection lorsque la grille d’alimentation principale est affectée. Ce système est totalement transparent et fluide pour les utilisateurs finaux. Il est à présent en production et protège une partie de nos flux d’authentification critiques pour un ensemble de charges de travail M365. Nous développerons rapidement son applicabilité pour couvrir davantage de scénarios et de charges de travail.

Nous sommes impatients de partager d’autres informations sur notre blog Azure Active Directory Identity. Nous vous invitons à poser vos questions et à indiquer vos sujets d’intérêt pour les prochaines publications.