Google Cloud × UniSuper (2024): Quando uma Configuração Apagou uma Subscrição Inteira

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.

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.

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?