<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=238571769679765&amp;ev=PageView&amp;noscript=1">
  • Não há sugestões porque o campo de pesquisa está em branco.

⏱ 9 min de leitura

📌 EM RESUMO

Object Lock é o recurso da API S3 que torna objetos imutáveis seguindo o modelo WORM (Write Once Read Many): uma vez gravado, o objeto não pode ser alterado nem apagado até o fim de um período de retenção. É o padrão da indústria para proteger backups contra ransomware, porque nem um administrador comprometido nem o próprio atacante conseguem destruir os dados travados. Tecnicamente, o Object Lock exige que o versionamento esteja habilitado no bucket e opera em dois modos: Compliance, o mais rígido, em que ninguém (nem a conta root) consegue remover ou encurtar a proteção até a retenção expirar; e Governance, mais flexível, em que usuários com permissão especial podem alterar, útil para ambientes que precisam de exceções controladas. A proteção pode ser definida por um período de retenção (uma data ou duração até quando o objeto fica imutável) ou por um legal hold (uma trava indefinida, sem data de expiração, removida apenas manualmente por quem tem permissão). É possível aplicar o Object Lock objeto a objeto ou definir uma retenção padrão para todo o bucket. O Object Storage S3 da EVEO tem Object Lock nativo com proteção WORM, em data centers Tier III no Brasil, permitindo manter cópias imutáveis contra ransomware sob jurisdição nacional. Para arquiteto, profissional de segurança ou gestor de TI, este artigo explica como o Object Lock funciona, a diferença entre os modos e como usá-lo.

Quando o assunto é proteger dados contra ransomware, a palavra imutabilidade aparece sempre. Mas como, tecnicamente, o object storage torna um dado imutável? A resposta tem nome: Object Lock. Esse é o recurso da API S3 que implementa a proteção WORM e virou o padrão da indústria para backups invioláveis.

Este artigo explica o que é o Object Lock, como ele funciona por baixo, a diferença entre os modos Compliance e Governance, o papel da retenção e do legal hold, e como usar o recurso na prática.

Antes de começar: este artigo foca no recurso técnico Object Lock (como o S3 implementa imutabilidade: modos, retenção, legal hold). Se você busca entender a estratégia de backup imutável como defesa contra ransomware (por que adotar, o conceito geral), comece pelo conteúdo sobre backup imutável contra ransomware. Aqui, mergulhamos no mecanismo técnico que torna isso possível.

Este artigo é para você se:

  • É arquiteto, profissional de segurança ou administrador de storage
  • Quer entender como o Object Lock funciona tecnicamente
  • Precisa decidir entre os modos Compliance e Governance
  • Configura imutabilidade para backups ou compliance
  • Avalia object storage com Object Lock para proteção anti-ransomware

Neste artigo:

  1. O que é Object Lock
  2. O modelo WORM e por que protege contra ransomware
  3. O pré-requisito: versionamento
  4. Os dois modos: Compliance e Governance
  5. Período de retenção e legal hold
  6. Como usar o Object Lock na prática
  7. Object Lock nativo no Object Storage S3 da EVEO
  8. Perguntas frequentes

O que é Object Lock

Object Lock Object Lock é o recurso da API S3 que torna objetos imutáveis seguindo o modelo WORM (Write Once Read Many): uma vez gravado, o objeto não pode ser alterado nem apagado até o fim de um período de retenção definido. Tornou-se o padrão da indústria para proteger backups contra ransomware, porque impede que tanto um administrador comprometido quanto o próprio atacante destruam os dados travados. Tecnicamente, o Object Lock exige que o versionamento esteja habilitado no bucket e opera em dois modos: Compliance, o mais rígido, em que ninguém (nem a conta root) consegue remover ou encurtar a proteção até a retenção expirar; e Governance, mais flexível, em que usuários com permissão especial podem alterar a proteção, útil para exceções controladas. A imutabilidade pode ser definida por um período de retenção (uma data ou duração até quando o objeto fica protegido) ou por um legal hold (uma trava indefinida, sem data de expiração, removida apenas manualmente). É possível aplicar o Object Lock objeto a objeto ou configurar uma retenção padrão para todo o bucket. Diversos provedores de object storage compatível com S3 implementam Object Lock nativo, permitindo cópias imutáveis contra ransomware.

Object Lock é o recurso da API S3 que torna objetos imutáveis. Em termos práticos, ele permite que você grave um objeto e garanta que, a partir dali, ninguém poderá alterá-lo ou apagá-lo até o fim de um período de retenção que você define.

O nome técnico do que ele implementa é WORM (Write Once Read Many): escreve uma vez, lê muitas. É um conceito antigo de armazenamento (existia em mídias físicas como discos ópticos), trazido para o mundo do object storage moderno via API. O Object Lock é a forma como o S3, e os provedores compatíveis com S3, oferecem essa garantia.

O recurso virou central na defesa contra ransomware porque ataca o ponto fraco dos backups tradicionais: a possibilidade de serem apagados ou criptografados. Para entender a API S3 que sustenta esse recurso, vale o conteúdo sobre o que é a API S3 e por que virou o padrão.

O modelo WORM e por que protege contra ransomware

Para entender por que o Object Lock é tão eficaz, é preciso entender como o ransomware moderno opera. Os ataques evoluíram: não miram apenas os dados de produção, mas caçam ativamente os backups, porque sabem que um backup intacto torna o resgate desnecessário.

Em um ataque sofisticado, o invasor frequentemente obtém credenciais privilegiadas (acesso de administrador). Com isso, em um backup tradicional, ele pode apagar ou criptografar as cópias de segurança antes de atacar a produção. Quando a empresa percebe, não há para onde voltar.

É aqui que o WORM muda o jogo. Um objeto protegido por Object Lock não pode ser alterado nem apagado durante o período de retenção, e essa regra vale para todos, inclusive para quem tem acesso de administrador. Mesmo que o atacante comprometa as credenciais mais poderosas, ele encontra uma cópia que simplesmente não aceita ser destruída. A imutabilidade é imposta pela infraestrutura de storage, não por permissões que podem ser burladas.

Essa é a diferença entre uma cópia protegida por permissões (que um administrador comprometido pode remover) e uma cópia imutável (que ninguém pode tocar até a retenção expirar). Para entender como o ransomware atua, vale o conteúdo sobre principais tipos de ransomware.

O pré-requisito: versionamento

Um detalhe técnico essencial: o Object Lock depende do versionamento estar habilitado no bucket. Não dá para ativar imutabilidade sem versionamento ligado.

A razão é a forma como o object storage gerencia mudanças. Com versionamento, cada alteração em um objeto cria uma nova versão, em vez de sobrescrever a anterior. O Object Lock protege versões específicas dos objetos. Quando uma versão está travada, ela permanece intacta e recuperável, mesmo que novas versões sejam criadas ou que alguém tente apagar.

Na prática, isso significa que ativar o Object Lock geralmente envolve habilitar o versionamento primeiro (em muitos provedores, ativar Object Lock na criação do bucket já liga o versionamento automaticamente). O versionamento é o alicerce sobre o qual a imutabilidade se apoia. Esse mecanismo será detalhado no artigo dedicado a versionamento no S3.

Os dois modos: Compliance e Governance

O Object Lock oferece dois modos de proteção, com níveis diferentes de rigidez. Entender a diferença é o ponto mais importante para usar o recurso corretamente.

Modo Compliance (conformidade)

É o modo mais rígido. Quando um objeto está protegido em modo Compliance, ninguém consegue remover a proteção, encurtar o período de retenção ou apagar o objeto até a retenção expirar. E ninguém significa ninguém: nem usuários com permissões máximas, nem a conta root da organização.

Esse modo existe para cenários onde a imutabilidade precisa ser absoluta e auditável, como requisitos regulatórios que exigem que dados sejam preservados por um período legal sem qualquer possibilidade de adulteração. É a escolha para proteção máxima contra ransomware e para compliance estrito, mas exige cuidado: uma vez travado em Compliance, não há volta até o prazo acabar.

Modo Governance (governança)

É o modo mais flexível. A proteção funciona da mesma forma para usuários comuns (não podem alterar nem apagar), mas usuários com uma permissão especial e explícita podem modificar a retenção ou remover a proteção quando necessário.

Esse modo é útil quando a empresa quer a proteção da imutabilidade no dia a dia, mas precisa manter a capacidade de fazer exceções controladas, por exemplo, corrigir um erro de configuração ou liberar dados após uma revisão autorizada. A proteção continua forte contra ataques e erros acidentais, mas existe uma válvula de escape para quem tem autoridade explícita.

Período de retenção e legal hold

O Object Lock define a duração da imutabilidade de duas formas, que podem ser usadas juntas:

Período de retenção (retention period)
É uma data ou duração específica até quando o objeto fica imutável. Você define, por exemplo, que um backup ficará protegido por 90 dias. Durante esse prazo, o objeto não pode ser alterado nem apagado (conforme o modo escolhido). Quando o período expira, a proteção é liberada e o objeto pode ser gerenciado normalmente. É a forma mais comum, usada para políticas de retenção de backup.
Legal hold (retenção legal)
É uma trava indefinida, sem data de expiração. Um objeto sob legal hold permanece imutável até que alguém com permissão remova explicitamente a trava. É independente do período de retenção: um objeto pode ter os dois ao mesmo tempo. O legal hold é usado em situações como litígios, investigações ou auditorias, em que os dados precisam ser preservados por tempo indeterminado, até que a necessidade legal acabe.

A combinação dos dois dá controle fino. Você pode ter uma política de retenção padrão (90 dias, por exemplo) e, sobre objetos específicos relevantes para um processo judicial, aplicar um legal hold que os mantém intactos além do prazo normal, até a liberação manual.

Como usar o Object Lock na prática

A aplicação do Object Lock segue alguns passos e decisões:

1. Habilite o Object Lock no bucket. Em geral, isso é feito na criação do bucket (muitos provedores não permitem ativar em buckets existentes, justamente para garantir a integridade). Ativar o Object Lock liga o versionamento automaticamente.

2. Defina o modo e a retenção padrão. Você pode configurar uma retenção padrão para o bucket (todos os objetos novos herdam aquela proteção) ou aplicar proteção objeto a objeto. Escolha entre Compliance e Governance conforme a necessidade de rigidez.

3. Integre com sua ferramenta de backup. Ferramentas modernas de backup (Veeam, Commvault, Veritas e outras) suportam Object Lock nativamente. Elas gravam os backups já com a proteção de imutabilidade aplicada, o que automatiza a defesa anti-ransomware. Você configura a política na ferramenta, e ela cuida de travar cada backup.

4. Aplique legal hold quando necessário. Para casos específicos (litígio, auditoria), aplique o legal hold sobre os objetos relevantes, e remova quando a necessidade acabar.

Na prática, o uso mais comum em empresas é a combinação de Object Lock com a ferramenta de backup: a política de imutabilidade é definida uma vez, e cada backup gravado já nasce protegido. Isso cumpre a camada de imutabilidade da regra 3-2-1-1-0. Para entender o framework completo, vale o conteúdo sobre backup 3-2-1-1-0.

Object Lock nativo no Object Storage S3 da EVEO

O Object Storage S3 da EVEO tem Object Lock nativo, com proteção WORM que mantém os dados imutáveis contra ransomware. Como a solução é compatível com a API S3, o recurso funciona com as ferramentas de backup que o mercado já usa (Veeam, Commvault, Veritas, Restic, MSP360): você define a política de imutabilidade na ferramenta e os backups nascem protegidos.

O diferencial está em combinar essa proteção técnica com vantagens de custo e soberania:

  • Object Lock nativo: proteção WORM imposta pela infraestrutura, inviolável durante a retenção.
  • Soberania: backups imutáveis em data centers Tier III no Brasil (Cotia/SP, Osasco/SP, Curitiba/PR, Fortaleza/CE) mais Miami/FL, sob jurisdição nacional.
  • Sem egress fee: recuperar os dados em um desastre não gera custo de saída, ao contrário das nuvens públicas.
  • Sem cobrança por API: as operações não pesam na fatura.
  • Custo previsível: a partir de R$ 0,05 por GB, com replicação geográfica em duas regiões.
  • Suporte em português 24/7: ajuda especializada para configurar a imutabilidade na sua arquitetura.

Para empresas que precisam de backups invioláveis contra ransomware sem a imprevisibilidade de custo das nuvens globais, a combinação de Object Lock nativo com soberania nacional entrega proteção completa.

No fim, o Object Lock é o mecanismo que transforma a promessa de imutabilidade em garantia técnica real. Entender a diferença entre Compliance e Governance, o papel da retenção e do legal hold, é o que separa uma configuração que realmente protege de uma que só parece proteger. Contra o ransomware moderno, que caça os backups, a imutabilidade imposta pela infraestrutura é a linha de defesa que não pode ser burlada.

Perguntas frequentes sobre Object Lock

O que é Object Lock no S3?

Object Lock é o recurso da API S3 que torna objetos imutáveis seguindo o modelo WORM (Write Once Read Many). Uma vez gravado, o objeto não pode ser alterado nem apagado até o fim de um período de retenção definido, nem mesmo por administradores. É o padrão da indústria para proteger backups contra ransomware, porque impede que um atacante com credenciais privilegiadas destrua as cópias de segurança.

Qual a diferença entre os modos Compliance e Governance?

No modo Compliance, ninguém consegue remover a proteção ou apagar o objeto até a retenção expirar, nem mesmo a conta root, sendo o modo mais rígido e irreversível. No modo Governance, usuários com permissão especial e explícita podem alterar a retenção ou remover a proteção, oferecendo flexibilidade para exceções controladas. Compliance é para imutabilidade absoluta e compliance estrito; Governance é para proteção robusta com válvula de escape autorizada.

Object Lock precisa de versionamento habilitado?

Sim. O Object Lock depende do versionamento estar habilitado no bucket, porque protege versões específicas dos objetos. Em geral, ativar o Object Lock na criação do bucket liga o versionamento automaticamente. Não é possível ter imutabilidade sem versionamento, que é o alicerce técnico sobre o qual a proteção se apoia.

O que é legal hold no Object Lock?

Legal hold é uma trava de imutabilidade indefinida, sem data de expiração. Um objeto sob legal hold permanece imutável até que alguém com permissão remova explicitamente a trava, independentemente de qualquer período de retenção. É usado em situações como litígios, investigações ou auditorias, em que os dados precisam ser preservados por tempo indeterminado. Pode ser combinado com um período de retenção sobre o mesmo objeto.

Object Lock protege mesmo contra ransomware?

Sim, e é uma das proteções mais eficazes. Como a imutabilidade é imposta pela infraestrutura de storage, e não por permissões, um objeto travado não pode ser alterado nem apagado durante a retenção, mesmo que o atacante comprometa credenciais de administrador. Isso garante uma cópia intacta para restauração, eliminando a necessidade de pagar resgate. Para proteção completa, o Object Lock deve fazer parte de uma estratégia mais ampla, como a regra 3-2-1-1-0.