Compatibilidade com S3 não significa segurança igual à do S3, alerta a Wiz

Uma pesquisa da Wiz colocou lado a lado o object storage de seis neoclouds que se dizem compatíveis com o Amazon S3 e chegou a uma conclusão incômoda para quem migra por preço: compatibilidade de API não é compatibilidade de segurança. O S3 virou o padrão de fato para armazenamento de objetos, mas a maioria dos clones não reproduz as proteções que a AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → acumulou ao longo de mais de 20 anos.

O que foi testado

O estudo, conduzido por Scott Piper, principal cloud security researcher da Wiz, comparou os serviços gerenciados de Nebius, Crusoe, Vultr, Lambda Labs, Cloudflare R2 e DigitalOcean com o Amazon S3. A tese central de Piper é que a compatibilidade com S3 cria uma falsa sensação de portabilidade perigosa. Nas palavras dele:

Existem quase 300 APIs associadas ao AWS S3 e aos serviços relacionados (como S3 tables, S3 vectors, S3 express e mais). Todo tipo de funcionalidade especializada foi adicionada ao S3 ao longo de mais de 20 anos de existência. Como era de se esperar, nem toda essa funcionalidade foi replicada, e alguns desses clones de S3 funcionam de maneiras inesperadas.

Ou seja: a memória muscular de quem opera S3 na AWS acompanha o dev quando ele muda de provedor, mas o comportamento por trás dos mesmos comandos não.

Buckets públicos: cada um faz de um jeito

O tratamento de buckets públicos varia bastante entre os serviços. Segundo o estudo, Crusoe e Lambda Labs sequer têm recurso de acesso público. Já Nebius e Cloudflare R2 permitem buckets públicos, mas não listagem anônima de objetos. DigitalOcean suporta buckets publicamente listáveis, e Vultr aceita tanto ACLs quanto bucket policies para acesso público.

O ponto sensível é que quase nenhum oferece algo equivalente ao Block Public Access da AWS, o mecanismo que a Amazon adicionou justamente para conter os vazamentos crônicos de buckets abertos por engano. Quem constrói assumindo que existe uma trava global de bloqueio de acesso público pode simplesmente não tê-la.

Chaves de acesso que passam despercebidas

Outro problema afeta diretamente quem versiona credenciais por descuido. Os serviços S3-compatíveis costumam não seguir os formatos estruturados de access key da AWS, o que dificulta a detecção tanto por times de segurança quanto por ferramentas como o secret scanning do GitHub. Piper explica:

Há outras credenciais detectadas pelo GitHub para DigitalOcean e Cloudflare via secret scanning, mas não essas. Essas credenciais dos serviços S3-compatíveis também não são comumente encontradas por outros secret scanners. Parte do motivo é que algumas nem têm padrões que possam ser usados para identificá-las.

Na prática, uma chave da AWS vazada num commit tende a disparar alerta automático; a chave equivalente de um clone pode ficar exposta sem que nenhuma ferramenta perceba.

Quando o comando faz outra coisa

As diferenças de IAM entre implementações já produziram vulnerabilidades reais. O texto cita uma falha no MinIO que permitia escalação de privilégio não autorizada e uma no RustFS que quebrava o isolamento entre tenants e a semântica de autorização.

O exemplo mais didático veio de Corey Quinn, chief cloud economist do The Duckbill Group, em sua newsletter:

Todo neocloud entrega um endpoint compatível com S3, e sua memória muscular segue você para lá, quer as APIs se comportem ou não. Em um deles, delete-bucket-policy apagou o bucket inteiro. Vale a leitura antes de assumir que Block Public Access existe.

Um aws s3api delete-bucket-policy que, em vez de remover a policy, destrói o bucket com os objetos dentro é o tipo de surpresa que nenhum runbook de AWS prepara.

Presigned URLs: o que todos herdam

Como os presigned URLs fazem parte da própria API do S3, todos os clones os suportam, junto com as implicações de segurança associadas. Rishi Raj Singh, senior solutions engineer da Wiz, resumiu no LinkedIn a recomendação operacional:

Se você usa storage S3-compatível em neoclouds, garanta que seu time esteja explicitamente auditando o comportamento das APIs, verificando os modelos de permissão e validando o que acontece quando as ferramentas padrão da AWS interagem com esses endpoints.

O que isso muda para quem constrói no Brasil

A pressão por corte de custos empurra muitas empresas brasileiras para provedores S3-compatíveis, seja para reduzir gasto em dólar, seja por soberania de dados com storage hospedado localmente. O risco é adotar o endpoint compatível e reaproveitar tal e qual as práticas de segurança pensadas para a AWS: policies de bucket, expectativa de secret scanning, confiança no bloqueio de acesso público.

Na prática, antes de mover dados sensíveis vale testar em ambiente controlado como cada comando destrutivo se comporta, confirmar se existe algo equivalente ao Block Public Access, e não depender de detecção automática de credencial vazada para as chaves desses serviços. A auditoria de comportamento de API, e não só de configuração, passa a ser parte do checklist de migração.

O que fica em aberto

O levantamento da Wiz não cobre outras implementações relevantes, como Backblaze B2, Wasabi e Google Cloud Storage. O universo é grande: o diretório de provedores S3-compatíveis lista mais de 90 opções, e o projeto Awesome Object Storage compara 21 provedores entre hyperscalers, alternativas, edge/CDN, self-hosted e descentralizados. Ou seja, o mapa de quais clones reproduzem quais proteções ainda está longe de completo, e cada provedor fora da lista exige a mesma verificação caso a caso.

Fonte: InfoQ