UniSupers week offline: het pleidooi voor back-ups die je cloud niet kan wissen
Google Cloud verwijderde een complete klantomgeving — beide redundante regio's incluis. Eén externe back-up maakte herstel mogelijk.
In mei 2024 ging het Australische pensioenfonds UniSuper — beheerder van zo'n $125 miljard voor ruim 600.000 deelnemers — op zwart. Niet door ransomware of een cyberaanval: een misconfiguratie bij het inrichten zorgde ervoor dat Google Cloud UniSupers volledige private-cloudabonnement verwijderde. De verwijdering plantte zich voort naar beide geografische regio's waar het fonds zijn data redundant had gedupliceerd. De redundantie deed precies niets, omdat beide kopieën leefden binnen het account dat ophield te bestaan.
Het herstel kostte meer dan een week onafgebroken werk, met honderden virtuele machines en databases die herbouwd moesten worden. De beslissende factor, door UniSuper zelf erkend: back-ups bij een andere provider, buiten Googles ecosysteem. Zonder die externe kopie had een van 's werelds grotere pensioenfondsen de data van zijn deelnemers definitief kunnen verliezen aan een administratieve fout.
De misvatting die dit incident begroef: "de redundantie van onze cloudprovider beschermt ons." Redundantie beschermt tegen falende hardware van de provider. Het beschermt niet tegen falende processen van de provider — en het beschermt nooit data die binnen het account leeft dat wordt verwijderd.
Wat gebeurde er precies bij UniSuper?
Tijdens het inrichten van UniSupers Google Cloud VMware Engine private cloud bleef door een configuratiefout een parameter staan waardoor het abonnement als tijdelijk werd behandeld. Toen de termijn verstreek, verwijderden Googles systemen de private cloud — automatisch, zonder melding aan de klant, en over beide regio's die UniSuper voor redundantie gebruikte. Google en UniSuper omschreven het gezamenlijk als een uitzonderlijke, geïsoleerde gebeurtenis, veroorzaakt door een intern tooling-hiaat en niet door enige klantactie.
De tijdlijn die ertoe doet
De verwijdering werd begin mei 2024 effectief; deelnemersdiensten gingen onmiddellijk offline. Het herstel duurde ruim een week en slaagde omdat UniSuper kon putten uit back-ups bij een aparte, externe partij. De provider-interne waarborgen — geo-redundantie, accountbeschermingen — zaten allemaal stroomafwaarts van het falende account en verdwenen ermee.
Kan dit niet iedereen met een cloudomgeving overkomen?
Ja — dat is de ongemakkelijke kern van de les. Elke hyperscaler draait geautomatiseerde lifecycle-systemen die onder zeldzame faalcondities destructief kunnen handelen op accountniveau. En vernietiging op accountniveau heeft gangbaardere oorzaken dan providerfouten: gecompromitteerde beheerderscredentials (een aanvaller die je omgeving wist), kwaadwillende insiders, factureringsproblemen die uitmonden in opschorting en opruiming, of je eigen ontspoorde automatisering.
Het structurele punt is provideronafhankelijk. Alles binnen het account — snapshots, native back-ups, replica's, versioning — deelt het lot van het account. Het antwoord van de branche is het 3-2-1-principe, en specifiek zijn meest verwaarloosde poot: één kopie off-site, dat wil zeggen volledig buiten het controlevlak van de primaire provider. UniSuper is simpelweg de grootste publieke demonstratie van waarom die poot bestaat.
De EU-lezing: soevereiniteit verhoogt de inzet
Voor Europese organisaties kruist het incident een tweede blootstelling. Data bij Amerikaanse hyperscalers blijft onderworpen aan Amerikaanse jurisdictie — de CLOUD Act bereikt de provider ongeacht de datacenterlocatie — wat schuurt met AVG-verwachtingen over controle op persoonsgegevens. Een onafhankelijke back-up bij een Europese provider lost beide problemen op in één architectuur: de kopie overleeft falen op accountniveau, en hij valt onder EER-recht.
De regelgevingskaders wijzen dezelfde kant op. De NIS2-richtlijn verplicht entiteiten binnen de reikwijdte tot ketenrisicobeheer — en je cloudprovider is je meest geconcentreerde leveranciersafhankelijkheid — terwijl ENISA's technische implementatierichtsnoeren de verwachtingen rond back-up en herstel uitwerken, inclusief onafhankelijkheid en testen. Een auditor die het UniSuper-postmortem heeft gelezen, stelt je één vraag: welke van jouw herstelroutes overleeft de verwijdering van je primaire cloudaccount?
De les toepassen: een stappenplan in vijf stappen
Breng in kaart wat binnen elk provideraccount leeft. Benoem elke workload, snapshot en "back-up" waarvan het bestaan afhangt van één cloudabonnement — die lijst is je UniSuper-blootstelling.
Regel één werkelijk externe kopie. Back-up kritieke workloads en SaaS-data naar een onafhankelijke provider op gescheiden infrastructuur — een EU-gehoste backup-as-a-service met eigen credentialruimte, onbereikbaar vanuit de beheerconsole van je primaire cloud.
Maak de externe kopie immutable. Providerfouten zijn één scenario; een gecompromitteerde beheerder die back-ups wist is het gangbaardere. WORM-opslag dekt beide.
Dek ook de SaaS-laag. Dezelfde accountlogica geldt voor Microsoft 365 en Google Workspace: native retentie leeft binnen de tenant die hij zou moeten beschermen.
Test het totaalverliesscenario. Oefen minstens jaarlijks herstel in de aanname dat het primaire provideraccount weg is — meet hoelang herbouwen vanaf alleen de externe kopie duurt, met een geoefende disaster recovery-procedure, en archiveer de resultaten als compliancebewijs.
Redundantie versus back-up versus onafhankelijkheid
| Eigenschap | Geo-redundantie | Provider-native back-up | Onafhankelijke externe back-up |
|---|---|---|---|
| Overleeft hardwarefalen | ✔ | ✔ | ✔ |
| Overleeft onbedoelde verwijdering | ✘ (repliceert haar) | Meestal | ✔ |
| Overleeft account-/abonnementsverlies | ✘ | ✘ | ✔ |
| Overleeft gecompromitteerde beheerder | ✘ | ✘ | ✔ (mits immutable) |
| EU-jurisdictie mogelijk | Afhankelijk van provider | Afhankelijk van provider | ✔ per ontwerp |
De eerste kolom is wat UniSuper had; de laatste kolom is wat het fonds redde. De meeste organisaties stoppen architecturaal bij kolom twee en noemen dat een back-upstrategie — wat klopt, precies tot het falen één niveau hoger plaatsvindt dan waar de back-up leeft.
Conclusie
UniSuper deed het meeste goed — redundante regio's, een grote provider, professioneel beheer — en stond toch een week stil, omdat elke interne waarborg binnen het verwijderde account zat. De ene beslissing die catastrofe in herstel veranderde, was lang vóór het incident genomen: één kopie bij iemand anders bewaren. Dat is de hele les, en hij geldt evenzeer voor IaaS-workloads, Microsoft 365-tenants en Google Workspace-domeinen. Wil je weten welke delen van jouw omgeving het verlies van je primaire cloudaccount zouden overleven — en welke niet? We brengen het graag met je in kaart.
Veelgestelde Vragen
Wat gebeurde er in het UniSuper Google Cloud-incident?
In mei 2024 zorgde een configuratiefout bij het inrichten ervoor dat Google Cloud UniSupers volledige private-cloudabonnement automatisch verwijderde, inclusief data die over twee geografische regio's was gedupliceerd. Het Australische pensioenfonds, met circa $125 miljard onder beheer, was ruim een week offline. Herstel was mogelijk doordat UniSuper back-ups aanhield bij een aparte externe partij buiten Googles ecosysteem; de provider-interne redundantie bood geen bescherming omdat die samen met het account werd verwijderd.
Waarom beschermt cloudredundantie niet tegen dataverlies?
Redundantie repliceert je data over locaties om hardware- en datacenterstoringen te overleven — maar repliceert verwijderingen, corruptie en gebeurtenissen op accountniveau even trouw. Wordt het account of abonnement dat de data bevat verwijderd, dan verdwijnt elke replica erbinnen tegelijk. Bescherming tegen dat scenario vereist een kopie buiten het controlevlak van de provider: onafhankelijke infrastructuur, aparte credentials, idealiter immutable opslag.
Wat is de 3-2-1-back-upregel en hoe geldt die voor cloudomgevingen?
De 3-2-1-regel schrijft drie kopieën van je data voor, op twee verschillende media of platforms, met één kopie off-site. In cloudtermen betekent "off-site" buiten het ecosysteem van je primaire provider — een back-up bij een onafhankelijke partij op gescheiden infrastructuur, onbereikbaar met je primaire cloudcredentials. Provider-native snapshots en replicatie tellen mee als kopieën maar niet als onafhankelijkheid; het UniSuper-incident toonde waarom juist de onafhankelijke kopie in worstcasescenario's de doorslag geeft.