Uma análise da empresa de segurança de nuvem Wiz em seis "neoclouds", provedores de nuvem alternativos que anunciam compatibilidade com o padrão S3, mostrou que compatibilidade de API não é o mesmo que paridade de segurança. Os resultados apontam lacunas importantes em proteções que os usuários da AWS já tratam como básicas.
Resposta rápida: dizer que a API é compatível com o S3 não faz desses serviços seguros como o S3 da AWS. A Wiz encontrou diferenças em acesso público, chaves de acesso sem formato padronizado para detecção por ferramentas de segredo, e controles de identidade mais frágeis. O alerta principal é para equipes que pretendem migrar achando que tudo virá igual.
# publicidade
Leia também
Como funciona a cadeia de um data center
O que a pesquisa encontrou
A análise da Wiz examinou como cada provedor lida com acesso público a buckets, formato de chaves de acesso e permissões de identidade e acesso (IAM). As diferenças se organizam em três frentes: em publicação de bucket, alguns não oferecem bloqueio de exposição pública apropriado, semelhante ao Block Public Access da AWS; em chaves de acesso, cada provedor usa formato próprio, e a chave vazada não é reconhecida por ferramentas de scanner, como o GitHub, que esperam o padrão da AWS; e em IAM, há casos de propriedades não implementadas ou que se comportam de forma distinta da esperada.
O que torna isso realmente problemático
Empresas adotam serviços compatíveis com S3 em busca de custo, latência ou soberania de dado. O perigo cresce quando a infraestrutura compartilha as mesmas chamadas de API que os times aprenderam na AWS, onde os padrões de segurança são mais maduros e bem documentados. Se você executa o mesmo comando em um sistema que não carrega os mesmos padrões de proteção, cria um modelo mental incorreto e, com ele, um risco sistemático. O relatório cita duas vulnerabilidades reais, uma no MinIO de escalação de privilégio e outra recente no RustFS, que quebram isolamento ou autorização, cenários de alto risco em produção.
A falsa sensação de portabilidade
É tentador tratar compatibilidade de API como permissão para sair da AWS sem custo de aprendizado. Corey Quinn, economista-chefe de nuvem da Duckbill Group, resumiu o fenômeno em sua newsletter: a memória muscular do utilizador vai junto, mesmo se as APIs funcionam ou não. A pesquisa da Wiz documenta que isso falha na prática: na mesma operação, um provedor tem comportamento esperado de delete-bucket-policy; outro remove o bucket inteiro.
# publicidade
Além da operação frustrada, contam as faltas de extensões. O padrão S3 da AWS evolui além da API básica, com tabelas S3, vetores S3 e express S3, e cada capability nova exige que o provedor clone implemente comportamento próprio. As assinaturas de URL pré-assinadas, amplamente usadas, carregam uma semântica de segurança que muda de provider para provider e exige validação real em cada um.
Como essa lacuna se conecta à LGPD
O ponto de atrito com o Brasil é o seguinte: um bucket mal configurado com dados pessoais não é só incidente de segurança tecnológica, mas também questão de conformidade da LGPD. A exposição indevida traz custo regulatório e reputacional, e a escolha de serviços compatíveis com S3 sem auditoria própria de segurança pode gerar responsabilidade que as equipes de TI não esperavam. A ponte com essa camada regulatória está mais desenvolvida no texto sobre Brasil e no editoria de cibersegurança, e a comparação de provedores alternativos continua em cloud e infraestrutura.
O que fazer antes de adotar
Como recomenda o estudo, o caminho seguro é simples: antes de confiar dados reais a um provedor compatível com S3, audite explicitamente o comportamento da API, os modelos de permissão e as diferenças de segurança em relação à AWS. O checklist inclui testar como bloqueios de acesso público operam de verdade, como são formatadas as chaves de acesso, quais ferramentas de varredura de segredos funcionam com eles, o que acontece quando as operações destrutivas são chamadas, e se há diferenças de semântica nas assinaturas pré-assinadas. Cada item confere uma peça do padrão que você está adotando de fato.
⚠️ Atenção: compatibilidade de API não implica segurança equivalente. Antes de confiar dados a um provedor alternativo, audite o comportamento real do serviço, teste operações destrutivas e valide a exposição a buckets públicos.
O que fica de fora e o que muda para o Brasil
O levantamento da Wiz cobriu determinados players e não inclui outros provedores que também anunciam compatibilidade com S3. Portanto, a pesquisa não é censo, mas a conclusão geral se mantém: a API não carrega automaticamente a proteção padrão da AWS. Para empresas brasileiras, a orientação final é projetar a política de segurança do storage como propriedade do provedor, e não como herdada do comando S3.
Perguntas frequentes
Compatibilidade com API S3 garante segurança equivalente?
Não. A pesquisa da Wiz mostra que muitos provedores implementam a chamada de API, mas não dispõem dos mesmos controles internos (bloqueio de acesso público, formato de chaves, modelos de IAM) da AWS.
Quais foram as falhas concretas identificadas?
Entre os exemplos citados estão: ausência de bloqueio de acesso público em vários provedores, chaves de acesso fora do formato detectável por scanners de segredo, e vulnerabilidades específicas de escalonamento de privilégio no MinIO e de quebra de isolamento de tenants no RustFS.
Por que isso afeta empresas brasileiras?
Porque exposição de dados pessoais em bucket público ou mal configurado viola a LGPD e cria risco regulatório junto ao risco técnico.
O que fazer antes de migrar para um clone do S3?
Auditar a API na prática, testar como configurar bloqueio de acesso público se comporta, confirmar formato de chaves, validar ferramentas de detecção de segredo e certificar-se de que operações destrutivas funcionam como você espera.
