Amazon S3: como armazenar arquivos com segurança e controle de acesso

Um guia prático para configurar buckets privados, definir permissões e integrar uploads e downloads seguros ao seu site.

A segurança no Amazon S3 começa com uma decisão: quais arquivos podem ser publicados e quais precisam permanecer restritos? Em uma área do cliente, uma imagem institucional e um contrato exigem formas diferentes de acesso, mesmo quando ambos são armazenados na nuvem.

Uma configuração adequada combina bucket privado, permissões limitadas, criptografia e autorização no backend. O armazenamento protege os objetos conforme as políticas da AWS; a aplicação decide qual cliente pode receber cada documento.

Neste tutorial, usaremos uma empresa fictícia de Recife que publica imagens no site e disponibiliza contratos em uma área autenticada. Os exemplos são voltados a buckets de uso geral e devem ser adaptados aos recursos do seu projeto.

Como o Amazon S3 armazena arquivos de sites e aplicações

O Amazon S3 é um serviço de armazenamento de objetos. Um bucket funciona como um recipiente; cada objeto reúne o conteúdo de um arquivo e seus metadados. A chave identifica o objeto dentro do bucket.

Por exemplo, um contrato pode ter a chave documentos/cliente-7f3a/contrato-91bc.pdf. O trecho documentos/ é um prefixo: ajuda a organizar os arquivos e pode ser usado em políticas de acesso, mas não cria uma barreira de segurança por si só.

Usar Amazon S3 para sites permite guardar imagens, anexos e documentos fora do servidor da aplicação. O serviço não executa o backend nem substitui o banco de dados responsável por registrar usuários, contratos e vínculos entre clientes e arquivos.

No exemplo, o banco guarda o identificador do documento, seu proprietário e a chave do objeto. O S3 guarda o arquivo. Essa separação permite consultar os documentos de um cliente sem conceder a ele permissão para listar o bucket.

Separar imagens destinadas à publicação e documentos restritos em buckets diferentes facilita a administração. Se o projeto usar apenas um bucket, delimite os prefixos nas políticas e verifique o isolamento na aplicação.

Planeje quem pode acessar cada tipo de arquivo

Antes de configurar o controle de acesso no S3, monte uma matriz de permissões. Ela deve indicar quem pode ler, enviar, substituir e excluir cada categoria de arquivo.

Autenticação identifica quem está usando o site. Autorização determina quais documentos essa pessoa pode acessar. Estar conectado à área do cliente não deve permitir baixar contratos de outros clientes.

O backend precisa consultar o vínculo entre usuário, empresa e documento antes de liberar qualquer operação. Não aceite uma chave de objeto enviada pelo navegador como prova de que o usuário pode acessar aquele arquivo.

Use identificadores internos nos nomes dos objetos e evite CPF, e-mail ou outros dados pessoais desnecessários. Prepare também buckets e identidades separados para desenvolvimento e produção, impedindo que testes utilizem permissões de produção.

Crie um bucket privado e bloqueie o acesso público

Para criar um bucket privado S3, acesse o console do serviço com uma identidade administrativa autorizada. A aplicação terá uma identidade própria, com permissões menores.

1. Escolha um bucket de uso geral e a região. Considere a região do backend, os requisitos do projeto e os custos de armazenamento e transferência.
2. Defina um nome sem informações sensíveis. Registre qual ambiente e finalidade o recurso atende.
3. Mantenha todas as opções de Block Public Access habilitadas. Revise também os controles de bloqueio existentes na conta.
4. Use Object Ownership com Bucket owner enforced. Essa configuração mantém ACLs desativadas e concentra o controle de acesso em políticas.
5. Confira a criptografia padrão. A escolha entre SSE-S3 e SSE-KMS será detalhada adiante.
6. Envie um arquivo de teste sem dados reais. Tente acessar seu endpoint S3 por HTTPS sem assinatura ou credenciais.

A leitura anônima do objeto privado deve ser negada. Faça esse teste com um objeto que você sabe que existe, para não confundir um caminho incorreto com uma proteção validada.

Se a integração retornar AccessDenied, investigue as permissões da identidade utilizada. Desativar o bloqueio público para fazer o upload funcionar pode introduzir uma exposição desnecessária.

Com ACLs desativadas, remova do código parâmetros que tentem enviar arquivos como public-read. A integração deve operar com os controles de acesso definidos nas políticas.

Configure IAM e políticas de bucket com menor privilégio

As permissões IAM para S3 podem ser concedidas por políticas de identidade, associadas a usuários ou roles. Já uma política de bucket S3 fica associada ao recurso e pode definir acesso para determinados principais ou impor restrições.

Priorize roles com credenciais temporárias quando o ambiente permitir. Em serviços AWS compatíveis, associe a role à execução da aplicação. Não inclua chaves secretas no JavaScript entregue ao navegador, no repositório ou em imagens de contêiner.

O exemplo abaixo é uma política de identidade para permitir leitura e envio no prefixo documentos/. Substitua o nome fictício pelo bucket do projeto antes de aplicá-la.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LerEEnviarDocumentos",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::empresa-exemplo-documentos-prod/documentos/*"
    }
  ]
}

s3:GetObject permite ler objetos; s3:PutObject permite enviá-los e também substituir um objeto existente com a mesma chave. Essa política não concede exclusão nem administração do bucket.

A ação s3:ListBucket usa o ARN do bucket, sem /*. Se a aplicação realmente precisar listar objetos, acrescente uma declaração separada e limite a listagem com a condição s3:prefix. Para downloads por chaves já registradas no banco, a listagem pode ser dispensável.

Revise as permissões efetivas da role: outras políticas podem conceder operações ausentes neste exemplo. Uma negação explícita aplicável prevalece sobre uma permissão concedida.

Essa role pode ler todos os documentos do prefixo autorizado. Portanto, ela não isola os clientes da aplicação: o backend continua responsável por verificar a propriedade de cada documento antes de emitir acesso.

Proteja os arquivos com criptografia e HTTPS

A criptografia no Amazon S3 protege os dados armazenados. Novos uploads recebem criptografia em repouso por padrão, mas você deve verificar a configuração do bucket e sua adequação ao projeto.

SSE-S3 utiliza chaves gerenciadas pelo próprio S3 e pode atender a projetos que não precisam administrar uma chave específica. SSE-KMS integra o armazenamento ao AWS KMS; com uma chave gerenciada pelo cliente, oferece controles próprios de acesso e administração da chave.

Para imagens institucionais, SSE-S3 pode ser suficiente. Documentos sujeitos a requisitos específicos de controle de chaves podem justificar SSE-KMS. A classificação como documento privado, isoladamente, não torna KMS obrigatório.

Ao adotar SSE-KMS, planeje custos e permissões. Um envio com PutObject exige kms:GenerateDataKey; a leitura exige kms:Decrypt. Uploads multipart exigem ambas. Revise as políticas IAM e da chave para autorizar somente as identidades necessárias.

Para proteger o transporte, use HTTPS entre navegador, backend e S3. A declaração abaixo pode integrar a política do bucket para negar requisições sem transporte seguro:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NegarTransporteInseguro",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::empresa-exemplo-documentos-prod",
        "arn:aws:s3:::empresa-exemplo-documentos-prod/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Substitua o bucket fictício e incorpore a declaração à política existente, preservando as regras necessárias ao projeto. O curinga em Principal aparece em uma negação: essa declaração não concede acesso público.

Criptografia e autorização resolvem problemas diferentes. Uma identidade autorizada pode receber o conteúdo descriptografado; criptografar um contrato não corrige uma permissão de leitura excessiva.

Use URLs pré-assinadas para uploads e downloads autorizados

Uma URL pré-assinada S3 permite executar uma operação específica sobre um objeto durante um período determinado. O bucket permanece privado, e o navegador não recebe a chave secreta usada para assinar a requisição.

No download de um contrato, o fluxo recomendado é:

1. O cliente se autentica e solicita um documento pelo identificador da aplicação.
2. O backend consulta o documento e confirma que ele pertence ao cliente autorizado.
3. O backend obtém a chave armazenada no banco e gera uma URL para GetObject, com validade de cinco minutos neste exemplo.
4. O navegador usa essa URL para solicitar o arquivo diretamente ao S3.

A identidade que gera a assinatura precisa ter permissão para a operação. A validade também depende das credenciais utilizadas: uma sessão temporária que termina antes do prazo solicitado pode encerrar o acesso antecipadamente.

Trate a URL como um segredo. Quem a possui pode utilizá-la enquanto estiver válida. Ela não é automaticamente vinculada ao usuário da aplicação e não é, por padrão, um link de uso único. Evite registrar a URL completa em logs ou ferramentas de análise.

Como organizar um upload seguro de arquivos

No envio, o backend deve autorizar a operação e escolher uma chave única, em vez de aceitar livremente o caminho informado pelo navegador. Registre o upload como pendente e só disponibilize o documento depois de validar o arquivo recebido.

Uma URL para PutObject pode substituir um objeto com a mesma chave. A geração de identificadores exclusivos reduz sobrescritas acidentais, mas o fluxo também precisa considerar reutilizações da URL durante sua validade.

Defina limites de tamanho e tipos aceitos conforme o mecanismo de upload. Em um POST pré-assinado, a política pode incluir condições como content-length-range. Não presuma que uma URL PUT comum aplica automaticamente os mesmos controles.

Extensão e Content-Type informados pelo cliente não comprovam o conteúdo do arquivo. Verifique o tamanho real, inspecione o formato e aplique análise de conteúdo quando necessária. Mantenha arquivos pendentes fora dos fluxos de download autorizados.

Se o navegador enviar diretamente ao S3, configure CORS para as origens, métodos e cabeçalhos necessários. CORS controla interações entre origens no navegador; não concede permissão de leitura ou envio no bucket.

Entregue imagens do site com CloudFront e origem privada

Arquivos destinados ao público podem ser distribuídos pelo Amazon CloudFront sem tornar o bucket público. Para isso, configure Origin Access Control, conhecido como OAC, em uma origem de bucket S3 compatível.

Use o endpoint do bucket, e não o endpoint de website estático do S3, que não aceita essa integração com OAC. Configure a assinatura de requisições com a opção recomendada de assinar sempre.

Na política do bucket, conceda ao principal de serviço do CloudFront somente a leitura necessária e restrinja a permissão ao ARN da distribuição esperada. Se os arquivos utilizarem SSE-KMS, confira também a autorização na chave.

Essa configuração protege o acesso à origem. Ela não exige, por si só, que os visitantes se autentiquem na distribuição. Imagens institucionais podem ficar disponíveis aos visitantes, enquanto contratos continuam no fluxo autorizado da área do cliente.

Quando a entrega pelo CloudFront também precisar ser restrita, avalie URLs ou cookies assinados do próprio CloudFront. Eles são controles diferentes das URLs pré-assinadas do S3.

A distribuição deve acompanhar o cuidado com tamanho, formato e dimensões das imagens. O artigo sobre como reduzir o tempo de carregamento de uma aplicação web complementa esse planejamento de desempenho.

Prepare auditoria, versionamento e recuperação de arquivos

Além de controlar o acesso, prepare a investigação de incidentes. Para registrar operações sobre objetos, como leitura, envio e exclusão, configure os eventos de dados do CloudTrail para os buckets ou prefixos relevantes.

Esses eventos não são registrados por padrão e não aparecem no histórico comum de eventos do CloudTrail. Defina os seletores necessários, faça uma operação de teste e confirme que o registro foi produzido no destino configurado.

Nos logs da aplicação, registre quem solicitou acesso, qual documento estava envolvido e o resultado da autorização. Isso complementa os registros da AWS, especialmente quando os acessos ao S3 usam uma role compartilhada pelo backend.

Configure alertas para alterações de políticas, bloqueio de acesso público e outros controles críticos. Proteja os registros contra alterações indevidas e determine responsáveis por acompanhar os alertas.

Recupere versões e teste a restauração

O versionamento mantém diferentes versões de um objeto. Após uma sobrescrita, uma identidade autorizada pode recuperar a versão anterior e restaurá-la. Uma exclusão comum em um bucket versionado geralmente cria um marcador de exclusão, sem remover imediatamente as versões anteriores.

Permissões para consultar versões, ler uma versão específica ou remover marcadores devem ficar com a função responsável pela recuperação. A role limitada apresentada anteriormente não recebe essas operações adicionais.

Versionamento isolado não constitui uma estratégia completa de backup: versões podem ser removidas por identidades autorizadas ou por regras de ciclo de vida. Defina retenção, proteção adicional conforme a criticidade e recuperação também do banco de dados.

Teste a restauração de um documento fictício e registre o procedimento. Inclua no orçamento o armazenamento de versões antigas, os eventos de auditoria e as operações de monitoramento.

Valide as permissões antes de colocar a integração em produção

A configuração precisa ser demonstrada por testes. Use dois clientes fictícios, A e B, cada um com seu documento, e verifique acessos permitidos e bloqueados.

No teste de expiração, inicie uma nova requisição após o prazo. Um download iniciado antes de a URL expirar pode continuar; a expiração não interrompe automaticamente uma transferência em andamento.

Teste também o envio pelo navegador na origem autorizada e uma tentativa a partir de outra origem. Verifique o comportamento de CORS sem tratá-lo como prova de autorização no S3.

Inspecione os arquivos JavaScript publicados para confirmar a ausência de chaves secretas. Revise ainda se URLs temporárias completas estão sendo capturadas em logs.

Para investigar AccessDenied, confira a identidade efetivamente utilizada, a ação solicitada, o ARN do recurso, as políticas IAM e do bucket e as negações explícitas. Quando aplicável, revise permissões KMS, políticas de endpoint e restrições da organização.

Se o upload falhar com AccessControlListNotSupported, procure parâmetros de ACL incompatíveis com Bucket owner enforced. Registre os resultados dos testes e repita a validação após mudanças em permissões, autenticação ou integrações.

Como aplicar armazenamento seguro ao seu site empresarial

Uma empresa em Recife que recebe anexos e disponibiliza contratos precisa definir mais que o local de armazenamento. O projeto deve estabelecer quem envia, quem consulta, quanto tempo os documentos permanecem disponíveis e quem administra a operação.

Para uma área do cliente, um escopo útil inclui autenticação, autorização por documento, bucket privado, URLs temporárias, validação de uploads, auditoria e testes de recuperação. Para imagens institucionais, pode incluir CloudFront com origem privada e otimização dos arquivos.

Antes da implementação, levante os tipos de arquivo, o volume esperado, os tamanhos máximos, os requisitos de retenção e as responsabilidades da equipe. Considere armazenamento, requisições, transferência, distribuição e recursos adicionais no acompanhamento dos custos.

Essas decisões devem entrar no escopo de criação ou modernização do site, junto com os testes e a manutenção. Assim, formulários com anexos, portais empresariais e áreas autenticadas recebem controles coerentes com seu uso.

Seu site precisa receber anexos ou disponibilizar documentos para clientes? Entre em contato pelo site da Codephix, em codephix.com, e converse sobre um projeto de criação de sites em Recife com armazenamento no Amazon S3 e controle de acesso adequado ao seu negócio.