A anatomia do apagão da Microsoft: como uma falha na autenticação derrubou 18 serviços em cascata

O apagão global que atingiu o ecossistema Microsoft 365 a partir da tarde de quinta-feira, 12 de novembro, e se prolongou pela sexta-feira, dia 13, não resultou de um ciberataque, mas de uma reação em cadeia na infraestrutura central da nuvem da empresa. Tal é possível concluir pelo cruzamento dos boletins operacionais da tecnológica norte-americana com análises independentes de engenharia de fiabilidade de sistemas.

Essa consulta permite reconstituir a sequência técnica que paralisou o correio eletrónico empresarial e até pessoal de muitos utilizadores e afetou ferramentas como o Teams, o Copilot e mesmo soluções de cibersegurança como o Microsoft Defender.

Embora a tecnológica norte-americana esteja, nesta sexta-feira à tarde, ainda a concluir a estabilização do serviço e só deva publicar o relatório final pós-incidente nos próximos dias, os dados técnicos já divulgados expõem a fragilidade inerente a arquiteturas onde dezenas de serviços dependem de um mesmo plano central de identidade e encaminhamento. Algo, aliás, que é comum a muitas infraestruturas de nuvem à escala global.

O falso alarme de tráfego e o "canibalismo" dos servidores

Os primeiros sinais de falha surgiram às 16h17 UTC (mesma hora em Lisboa) de quinta-feira no Exchange Online, o serviço de email da Microsoft, registados internamente sob o código de incidente EX1550543.

Durante a primeira hora, a telemetria apontava para um pico súbito de carga nos servidores ativos. Isto levou a que as primeiras notícias dessem conta de tráfego fora do vulgar na origem do apagão. No entanto, as equipas de engenharia verificaram, pouco depois, que o volume global de pedidos dos utilizadores não tinha, afinal, aumentado: o tráfego manteve-se estável, só que uma parte significativa da 'frota' de servidores tinha, simplesmente, deixado de responder.

Na origem do estrangulamento esteve a saturação de um processo central responsável por estabelecer ligações encriptadas (negociações TLS) e validar a autenticação a montante, desencadeada após uma alteração recente de configuração na rede.

Com esse processo bloqueado, os servidores começaram a responder com lentidão às sondas automáticas de verificação de estado (os automated health checks).

Por desenho arquitetural, quando um servidor falha estes testes automáticos, o balanceador de carga retira-o de rotação para proteger os utilizadores - o sistema considera: 'alguma coisa está mal nesta máquina, tiro-a de serviço à cautela'.

Só que... Numa situação de crise sistémica, este mecanismo de autodefesa produziu um efeito perverso: cada máquina que foi expulsa da rede transferia a sua quota de tráfego para os servidores vizinhos, que por sua vez ficavam igualmente sobrecarregados, falhavam o teste seguinte e eram também retirados de serviço.

Esta perda de capacidade em cascata só foi travada às 19h57 UTC, quando os engenheiros intervieram manualmente para impedir o sistema de continuar a remover servidores.

Um contágio arquitetural que 'infetou' 18 serviços

Cerca de duas horas após o início dos problemas no correio eletrónico, a Microsoft foi obrigada a abrir um segundo incidente de âmbito alargado (MO1550821), abrangendo um total de 18 serviços da plataforma.

A análise técnica revela um padrão de acoplamento interno: todas as funcionalidades do Microsoft Teams (como calendários, estados de presença ou histórico de mensagens), do assistente de inteligência artificial Copilot e até do Microsoft Defender XDR que dependem de chamadas autenticadas ao Exchange Online ou ao plano central do Microsoft Graph falharam em simultâneo.

Desta vez, ao contrário de incidentes anteriores no setor provocados por falhas em software de segurança, o Defender e o Copilot não estiveram na origem do problema, tendo sido vítimas colaterais da interrupção no acesso aos dados e à autenticação.

Ou seja: não houve falhas nos sistemas 'anti-hackers' ou em agentes de IA criados para salvaguardar ataques. O problema decorreu de 'erros em cascata' derivados da própria arquitetura da nuvem.

"Tempestades de tentativas" travaram a recuperação

O prolongamento da degradação de serviços, que se estenderam pela noite e pela manhã desta sexta-feira, ficou a dever-se a um fenómeno conhecido na engenharia de redes como retry storm ("tempestade de tentativas"). Durante a madrugada, as primeiras tentativas de desviar tráfego e lançar máquinas virtuais de reforço geraram vagas adicionais de chamadas internas aos servidores centrais.

Além disso, sempre que os engenheiros reiniciavam servidores e os devolviam ao tráfego real, estes voltavam a colapsar em poucos minutos. Sem sessões ativas, milhões de aplicações cliente — entre computadores com Outlook e Teams, telemóveis e conectores automatizados — tentavam renegociar certificados de segurança TLS e tokens de autenticação em simultâneo. Como iniciar uma sessão encriptada exige muito mais capacidade de processamento do que manter uma ligação aberta, os servidores recém-ligados eram imediatamente derrubados pela avalanche de pedidos legítimos de reconexão.

Perguntas ainda em aberto

Para quebrar o ciclo vicioso, a Microsoft congelou todas as alterações de código, reconfigurou os critérios dos health checks para evitar falsos negativos sob carga, aplicou uma correção no componente de autenticação e encaminhamento a montante e iniciou uma reintrodução controlada e estrangulada (o throttling) da capacidade de sistemas, começando pela região Ásia-Pacífico às 07h30 UTC desta sexta-feira, avançando depois para a Europa e América do Norte. Para evitar a perda de mensagens retidas, a empresa alargou também para 48 horas o prazo limite de entrega de correio eletrónico em fila.

Até ao final da tarde de sexta-feira, os incidentes EX1550543 e MO1550821 mantinham-se abertos no painel de estado da empresa sob a classificação de "degradação de serviço", enquanto decorria o escoamento das filas de mensagens em atraso.

O relatório técnico final, que a Microsoft disponibiliza habitualmente num prazo máximo de cinco dias úteis após o encerramento oficial do incidente, terá ainda de esclarecer qual foi exatamente a alteração de configuração aplicada no segundo zero, o momento em que se desencadeou o bloqueio inicial. Será ainda preciso confirmar se houve perda definitiva de dados e determinar a duração oficial da falha para efeitos de compensação contratual (SLA) aos clientes empresariais.