I maj 2024 kunne medlemmerne af en af Australiens store pensionskasser i over en uge ikke komme ind på deres konti. Årsagen var hverken et angreb eller en fejl hos kunden. Udbyderen havde selv slettet det miljø, kundens systemer kørte i.
Sagen kort
UniSuper havde ifølge den fælles erklæring med Google Cloud over 647.000 medlemmer pr. 31. marts 2024. I dag oplyser UniSuper på sin egen side mere end 688.000 medlemmer og omkring 175 mia. australske dollar under forvaltning pr. 30. juni 2026.
Systemerne kørte blandt andet i Google Cloud VMware Engine (GCVE), en tjeneste hvor kunden lejer et privat VMware-miljø i Googles datacentre. Det miljø forsvandt. Gendannelsen omfattede flere hundrede virtuelle maskiner, databaser og applikationer, skrev de to direktører.
Hvad skete der, dato for dato
- Begyndelsen af 2023 · Googles egne medarbejdere oprettede en af UniSupers private GCVE-clouds med et internt værktøj, fordi kunden havde særlige krav til placering af kapacitet. Det fremgår af Googles redegørelse.
- 4. kvartal 2023 · Google udfasede værktøjet og automatiserede processen.
- Begyndelsen af maj 2024 · Et år efter oprettelsen slettede systemet miljøet. Kunden fik ingen varsel. Medlemmerne mistede adgangen til deres konti.
- 7. maj 2024 · UniSuper meddelte, at tjenesterne gradvist ville komme tilbage fra 9. maj, med saldi som pr. 29. april 2024, skrev iTnews og iTWire.
- 8. maj 2024 · UniSupers administrerende direktør Peter Chun og Google Clouds direktør Thomas Kurian udsendte en fælles erklæring. Google tog ansvaret og kaldte hændelsen enestående blandt selskabets kunder.
- 9. maj 2024 · Medlemmerne kunne igen logge ind. Platformen havde da været nede i omkring en uge, ifølge The Register.
- 24. maj 2024 · Google offentliggjorde en teknisk redegørelse, efter at kundens systemer var helt gendannet og den interne gennemgang afsluttet.
Hvem besluttede
Ingen besluttede at slette miljøet. Ifølge Google blev et inputfelt efterladt tomt, da medarbejderne oprettede kundens private cloud. Systemet udfyldte derefter feltet med en standardværdi på et års løbetid, som ingen kendte til. Da året var gået, blev miljøet slettet automatisk.
Google forklarer, hvorfor kunden ikke blev advaret. En sletning, kunden selv beder om, udløser en meddelelse. Denne sletning skyldtes en indstilling, Googles egne folk havde lavet, og derfor gik der ingen meddelelse ud.
Hvilken mekanisme
Kunden havde spredt miljøet over to geografiske områder for at kunne tåle nedbrud og tab. Det hjalp ikke. Det slettede abonnement dækkede begge områder, så sletningen ramte begge på én gang, står der i den fælles erklæring.
Mekanismen er driftslaget i → de tre lag. Data lå, hvor kunden ville have dem, og der var intet juridisk indgreb. Alligevel kunne én fejl i udbyderens interne processer fjerne det hele. Redundans inden for samme abonnement og samme udbyder deler det samme svage punkt, hvilket er emnet i → backup hos samme udbyder.
Hvad reddede data
De to kilder lægger vægten forskelligt. Den fælles erklæring fra 8. maj fremhæver, at UniSuper havde backup hos en anden tjenesteudbyder. Den begrænsede tabet og gjorde gendannelsen lettere.
Googles redegørelse fra 24. maj tilføjer et led. Kundens backup i Google Cloud Storage i samme region blev ikke slettet. Ifølge Google var netop den, sammen med backupsoftware fra en tredjepart, afgørende for den hurtige gendannelse. Google oplyser også, at kundens øvrige private clouds, Google-konto og projekter ikke blev berørt.
Begge kilder peger altså på kopier uden for det slettede miljø. De er uenige om vægtningen mellem kopien hos Google og kopien uden for Google.
Hvad UniSuper kunne have vidst på forhånd
Den konkrete fejl kunne kunden ikke se. Løbetiden var sat internt hos Google, og ifølge Google var værdien ukendt, også for Googles egne folk. Ingen kontrakt eller konsol viste en udløbsdato.
Det, kunden kunne vide, var mere generelt. To regioner hos samme udbyder deler konto, abonnement og udbyderens interne værktøjer. En plan, der regner med, at én udbyder kan forsvinde helt, skal derfor have en kopi og en gendannelsesvej et andet sted. UniSuper havde netop en kopi hos en anden udbyder, og den blev brugt i gendannelsen.
Hvad sagen ikke viser
Sagen viser ikke, at cloud generelt er usikker, eller at Google Cloud er mere udsat end andre udbydere. Google skriver, at der ikke har været en tilsvarende hændelse før, og kalder den ikke systemisk. Den påstand kan ikke efterprøves udefra.
Sagen viser heller ikke, at al backup hos udbyderen var tabt. Ifølge Google overlevede kopien i Cloud Storage. Den viser ikke, hvad nedbruddet kostede UniSuper eller medlemmerne. De offentlige kilder oplyser intet beløb. Den viser heller ikke en juridisk eller politisk udløser som i → Amsterdam Trade Bank. Her var udløseren en driftsfejl, og det er netop pointen.
Hvad Google ændrede
Google oplyser tre tiltag. Det interne værktøj er taget ud af brug, og kunden styrer nu selv oprettelsen i brugerfladen. Google har gennemgået alle private GCVE-clouds manuelt for at finde andre i samme risiko. Og systemets adfærd, der markerede den slags miljøer til sletning, er rettet.
Google nævner også sine generelle sikringer mod sletning, nemlig blød sletning, forudgående varsel og en menneskelig kontrol, hvor det er relevant. I denne sag gik der alligevel intet varsel ud.
Læren for en exit-plan
En exit-plan handler også om den exit, I ikke selv vælger. Hvis udbyderen fjerner jeres miljø fra den ene dag til den anden, er det den samme opgave som et planlagt skifte, bare uden forberedelsestid. Brug sagen til fire handlinger.
- Hold mindst én kopi uden for udbyderen · Placer den hos en anden udbyder med egen konto og egne adgangsnøgler. Se → koncentrationsrisiko.
- Kortlæg, hvad der deler skæbne · Notér for hvert system, hvilke kopier der hænger på samme konto, samme abonnement og samme leverandør, som i → trin 1 og → trin 4.
- Afprøv gendannelsen et andet sted · UniSuper skulle genopbygge netværk, sikkerhedsopsætning og applikationer, ud over at hente data. Øv det, som → trin 9 beskriver.
- Spørg ind til sletning i kontrakten · Afklar varsel, blød sletning og udlevering ved ophør, jf. → trin 8.
Ved mange systemer hos få udbydere kan det betale sig at få afhængighederne vurderet udefra. Nielco IT’s jurisdiktions- og afhængighedsvurdering beskriver pr. system, hvem der kan lukke, og hvad en exit koster.
Kilder
- UniSuper og Google Cloud: A joint statement from UniSuper CEO Peter Chun, and Google Cloud CEO, Thomas Kurian, 8. maj 2024 (med note om Googles supplerende oplysninger). https://www.unisuper.com.au/about-us/media-centre/2024/a-joint-statement-from-unisuper-and-google-cloud
- Google Cloud Customer Support: Sharing details on a recent incident impacting one of our customers, 24. maj 2024. https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident
- UniSuper: Who we are, medlemstal og formue pr. 30. juni 2026, set 30. oktober 2026. https://www.unisuper.com.au/about-us/who-we-are
- iTnews: UniSuper private cloud, secondary systems taken out by “rare” Google Cloud “issues”, 7. maj 2024. https://www.itnews.com.au/news/unisuper-private-cloud-secondary-systems-taken-out-by-rare-google-cloud-issues-607744
- iTWire: UniSuper says Google Cloud issues being sorted, services to return from 9 May, 7. maj 2024. https://itwire.com/business-it-news/cloud/unisuper-says-google-cloud-issues-being-sorted,-services-to-return-from-9-may
- The Register: UniSuper Google Cloud outage caused by misconfiguration, 9. maj 2024. https://www.theregister.com/2024/05/09/unisuper_google_cloud_outage_caused
