# Google Cloud × UniSuper (2024): Quando uma Configuração Apagou uma Subscrição Inteira Em maio de 2024, uma configuração equivocada durante o provisionamento de um ambiente VMware privado na Google Cloud resultou na exclusão completa da subscrição da UniSuper em duas regiões. A recuperação só foi possível porque a UniSuper mantinha backups em um provedor de nuvem separado — uma decisão que salvou dados de 500 mil membros. O incidente expõe falhas sistêmicas em salvaguardas de exclusão, blast radius de automação e a falácia de assumir resiliência dentro de um único provedor. - URL: https://fernando.moretes.com/studies/google-cloud-unisuper-2024 - Markdown: https://fernando.moretes.com/studies/google-cloud-unisuper-2024/study.md?lang=pt - Type: Post-mortem - Company: Google Cloud / UniSuper - Domain: Cloud/Resiliência - Date: 2024-05-02 - Tags: postmortem, google-cloud, resiliência, backup, gcve, exclusão-acidental, multi-cloud, disaster-recovery - Reading time: 11 min --- ## Ficha do Incidente - **Organização afetada:** UniSuper — fundo de pensão australiano - **Provedor de nuvem:** Google Cloud (GCVE — Google Cloud VMware Engine) - **Data do incidente:** Início: maio de 2024 (data exata não divulgada publicamente) - **Duração da interrupção:** Aproximadamente 2 semanas para restauração completa dos serviços - **Escala de membros:** ~500.000 membros com acesso a serviços afetado - **Regiões afetadas:** Duas regiões do Google Cloud (ambas as instâncias GCVE da UniSuper) - **Causa raiz:** Configuração equivocada durante provisionamento GCVE que ativou exclusão automática da subscrição após período de trial - **Fator de recuperação:** Backups mantidos em provedor de nuvem separado (não-Google) - **Stack técnico:** GCVE (VMware Engine), Google Cloud Storage, backups em nuvem alternativa - **Declaração pública:** Declaração conjunta UniSuper + Google Cloud — inédita em transparência para o setor Um único parâmetro configurado incorretamente durante o provisionamento de uma nuvem privada VMware apagou a subscrição inteira da UniSuper no Google Cloud — em duas regiões simultaneamente. Não foi um ataque. Não foi uma falha de hardware. Foi automação executando exatamente o que foi instruída a fazer, sem nenhuma salvaguarda para questionar se deveria. O que salvou 500 mil membros de um desastre irreversível não foi a resiliência do provedor — foi um backup em outro provedor. ## O que aconteceu A UniSuper é um dos maiores fundos de pensão da Austrália, gerenciando ativos de aproximadamente 500 mil membros — predominantemente funcionários do setor de ensino superior. Como parte de sua estratégia de modernização de infraestrutura, a UniSuper migrou cargas de trabalho para o Google Cloud utilizando o **Google Cloud VMware Engine (GCVE)**, um serviço gerenciado que permite executar workloads VMware nativamente na infraestrutura do Google. A escolha do GCVE é comum em organizações que precisam manter compatibilidade com ambientes VMware legados enquanto adotam a nuvem. Durante o processo de provisionamento do ambiente GCVE — executado pelo lado do Google Cloud — um operador cometeu um erro crítico: configurou inadvertidamente a subscrição com um **período de expiração**, como se fosse um ambiente de trial ou temporário. Esse tipo de configuração, quando ativada, instrui a plataforma a destruir automaticamente todos os recursos associados à subscrição ao final do período definido. A UniSuper não foi informada dessa configuração. Não havia alerta visível. Não havia confirmação adicional exigida. Quando o prazo configurado expirou, a automação da Google Cloud executou o processo de exclusão com fidelidade total: **todas as máquinas virtuais, todos os volumes de dados, todos os snapshots, todos os backups internos** — em ambas as regiões onde a UniSuper operava. A exclusão foi completa e, dentro do ecossistema Google Cloud, irreversível. Não havia lixeira. Não havia período de retenção pós-exclusão que cobrisse o escopo total do evento. A subscrição simplesmente deixou de existir. O que impediu que isso se tornasse uma perda catastrófica e permanente de dados foi uma decisão arquitetural que, na época em que foi tomada, pode ter parecido redundante para alguns: a UniSuper mantinha cópias de seus dados críticos em **um provedor de nuvem completamente separado**, fora do ecossistema Google. Essa separação de provedor — não apenas separação de região ou de conta — foi o único mecanismo que sobreviveu ao evento. ## Linha do Tempo do Incidente 1. **Meses antes — Provisionamento GCVE** — Google Cloud provisiona o ambiente GCVE para a UniSuper. Durante esse processo, um operador do Google configura inadvertidamente a subscrição com um parâmetro de expiração automática — equivalente a um período de trial — em vez de uma subscrição de produção permanente. Esse parâmetro não é visível ou comunicado claramente à UniSuper. 2. **Período de operação normal** — A UniSuper opera normalmente sobre a infraestrutura GCVE. Cargas de trabalho críticas rodam em ambas as regiões configuradas. Backups são executados regularmente — incluindo cópias mantidas em um provedor de nuvem separado, fora do Google. Nenhum alerta ou indicação do parâmetro de expiração é observado. 3. **Maio de 2024 — Expiração automática executada** — O prazo de expiração configurado é atingido. A automação da Google Cloud inicia o processo de exclusão da subscrição. Todos os recursos associados — VMs, volumes, snapshots, backups internos — são destruídos em ambas as regiões simultaneamente. A exclusão é completa dentro do ecossistema Google Cloud. 4. **Detecção e declaração de incidente** — A UniSuper detecta a indisponibilidade total dos serviços. O Google Cloud confirma que a subscrição foi excluída e que os dados não são recuperáveis dentro do ecossistema Google. As equipes de ambas as organizações iniciam colaboração para avaliar o escopo e planejar a recuperação. 5. **Início da recuperação — Backups externos ativados** — A recuperação é iniciada a partir dos backups mantidos no provedor de nuvem alternativo. Esse é o único caminho de recuperação disponível. O processo é complexo: requer reconfiguração completa do ambiente GCVE, restauração de dados em volume significativo e revalidação de integridade de sistemas críticos de um fundo de pensão. 6. **~2 semanas após o incidente — Restauração completa** — Os serviços da UniSuper são completamente restaurados. A UniSuper e o Google Cloud emitem uma declaração conjunta — incomum no setor pela sua transparência — reconhecendo o erro do lado do Google, descrevendo o que aconteceu e confirmando que nenhum dado de membro foi permanentemente perdido graças aos backups externos. ## Fluxo de Falha: Exclusão em Cascata e Caminho de Recuperação O diagrama reconstrói a topologia operacional da UniSuper no Google Cloud e o caminho de falha. A exclusão propagou-se de um único parâmetro de configuração para todos os recursos em ambas as regiões. O único vetor de recuperação foi externo ao provedor. ### ⚙️ Google Cloud — Plano de Controle / Control Plane - Google Cloud Control Plane (security) - GCVE Provisioning ⚠️ expiry param set (compute) - Subscription Auto-Delete Job (compute) ### 🌏 Google Cloud — Região A / Region A - GCVE Cluster Region A (compute) - Virtual Machines (workloads) (compute) - Persistent Volumes + Snapshots (storage) - Internal Backups (Google-side) (storage) ### 🌏 Google Cloud — Região B / Region B - GCVE Cluster Region B (compute) - Virtual Machines (workloads) (compute) - Persistent Volumes + Snapshots (storage) - Internal Backups (Google-side) (storage) ### 🛡️ Provedor Externo / External Cloud Provider - Offsite Backups ✅ Survived deletion (storage) ### 👤 UniSuper - UniSuper Operations (user) - ~500k Members (service disrupted) (user) ### Fluxos - gccp -> gcve-config: provisionamento com parâmetro errado - gcve-config -> auto-delete: expiry timer ativado - auto-delete -> gcve-a: ⚠️ exclusão disparada - auto-delete -> gcve-b: ⚠️ exclusão disparada - gcve-a -> vms-a: ❌ destruído - gcve-a -> storage-a: ❌ destruído - gcve-a -> backup-a: ❌ destruído - gcve-b -> vms-b: ❌ destruído - gcve-b -> storage-b: ❌ destruído - gcve-b -> backup-b: ❌ destruído - ext-backup -> gcve-a: ✅ restauração - unisuper -> gcve-a: opera workloads - unisuper -> ext-backup: mantém backups externos - members -> unisuper: acesso interrompido ~2 semanas > **Causa Raiz: Automação sem Blast Radius Limitado e Ausência de Salvaguardas de Exclusão:** A causa raiz não foi apenas o erro humano de configurar o parâmetro errado — erros humanos são inevitáveis. A causa raiz sistêmica foi a **ausência de múltiplas camadas de proteção que deveriam ter impedido ou limitado o impacto** de um erro desse tipo: 1. **Sem confirmação explícita para operações destrutivas em escala de produção**: um parâmetro que instrui a exclusão de uma subscrição inteira deveria exigir confirmação múltipla, aprovação separada e notificação ao cliente antes de qualquer execução. 2. **Sem diferenciação clara entre ambientes trial e produção no fluxo de provisionamento**: o mesmo mecanismo de expiração usado para trials foi aplicável a uma subscrição de produção ativa de um fundo de pensão regulado. 3. **Sem período de retenção pós-exclusão suficiente**: backups internos foram destruídos junto com os dados primários — eles eram co-dependentes da subscrição, não independentes dela. 4. **Blast radius total**: a exclusão afetou ambas as regiões simultaneamente porque ambas estavam vinculadas à mesma subscrição. Redundância geográfica dentro do mesmo provedor não protegeu contra uma operação executada no nível da subscrição. ## A Recuperação e o que ela Revelou A recuperação levou aproximadamente duas semanas — um período longo para qualquer serviço, mas extraordinariamente longo para um fundo de pensão onde membros precisam acessar informações sobre suas aposentadorias, fazer contribuições e tomar decisões financeiras. Durante esse período, os membros da UniSuper ficaram sem acesso aos seus portais e serviços digitais. O processo de recuperação foi tecnicamente complexo por razões que vão além do simples volume de dados. Restaurar um ambiente GCVE do zero a partir de backups externos não é como restaurar arquivos de um disco — envolve reconfigurar a infraestrutura VMware subjacente, reestabelecer configurações de rede, revalidar integridade de dados em sistemas que têm dependências cruzadas, e garantir que o estado restaurado seja consistente o suficiente para operar em conformidade com as obrigações regulatórias de um fundo de pensão australiano. O que a recuperação revelou com clareza brutal é a diferença entre **redundância e independência**. A UniSuper tinha redundância geográfica — duas regiões. Mas ambas as regiões estavam sob o mesmo plano de controle, vinculadas à mesma subscrição. Quando a subscrição foi excluída, a redundância geográfica tornou-se irrelevante. A independência — manter dados em um provedor completamente separado, com credenciais separadas, com um plano de controle que não compartilha nenhuma superfície de falha com o provedor primário — foi o único mecanismo que importou. É também notável o que **não** aconteceu: não houve perda permanente de dados de membros. Em um cenário onde a decisão arquitetural de manter backups externos não tivesse sido tomada, o incidente teria sido catastrófico e provavelmente irreversível. A declaração conjunta emitida pelo CEO da UniSuper e pelo CEO do Google Cloud é explícita nesse ponto — e o fato de que uma declaração conjunta foi emitida é, em si, significativo. Provedores de nuvem raramente admitem publicamente erros operacionais com esse nível de detalhe. ## O que Deveria Existir: Salvaguardas Estruturais contra Exclusão Catastrófica Este incidente não é sobre um operador que cometeu um erro. É sobre um sistema que permitiu que um erro de operador tivesse blast radius ilimitado. Arquitetar contra esse tipo de falha requer controles em múltiplas camadas: **No nível do provedor (o que o Google Cloud deveria ter):** - Diferenciação estrutural e obrigatória entre parâmetros de trial e produção, com validação explícita do tipo de subscrição antes de qualquer configuração de expiração. - Notificação proativa ao cliente quando qualquer parâmetro destrutivo é configurado, com janela de confirmação e período de carência. - Período de retenção pós-exclusão independente da subscrição — dados em soft-delete por no mínimo 30 dias após qualquer operação de exclusão em escala de subscrição. - Aprovação multi-parte para operações que afetam recursos em múltiplas regiões simultaneamente. **No nível do cliente (o que qualquer organização crítica deveria ter):** - **Backups fora do provedor primário** — não apenas fora da região, mas fora do provedor. Credenciais separadas, plano de controle separado, sem dependência do provedor primário para recuperação. - Testes periódicos de restauração completa a partir dos backups externos — não apenas verificação de existência, mas exercícios de DR que validem o tempo e a integridade da recuperação. - Inventário e auditoria regular de configurações de subscrição, incluindo parâmetros de ciclo de vida que possam ter sido definidos durante o provisionamento. - Definição clara de RTO e RPO para o cenário de perda total de provedor — não apenas para falhas de zona ou região. **No nível arquitetural:** - Separar o plano de controle de identidade e acesso dos recursos de dados. Em nuvens públicas, uma subscrição ou organização comprometida ou excluída pode levar consigo todos os recursos. Considerar padrões onde dados críticos têm proteções que sobrevivem à exclusão do container organizacional. - Implementar **deletion locks** (como o `resourcemanager.projects.delete` constraint no GCP, ou `DeletionPolicy: Retain` no CloudFormation da AWS) em todos os recursos de produção críticos. Esses mecanismos existem; precisam ser usados sistematicamente, não opcionalmente. A ironia deste caso é que a UniSuper fez a coisa certa — manteve backups externos. Mas isso foi uma decisão individual de uma organização específica, não uma garantia estrutural do ecossistema. Para cada UniSuper que tomou essa decisão, quantas organizações assumem que a redundância geográfica dentro do provedor é suficiente? ## Lições Técnicas - **Redundância geográfica dentro do mesmo provedor não protege contra falhas no plano de controle ou na subscrição.** Duas regiões vinculadas à mesma subscrição têm o mesmo blast radius para operações executadas no nível da subscrição. - **Backups fora do provedor primário são um requisito, não uma opção, para sistemas críticos.** 'Fora do provedor' significa credenciais separadas, plano de controle separado, sem dependência operacional do provedor primário. - **Deletion locks devem ser aplicados sistematicamente em recursos de produção.** GCP, AWS e Azure oferecem mecanismos para prevenir exclusão acidental. Eles devem ser parte do baseline de segurança, não configurações opcionais. - **Operações destrutivas em escala de subscrição ou organização precisam de salvaguardas proporcionais ao impacto.** Confirmação multi-parte, notificação ao cliente, período de carência e soft-delete pós-exclusão são controles necessários, não opcionais. - **Teste seu DR regularmente e para o cenário correto.** Testar restauração de uma zona é diferente de testar restauração de perda total de provedor. O segundo cenário é o que importou aqui. - **Audite configurações de ciclo de vida de subscrições periodicamente.** Parâmetros configurados durante o provisionamento — especialmente por terceiros — podem conter configurações destrutivas que não são visíveis nas operações do dia a dia. > **Minha Leitura Sênior:** Trabalho com sistemas financeiros há mais de 16 anos e esse incidente me incomoda de uma forma específica: não pelo erro em si, mas pela ausência de controles que deveriam ser óbvios em qualquer plataforma que hospeda dados de produção de uma instituição financeira regulada. O que me preocupa mais do que o erro do operador do Google é a **arquitetura de confiança implícita** que a maioria das organizações tem com seus provedores de nuvem. Quando você coloca seus backups no mesmo provedor que seus dados primários — mesmo em regiões diferentes, mesmo em contas diferentes — você está assumindo que o provedor nunca cometerá um erro que afete o plano de controle de forma ampla. Esse é um pressuposto que este incidente prova ser falso. Minha posição é direta: **para qualquer sistema onde a perda de dados é inaceitável, a estratégia de backup deve incluir pelo menos uma cópia completamente fora do provedor primário, com acesso gerenciado por credenciais que não dependem do provedor primário para autenticação ou autorização.** Isso não é paranoia — é o mínimo razoável dado o que sabemos sobre blast radius de plano de controle. Há também uma lição sobre automação que frequentemente é subestimada: **automação é fiel, não inteligente**. Ela executa o que foi configurada para executar, sem considerar contexto, sem questionar intenção, sem avaliar consequências. O trabalho de limitar o blast radius de automação é do arquiteto, não da automação. Deletion locks, aprovações multi-parte, períodos de carência e notificações proativas são o equivalente arquitetural de 'você tem certeza?' — e eles precisam ser defaults, não opções. Por fim: a UniSuper tomou a decisão certa de manter backups externos. Mas essa decisão foi tomada apesar do ecossistema, não por causa dele. O que precisamos é de um ecossistema onde a decisão certa seja o caminho de menor resistência — onde a configuração padrão de qualquer subscrição de produção inclua proteções contra exclusão acidental, não onde o cliente precise descobrir e configurar isso manualmente. ## Veredicto O incidente UniSuper-Google Cloud de 2024 é um dos casos mais importantes de resiliência em nuvem da última década — não porque foi o maior em escala, mas porque expõe uma falha de pressuposto que é endêmica na indústria: a crença de que redundância dentro de um provedor é equivalente a resiliência contra o provedor. A UniSuper sobreviveu porque tomou uma decisão arquitetural que, na época, pode ter parecido excessivamente conservadora para alguns: manter backups completamente fora do Google Cloud. Essa decisão — e não nenhuma capacidade do Google Cloud — foi o que impediu a perda permanente de dados de 500 mil membros de um fundo de pensão. As implicações são diretas para qualquer arquiteto de sistemas críticos: **O que este caso prova:** Redundância geográfica dentro de um único provedor não protege contra falhas no plano de controle. Backups co-locados com dados primários no mesmo provedor não são backups independentes. Automação sem salvaguardas proporcionais ao impacto é um risco sistêmico, não uma eficiência operacional. **O que este caso recomenda:** Backups fora do provedor primário como requisito não-negociável para dados críticos. Deletion locks como default em recursos de produção. Testes de DR para o cenário de perda total de provedor, não apenas para falhas de zona. Auditoria periódica de configurações de ciclo de vida de subscrições. **O que este caso deixa em aberto:** Quantas organizações estão operando hoje com a mesma exposição que a UniSuper tinha — sem os backups externos que a salvaram? A resposta honesta é: provavelmente a maioria. E esse é o verdadeiro legado deste incidente. ## Referências - [UniSuper & Google Cloud — Joint Statement (May 2024)](https://www.unisuper.com.au/about-us/media-centre/2024/a-joint-statement-from-unisuper-and-google-cloud) ## Fontes do caso - [UniSuper & Google Cloud — Joint statement](https://www.unisuper.com.au/about-us/media-centre/2024/a-joint-statement-from-unisuper-and-google-cloud)