Armazenar e servir arquivos com segurança para vários clientes

8

Estamos trabalhando em um aplicativo da web, onde (entre outros recursos) nossos usuários podem fazer upload de seus arquivos. No entanto, não podemos armazenar esses arquivos em nosso VPS porque o espaço de armazenamento é limitado, então decidimos usar o S3.

O principal problema é que devemos garantir que os usuários acessem apenas seus próprios dados. Portanto, mantemos a lista de arquivos em nosso banco de dados e a lista de usuários que têm acesso a eles. Nosso servidor pode decidir facilmente se um usuário tem ou não acesso a um arquivo. Mas como realmente servir os arquivos para os usuários?

Existem algumas possibilidades que eu já considerei, mas nenhuma delas parece ser a melhor.

1. Gerando (expirando) URLs assinados com PHP

Esta é uma abordagem muito simples, também é rápida, mas resulta em URLs muito muito feias e longas.

Veja como fazer isso .

2. URLs ofuscados

Isso significa que mantemos os arquivos públicos para leitura no S3, mas todos os arquivos são armazenados em pastas difíceis de adivinhar como: 24fa0b8ef0ebb6e99c64be8092d3ede20000 . No entanto, talvez este não seja o caminho mais seguro a seguir. Mesmo que você nunca consiga adivinhar um nome de pasta, depois de conhecê-lo (porque você realmente tem acesso a ele), você pode compartilhar esse link com qualquer pessoa (com qualquer pessoa não autorizada).

3. Baixe os arquivos através do nosso servidor

Isso significa que os arquivos não são servidos diretamente pelo S3, mas primeiro nosso servidor o lê com segurança e o veicula. Nós realmente não queremos isso:)

4. Verificando o referenciador

A solução URLs ofuscadas pode ser melhorada "garantindo" que o pedido venha do nosso servidor (você pode configurar o S3 para verificar o referenciador). No entanto, essa seria uma solução muito pouco confiável, porque nem todos os navegadores enviam os dados do referenciador e também podem ser falsificados.

Qual é uma boa maneira de exibir arquivos do Amazon S3 com segurança para diferentes clientes?

    
por Tamás Pap 10.05.2013 / 17:50

2 respostas

11

Isso está realmente próximo de "Do my system architecture" para você, mas suas quatro ideias são estudos de caso interessantes em segurança variável, então vamos executar suas opções e ver como elas se comportam:

4. Verificando o referenciador

O referenciador é fornecido pelo cliente. Confiar nos dados de autenticação / autorização fornecidos pelo cliente praticamente anula a segurança (posso afirmar ter sido enviado de onde você espera que eu venha). TERRIBAD ideia - trivial para ignorar.

3. Baixe os arquivos através do nosso servidor

Não é uma má idéia, contanto que você esteja disposto a gastar a largura de banda para que isso aconteça, e seu servidor é confiável.
Supondo que você já resolveu o problema de segurança do seu servidor / aplicativo normal, essa é a opção mais segura apresentada.
Veredicto: Boa solução. Muito seguro, mas possivelmente sub-ótimo se a largura de banda for um fator.

2. URLs ofuscados

Segurança através da obscuridade ? Mesmo? Não.
Eu nem vou analisar isso. Apenas não.
Veredicto: Se o número 4 for TERRIBAD , isto é TERRIWORSE porque as pessoas nem precisam passar pelo esforço de forjar um cabeçalho de referência. Adivinhe a string e ganhe um prêmio de todos os dados!

1. Gerando (expirando) URLs assinados com PHP

Esta opção tem um quociente bem baixo de sucção.
Qualquer um pode clicar no URL e selecionar os dados, o que é um não-não-seguro, mas você atenua isso fazendo com que o link expire (contanto que a vida útil do link seja curta o suficiente, a janela de vulnerabilidade é pequena). O URL que expira pode incomodar alguns usuários que querem se agarrar ao link de download por um longo tempo, ou que não obtêm o link em tempo hábil - isso é um pouco como uma experiência de usuário ruim , mas pode valer a pena.
Veredicto : Não tão bom quanto # 3, mas se a largura de banda é uma grande preocupação, certamente é melhor que # 4 ou # 2.

O que eu faria?

Com essas opções, eu optaria pelo # 3 - passe os arquivos pelo seu próprio servidor front-end e autentique a maneira como seu aplicativo normalmente funciona. Supondo que sua segurança normal é bastante decente, essa é a melhor opção do ponto de vista de segurança. Sim, isso significa mais uso de largura de banda em seu servidor e mais recursos jogando intermediário - mas você pode sempre cobrar um pouco mais por isso.

    
por 10.05.2013 / 22:11
2

Use consultas pré-assinadas do Amazon S3 para veicular os objetos do S3 diretamente aos usuários depois de fazer qualquer validação de usuário desejada. Esse método cria uma URL limitada por tempo para a qual você pode redirecionar usuários.

    
por 11.05.2013 / 01:31

Tags