A compatibilidade com a API S3 facilita a migração entre provedores, mas não garante que os mesmos controles de segurança da Amazon S3 estejam disponíveis ou funcionem da mesma forma. Uma análise da Wiz encontrou diferenças relevantes em acesso público, credenciais, IAM e políticas de buckets em seis serviços S3 compatíveis oferecidos por neoclouds.
A promessa de compatibilidade com o Amazon S3 é atraente para empresas que querem reduzir dependência de um único provedor. Em teoria, aplicações desenvolvidas para utilizar a API S3 poderiam migrar para outro serviço com poucas alterações.
O problema é que compatibilidade de API não significa equivalência de segurança.
# publicidade
Uma aplicação pode continuar funcionando normalmente depois de migrada e, ainda assim, perder mecanismos importantes de proteção. Para equipes que trabalham com dados sensíveis, inteligência artificial, backups ou cargas de trabalho em produção, essa diferença pode representar um risco significativo.
O que a pesquisa da Wiz descobriu
A Wiz analisou seis provedores de armazenamento S3 compatíveis: Nebius, Crusoe, Vultr, Lambda Labs, Cloudflare R2 e DigitalOcean.
A investigação avaliou aspectos como acesso público, listagem anônima de objetos, credenciais, controles de acesso e modelos de permissões.
Os resultados mostraram que os serviços apresentam diferenças importantes, mesmo quando utilizam a mesma interface de programação.
Em alguns casos, determinadas funcionalidades de segurança simplesmente não existem. Em outros, elas existem, mas apresentam comportamento diferente daquele esperado por quem já conhece a AWS.
Isso cria um problema particularmente perigoso: o desenvolvedor pode aplicar corretamente um conceito aprendido na AWS e ainda assim obter um resultado diferente em outro provedor.
As principais diferenças encontradas incluem:
Controles diferentes para acesso público aos buckets.
Ausência ou implementação parcial de mecanismos semelhantes ao Block Public Access.
Modelos de IAM com diferentes níveis de granularidade.
Formatos de credenciais que podem dificultar a detecção automática de segredos.
Comportamentos diferentes para determinadas chamadas da API.
Suporte desigual a ACLs e bucket policies.
Compatibilidade de API não significa segurança equivalente
A API S3 se tornou praticamente um padrão de mercado para armazenamento de objetos.
Isso facilita muito a vida dos desenvolvedores. Uma aplicação pode utilizar bibliotecas e ferramentas já conhecidas sem precisar ser completamente reescrita para cada provedor.
Porém, o S3 é muito mais complexo do que um conjunto de operações básicas para enviar e baixar arquivos.
Existem centenas de APIs e funcionalidades relacionadas ao ecossistema de armazenamento da AWS, resultado de décadas de evolução do serviço.
Um provedor pode implementar as operações mais utilizadas e ainda assim não reproduzir todo o conjunto de controles, políticas e mecanismos de segurança existentes no Amazon S3.
É justamente aí que surge a falsa sensação de portabilidade.
Se a aplicação funciona com S3, isso não significa que ela possui o mesmo nível de proteção que teria na AWS.
O problema dos controles de acesso público
Um dos pontos mais importantes observados pela pesquisa envolve o acesso público.
Na AWS, equipes podem utilizar mecanismos específicos para impedir configurações acidentais que exponham buckets e objetos na internet.
Em provedores compatíveis, esse comportamento pode ser diferente.
A pesquisa encontrou, por exemplo, serviços que não oferecem acesso público, enquanto outros permitem buckets públicos com diferentes níveis de restrição.
A diferença pode parecer pequena durante o desenvolvimento, mas se torna crítica quando uma aplicação depende de políticas específicas para controlar quem pode acessar determinado objeto.
Comparação das capacidades de segurança
Serviço | Acesso público | Listagem anônima | Block Public Access |
|---|---|---|---|
Amazon S3 | Sim | Configurável | Sim |
Nebius | Sim | Não | Parcial |
Cloudflare R2 | Sim | Não | Parcial |
DigitalOcean | Sim | Sim | Limitado |
Vultr | Sim | Configurável | Limitado |
Crusoe | Não | Não | N/A |
Lambda Labs | Não | Não | N/A |
Arraste para o lado para ver toda a tabela.
O ponto mais importante não é qual provedor possui mais recursos, mas entender que o comportamento não é uniforme. Uma política considerada segura em um ambiente pode não produzir o mesmo resultado em outro.
Credenciais também podem criar um problema
Outro ponto relevante está nas chaves de acesso.
Na AWS, os formatos de credenciais são amplamente reconhecidos por ferramentas de segurança, scanners de código e plataformas de proteção contra vazamento de segredos.
Em implementações S3 compatíveis, entretanto, as credenciais podem utilizar formatos diferentes.
Isso pode dificultar a identificação automática de uma chave exposta em um repositório Git, por exemplo.
Imagine um desenvolvedor que acidentalmente publica uma credencial em um arquivo de configuração:
AWS_ACCESS_KEY_ID=...AWS_SECRET_ACCESS_KEY=...
Ferramentas de segurança podem reconhecer determinados padrões associados à AWS.
Se o provedor utilizar um formato diferente, a mesma ferramenta pode não identificar o segredo.
A compatibilidade com a API não garante compatibilidade com todo o ecossistema de segurança construído ao redor dela.
O risco de confiar demais no conhecimento da AWS
Um dos problemas mais perigosos para equipes experientes é justamente o conhecimento prévio.
Um desenvolvedor que trabalha há anos com Amazon S3 já possui expectativas sobre como determinadas operações funcionam.
Ao migrar para um serviço compatível, ele pode presumir que essas mesmas operações produzirão os mesmos efeitos.
Nem sempre isso acontece.
A pesquisa cita inclusive um caso em que uma chamada equivalente a delete-bucket-policy apresentou um comportamento inesperado, chegando a excluir o bucket.
Esse tipo de divergência demonstra por que testar apenas a compatibilidade funcional não é suficiente.
Uma aplicação pode passar por todos os testes tradicionais de upload, download e exclusão de objetos e ainda possuir problemas de segurança ou comportamento em operações menos comuns.
O que isso muda para projetos de IA
O alerta é especialmente relevante para aplicações de inteligência artificial.
Projetos de IA frequentemente trabalham com grandes volumes de dados armazenados em object storage, incluindo:
Datasets para treinamento.
Documentos utilizados por sistemas RAG.
Embeddings e vetores.
Logs de agentes.
Arquivos enviados por usuários.
Modelos e checkpoints.
Resultados de processamento.
Dados utilizados em pipelines de machine learning.
Em uma arquitetura desse tipo, um bucket mal configurado pode expor muito mais do que simples arquivos.
Um único erro de permissão pode revelar documentos utilizados para treinamento, informações de clientes ou dados internos utilizados como contexto por agentes de IA.
Por isso, migrar uma aplicação de AWS para uma neocloud apenas porque ela "suporta S3" exige uma avaliação mais profunda.
Quais provedores foram analisados?
A pesquisa da Wiz analisou:
Nebius
Crusoe
Vultr
Lambda Labs
Cloudflare R2
DigitalOcean
A análise não incluiu outros provedores relevantes, como Backblaze B2, Wasabi e Google Cloud Storage.
Isso é importante porque o estudo não representa todo o mercado de armazenamento compatível com S3.
O próprio ecossistema possui dezenas de implementações diferentes. Portanto, não é possível utilizar os resultados de um provedor para presumir como outro funcionará.
Cada implementação precisa ser validada individualmente.
Como avaliar um serviço S3 compatível antes de colocá-lo em produção
A melhor abordagem é abandonar a ideia de que "compatível com S3" significa "seguro como S3".
Antes de migrar uma aplicação, a equipe deve testar diretamente os recursos utilizados pelo projeto.
1. Teste as políticas de acesso
Verifique como o provedor trata:
Buckets privados.
Buckets públicos.
Objetos públicos.
Listagem anônima.
ACLs.
Bucket policies.
Políticas de usuário.
Permissões negativas ou explícitas.
Não presuma que uma política utilizada na AWS terá exatamente o mesmo comportamento.
2. Teste as credenciais
Avalie:
Formato das chaves.
Rotação de credenciais.
Expiração.
Revogação.
Permissões.
Integração com ferramentas de secret scanning.
Também é importante verificar se ferramentas utilizadas pela empresa conseguem identificar credenciais específicas daquele provedor.
3. Crie testes de integração
Em vez de validar apenas se o upload funciona, teste cenários de segurança.
Por exemplo:
Usuário sem permissão → não pode listar bucketUsuário sem permissão → não pode baixar objeto
Objeto privado → não pode ser acessado anonimamente
Credencial revogada → requisição deve falhar
Bucket privado → URL pública não deve funcionar
Esse tipo de teste pode ser executado automaticamente no CI/CD.
4. Teste operações críticas manualmente
Para operações de alto impacto, vale realizar testes controlados antes de colocar o serviço em produção.
Isso é particularmente importante para operações de exclusão, alteração de políticas e gerenciamento de permissões.
5. Não dependa apenas da documentação
A documentação informa o comportamento esperado.
Os testes mostram o comportamento real.
Para uma infraestrutura crítica, os dois são necessários.
A compatibilidade S3 deve ser tratada como uma camada, não como uma garantia
O principal aprendizado da análise da Wiz é que S3 virou uma interface de interoperabilidade, não uma certificação de segurança.
Do ponto de vista do desenvolvedor, isso muda bastante a maneira de avaliar uma neocloud.
Em vez de perguntar:
"Esse provedor é compatível com S3?"
A pergunta deveria ser:
"Quais recursos S3 minha aplicação utiliza e como cada um deles se comporta neste provedor?"
Essa mudança de perspectiva é importante porque reduz o risco de transportar pressupostos de segurança de uma plataforma para outra.
O que desenvolvedores e empresas devem fazer
Para projetos novos, o ideal é criar uma matriz de compatibilidade antes de escolher o provedor.
Para projetos existentes, a recomendação é revisar as políticas e os testes antes de realizar uma migração.
Uma estratégia prática inclui:
Mapear todas as funcionalidades S3 utilizadas pela aplicação.
Comparar o comportamento entre AWS e o novo provedor.
Testar permissões e cenários de acesso público.
Validar o formato e a detecção das credenciais.
Automatizar testes de segurança no CI/CD.
Monitorar alterações de políticas e permissões.
Revisar periodicamente a configuração dos buckets.
S3 compatível é ótimo para portabilidade, mas exige validação
A compatibilidade com S3 continua sendo uma vantagem enorme para desenvolvedores.
Ela permite que empresas aproveitem bibliotecas, SDKs e ferramentas existentes e reduz o custo de migração entre plataformas.
O problema aparece quando essa compatibilidade é confundida com equivalência arquitetural.
Uma API compatível pode esconder modelos de segurança completamente diferentes.
Para empresas que utilizam neoclouds em aplicações de IA, dados corporativos ou sistemas críticos, essa distinção precisa fazer parte da arquitetura desde o início.
No fim, a pergunta não deve ser apenas se o serviço consegue armazenar os mesmos objetos.
A pergunta mais importante é:
ele consegue proteger esses objetos da mesma maneira que sua aplicação espera?
Essa é a diferença entre simplesmente migrar uma aplicação e migrar uma infraestrutura com segurança.
