Compreendendo os identificadores de acesso de origem do AWS Cloudfront

2

Eu realmente não entendo a segurança por trás do OAI da AWS Cloudfront. A única coisa que faz é mudar o domínio do bucket. Em vez de acessar o intervalo com https://s3.amazonaws.com/[Bucket]/* , basta alterá-lo com seu domínio.

Mas, mais uma vez, qualquer pessoa pode procurar esse bucket / pasta sabendo o domínio do CF.

Estou faltando alguma coisa? Eu sei que você pode adicionar uma função lambda no lado do pedido do visualizador para limitar o acesso de um determinado aplicativo. Mas como posso evitar que os usuários tentem apenas URLs aleatórios? E não acho que seja uma boa prática fazer autenticação e verificar se esse usuário deve ter acesso ao recurso em cada solicitação.

Então, quais são as boas práticas para restringir meus usuários a acessar apenas os recursos que eles podem ver?

    
por Zaid Amir 29.10.2018 / 10:48

1 resposta

2

O objetivo de Origin Access Identity é impedir que os usuários diretamente acessem o bucket do S3. Em vez disso, eles precisam passar pelo CloudFront; a origem S3 Bucket não permitirá acesso a qualquer pessoa que a acesse diretamente.

Algumas razões para impor o acesso por meio do CloudFront :

  • Cache na borda (a transferência do CloudFront é mais barata que a do S3, e também está mais próxima do usuário)
  • Autenticação através do Lambda na extremidade
  • aplicação do WAF

Se você quiser restringir o acesso a objetos individuais em seu intervalo, considere usar URLs assinados . Por exemplo, quando o usuário fizer login em seu website, você fornecerá os documentos dele por meio de um formulário pré-assinado. URLs, talvez com algum limite de expiração.

A prática recomendada é ter um intervalo separado para objetos públicos (por exemplo, recursos do site - imagens, css, html) e um diferente para objetos particulares que precisam de autenticação (por exemplo, documentos dos clientes).

Veja aqui Exemplo de URL pré-assinado do S3

Atualização:

Você também pode usar Lambda na borda para autenticação, conforme descrito aqui: Use o Lambda @ Edge para melhorar a segurança de aplicações web

Qual deles usar depende do seu usecase. Os URLs pré-assinados são compartilháveis e podem ser limitados por tempo, os URLs autenticados do Lambda @ Edge não serão compartilháveis e exigirão que o usuário faça o login. Depende do que você precisa.

Espero que ajude:)

    
por 29.10.2018 / 11:11