Maakt Google Cloud een back-up van je data? Gedeelde verantwoordelijkheid uitgelegd

Wat is het model van gedeelde verantwoordelijkheid van Google Cloud?

Het is de verdeling tussen wat Google beveiligt en wat je zelf beveiligt. Google is verantwoordelijk voor het onderliggende netwerk en de infrastructuur. Jij bent verantwoordelijk voor alles wat je erop zet en voor hoe je de toegang daartoe instelt.

Denk aan een team dat zijn ERP en Cloud SQL-databases naar Google Cloud heeft verhuisd. Dan voert een engineer een opschoonscript uit op het verkeerde project. De infrastructuur van Google werkt perfect en de data is toch weg. Over dat gat gaat dit artikel. Daarom zien we cloudworkloads als onderdeel van je Backup as a Service-strategie en niet als iets wat de aanbieder regelt.

Op de pagina in het Architecture Framework over shared responsibility en shared fate is Google er duidelijk over: de aanbieder "blijft altijd verantwoordelijk voor het onderliggende netwerk en de infrastructuur", terwijl klanten "altijd verantwoordelijk blijven voor hun toegangsbeleid en data". De laag "shared fate" van Google voegt beveiligde blauwdrukken en standaardinstellingen toe, maar brengt het eigendom van je data niet terug naar Google.

• Google: datacenters, hardware, netwerk en de beschikbaarheid van beheerde diensten.
• Jij: je data, IAM-rollen (rollen voor identiteits- en toegangsbeheer), projectinstellingen, bewaartermijnen en je vermogen om terug te zetten.

Wat dekt de ingebouwde bescherming van Google Cloud eigenlijk?

Google biedt verschillende nuttige vangnetten, maar elk beschermt tegen één specifieke storing en elk heeft grenzen. Geen ervan is een onafhankelijke kopie buiten het bereik van Google.

Volgens de documentatie van Google over soft delete in Cloud Storage staat soft delete standaard aan met een bewaartermijn van 7 dagen. Als een project wordt verwijderd, worden buckets alleen bewaard voor de duur van soft delete of het herstelvenster van het project, afhankelijk van wat korter is. Buckets zonder soft delete "kunnen direct worden verwijderd wanneer een project wordt verwijderd". De documentatie van Resource Manager bevestigt dat soft-deleted projecten na 30 dagen volledig worden verwijderd.

Die termijnen passen bij een fout die je in dezelfde week merkt, niet bij een fout die pas na een maandafsluiting of een langdurige inbraak opvalt.

Wat kan er nog misgaan met data in Google Cloud?

De meeste dataverlies in de cloud komt voort uit wat er bovenop de infrastructuur gebeurt: mensen, inloggegevens, configuratie en soms de eigen processen van de aanbieder.

1. Menselijke fouten. Een verwijderde bucket of een Terraform-run op de verkeerde omgeving, door replicatie naar elke zone gekopieerd.
2. Gecompromitteerde inloggegevens. Een aanvaller met een Owner-rol of een sleutel van een service account met veel rechten kan snapshots verwijderen, bewaartermijnen verkorten en projecten verwijderen via legitieme API's. Het Verizon 2025 Data Breach Investigations Report vond ransomware bij 44% van de geanalyseerde datalekken, en aanvallers gaan routinematig eerst achter de herstelopties aan.
3. Verkeerde configuratie. Te brede IAM-bindings of een lifecycle-regel die objecten te vroeg verwijdert. Geen enkele toezegging over beschikbaarheid dekt dit.
4. Fout bij de aanbieder. Zeldzaam, maar echt. In 2024 legde Google Cloud uit dat een lege parameter in een intern hulpmiddel ervoor zorgde dat de private cloud van één klant in Google Cloud VMware Engine na een standaardtermijn van een jaar werd verwijderd.

Die laatste klant was het Australische pensioenfonds UniSuper. Het incident en de lessen daaruit behandelen we uitgebreid in wat de verwijdering bij UniSuper leert over back-ups van een derde partij.

Is Google Cloud Backup and DR op zichzelf genoeg?

Voor dagelijkse herstelacties is het een solide hulpmiddel, en dat moet je gebruiken. Als je enige kopie maakt het je voor productie én herstel afhankelijk van één aanbieder.

Het overzicht van Backup and DR van Google beschrijft een beheerde dienst voor Compute Engine, Persistent Disk, Filestore, VM's in VMware Engine, Cloud SQL, AlloyDB en zelfbeheerde databases. De back-upvaults zijn "door Google beheerde, geïsoleerde opslagresources" met write-once-read-many-onveranderbaarheid en een optionele, afgedwongen minimale bewaartermijn tot 99 jaar. Dat is een echte verbetering ten opzichte van gewone snapshots.

Wat niet verandert, is wie het beheert. Productie en back-up delen één aanbieder, één contract en één rechtsgebied, dus een storing op dat niveau raakt beide. Bij UniSuper zei de gezamenlijke verklaring van UniSuper en Google Cloud dat back-ups "bij een extra serviceprovider" het dataverlies beperkten en het vermogen om te herstellen aanzienlijk verbeterden.

Hetzelfde geldt elders: lees waarom data in AWS nog geen back-up is en waarom multicloud geen back-upstrategie is.

Maakt een EU-regio je Google Cloud-data soeverein?

Nee. Een EU-regio geeft je data residency: de servers staan in Europa. Soevereiniteit gaat over wie wettelijk kan worden gedwongen de data af te geven, en Google is een Amerikaans bedrijf.

De Amerikaanse CLOUD Act van 2018 voegde 18 U.S.C. § 2713 toe. Die verplicht Amerikaanse aanbieders om data openbaar te maken die zij in hun "bezit, bewaring of controle" hebben, "ongeacht of die communicatie, dat record of die andere informatie zich binnen of buiten de Verenigde Staten bevindt". Aan EU-kant bepaalt AVG-artikel 48 dat een bevel van een rechter uit een derde land om persoonsgegevens door te geven alleen wordt erkend of uitvoerbaar is als het is gebaseerd op een internationale overeenkomst, zoals een verdrag over wederzijdse rechtshulp. Een back-up bij dezelfde Amerikaanse aanbieder loopt hetzelfde risico als productie.

Voor organisaties onder NIS2 vraagt NIS2-artikel 21(2)(c) (Richtlijn (EU) 2022/2555) om bedrijfscontinuïteit, waaronder back-upbeheer en disaster recovery (je systemen weer draaiend krijgen na een calamiteit). NIS2-artikel 21(2)(d) voegt ketenbeveiliging toe. Een kopie bij een EU-beheerder buiten je primaire aanbieder dekt beide. Lees meer in wat datasoevereiniteit in de praktijk betekent.

Hoe bouw je een onafhankelijke back-up voor Google Cloud?

Houd de ingebouwde tools van Google voor snelle operationele herstelacties en voeg één kopie toe die buiten Google Cloud staat, niet te wijzigen is en getest wordt. Met vijf stappen kom je er.

1. Breng in kaart wat telt. Maak een lijst van de projecten, VM's, databases en buckets waar je diensten van afhangen en spreek af hoeveel dataverlies en downtime elk kan verdragen. RPO is hoeveel werk je kunt missen. RTO is hoelang je stil mag liggen. In onze gids over RTO en RPO lees je hoe je beide bepaalt.
2. Versterk de ingebouwde laag. Verleng de bewaartermijn van soft delete, gebruik vaults met afgedwongen bewaartermijn en beperk Owner-rollen.
3. Voeg een kopie buiten het platform toe. Volg de 3-2-1-1-0-regel: drie kopieën, twee media, één off-site, één onveranderbaar of air-gapped (een kopie zonder verbinding met je netwerk), nul fouten bij verificatie.
4. Scheid de inloggegevens. Het account dat productie kan verwijderen, mag de back-up niet kunnen verwijderen.
5. Test het terugzetten. Zet volgens een schema een VM en een database terug naar een geïsoleerde omgeving en bewaar de resultaten als bewijs.

Met onze back-up van Google Cloud staat de kopie buiten het platform alleen in onze eigen Tier III-datacenters in Nederland en Duitsland, onder EU-recht en onafhankelijk van Amerikaanse hyperscalers (grote cloudaanbieders). De back-ups zijn onveranderbaar met Object Lock plus een air-gapped kopie, we controleren elke back-uptaak automatisch, back-ups worden gescand op malware en beheeracties vragen MFA (meervoudige authenticatie). We zijn ISO 27001- en NEN 7510-gecertificeerd.

Wat je nu kunt doen

Google Cloud gebruiken is een verstandige keuze. Ervan uitgaan dat het een back-up van je data maakt, is dat niet. Je data, toegangsbeheer en vermogen om terug te zetten blijven je eigen verantwoordelijkheid. Dat doe je het veiligst met een geteste, onveranderbare kopie buiten het platform van Google, onder EU-recht.

Controleer deze week de bewaartermijn van soft delete, wie Owner-rechten heeft en wanneer je voor het laatst hebt teruggezet vanuit een kopie die Google niet beheert. Bekijk daarna hoe een onafhankelijke kopie past in je bredere aanpak met Backup as a Service.

Wil je zien hoe het werkt met je eigen omgeving? Plan een gratis demo van 15 minuten. We laten je een herstel in Google Cloud zien.

Dit artikel is algemene informatie, geen juridisch advies.