Alisina NawabiMicrosoft wijt de grote storing die donderdag Teams, SharePoint en delen van Azure urenlang platlegde aan een bug in zijn eigen geautomatiseerde onderhoudssysteem, dat te veel netwerkapparaten voor onderhoud aanmerkte en zo IP-routes verwijderde. Het ging om een interne fout in het netwerkonderhoud, niet om een aanval van buiten.
Voor elk Nederlands bedrijf dat zijn mail, bestanden en samenwerking op Microsoft 365 of Azure draait, verschuift daarmee de kernvraag. Niet 'zijn we gehackt', maar: hoe kwetsbaar maakt de afhankelijkheid van één cloudleverancier je voor diens eigen fouten? De storing concentreerde zich in Microsofts West US-regio, dus niet iedereen hier merkte er iets van. Maar wie clouddiensten daar draait of leunt op de getroffen 365-onderdelen, zat zonder toegang, en de bredere les raakt iedereen op de Microsoft-stack.
Wat er precies misging
Microsoft voert doorlopend routineonderhoud uit aan zijn netwerk. Een systeem zet die werkorders om in instructies en controleert vooraf of er genoeg redundante paden gezond blijven. Een bug in dat conversiesysteem merkte extra netwerkapparaten aan als onderdeel van het onderhoud, waardoor bij te veel apparaten de IP-routes werden weggehaald.
Daardoor vielen de routes tussen het West US-datacenter en Microsofts wide-area netwerk weg, en kon verkeer de regio niet meer in of uit. Verkeer binnen de regio bleef wel overeind. De ingebouwde veiligheidscheck, die borgt dat minstens één van twee redundante paden gezond blijft, werd door de te ruime scope ondermijnd.
Op Downdetector piekte het aantal meldingen naar 2.403, tegen een normale achtergrond van 29. The Register kwam op 27 getroffen Azure-diensten, van Application Gateway en Cosmos DB tot Kubernetes Service en ExpressRoute. Ook Microsoft 365-diensten als Teams, SharePoint, OneDrive en Copilot hadden last.
Bijna vijf uur tot herstel
De storing begon rond 14:44 UTC, toen het onderhoud startte. Microsoft koppelde het probleem tussen 16:00 en 17:45 UTC aan de recente onderhoudsactie, draaide de wijziging vanaf 17:45 UTC terug en herstelde het wide-area netwerk om 18:26 UTC. Om 19:41 UTC meldde het bedrijf volledig herstel, bijna vijf uur na het begin.
De echte les zit in de afhankelijkheid
Dit incident laat niet zien dat Microsoft onveilig is, maar dat een storing net zo goed van binnenuit komt. Geen aanvaller, geen losgeld, gewoon een fout in een geautomatiseerd proces bij je leverancier, en je kerntools liggen plat.
Diezelfde afhankelijkheid deed het kabinet de uitrol van Microsoft 365 bij de Belastingdienst en Douane pauzeren, na een advies dat waarschuwde voor concentratierisico. Op dat moment hadden al zo'n 5.000 medewerkers een M365-werkplek. Waar de overheid dat risico expliciet weegt, laat een MKB'er het meestal impliciet lopen.
Een uitval van vijf uur overleeft bijna elk bedrijf. Het punt is dat je die uren niet zelf in de hand hebt: het herstel hangt volledig af van hoe snel je leverancier zijn eigen fout terugdraait. Dat maakt de vraag waar je je kritieke diensten neerzet, en of je een terugvaloptie hebt als één regio of één leverancier wegvalt, geen theoretische oefening maar een ontwerpkeuze die je nu maakt.
Veelgestelde vragen
Niet vast aan één cloud
Ik help je van idee tot livegang je kritieke diensten zo neerzetten dat je niet volledig aan één leverancier of regio vastzit, met slimme koppelingen en terugvalopties, en self-hosted waar dat kan.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
