Coisas sobre o S3 que você preferia não precisar saber

A criptografia de buckets do AWS S3 não é tão simples quanto parece

Opções de criptografia do S3

• Criptografia no lado do servidor (SSE-S3): criptografa os dados usando chaves gerenciadas pela AWS.
• Criptografia no lado do servidor (SSE-KMS): criptografa os dados usando o AWS Key Management Service (KMS).
• Criptografia no lado do servidor (SSE-C): criptografa os dados usando chaves fornecidas pelo usuário.
• Criptografia no lado do cliente: o usuário criptografa diretamente os dados antes de fazer o upload.

Diferença entre criptografia e controle de acesso

• Criptografia: processo de transformar os dados para protegê-los.
• Controle de acesso: política que determina quem pode acessar os dados.
• Na prática, a criptografia do S3 se aproxima mais de controle de acesso, com foco maior na gestão de permissões do que na proteção dos dados.

Por que isso é importante

• Segurança: a criptografia pode proteger os dados mesmo em caso de vazamento.
• Conformidade: a criptografia pode ser necessária para atender regulações setoriais específicas ou exigências legais.
• Integridade dos dados: a criptografia garante que os dados não foram adulterados.

Opinião do GN⁺

• Confusão entre criptografia e controle de acesso: muitas pessoas confundem criptografia com controle de acesso. Este artigo explica claramente essa diferença.
• Nível real de segurança: é preciso ter uma visão crítica sobre o quão seguras são, de fato, as opções de criptografia do S3.
• Tecnologias alternativas: além do S3, também vale considerar outros serviços de armazenamento em nuvem, como Google Cloud Storage e Azure Blob Storage.
• Educação do usuário: é importante que engenheiros iniciantes entendam com clareza a diferença entre criptografia e controle de acesso.
• Pontos a considerar ao adotar a tecnologia: ao adotar tecnologias de criptografia, é preciso considerar fatores como queda de desempenho e aumento de custos.

[GN⁺]

Comentários do Hacker News

• Não concordo com a reclamação sobre sistemas de arquivos diferenciarem maiúsculas de minúsculas. Isso é o esperado, e o incômodo é o macOS não dar suporte a isso.
• Os caminhos do S3 são uma simulação, não diretórios reais. Por exemplo, /builds/1/installer.exe na verdade é um arquivo cujo nome contém /.
• Usar o S3 ou outros serviços da AWS é complexo e a documentação é enorme, então é fácil expor dados por engano. Prefiro serviços mais simples, como Hetzner Storage Boxes ou DigitalOcean Spaces.
• Excluir dezenas de bilhões de objetos pode sair caro. Mas, se você definir um wildcard ou um tempo de expiração para todos os objetos do bucket, pode parar imediatamente de pagar pelo armazenamento sem custo.
• Uploads multipart que falharam podem ficar invisivelmente lá, gerando custo de armazenamento. O nome "Simple" do S3 acaba não fazendo jus.
• Upload multipart não pode ser feito a partir de várias máquinas, e requisições LIST são lentas e caras. A criação de buckets pode não ser consistente.
• O S3 diferencia maiúsculas de minúsculas, e isso pode causar problemas ao converter para uma estrutura de sistema de arquivos.
• A maioria das configurações de S3 permite requisições GET, mas não HEAD. Fluxos que dependem de cache podem não funcionar.
• Se você usa muitas URLs pré-assinadas, é possível melhorar a velocidade de geração das URLs em 10 a 40 vezes.
• É preciso pagar pelo armazenamento de uploads multipart não concluídos. É necessário ativar a exclusão automática.
• A discussão sobre diferenciação entre maiúsculas e minúsculas é centrada demais no inglês.
• O S3 faz uma única conexão TCP ignorar silenciosamente todas as requisições depois de enviar 100 requisições HTTP.
• Um site mal configurado pode enviar conteúdo de usuário para o Amazon Glacier e depois servi-lo mais tarde.
• O S3 não é adequado para servir conteúdo web por causa da alta latência. A latência consistente para objetos pequenos fica entre 100 e 200 milissegundos.