Stockage et service de fichiers en toute sécurité pour plusieurs clients


8

Nous travaillons sur une application web, où (entre autres fonctionnalités) nos utilisateurs peuvent télécharger leurs fichiers. Cependant, nous ne pouvons pas stocker ces fichiers sur notre VPS car l'espace de stockage est limité, nous avons donc décidé d'utiliser S3.

Le principal problème est que nous devons nous assurer que les utilisateurs ne peuvent accéder qu'à leurs propres données. Nous gardons donc la liste des fichiers dans notre base de données, ainsi que la liste des utilisateurs y ayant accès. Notre serveur peut facilement décider si un utilisateur a accès ou non à un fichier. Mais comment réellement servir les fichiers aux utilisateurs?

J'ai déjà envisagé certaines possibilités, mais aucune d'entre elles ne semble être la meilleure.

1. Générer (expirer) des URL signées avec PHP

C'est une approche vraiment simple, elle est aussi rapide mais se traduit par des URL très très laides et longues.

Voici comment procéder .

2. URLs obscurcies

Cela signifie que nous gardons les dossiers publics pour lire sur S3, mais tous les fichiers sont stockés dans difficile à deviner dossiers nommés comme: 24fa0b8ef0ebb6e99c64be8092d3ede20000. Cependant, ce n'est peut-être pas la voie la plus sûre. Même si vous ne pouvez jamais deviner le nom d'un dossier, après l'avoir connu (parce que vous y avez réellement accès), vous pouvez partager ce lien avec n'importe qui (avec toute personne non autorisée).

3. Téléchargez les fichiers via notre serveur

Cela signifie que les fichiers ne sont pas servis directement par S3, mais d'abord notre serveur les lit en toute sécurité et les sert. Nous ne voulons vraiment pas ça :)

4. Vérification du référent

La solution des URL obscurcies peut être améliorée en "s'assurant" que la demande provient de notre serveur (vous pouvez configurer S3 pour vérifier le référent). Cependant, ce serait une solution très peu fiable, car tous les navigateurs n'envoient pas les données du référent, et elles peuvent également être truquées.

Quelle est la bonne façon de servir des fichiers d'Amazon S3 en toute sécurité pour différents clients?


1
Pourquoi vous souciez-vous de l'URL laide / longue? Vous ne faites pas taper l'utilisateur, n'est-ce pas?
ceejayoz

Je crois vraiment que les URL font partie de l'expérience utilisateur, et nous ne voulons pas qu'elles soient trop longues et moches :)
Tamás Pap

2
La sécurité et la stabilité devraient l'emporter sur les jolies URL dans ce cas, je dirais. Ce ne sont pas des liens permanents vers des articles de blog.
ceejayoz

Réponses:


12

Cela est vraiment à la limite de "Faire mon architecture de système" pour vous, mais vos quatre idées sont des études de cas intéressantes en sécurité variable, alors exécutons vos options et voyons comment elles se comportent:


4. Vérification du référent

Le référent est fourni par le client. Faire confiance aux données d'authentification / autorisation fournies par le client annule à peu près la sécurité (je peux simplement prétendre avoir été envoyé d'où vous vous attendez à ce que je vienne).
Verdict: idée TERRIBAD - trivial à contourner.


3. Téléchargez les fichiers via notre serveur

Pas une mauvaise idée, tant que vous êtes prêt à dépenser la bande passante pour y arriver et que votre serveur est fiable.
En supposant que vous avez déjà résolu le problème de sécurité pour votre serveur / application normal, c'est la plus sûre des options que vous avez présentées.
Verdict: bonne solution. Très sécurisé, mais peut-être sous-optimal si la bande passante est un facteur.


2. URLs obscurcies

La sécurité par l'obscurité ? Vraiment? Non,
je ne vais même pas l'analyser. Tout simplement pas.
Verdict: Si # 4 était TERRIBAD, c'est TERRIWORSE parce que les gens n'ont même pas à faire l'effort de forger un en-tête de référent. Devinez la chaîne et gagnez un prix toutes les données!


1. Générer (expirer) des URL signées avec PHP

Cette option a un quotient d'aspiration assez bas.
Tout le monde peut cliquer sur l'URL et accrocher les données, ce qui est un non-non de sécurité, mais vous atténuez cela en faisant expirer le lien (tant que la durée de vie du lien est suffisamment courte, la fenêtre de vulnérabilité est petite).
L'URL expirant peut gêner certains utilisateurs qui souhaitent conserver le lien de téléchargement pendant une longue période, ou qui ne reçoivent pas le lien en temps opportun - c'est un peu une expérience utilisateur, mais cela peut valoir la peine .
Verdict : Pas aussi bon que # 3, mais si la bande passante est une préoccupation majeure, c'est certainement mieux que # 4 ou # 2.


Qu'est ce que je ferais?

Compte tenu de ces options, j'irais avec # 3 - Passer les fichiers via votre propre serveur frontal et authentifier la façon dont votre application le fait normalement. En supposant que votre sécurité normale est assez décente, c'est la meilleure option du point de vue de la sécurité.
Oui, cela signifie plus d'utilisation de la bande passante sur votre serveur et plus de ressources pour jouer à l'intermédiaire - mais vous pouvez toujours facturer un tout petit peu plus pour cela.


Il s'agit d'une analyse vraiment utile, et j'en suis très reconnaissante. Un autre grand avantage de # 3 est que - parce que l'URL d'un fichier ne change jamais - nous pouvons utiliser fortement la mise en cache du navigateur. Merci encore pour votre temps.
Tamás Pap

@TamasPap qui est un avantage du # 3 pour être sûr - la taille d'un avantage dépend de la façon agressive dont vous pouvez configurer la mise en cache (et de la fréquence à laquelle les gens accèdent à ces fichiers à partir de "nouvelles" machines).
voretaq7

4

Utilisez des requêtes pré-signées Amazon S3 pour servir les objets S3 directement aux utilisateurs après avoir effectué la validation utilisateur que vous souhaitez. Cette méthode crée une URL à durée limitée vers laquelle vous pouvez rediriger les utilisateurs.


0

Il y a aussi une autre façon.

Vous pouvez pointer un AWS CloudFront vers votre compartiment S3 et utiliser des cookies signés pour servir le contenu en toute sécurité à vos utilisateurs finaux.

Les utilisateurs finaux doivent se connecter à votre serveur pour obtenir les cookies signés qui seront ensuite envoyés à CDN lors de l'accès à n'importe quel fichier.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.