Archiviazione e pubblicazione di file in modo sicuro per più client

Stiamo lavorando su un'app Web, in cui (tra le altre funzionalità) i nostri utenti possono caricare i propri file. Tuttavia non possiamo archiviare questi file sul nostro VPS perché lo spazio di archiviazione è limitato, quindi abbiamo deciso di utilizzare S3.

Il problema principale è che dobbiamo assicurarci che gli utenti possano accedere solo ai propri dati. Quindi conserviamo l'elenco dei file nel nostro database e l'elenco degli utenti che hanno accesso ad essi. Il nostro server può facilmente decidere se un utente ha o meno accesso a un file. Ma come servire effettivamente i file agli utenti?

Ci sono già alcune possibilità che ho già preso in considerazione, ma nessuna sembra essere la migliore.

1. Generazione (scadenza) di URL firmati con PHP

Questo è un approccio davvero semplice, è anche veloce ma si traduce in URL molto brutti e lunghi.

Ecco come farlo .

2. URL offuscati

Questo significa che noi mantenere il pubblico dei file per la lettura su S3, ma tutti i file sono memorizzati in difficile da indovinare cartelle denominate come: 24fa0b8ef0ebb6e99c64be8092d3ede20000. Tuttavia, forse questo non è il modo più sicuro di andare. Anche se non puoi mai indovinare il nome di una cartella, dopo averlo conosciuto (perché in realtà hai accesso ad esso), puoi condividere quel collegamento con chiunque (con qualsiasi persona non autorizzata).

3. Scarica i file attraverso il nostro server

Ciò significa che i file non sono serviti direttamente da S3, ma prima il nostro server lo legge in modo sicuro e lo serve. Non lo vogliamo davvero :)

4. Verifica referrer

La soluzione URL offuscati può essere migliorata "assicurandosi" che la richiesta provenga dal nostro server (è possibile impostare S3 per controllare il referrer). Tuttavia, questa sarebbe una soluzione molto inaffidabile, perché non tutti i browser inviano i dati del referrer e possono anche essere falsificati.

Qual è un buon modo per servire i file da Amazon S3 in modo sicuro per diversi client?

Questo è davvero al limite di "Fai la mia architettura di sistema" per te, ma le tue quattro idee sono case study interessanti sulla sicurezza variabile, quindi eseguiamo le tue opzioni e vediamo come vanno:

4. Verifica referrer

Il referrer è fornito dal client. Fidarsi dei dati di autenticazione / autorizzazione forniti dal cliente praticamente invalida la sicurezza (posso solo affermare di essere stato inviato da dove ti aspetti che venga).
Verdetto: idea di TERRIBAD - banale da aggirare.

3. Scarica i file attraverso il nostro server

Non è una cattiva idea, purché tu sia disposto a spendere la larghezza di banda per farlo accadere e il tuo server è affidabile.
Partendo dal presupposto che hai già risolto il problema di sicurezza per il tuo normale server / app, questa è la più sicura delle opzioni che hai presentato.
Verdetto: buona soluzione. Molto sicuro, ma forse non ottimale se la larghezza di banda è un fattore.

2. URL offuscati

Sicurezza attraverso l'oscurità ? Veramente? No.
Non ho nemmeno intenzione di analizzarlo. Proprio no.
Verdetto: Se il numero 4 era TERRIBAD, questo è TERRIWORSE perché le persone non devono nemmeno passare attraverso lo sforzo di forgiare un header referrer. Indovina la stringa e vinci un premio con tutti i dati!

1. Generazione (scadenza) di URL firmati con PHP

Questa opzione ha un quoziente di aspirazione piuttosto basso.
Chiunque può fare clic sull'URL e acquisire i dati, che è un no-no di sicurezza, ma puoi mitigarlo facendo scadere il collegamento (finché la durata del collegamento è abbastanza breve la finestra della vulnerabilità è piccola).
La scadenza dell'URL può causare inconvenienti ad alcuni utenti che desiderano rimanere a lungo sul collegamento per il download o che non ottengono il collegamento in modo tempestivo: è un po 'una esperienza utente, ma può valerne la pena .
Verdetto : non buono come il n. 3, ma se la larghezza di banda è una delle maggiori preoccupazioni è sicuramente meglio del n. 4 o del n. 2.

Cosa farei?

Date queste opzioni, andrei con # 3 - Passa i file attraverso il tuo server front-end e autentico come fa normalmente la tua app. Supponendo che la tua normale sicurezza sia abbastanza decente, questa è l'opzione migliore dal punto di vista della sicurezza.
Sì, questo significa un maggiore utilizzo della larghezza di banda sul tuo server e più risorse per giocare a middleman, ma puoi sempre caricarne un po 'di più.

Usa le query pre-firmate Amazon S3 per servire gli oggetti S3 direttamente agli utenti dopo aver effettuato la convalida dell'utente che desideri. Questo metodo crea un URL a tempo limitato al quale è possibile reindirizzare gli utenti.

C'è anche un altro modo.

Puoi indicare un AWS CloudFront al tuo bucket S3 e utilizzare i cookie firmati per offrire contenuti in modo sicuro agli utenti finali.

Gli utenti finali devono accedere al proprio server per ottenere i cookie firmati che verranno quindi inviati a CDN durante l'accesso a qualsiasi file.