Controle de acesso do S3: políticas de bucket e ACLs

O S3 oferece vários mecanismos de controle de acesso sobrepostos: políticas do IAM (baseadas em identidade, controlam o que as entidades principais podem fazer), políticas de bucket (políticas JSON baseadas em recursos no bucket), Listas de Controle de Acesso (ACLs) (concessões legadas por objeto ou bucket) e S3 Block Public Access (substituição no nível da conta ou do bucket que bloqueia qualquer acesso público, independentemente de outras políticas). Atualmente, para a maioria dos casos de uso, a abordagem recomendada é usar políticas de bucket junto com Block Public Access; as ACLs são consideradas legadas.

Uma política de bucket é um documento JSON anexado diretamente ao bucket do S3. Ela especifica quais entidades principais (usuários do IAM, funções, contas da AWS, serviços ou o público) podem executar quais ações em quais recursos (o bucket e/ou prefixos de chaves específicos). As políticas de bucket permitem acesso entre contas sem a necessidade de funções do IAM: você pode conceder diretamente, na política de bucket, acesso de leitura a objetos específicos para uma função do IAM de outra conta da AWS. Cada bucket pode ter uma política, e o tamanho máximo é de 20 KB.

Para disponibilizar conteúdo público (por exemplo, recursos de sites estáticos e conjuntos de dados públicos), você pode tornar os objetos legíveis publicamente por meio de uma política de bucket. Primeiro, desative Block Public Access no nível do bucket e, em seguida, adicione uma declaração de política de bucket com Principal: '*' e Action: s3:GetObject. É necessária a combinação da desativação da configuração Block Public Access com a permissão Allow da política de bucket — ativar apenas uma delas não funcionará. Sempre restrinja o Resource a um prefixo específico, em vez de ao bucket inteiro, a menos que você queira intencionalmente tornar todos os objetos públicos.

S3 Block Public Access é uma rede de segurança com quatro configurações que substituem as políticas de bucket e as ACLs: BlockPublicAcls (rejeita solicitações para definir ACLs públicas), IgnorePublicAcls (ignora ACLs públicas existentes), BlockPublicPolicy (rejeita políticas de bucket que concedem acesso público) e RestrictPublicBuckets (restringe o acesso com base em uma política pública). Todas as quatro configurações são ativadas por padrão. Você também pode ativar Block Public Access no nível da conta, bloqueando-o para todos os buckets independentemente das configurações individuais — uma medida ideal para evitar exposição pública acidental.

As ACLs do S3 são o mecanismo original de controle de acesso, anterior ao IAM. Uma ACL concede permissões predefinidas (READ, WRITE, FULL_CONTROL) a contas da AWS ou grupos predefinidos (todos os usuários, usuários da AWS autenticados e entrega de registros). As ACLs podem ser aplicadas no nível do bucket ou no nível de um objeto individual. Atualmente, a AWS recomenda desativar as ACLs (a configuração 'Bucket Owner Enforced' do S3 faz com que o proprietário do bucket seja o proprietário de todos os objetos, desativando as ACLs) e usar políticas de bucket e IAM. As ACLs ainda são cobradas na prova SAA-C03 como um conceito legado.

Ao disponibilizar conteúdo do S3 por meio do CloudFront, você quer manter o bucket privado, mas permitir que o CloudFront busque os objetos. Use Origin Access Control (OAC) — o substituto moderno do Origin Access Identity (OAI). O OAC cria uma identidade do CloudFront à qual você concede a permissão s3:GetObject na política de bucket, mantendo Block Public Access ativado. Dessa forma, os usuários precisam passar pelo CloudFront (para armazenamento em cache, WAF e HTTPS) e não podem acessar o bucket diretamente — um padrão comum de arquitetura segura na prova SAA-C03.

Há duas maneiras de conceder acesso de outra conta da AWS ao seu bucket do S3. Opção 1 — política de bucket: adicione uma declaração com o ARN da conta externa como Principal e as ações desejadas do S3. Os usuários e as funções do IAM da conta externa ainda precisam de permissões do IAM para chamar o S3, e a política de bucket também precisa conceder Allow a eles. Opção 2 — função do IAM com política de confiança: crie uma função na sua conta que confie na conta externa; as identidades da conta externa assumem a função e obtêm as permissões do seu bucket. A política de bucket é mais simples para cenários somente de leitura; as funções são melhores para acesso operacional.

Cross-Origin Resource Sharing (CORS) permite que uma aplicação Web hospedada em um domínio faça solicitações de busca do JavaScript para um bucket do S3 em um domínio diferente. Sem uma configuração de CORS, os navegadores bloqueiam essas solicitações por motivos de segurança. Você adiciona uma configuração de CORS ao bucket que especifica origens, métodos HTTP e cabeçalhos permitidos. O CORS é comumente necessário quando uma SPA do React hospedada em example.com busca imagens ou arquivos diretamente de um URL de bucket do S3.

Um URL pré-assinado concede acesso por tempo limitado a um objeto privado do S3 (para GET ou PUT) sem alterar nenhuma permissão do bucket ou do objeto. O URL inclui suas credenciais e um horário de expiração — qualquer pessoa com o URL pode acessar o objeto até que ele expire. Use URLs pré-assinados para: permitir que usuários autenticados da sua aplicação baixem arquivos privados, permitir que clientes carreguem arquivos diretamente no S3 sem passar pelo seu back-end ou compartilhar relatórios temporariamente. A expiração pode variar de 1 segundo a 7 dias (ao usar credenciais temporárias do STS, o máximo é de 12 horas).

Use condições de política de bucket para adicionar segurança baseada em contexto. Padrões comuns: aws:SourceIp restringe o acesso a intervalos de IP específicos (por exemplo, endpoints de VPC ou redes corporativas); aws:SecureTransport: true força o uso de HTTPS ao negar solicitações por HTTP (uma prática recomendada para todos os buckets que armazenam dados confidenciais); s3:x-amz-server-side-encryption garante que os objetos sejam carregados com criptografia no lado do servidor; e aws:PrincipalOrgID restringe o acesso a entidades principais dentro da sua Organização da AWS, evitando a exfiltração de dados para contas externas.

Por padrão, as instâncias do EC2 em uma sub-rede privada acessam o S3 pela Internet (por meio de um gateway NAT), gerando custos de NAT e expondo o tráfego à Internet pública. Os Endpoints de Gateway do S3 fornecem conectividade privada ao S3 dentro de uma VPC, sem um gateway NAT e sem custo adicional. Você adiciona o Endpoint de Gateway à sua tabela de rotas; o tráfego para o S3 é roteado automaticamente pela rede privada da AWS. Você também pode adicionar condições à política de bucket usando aws:SourceVpce para restringir o acesso apenas a solicitações provenientes do endpoint.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: as políticas de bucket são documentos JSON baseados em recursos que controlam o acesso entre contas e o acesso de serviços ao S3, S3 Block Public Access é uma substituição de segurança que evita exposição pública acidental e URLs pré-assinados, endpoints de VPC e configurações de CORS atendem com segurança a padrões de acesso específicos. A seguir, abordaremos versionamento do S3, MFA Delete e replicação.