Posté le janvier 29, 2023 à 6:12
MICROSOFT ATTRIBUE UNE PANNE DE CINQ HEURES DE MICROSOFT 365 AU CHANGEMENT D’ADRESSE IP D’UN ROUTEUR
Microsoft a récemment connu une interruption de cinq heures de son service Microsoft 365. Cette panne, qui s’est étendue au monde entier, a suscité beaucoup d’inquiétude, mais l’entreprise vient de fournir une explication. Selon l’entreprise, la panne a été causée par un changement d’adresse IP d’un routeur, qui a entraîné des problèmes de transfert de paquets entre d’autres routeurs connectés à son réseau étendu (WAN).
Au moment de la panne, l’annonce officielle de Redmond était que l’incident s’est produit en raison de problèmes de configuration impliquant le WAN et le DNS, dus à une mise à jour du WAN. Pendant ce temps, les utilisateurs de toutes les régions desservies par l’infrastructure touchée ont souffert des mêmes problèmes lorsqu’ils ont essayé d’accéder aux services Microsoft 365.
L’incident a touché de nombreux services
Le problème initial a affecté les services Microsoft 365 par vagues, avec des pics toutes les 30 minutes en moyenne sur la page d’état des services Microsoft Azure, qui était elle-même affectée par le problème. En fait, la liste des services touchés est assez longue, et elle comprend Microsoft Teams, Outlook, Exchange Online, SharePoint Online, PowerBi, OneDrive for Business, Microsoft Graph, Microsoft 365 Admin Center, Microsoft Defender for Cloud Apps, Microsoft Intune, ainsi que Microsoft Defender for Identity.
Redmond a eu besoin de plus de cinq heures de travail constant, concentré uniquement sur ce seul problème afin de le résoudre. La panne a commencé vers 7 h 05 UTC et a duré jusqu’à 12 h 43 UTC, heure à laquelle l’équipe de Microsoft a finalement réussi à rétablir complètement le service.
La société a ensuite publié un rapport préliminaire post-incident, expliquant ce qui s’est passé le 25 janvier. Elle a souligné que la plupart des régions et des services ont réussi à se rétablir à 9 h UTC, mais que les problèmes de perte de paquets intermittents n’ont pas été complètement atténués avant 12 h 43 UTC. L’incident a même eu un impact sur les services de cloud computing d’Azure Government, qui dépendaient du cloud public d’Azure, selon l’annonce.
Depuis lors, Microsoft a déclaré avoir découvert davantage d’informations sur l’incident, notamment le fait qu’il a été déclenché par un changement d’adresse IP d’un routeur WAN. Cela s’est produit en raison d’une commande qui n’a pas été examinée de manière suffisamment approfondie. Selon l’entreprise, la commande se comporte différemment sur les différents périphériques réseau, ce qui est à l’origine du problème.
Le routeur a reçu la commande dans le cadre d’un changement planifié pour mettre à jour l’adresse IP du routeur, mais le routeur a ensuite envoyé des messages à tous les autres routeurs du réseau WAN. En conséquence, certains d’entre eux ont commencé à recalculer leurs tables d’adjacence et de transfert. Le processus de recalcul a rendu les routeurs incapables d’acheminer correctement les paquets, ce qui a entraîné la perturbation de tous les autres services.
Le système de santé du réseau était en pause lorsque l’incident s’est produit
Le réseau a en fait commencé à se rétablir de lui-même vers 8 h 10 UTC, grâce au système automatisé mis en place pour maintenir la santé du réseau WAN. Cependant, le système était en pause au moment où le réseau a été touché, ce qui peut expliquer pourquoi l’impact a été possible en premier lieu.
Le système dispose de fonctions intégrées permettant d’identifier et d’éliminer tous les dispositifs malsains. Il dispose également de systèmes d’ingénierie du trafic utilisés pour optimiser le flux de données sur le réseau. Cependant, la pause a eu lieu pour les raisons mentionnées, et en conséquence, certains chemins de réseau ont fini par subir une plus grande perte de paquets jusqu’à ce que les systèmes soient redémarrés manuellement dans leur intégralité.
Finalement, le réseau WAN a retrouvé ses conditions optimales de fonctionnement à 12h43 UTC, heure à laquelle le processus de récupération a pris fin. L’incident étant derrière lui, Microsoft a déclaré qu’elle avait tiré les leçons de l’expérience et qu’elle commencerait à bloquer les commandes à fort impact, en les empêchant d’être exécutées. En outre, il exigera également que l’exécution des commandes suive certaines directives pour des changements de configuration sûrs.
Bien que la panne ait touché un aussi grand nombre de services et ait duré aussi longtemps, les utilisateurs du monde entier ont été soulagés d’apprendre qu’il ne s’agissait que d’une erreur système et non d’un incident de sécurité.
