Índice
Um backup imutável É uma cópia de dados que não pode ser alterada, criptografada ou excluída durante um período de retenção definido — nem por ransomware, nem por uma conta roubada, nem por um administrador. Para KVM e outros ambientes virtuais, isso significa que os pontos de restauração da VM são gravados uma única vez no armazenamento WORM (gravação única, leitura múltipla) e permanecem legíveis, porém bloqueados, até que o período de retenção expire. Quando os dados de produção são criptografados, ainda existe uma cópia íntegra que um invasor não pode acessar.
Este guia explica o significado prático de backup imutável, como a imutabilidade bloqueia ransomware, a diferença entre o modo de governança e o modo de conformidade e como implementar uma solução de backup imutável para plataformas baseadas em KVM/QEMU, como OpenStack, oVirt, OpenNebula, Proxmox VE e KubeVirt.
O que é um backup imutável?
Um backup imutável é um backup gravado em um armazenamento que impõe uma política de gravação única e leitura múltipla (WORM): uma vez que os dados são confirmados, a camada de armazenamento rejeita todas as solicitações de sobrescrita e exclusão até que um período de retenção predefinido expire. A expressão-chave é "camada de armazenamento" – a imutabilidade não é uma opção selecionável dentro do aplicativo de backup, mas sim uma propriedade de onde o ponto de restauração reside: armazenamento de objetos com Object Lock, um dispositivo habilitado para WORM ou um cofre isolado da internet (air-gapped).
Quando o software de backup termina de gravar um ponto de restauração, o objeto recebe um carimbo de data/hora de retenção, definido explicitamente ou herdado da retenção padrão do bucket. A partir desse momento, qualquer chamada que modifique ou exclua o objeto retorna um erro, enquanto as operações de leitura e restauração funcionam normalmente.
Um backup convencional é protegido apenas pelo controle de acesso: quem detém as credenciais – ou as rouba – pode apagá-las, sobrescrevê-las ou criptografá-las permanentemente. A criptografia de backup impede que alguém leia os dados; porém, não impede que sejam destruídos. A imutabilidade adiciona um controle que nenhuma credencial pode burlar durante o período de retenção – a diferença prática entre “protegido” e “imutável”.”
Como a imutabilidade impede o ransomware?
Grupos de ransomware raramente começam criptografando dados de produção. Primeiro, eles localizam servidores de backup, repositórios e credenciais de armazenamento em nuvem, porque uma vítima com backups utilizáveis não tem motivos para pagar. A Palo Alto Networks...’ Relatório Global de Resposta a Incidentes da Unidade 42 - 2026, Com base em mais de 750 casos de resposta a incidentes, constatou-se que Os atacantes danificaram backups em 26% de casos de extorsão., e que Apenas 411.000 vítimas conseguiram restaurar o sistema a partir do backup sem pagar.. A economia favorece o atacante: a demanda inicial mediana subiu para US$ 1,5 milhão em 2025, e o pagamento mediano quase dobrou para US$ 500.000. O relatório Sophos State of Ransomware 2026 mostra o outro lado da mesma moeda: 661.300 organizações cujos dados foram criptografados conseguiram recuperá-los por meio de backups, um aumento de 12 pontos percentuais em relação ao ano anterior, mas o custo médio de recuperação ainda subiu US$ 1,7 milhão por incidente. A janela para detectar uma intrusão é curta: a Unit 42 estima o tempo mediano entre o acesso inicial e a exfiltração de dados em dois dias, e o quartil mais rápido em 72 minutos.
Figura 1. Por que os backups são o primeiro alvo. Fontes: Relatório Global de Resposta a Incidentes da Unit 42 de 2026; Estado do Ransomware da Sophos em 2026.
Existem três maneiras de neutralizar um backup, e a imutabilidade bloqueia todas elas:
- Eliminação – usar credenciais de administrador roubadas para remover o repositório, bucket ou catálogo. Uma solicitação de exclusão contra um objeto bloqueado é rejeitada, independentemente de quem a envia.
- Criptografia in-place – Criptografando arquivos de backup como qualquer outro disco. A criptografia sobrescreve os dados, e as sobrescritas são rejeitadas.
- adulteração de retenção – Reduzindo o período de retenção para que os pontos de restauração expirem antes que a intrusão seja detectada. No modo de conformidade, você só pode estender o período de retenção.
Considere um cluster KVM executando 200 máquinas virtuais. Um atacante realiza um ataque de phishing contra um administrador de domínio, acessa o servidor de backup e exclui o catálogo de backup local e o repositório NFS subjacente. Sem imutabilidade, as opções são pagar o resgate ou reconstruir tudo do zero. Se os mesmos pontos de restauração também fossem copiados para um bucket de armazenamento de objetos com Bloqueio de Objeto e um período de retenção de 30 dias, toda tentativa de exclusão nesse bucket falharia: a equipe provisionaria hosts KVM limpos, restauraria as VMs a partir dos pontos de restauração bloqueados e a exigência de resgate perderia sua vantagem. A imutabilidade não impede a intrusão – ela remove a moeda de troca do atacante.
A mesma lógica se aplica a ameaças internas e erros humanos: um administrador insatisfeito ou um script de limpeza digitado incorretamente não podem destruir o que o armazenamento se recusa a excluir. É por isso que a CISA Guia #StopRansomware A lista inclui backups offline, criptografados e imutáveis entre suas recomendações básicas.
Figura 2. Como um backup imutável impede um ataque de ransomware.
Agende uma demonstração ao vivo do Hystax Acura. – Replicação em segundo plano, planos de migração, migrações de teste e uma transição controlada, além de failover e failback de recuperação de desastres.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
Modos de imutabilidade: governança versus conformidade
As plataformas de armazenamento de objetos que suportam o Object Lock — AWS S3, sistemas locais compatíveis com S3, como Ceph RGW e MinIO, e a maioria dos provedores de nuvem — oferecem dois modos de retenção. A escolha determina quem, se houver alguém, pode desfazer a imutabilidade antes do término do período de retenção.
| Aspecto | Modo de governança | Modo de conformidade |
|---|---|---|
| Apagar ou sobrescrever antes do prazo de retenção. | Somente usuários com a permissão s3:BypassGovernanceRetention e somente com um cabeçalho de bypass explícito. | Ninguém, incluindo o usuário root da conta na nuvem. |
| Reduzir o período de retenção | Sim, com permissão para contornar o bloqueio. | Não – a retenção só pode ser prorrogada. |
| Alterar o modo de retenção | Sim, a governança pode ser aprimorada para incluir a conformidade. | Não |
| Impede que um invasor obtenha credenciais de administrador. | Parcial – falha se a conta comprometida tiver permissão de bypass. | Sim |
| Ideal para | Testando políticas de retenção; backups que precisam de flexibilidade operacional. | Defesa contra ransomware; retenção regulamentada (finanças, saúde, setor público) |
| Principal risco | Contas com privilégios excessivos podem burlar o bloqueio. | Um período de retenção incorreto não pode ser desfeito; o custo de armazenamento é irrecuperável. |
Uma prática recomendada é validar as configurações de retenção no modo de governança e, em seguida, alternar os pontos de restauração críticos para proteção contra ransomware para o modo de conformidade. Três regras se aplicam a ambos os modos no AWS Object Lock e na maioria das implementações compatíveis: o Object Lock deve ser ativado quando o bucket é criado, requer versionamento e as regras de expiração do ciclo de vida não removem as versões de objetos bloqueados. Um controle separado, o Legal Hold, bloqueia a exclusão indefinidamente até que seja explicitamente removido. Guia do usuário do Amazon S3, Bloqueio de objetos.
Figura 3. Modo de governança versus modo de conformidade. Fonte: Guia do usuário do Amazon S3.
Backup imutável para ambientes KVM/QEMU
KVM, libvirt e as plataformas construídas sobre elas – OpenStack, oVirt, OpenNebula, Proxmox VE, Virtuozzo, KubeVirt, Red Hat OpenShift Virtualization – não incluem imutabilidade nativa. Os snapshots em nível de hipervisor (qcow2, Ceph RBD, LVM) ficam no mesmo armazenamento que os dados de produção e compartilham a mesma vulnerabilidade: um atacante com acesso ao hipervisor ou ao armazenamento remove ambos. A imutabilidade precisa ser adicionada no destino do backup e, como é uma propriedade do armazenamento e não um recurso do hipervisor, a mesma arquitetura funciona para todas as distribuições KVM.
Uma arquitetura de referência para backup imutável de KVM possui quatro camadas:
- Capturar. Um agente de replicação externo ou sem agente lê os dados do disco da máquina virtual no nível do hipervisor, rastreia os blocos alterados e produz pontos de restauração consistentes com o aplicativo sem pausar a máquina virtual.
- Camada rápida (armazenamento em bloco). Os pontos de restauração recentes permanecem no armazenamento em blocos no ambiente de destino, permitindo que uma máquina virtual com falha seja inicializada diretamente a partir de um snapshot em questão de minutos. Essa camada é otimizada para RTO (Objetivo de Tempo de Recuperação), não para imutabilidade.
- Camada imutável (armazenamento de objetos com bloqueio de objeto). Cada ponto de restauração é copiado para um armazenamento de objetos compatível com S3, com o Object Lock em modo de conformidade e um período de retenção maior do que a janela de detecção esperada. – Um período de 14 a 30 dias é um ponto de partida comum. Essa camada de backup imutável na nuvem é à prova de ransomware.
Cofre com espaço de ar (opcional). Uma cópia periódica é armazenada em uma conta, região ou provedor separado – ou em uma mídia offline – sem caminho de rede permanente e com credenciais distintas, protegendo contra a violação da própria plataforma de armazenamento primária.
Figura 4. Arquitetura de referência: camada de ponto de restauração imutável para plataformas baseadas em KVM.
Este é o modelo Hystax Acura Segue o procedimento para plataformas baseadas em KVM: mantém pontos de restauração em armazenamento em blocos para failover rápido e em armazenamento de objetos econômico (compatível com S3, NFS ou Samba) para retenção, com políticas de retenção de snapshots configuráveis, deduplicação e controle de acesso baseado em funções com trilha de auditoria. Quando você configura o destino de armazenamento de objetos com Bloqueio de Objetos, os pontos de restauração gravados nele herdam o bloqueio de retenção do bucket, de modo que o armazenamento impõe a imutabilidade em vez do aplicativo de backup. Para um contexto mais amplo, consulte Por que a recuperação de desastres e o backup são essenciais para ambientes KVM.
Imutável vs. isolado da internet vs. 3-2-1: como eles se encaixam
Esses são controles complementares, não alternativas. A regra 3-2-1 define quantas cópias existem e onde; um espaço físico (air gap) define o isolamento da rede; a imutabilidade define se uma cópia pode ser alterada.
| Abordagem | Protege contra | Não protege contra | Velocidade de recuperação | Custo relativo |
|---|---|---|---|---|
| Regra 3-2-1 (3 cópias, 2 tipos de mídia, 1 fora do local) | Falha de hardware, perda de site, exclusão de ponto único | Um atacante com credenciais para todas as cópias. | Rápido (cópia local) | Baixo a médio |
| Cópia de segurança isolada da rede (cofre offline ou isolado da rede) | Ataques originados na rede; roubo de credenciais (sem caminho online) | Pessoas internas com acesso físico; RPO longo se as cópias forem periódicas. | Lento (horas a dias) | Médio-alto |
| Cópia de segurança imutável (Object Lock / WORM) | Exclusão, criptografia e adulteração de dados de retenção — por qualquer pessoa. | A própria intrusão; exfiltração de dados; um período de retenção definido como muito curto. | Rápido (online e legível) | Baixo a médio |
| 3-2-1-1-0 (combinação moderna) | Tudo isso: uma cópia imutável ou offline, zero erros de restauração. | restaurações não testadas | Rápido | Médio |
A interpretação moderna da regra – 3-2-1-1-0 – mantém pelo menos uma cópia imutável ou offline e exige zero erros na verificação de restauração. Para informações sobre contagem de cópias, tipos de mídia e erros comuns, consulte o Guia Hystax para a estratégia de backup 3-2-1.
Como configurar um backup imutável: passo a passo
- Escolha um destino de armazenamento compatível com o recurso Object Lock. AWS S3, Azure Blob Storage (armazenamento imutável), bloqueio de bucket do Google Cloud Storage ou plataformas locais compatíveis com S3, como Ceph RGW, MinIO ou NetApp StorageGRID. Habilite o versionamento e o bloqueio de objetos na criação do bucket – no AWS S3, essa funcionalidade não pode ser adicionada posteriormente.
- Defina o período de retenção. Deve exceder o tempo necessário para detectar uma intrusão; 14 a 30 dias é uma base prática para pontos de restauração operacionais, e arquivos regulamentados podem exigir de 1 a 7 anos. Comece no modo de governança e passe para o modo de conformidade assim que a política for comprovada.
- Credenciais isoladas. O software de backup deve gravar com uma identidade que tenha permissões de PutObject, mas não de DeleteObject ou BypassGovernanceRetention. Mantenha o bucket de backup em uma conta de nuvem separada da de produção, imponha autenticação multifator (MFA) e aplique controle de acesso baseado em funções na plataforma de backup para que nenhum operador individual possa alterar o período de retenção.
- Aponte o software de backup para o destino imutável. Agende uma tarefa de cópia da camada de armazenamento em bloco de alta velocidade para o bucket bloqueado para atender ao seu RPO. Mantenha a criptografia de backup em trânsito e em repouso – criptografia e imutabilidade protegem coisas diferentes.
- Adicione um espaço de ar onde o risco o justificar. Uma segunda cópia para um provedor ou região diferente, ou para uma mídia offline, representa uma vulnerabilidade na plataforma de armazenamento principal ou na conta em nuvem.
- Os testes restauram a partir da camada imutável. Pelo menos uma vez por mês, restaure uma máquina virtual completa em uma rede isolada diretamente a partir dos pontos de restauração bloqueados, verifique a consistência do aplicativo e registre o RTO real. Este é o "0" em 3-2-1-1-0.
- Monitorar e auditar. Alerta sobre trabalhos de backup com falha, tentativas de exclusão rejeitadas em objetos bloqueados (CloudTrail ou log de auditoria equivalente), alterações de retenção e permissões de bypass recém-concedidas. Revisar trimestralmente.
Resumo
Um backup imutável é a única cópia dos dados de produção que um invasor não pode excluir, criptografar ou tornar obsoleta — a última linha de defesa contra a perda de dados e o que transforma um incidente de ransomware de uma negociação em uma tarefa de restauração. Para KVM e ambientes virtuais, a implementação é bem definida: capturar pontos de restauração consistentes no nível do hipervisor, manter uma cópia rápida em armazenamento de blocos para o RTO (Objetivo de Tempo de Recuperação) e copiar cada ponto de restauração para armazenamento de objetos com o Object Lock em modo de conformidade — tudo isso envolto na regra 3-2-1, um isolamento físico (air gap) onde o orçamento permitir, credenciais com privilégios mínimos e testes regulares de restauração. Softwares de backup imutáveis, como... Hystax Acura A camada de armazenamento fornece a captura, o armazenamento em camadas, o agendamento de retenção e o controle de acesso; a imutabilidade em si é garantida pela camada de armazenamento – exatamente onde deve estar, pois essa é a única camada que uma conta de administrador comprometida não consegue alcançar.
Insira o e-mail da sua empresa e nossa equipe entrará em contato em breve para discutir uma arquitetura de backup imutável e resistente a ransomware para sua infraestrutura KVM ou em nuvem. – Projeto de retenção, estimativas de custos de armazenamento de objetos e um plano de teste de restauração.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
Perguntas frequentes
O ransomware pode apagar backups imutáveis?
Não. Durante o período de retenção, a camada de armazenamento rejeita todas as solicitações de exclusão e sobrescrita, incluindo solicitações feitas com credenciais de administrador válidas. Portanto, o ransomware não pode remover ou criptografar um ponto de restauração bloqueado. As exceções incluem pontos de restauração cujo período de retenção expirou e objetos em modo de governança quando a conta comprometida também possui a permissão de bypass — motivo pelo qual o modo de conformidade é recomendado para defesa contra ransomware.
Um administrador pode ignorar o bloqueio de retenção?
Depende do modo de retenção. No modo de governança, um administrador com a permissão s3:BypassGovernanceRetention pode reduzir o período de retenção ou excluir o objeto. No modo de conformidade, nenhum usuário pode fazer isso – no AWS S3, nem mesmo o usuário raiz da conta; a única maneira de remover os dados antecipadamente é fechar toda a conta da AWS.
Qual deve ser o período de retenção de um backup imutável?
Tempo suficiente para ultrapassar o período em que um invasor poderia permanecer indetectado em seu ambiente. Para pontos de restauração operacionais, 14 a 30 dias é uma base comum; dados regulamentados nos setores financeiro, de saúde ou público podem exigir de um a sete anos. Como o período de retenção no modo de conformidade não pode ser reduzido, valide a política primeiro no modo de governança.
O backup imutável funciona para KVM e OpenStack?
Sim. A imutabilidade é uma propriedade do destino de armazenamento, não do hipervisor, portanto, qualquer plataforma baseada em KVM – OpenStack, oVirt, OpenNebula, Proxmox VE, Virtuozzo, KubeVirt – pode usá-la, desde que o software de backup grave pontos de restauração em um armazenamento de objetos compatível com Object Lock. O Hystax Acura, por exemplo, protege essas plataformas e armazena pontos de restauração em um armazenamento de objetos compatível com S3 que pode ser configurado com Object Lock.
A imutabilidade é o mesmo que um espaço de ar?
Não. Um backup isolado da rede (air-gapped) fica fora da rede, portanto, um invasor não tem como acessá-lo online; um backup imutável permanece online, mas não pode ser modificado ou excluído. Cópias imutáveis são restauradas mais rapidamente e podem ser verificadas continuamente; cópias isoladas da rede oferecem proteção adicional caso a própria plataforma de armazenamento seja comprometida. A postura mais robusta utiliza ambos.
O backup imutável aumenta os custos de armazenamento?
Moderadamente. Os pontos de restauração bloqueados não podem ser excluídos antecipadamente e as regras de ciclo de vida não podem removê-los, portanto, você está comprometido com o período de retenção definido. A deduplicação, a manutenção da camada imutável em armazenamento de objetos (mais barato que o armazenamento em blocos) e as classes de armazenamento frio para retenção prolongada mantêm o custo sob controle — e uma camada imutável de 30 dias é pequena em comparação com o custo médio de recuperação de ransomware de 1,7 milhão de dólares relatado no relatório "Sophos State of Ransomware 2026".