Discussion :

[Bill Fassinou]

Microsoft attribue la panne d'Azure et de Teams à un bogue dans son système d'authentification Azure AD lors d'une migration intercloud
d'autres services comme Office 365, Dynamics 365 et Xbox Live ont été aussi affectés

Plusieurs services de Microsoft ont subi une panne mondiale de quelques heures (environ 2 heures) ce 15 mars. Dans les premiers rapports fournis par la société, elle a indiqué que les services qui ont été affectés sont ceux qui dépendent d'Azure AD (Azure Active Directory) pour l'authentification. Une autre analyse publiée par Microsoft le mardi indique qu'une erreur s'est produite dans la rotation des clés utilisées pour prendre en charge l'utilisation par Azure AD d'OpenID et d'autres protocoles standard d'identité pour les opérations de signature cryptographique.

Azure et d'autres services Microsoft sont restés à l'arrêt pendant au moins 2 heures

Microsoft a présenté lundi ses excuses pour un problème lié à Azure AD qui a perturbé l'accès aux applications Office 365 et au portail d'administration Azure pendant deux heures ou plus pour certains utilisateurs. Ces excuses font partie d'un avis publié par l'entreprise, qui expliquait comment une opération interne de migration "intercloud", visant à améliorer le service Azure AD, avait fini par perturber les services de certaines organisations. Des interruptions de service ont eu lieu le 15 mars pour certains utilisateurs d'Azure Admin Portal, Teams, Exchange, Azure KeyVault, SharePoint, Storage et d'autres applications majeures.

« Nous réalisons l'impact incroyable et inacceptable de cela et nous nous excusons profondément », a déclaré Microsoft dans un rapport d'examen post-incident sur la panne. « Nous prenons continuellement des mesures pour améliorer la plateforme Microsoft Azure et nos processus afin de nous assurer que de tels incidents ne se reproduisent pas à l'avenir ». Tous les services auraient été rétablis. L'incident s'est produit parce que Microsoft avait conservé une clé pour éviter qu'elle n'expire dans le cadre de la migration intercloud.

Cependant, le processus automatisé de Microsoft a ignoré l'état de conservation de la clé. En raison de cette circonstance, les jetons signés avec cette clé n'étaient pas fiables, ce qui a entraîné des interruptions de service. Plus précisément, Microsoft a expliqué dans son rapport d'analyse que, dans le cadre des pratiques de sécurité normales, un système automatisé supprime les clés qui ne sont plus utilisées, mais au cours des dernières semaines, une clé a été marquée comme "à conserver" pendant plus longtemps que la normale afin de faciliter le processus complexe de migration intercloud.

Résultat, cela a entraîné un bogue qui a provoqué la suppression de la clé conservée. Mais une fois que les métadonnées ont été modifiées vers 15 heures (heure de l'Est – début de la panne), les applications utilisant ces protocoles dans Azure AD ont commencé à prendre en compte les nouvelles métadonnées et ont cessé de faire confiance aux jetons signés avec la clé supprimée. Les ingénieurs de Microsoft ont rétabli le système dans son état antérieur vers 17 heures (heure de l'Est).

Mais il faut un certain temps pour que les applications récupèrent les métadonnées rétablies et se rafraîchissent avec les métadonnées correctes. Un sous-ensemble de ressources de stockage a nécessité une mise à jour pour invalider les entrées incorrectes et forcer un rafraîchissement. Voici la chronologie de Microsoft décrivant les problèmes d'Azure AD :

• 15 mars (lundi) à environ 19h UTC : les utilisateurs commencent à voir des erreurs d'authentification pour toute application qui utilise le service Azure AD ;
• 15 mars (lundi) à 21:05 UTC : Microsoft a ramené les métadonnées de la clé à leur état antérieur. Les services d'application commencent à se rétablir, à l'exception de certaines "ressources de stockage" ;
• 16 mars (mardi) à environ 9h25 UTC : Microsoft détermine que la plupart des problèmes, y compris pour les ressources de stockage, ont été atténués pour les clients ;

Azure AD est-il le "talon d'Achille" des services Microsoft 365 ?

Azure AD est le service de gestion des identités et des accès basé sur le cloud de Microsoft, qui aide les employés à se connecter et à accéder à différentes catégories de ressources. On distingue les ressources externes (Microsoft 365, le portail Azure et des milliers d'autres applications SaaS) et les ressources internes (es applications sur le réseau et l'intranet de votre entreprise, ainsi que les applications en nuage développées par votre propre organisation). L'incident du 15 mars n'était pas le premier du genre. Microsoft a admis qu'un précédent incident lié à Azure AD s'est produit le 28 septembre 2020, à peu près de la même manière.

Cette dernière panne a impacté les utilisateurs de Microsoft 365 pendant cinq heures. C'est à ce moment que Microsoft a pris la décision d'améliorer le service Azure AD en deux étapes. « Dans l'incident de septembre dernier, nous avons indiqué nos plans pour appliquer des protections supplémentaires au système SDP (Session Description Protocol) du back-end du service Azure AD (Active Directory) afin d'empêcher la catégorie de problèmes identifiés ici », a déclaré Microsoft dans son rapport du lundi. Selon le rapport, Microsoft est actuellement engagé dans un processus en deux étapes devant lui permettre d'améliorer le service Azure AD.

La société mène en effet des efforts pour éviter les mêmes problèmes qui se sont produits lorsque Microsoft a eu besoin de modifier une clé. Le processus vise à ajouter un système back-end "Safe Deployment Process" (SDP) pour prévenir une catégorie de risques, y compris ce problème. Microsoft a déjà achevé la première étape de ce processus de déploiement sécurisé pour le service Azure AD. La deuxième étape consiste en la mise en place d'un composant "remove-key", mais aussi d'autres systèmes. Selon l'entreprise, la deuxième étape du processus d'amélioration devrait être achevée au milieu de l'année.

Les responsables de Microsoft ont déclaré que la panne d'authentification Azure AD survenue à la fin du mois de septembre fait partie de la même catégorie de risques qu'ils pensent pouvoir contourner une fois le projet en plusieurs phases terminé. Une analyse complète des causes profondes sera publiée une fois l'enquête terminée, ont indiqué les responsables. Par ailleurs, les utilisateurs des services Microsoft 365 ont également connu d'autres pannes liées au service Azure AD. Il y a quelques années, d'éventuelles modifications de la configuration par Microsoft ont provoqué 2,5 heures d'interruption.

Courant 2018, la foudre a perturbé un hub Azure AD au Texas, provoquant des pannes de plus d'une journée. Tony Redmond, un Microsoft MVP (Most Valuable Professional), a qualifié Azure AD de "talon d'Achille" des services Microsoft 365 dans un billet décrivant la panne du lundi.

Sources : Microsoft (1, 2), Tony Redmond

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi

Microsoft met un terme à trois de ses parcours de certifications les plus populaires (MCSA, MCSD et MCSE) après juin 2020 pour se consacrer à de nouveaux autour d'Azure, de l'IA et de Dynamics 365

La vaste campagne de piratage informatique a atteint Microsoft, qui qualifie la violation de la chaîne d'approvisionnement contre SolarWinds d'« acte d'imprudence »

Président de Microsoft : le piratage de SolarWinds a été « l'attaque la plus importante et la plus sophistiquée » jamais réalisée, les empreintes informatiques de plus de 1000 développeurs trouvées

Les hackers de SolarWinds ont étudié le code source de Microsoft pour l'authentification et le courrier électronique, notamment en téléchargeant une partie du code source d'Azure, Exchange et Intune

Malgré le correctif de Microsoft dans son serveur de messagerie Exchange, le gouvernement US met en garde contre la "menace active qui continue de se développer" et appelle à l'action