Wat gebeurde er toen Google Cloud de private cloud van UniSuper verwijderde?

Wat gebeurde er bij het UniSuper-incident met Google Cloud?

Google Cloud heeft per ongeluk het private cloud-abonnement verwijderd waarop de kernsystemen van UniSuper draaiden. Het was geen cyberaanval. Het was een configuratiefout aan de kant van de leverancier, en die haalde de hele omgeving in één keer weg.

UniSuper is een van de grootste pensioenfondsen van Australië. Volgens de gezamenlijke verklaring van UniSuper en Google Cloud van 8 mei 2024 belegt het fonds "meer dan $135 miljard namens meer dan 647.000 leden". In de verklaring, uitgegeven samen met Thomas Kurian, CEO van Google Cloud, staat dat "een onbedoelde misconfiguratie tijdens het inrichten van de Private Cloud-diensten van UniSuper uiteindelijk heeft geleid tot de verwijdering van het Private Cloud-abonnement van UniSuper". De verklaring noemt het een geïsoleerd, "eenmalig voorval" dat bij geen enkele andere Google Cloud-klant ooit was voorgekomen.

Het incident is ook buiten Australië van belang. Het is het duidelijkste openbare voorbeeld van waarom we cloudworkloads zien als onderdeel van een strategie voor Backup as a Service, en niet aannemen dat de veerkracht van de leverancier je data dekt. Draai je op een hyperscaler (een grote cloudaanbieder), dan bestaat dezelfde faalwijze, hoe zeldzaam ook.

Waarom verwijderde Google Cloud de private cloud van UniSuper?

Omdat één invoerveld in een interne tool van Google leeg was gelaten. Het systeem gaf het abonnement daarna een vaste standaardlooptijd en verwijderde het toen die afliep.

In haar uitleg achteraf, Details of Google Cloud GCVE incident, schreef Google dat "één invoerparameter leeg was gelaten bij het gebruik van een interne tool om de Private Cloud van de klant in te richten". Door die lege parameter kende het systeem "een toen onbekende, vaste standaardlooptijd van 1 jaar" toe. Toen het jaar voorbij was, werd de private cloud verwijderd. Er is geen melding naar de klant gestuurd, omdat de verwijdering werd veroorzaakt door Google-medewerkers die de tool gebruikten, en niet door een verzoek van de klant.

Google zegt dat het de interne tool inmiddels heeft uitgefaseerd, elke GCVE-private cloud op hetzelfde risico heeft gecontroleerd en het verwijdergedrag heeft gecorrigeerd. Dat is een verstandige reactie. Het bevestigt ook dat het risico voor de klant onzichtbaar was tot de dag dat het gebeurde.

Waarom beschermde geografische redundantie UniSuper niet?

Omdat redundantie één omgeving naar meer plekken kopieert. Wordt de omgeving zelf verwijderd op abonnementsniveau, dan verdwijnt elke replica mee.

De gezamenlijke verklaring is duidelijk: UniSuper "had duplicatie in twee geografische locaties als bescherming tegen storingen en verlies", maar de verwijdering van het abonnement "leidde tot verwijdering in beide locaties". In een latere post beschrijft Google de impact als "één klant in één cloudregio". De twee verhalen schetsen de omvang verschillend, maar zijn het eens over de kern: de gerepliceerde omgeving was weg.

Dat is het kernverschil tussen redundantie en back-up. Redundantie beschermt tegen uitval van hardware of van een locatie. Het beschermt niet tegen een verwijderd abonnement, een gehackt beheerdersaccount of een verkeerd commando, omdat de replica onder dezelfde control plane valt, de laag waarmee de omgeving wordt beheerd. De eigen richtlijnen van Google over gedeelde verantwoordelijkheid leggen data en toegangsbeleid daarom bij de klant. Dezelfde valkuil behandelen we in waarom multicloud geen back-upstrategie is.

Welke rol speelden back-ups van derden bij het herstel van UniSuper?

Een beslissende rol. UniSuper en Google noemen allebei back-ups die de verwijdering niet raakte, ook kopieën buiten de omgeving van Google, als reden dat het herstel mogelijk was.

In de gezamenlijke verklaring staat: "UniSuper had back-ups bij een extra dienstverlener. Die back-ups hebben het dataverlies tot een minimum beperkt en het voor UniSuper en Google Cloud aanzienlijk makkelijker gemaakt om het herstel af te ronden." Google voegt in zijn post toe dat back-ups in Google Cloud Storage in dezelfde regio niet door de verwijdering werden geraakt en dat ze, "samen met back-upsoftware van derden, een grote rol speelden bij het snelle herstel".

Toch ging het herstel niet snel. De analyse van de storing door InformationWeek noemt 2 mei 2024 als start, met leden die rond 9 mei weer toegang kregen. DatacenterDynamics meldde dat leden op 13 mei weer konden inloggen en hun saldo konden zien. Teams werkten dag en nacht aan het opnieuw opbouwen van netwerk, beveiligingsconfiguratie, honderden virtuele machines en databases. De data hebben was nodig. Het opnieuw opbouwen van de omgeving eromheen kostte de tijd.

Welke lessen zijn er voor Europese organisaties?

Bewaar een kopie die je leverancier niet kan verwijderen, en zorg dat je die snel weer kunt omzetten in een werkende omgeving. Vijf lessen springen eruit.

1. Een fout van de leverancier is een reëel risico, hoe zeldzaam ook. Gedeelde verantwoordelijkheid betekent niet dat de leverancier nooit fouten maakt. Het betekent dat je herstel er niet van mag afhangen dat hij ze niet maakt.
2. Het abonnement is één enkel storingsdomein. Regio's, zones en replica's binnen één account of contract kunnen allemaal tegelijk verdwijnen.
3. Back-ups buiten het storingsdomein bepalen de uitkomst. Het liefst bij een andere beheerder, met andere inloggegevens en onveranderbare opslag.
4. Data is niet hetzelfde als een werkende dienst. Een hele omgeving terugzetten kost dagen, tenzij standby-infrastructuur en draaiboeken klaarstaan. Lees onze gids over de hersteltijdlijn voor wat de doorlooptijd bepaalt.
5. Je krijgt niet altijd een waarschuwing. UniSuper kreeg vóór de verwijdering geen melding. Houd je eigen omgeving en back-ups in de gaten.

Valt je organisatie onder NIS2, dan sluiten deze lessen direct aan op NIS2-artikel 21(2)(c), over bedrijfscontinuïteit, zoals back-upbeheer en disaster recovery (je systemen weer draaiend krijgen na een calamiteit), en op NIS2-artikel 21(2)(d), over ketenbeveiliging. In ons artikel over NIS2-ketenbeveiliging lees je hoe je cloudaanbieders als leveranciers beoordeelt.

Hoe pas je de lessen van UniSuper toe op je eigen cloud?

Behandel je cloudabonnement als iets dat kan verdwijnen en plan van daaruit terug. Vijf stappen maken van de les de praktijk.

1. Breng je afhankelijkheden van leveranciers in kaart. Maak een lijst van de systemen die stilvallen als één cloudaccount of abonnement verdwijnt.
2. Voeg een externe, onveranderbare kopie toe. Volg de 3-2-1-1-0-regel, met minstens één kopie buiten je primaire leverancier.
3. Dek ook SaaS af. Microsoft 365 en Google Workspace kennen dezelfde afhankelijkheid. Lees wat er gebeurt als je SaaS-leverancier uitvalt.
4. Bepaal waar je naartoe terugzet. Is de primaire omgeving weg, dan heb je een andere plek nodig om te draaien.
5. Test een scenario van totaal verlies. Geen los bestand, maar een hele applicatiestack, minstens één keer per jaar.

Onze Google Cloud-back-up bewaart die externe kopie in onze eigen Tier III-datacenters in Nederland en Duitsland, onafhankelijk van de grote Amerikaanse cloudaanbieders. De kopie is onveranderbaar met Object Lock, en je krijgt er een air-gapped kopie bij, een kopie zonder verbinding met je netwerk. Voeg je disaster recovery toe, dan heb je standby-infrastructuur, een directe start van VM's in een geïsoleerde herstelomgeving op een apart, schoon netwerk, en worden kritieke workloads hersteld binnen een SLA van 4 uur. Een gecertificeerde engineer valideert de eerste testfailover, meestal binnen 10 dagen. Elk kwartaal draaien geautomatiseerde DR-tests, met bewijs voor auditors.

Wat je nu kunt doen

UniSuper deed veel goed: het had redundantie en vooral back-ups buiten de omgeving die werd verwijderd. Daarom kon het herstellen. Het incident laat zien dat de veerkracht van je leverancier zijn platform beschermt en niet jouw account. Alleen een onafhankelijke kopie en een geoefend herstel dekken de zeldzame dag waarop de leverancier zelf de oorzaak is.

Stel deze week één vraag: als je belangrijkste cloudabonnement vanavond verdwijnt, waarvandaan zet je dan terug, en waarnaartoe? Is het antwoord onduidelijk, begin dan met de basis van Backup as a Service en onze gids over gedeelde verantwoordelijkheid bij Google Cloud.

Plan een gratis demo van 15 minuten en zie een herstel in een geïsoleerde omgeving vanaf een kopie buiten het platform.

Dit artikel is algemene informatie, geen juridisch advies.