Na semana em que outro registro nacional de propriedades foi apagado e um fornecedor de saúde dos EUA perdeu dados “significativos”, uma verdade ficou mais alta: se seus “backups” vivem onde seu IAM de produção pode tocá‑los, eles não são backups. São moeda de barganha.
Você não precisa de mais uma palestra sobre ransomware. Você precisa de um plano de recuperação que sobreviva a uma violação em nível de root sem drama, restaure rápido o suficiente para salvar o negócio e custe uma porcentagem de um dígito da sua conta de infra. Este post entrega esse plano.
O problema: snapshots são negociáveis; backups, não
Gangues de ransomware não começam criptografando arquivos. Elas começam apagando caminhos de recuperação. Se o seu caminho de recuperação são snapshots de EC2/EBS, um token de admin comprometido pode apagá‑los em minutos. Nem mesmo replicação entre regiões salvará você se a mesma cadeia de federação puder deletar lá também. O mesmo vale para volumes persistentes em Kubernetes, autosnapshots de banco amarrados ao mesmo control plane e “exports semanais” parados em um bucket S3 no qual o papel do seu app pode escrever.
Duas manchetes recentes deveriam ser um balde de água fria para qualquer CTO: um atacante apagou o banco de dados do registro de propriedades de um país; um fornecedor dos EUA que atende milhares de hospitais reportou grande roubo de dados e interrupção. Em ambos os casos, a continuidade dependeu de os backups serem imutáveis, isolados e comprovados em drill. A maioria não é.
O framework de decisão: pontue sua postura de recuperação em cinco eixos
Antes de comprar qualquer coisa, avalie sua postura de recuperação em cinco eixos. Você precisa dos cinco em verde.
1) Mutabilidade: um atacante com credenciais de admin de produção pode alterar ou deletar seus backups?
- Aceitável: S3 Object Lock (compliance mode) ou GCS Bucket Lock com retenção. Azure Immutable Blob com retenção baseada em tempo.
- Inaceitável: Snapshots ou objetos deletáveis pelos mesmos principais de IAM que operam produção, ou por qualquer caminho de SSO federado usado no dia a dia.
2) Isolamento: os backups estão em um raio de impacto separado?
- Aceitável: Conta/projeto/tenant de nuvem separado com Service Control Policies (SCPs) impedindo mudanças de políticas ou de locks, cadeia de admin separada, KMS root separado, MFA e tokens de hardware separados.
- Inaceitável: Mesma conta, mesmo KMS ou qualquer break‑glass que um IdP comprometido possa assumir.
3) Independência de chaves: você consegue descriptografar se seu KMS primário cair ou for comprometido?
- Aceitável: Chaves KMS dedicadas na conta de backup, com material de chave e admins não compartilhados com produção. Opcionalmente em escrow em um HSM ou em esquema de split‑knowledge.
- Inaceitável: Dados de backup criptografados somente sob as mesmas chaves KMS usadas pela produção.
4) SLOs de recuperabilidade: você tem RPO/RTO medidos?
- Aceitável: RPO definido e testado ≤ 15 minutos para dados OLTP primários; RTO ≤ 4 horas para recuperação de pilha completa do seu serviço de caminho crítico.
- Inaceitável: “Achamos que conseguimos restaurar em um dia.” Se você não cronometrar, não existe.
5) Cobertura: tudo que você roda e de que depende é recuperável?
- Aceitável: Bancos de dados, object stores, estado de infra, imagens de contêiner, segredos, artefatos de CI e dependências de SaaS (GitHub, Slack, Google Workspace, Notion) com exportação automatizada.
- Inaceitável: Somente bancos de dados ou somente snapshots de VMs.
A arquitetura de referência: backups resilientes a ransomware em nuvem pública
Esse padrão assume AWS, mas os mesmos primitivos existem em GCP e Azure.
Padrão central: duas contas, Object Lock e versionamento
- Crie uma conta “Backup” dedicada com seu próprio root, MFA e chaves de segurança de hardware. Sem federação do seu IdP corporativo para acesso root. Aplique SCPs que proíbam mudanças nas configurações de Object Lock, exclusão de chaves KMS e modificações de papéis, exceto por um caminho de break‑glass controlado.
- Provisionar buckets S3 com Object Lock habilitado em compliance mode, versionamento ligado e uma janela de default retention (ex.: 30 dias). Governance mode não basta; compliance mode impede até o root de remover a retenção antes do vencimento.
- Use replicação entre contas a partir de um bucket “Staging Vault” na sua conta de produção para os buckets com Object Lock na conta de Backup. A replicação deve ser unidirecional e iniciada por um papel de replicação dedicado na conta de backup, não pela produção. O bucket de destino aplica Object Lock na escrita.
- Criptografe com uma chave KMS da conta de backup (SSE‑KMS) que não tenha concessões para papéis de produção. Guarde os admins da chave em um grupo de segurança separado com tokens de hardware e contatos de emergência fora de banda.
- Faça tiering do storage: 30 dias em S3 Standard‑IA para restaure rápido; fulls mensais em Glacier Deep Archive por 12 meses. Object Lock se aplica a versões e classes de armazenamento.
Data movers: cientes da aplicação, incrementais, verificáveis
- Postgres: Use pgBackRest ou WAL‑G para enviar base backups e WAL para o Staging Vault, depois replique para o bucket com Lock. Configure arquivamento contínuo mirando um prefixo “append‑only” que um papel de app em produção não possa listar nem deletar. Rode jobs diários de restore‑verify que sobem uma instância temporária, aplicam WAL até um timestamp alvo, executam CHECKPOINT e rodam um conjunto de queries de sanidade lógica.
- MySQL: XtraBackup full + incremental, envio de binlogs e verificação diária de restore.
- MongoDB: Captura contínua do Oplog com snapshot periódico do mongod e replay; valide contagens e hashes de coleções após o restore.
- Blob stores: Não espelhe o bucket inteiro de hora em hora. Gere bundles endereçados por conteúdo com manifestos e hashes (ex.: tarballs por partição/dia compactados com zstd) para que a integridade seja verificável e o restore seja paralelizável.
- Estado de infra: Backend remoto do estado do Terraform com versionamento e object lock, mais snapshots periódicos para o bucket travado. Mantenha AMIs ou snapshots de imagem para o OS base “golden” na conta de backup.
- Segredos: Exportação noturna e recriptografia de itens do Vault/Secrets Manager para a conta de backup sob o KMS de backup. Na restauração, rotacione tudo.
Dependências de SaaS: automatize as exportações rotineiras
- GitHub: Espelhe repositórios para remotos de backup somente leitura na conta de backup ou em um espelho Gitea neutro; exporte issues e metadados de PR semanalmente.
- Slack: API de export Enterprise para canais públicos e privados; aplique política de retenção legal. Armazene exports sob Object Lock.
- Google Workspace/Microsoft 365: Use exports de Vault/Compliance para e‑mail e Drive; mensal para times não regulados, semanal para regulados.
- CI/CD: Faça snapshot do cache de build e artefatos essenciais; mantenha digests de imagens Docker e uma cópia de imagens críticas no registry de backup.
Números que importam: tamanho, velocidade e custo
Vamos ancorar isso com um perfil plausível de startup:
- OLTP Postgres primário: 4 TB
- Dados de objetos: 12 TB
- Infra/config/segredos/outros: equivalente a 4 TB
- Total primário: ~20 TB
Assuma taxa de mudança diária de 2% entre datasets e 40% de compressão/dedup nos backups.
- Pé de storage: ~8 TB de base full + ~400 GB/dia de incrementais. Janela quente de 30 dias ≈ 8 TB + (0,4 TB × 30) = ~20 TB em S3 Standard‑IA.
- Custo mensal da janela quente (us‑east‑1): ~20 TB × $0,0125/GB ≈ $250. Dobre por replicação entre contas ≈ $500. Some requests/retiradas: chame de $700–$900/mês.
- Arquivo frio: Guarde um full mensal no Glacier Deep Archive por 12 meses: 8 TB × 12 ≈ 96 TB × ~$0,001/GB ≈ $100/mês.
- Vazão de restore: Mire 1 TB/hora por banco e 2–3 TB/hora para pulls paralelos de dados de objetos. Isso coloca seu DB de 4 TB de volta em 4 horas; blobs em ~4–6 horas.
Em resumo: uma postura resiliente a ransomware para esse perfil fica bem abaixo de 1–2% de uma conta de nuvem de $50–100K/mês. O custo real é a disciplina de engenharia para treinar em drills.
Runbooks que realmente funcionam (e como provar)
Defina SLOs antes de escrever os passos
- RPO: ≤ 15 minutos para OLTP, 1 hora para blobs.
- RTO: ≤ 4 horas para serviço visível ao usuário, ≤ 24 horas para dados de cauda longa.
Ordem de operações de restauração
- Contenção: Trave o IdP, gire o break‑glass. Congele contas de produção. Preserve a forense: memória, discos e logs para um bucket de evidências WORM separado dos seus buckets de backup.
- Reconstrua as fundações primeiro: Identidade (Okta/AD), primitivos de rede, KMS na conta limpa.
- Segredos e imagens: Suba Vault/Secrets Manager a partir do backup. Gire chaves, tokens e senhas de banco imediatamente após o restore.
- Bancos de dados: Restaure a base, reproduza WAL/binlogs até o RPO alvo, valide esquema, contagens e hashes. Promova como somente leitura e depois faça o switch para primário.
- Blob/object stores: Restaure em paralelo por partição/dia. Valide manifestos/hashes.
- Aplicações/serviços: Faça deploy a partir de imagens golden; bloqueie estritamente AMIs desconhecidas e contêineres não assinados.
- Tráfego: Cutover gradual atrás de um feature flag ou modo somente leitura primeiro, depois tráfego de escrita completo.
Cadência de drills e métricas
- Mensal: Drill de restauração parcial de 2 horas (subconjunto de DB + um serviço) durante o horário comercial. Sucesso = RPO/RTO atingidos, dados validados, passos do runbook marcados com carimbos de tempo.
- Trimestral: Dia inteiro, exercício de mesa (table‑top) com red team + restore ao vivo em uma VPC isolada. Inclua importes de exports de SaaS. Sucesso = usuários conseguem fazer login e executar uma transação real.
- Acompanhe: Tempo de restore mediano/95º, falhas de verificação, dependências ausentes e surpresas. Seu relatório ao conselho deve mostrar um SLO de recuperação que você realmente cumpre.
Antipadrões para eliminar neste trimestre
- “O provedor nos cobre”: Snapshots de EBS, backups automatizados de RDS e snapshots de PVs no GKE estão no mesmo control plane. São restaurações convenientes, não defesas contra ransomware.
- KMS compartilhado: Criptografar backups com as mesmas chaves ou os mesmos admins da produção significa um único raio de impacto.
- “Vamos contar com o versionamento”: S3 versioning sem Object Lock é deletável por um admin.
- Somente quente: Uma janela quente de 30 dias sem arquivo frio deixa você exposto a manipulação de longo prazo.
- Blobs não verificáveis: Cópias aleatórias de objetos sem manifestos e hashes tornam as alegações de integridade performáticas.
E quanto ao offline?
Verdadeiro air‑gap ainda é o padrão‑ouro. Para a maioria das startups, é exagero operacional. Um meio‑termo pragmático:
- Snapshot offline trimestral: Exporte fulls trimestrais para volumes LUKS criptografados em SSDs removíveis, armazene em local externo seguro com logs de cadeia de custódia. Esta é sua cópia para impacto de meteoro.
- Variante de air‑gap na nuvem: Uma conta de backup com Object Lock + SCPs, sem peering de rede permanente com produção e autenticação de admin que não é federada do seu IdP corporativo. Não é um air‑gap literal, mas quebra a maioria das cadeias de violação.
Jurídico e forense que você vai querer ter
- Evidência WORM: Escreva logs de auditoria, telemetria de EDR e snapshots de sistemas comprometidos em um bucket WORM separado com retenção de 1 ano. Mantenha‑o lógica e administrativamente isolado do seu volume de backup.
- Prontidão de 72 horas: Muitos regimes exigem notificação de incidente em 72 horas. Pré‑prepare templates, contatos e um checklist factual do que você pode afirmar (janelas de retenção, criptografia em repouso/em trânsito, IDs de Object Lock).
- Cobertura de terceiros: Documente de quais fornecedores você depende para continuidade e qual é a postura deles de WORM/imutabilidade. Inclua cláusulas de imutabilidade de backup e drills de recuperação em MSAs.
Open source, agentes e tudo incremental
Duas tendências valem menção no burburinho técnico desta semana. Primeiro, bibliotecas de computação incremental estão boas o suficiente para tornar verificação contínua barata. Aplique essa mentalidade a backups: compute checksums e queries de verificação de forma incremental em vez de grandes jobs de fim de semana. Segundo, a onda de ferramentas de IA torna tentador delegar a disciplina de operações a “agentes”. Não faça isso. Use agentes para gerar manifestos de restore e validar registros, mas mantenha a autoridade de deletar ou destravar fora das mãos deles. Em uma violação, a decisão final deve ser humana.
Quem é dono disso e como alocar recursos
- Um único responsável: Designe um SRE Staff+ como Recovery Owner. A régua dele são os SLOs de RPO/RTO e a taxa de sucesso nos drills.
- Orçamento: Planeje 1–2% do gasto de nuvem. A maior parte é storage; o resto é tempo de drill.
- Horas operacionais: Use um pod nearshore para rodar drills mensais e manter os runbooks frescos. Com 6–8 horas de sobreposição com os EUA, drills não detonam sua rotação de plantão e você ainda cobre incidentes de madrugada.
Pontos de partida práticos para os próximos 30 dias
- Ative o Object Lock em uma nova conta de backup dedicada. Se não puder, crie um bucket novo; não é possível habilitá‑lo retroativamente em existentes.
- KMS separado nessa conta de backup e remova todos os principais de produção. Documente o break‑glass.
- Configure um data mover de ponta a ponta: por exemplo, pgBackRest base + WAL para o Staging Vault, replicado para o bucket travado. Prove um restore de 4 horas em um subconjunto de 500 GB.
- Exporte um SaaS do qual você depende (GitHub ou Slack) e armazene sob Object Lock. Cronometre.
- Agende seu primeiro drill no calendário e convide o jurídico. Se não estiver agendado, não é real.
Trade‑offs e checagens de realidade
- Imutabilidade vs. agilidade: Object Lock em compliance mode vai doer quando você errar. Esse é o ponto. Use buckets de staging para capturar erros antes de travar.
- Custo vs. RTO: Glacier é barato, mas lento. Mantenha uma janela quente de 30 dias em IA para bater seu RTO; empurre o mais antigo para Deep Archive.
- Segurança vs. operacionalidade: Contas e chaves separadas significam mais cerimônia. Escreva a cerimônia e pratique, ou você vai inventar atalhos durante um incidente.
- Pessoas vs. ferramentas: A melhor arquitetura não salva se a única pessoa que sabe os passos de restore está de férias. Faça cross‑training e grave execuções com captura de tela.
Se você não fizer mais nada
Se for fazer apenas uma coisa neste trimestre, torne um dataset realmente imutável e teste um restore cronometrado. Você vai aprender mais nesse único drill do que em dez exercícios de mesa. E nunca mais vai confundir snapshots com backups.
Pontos‑chave
- Snapshots não são backups. Se o IAM de produção pode deletar seu caminho de recuperação, um atacante também pode.
- Use Object Lock/Bucket Lock em uma conta separada, com chaves KMS separadas e SCPs.
- Defina e meça RPO ≤ 15 minutos e RTO ≤ 4 horas para o seu caminho crítico.
- Faça drill mensal (parcial) e trimestral (completo). Se não for testado, não existe.
- Faça backup de dependências de SaaS, não só de infra: GitHub, Slack, Google/Microsoft, CI.
- Mire 1–2% do gasto de nuvem para backups resilientes; o resto é disciplina.
- Designe um Recovery Owner e use um pod nearshore para manter os runbooks atualizados com 6–8 horas de sobreposição.