複数のクライアントにファイルを安全に保存して提供する


8

私たちはユーザーがファイルをアップロードできる(他の機能の中でも)Webアプリに取り組んでいます。ただし、ストレージスペースが限られているため、VPSにこれらのファイルを保存できないため、S3を使用することにしました。

主な問題は、ユーザーが自分のデータのみにアクセスできるようにする必要があることです。そのため、データベースにファイルのリストと、それらにアクセスできるユーザーのリストを保持しています。サーバーは、ユーザーがファイルにアクセスできるかどうかを簡単に判断できます。しかし、実際にファイルをユーザーに提供する方法は?

私はすでに考えたいくつかの可能性がありますが、それらのどれも実際には最良のものではないようです。

1. PHPを使用して(期限切れになる)署名付きURLを生成する

これは非常に単純なアプローチであり、高速でもありますが、非常に醜く長いURLになります。

方法は次のとおりです

2.難読化されたURL

これは、S3での読み取り用にファイルを公開していることを意味しますが、すべてのファイルは、次のような推測しにくい名前のフォルダーに保存されます24fa0b8ef0ebb6e99c64be8092d3ede20000。ただし、これが最も安全な方法ではないかもしれません。フォルダ名を推測できない場合でも、(実際にアクセスできるため)フォルダ名を知っていれば、誰でも(権限のないユーザーと)リンクを共有できます。

3.サーバーからファイルをダウンロードします

これは、ファイルがS3によって直接提供されないことを意味しますが、最初にサーバーがそれを安全に読み取り、提供します。私たちは本当にこれを望んでいません:)

4.リファラーの確認

難読化のURLの解決策は、要求が(あなたがリファラをチェックするためにS3を設定することができます)当社のサーバーから来ている「ことを確認すること」によって改善することができます。ただし、すべてのブラウザがリファラーデータを送信するわけではないため、これは非常に信頼性の低いソリューションとなり、偽装される可能性もあります。

さまざまなクライアントに対してAmazon S3からファイルを安全に提供するための良い方法は何ですか?


1
なぜ醜い/長いURLを気にするのですか?あなたはそれをユーザーにタイプさせていませんね?
ceejayoz 2013年

私は本当にURLはユーザー体験の一部であることを信じて、私たちはあまりにも長い間彼らと醜い:)を望んでいない
タマシュのPap

2
この場合、セキュリティと安定性はかなりのURLに勝るはずです。これらはブログ投稿へのパーマリンクではありません。
ceejayoz 2013年

回答:


12

これは本当に「システムアーキテクチャを実行する」の境界にありますが、4つのアイデアは可変セキュリティの興味深いケーススタディなので、オプションを実行して、それらがどのように機能するかを見てみましょう。


4.リファラーの確認

リファラーはクライアントによって提供されます。クライアントから提供された認証/承認データを信頼すると、セキュリティがかなり無効になります(私が送信元と思っているところから送信されたと主張できます)。
評決: TERRIBADのアイデア- 無視するのは簡単です。


3.サーバーからファイルをダウンロードします

それを実現するために帯域幅を費やす意思があり、サーバーが信頼できる限り、悪い考えではありません。
通常のサーバー/アプリのセキュリティ問題をすでに解決しているという前提で、これは提示したオプションの中で最も安全です。
評決:良い解決策。非常に安全ですが、帯域幅が重要な要素である場合は最適とは言えません。


2.難読化されたURL

あいまいさによるセキュリティ?本当に?いいえ
、分析するつもりはありません。いいえ。
評決:#4がTERRIBADだった場合、人々はリファラーヘッダーを偽造する労力を経験する必要さえないので、これはTERRIWORSEです。文字列を推測し、すべてのデータで賞品を獲得ましょう!


1. PHPを使用して(期限切れになる)署名付きURLを生成する

このオプションには、かなり低い吸込商があります。
誰でもURLをクリックしてデータを削ることができますが、これはセキュリティノーノーですが、リンクを期限切れにすることでこれを軽減できます(リンクの有効期間が十分に短い限り、脆弱性のウィンドウは小さくなります)。
URLの有効期限切れると、ダウンロードリンクを長時間使い続けたいユーザーや、リンクをタイムリーに取得できないユーザーにとって不便かもしれません。 。
評決:#3ほど良くはありませんが、帯域幅が大きな懸念事項である場合は、#4または#2よりも確かに優れています。


どうしましょう?

これらのオプションを前提として、私は#3を使用します-ファイルを独自のフロントエンドサーバーに渡し、アプリが通常行う方法で認証します。あなたの通常のセキュリティがかなりまともであると仮定すると、これはセキュリティの観点から最良のオプションです。
はい、これはあなたのサーバーでより多くの帯域幅の使用を意味し、より多くのリソースが仲介者を果たします-しかし、あなたはいつでもそのためにほんの少しだけ多くを請求することができます。


これは本当に役立つ分析で、とてもありがたいです。#3のもう1つの大きな利点は、ファイルへのURLが変更されないため、ブラウザーのキャッシュを頻繁に使用できることです。お時間をいただきありがとうございます。
タマシュのPap

確かに#3の利点である@TamasPap-利点の大きさは、キャッシュをどの程度積極的に構成できるか(および「新しい」マシンからこれらのファイルにアクセスする頻度)によって異なります。
voretaq7 2013年


0

別の方法もあります。

AWS CloudFrontをS3バケットに向け、署名付きCookieを使用してコンテンツを安全にエンドユーザーに提供できます。

エンドユーザーは、サーバーにサインインして署名付きCookieを取得する必要があります。署名されたCookieは、ファイルにアクセスしているときにCDNに送信されます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.