19

イメージのホスティングに Amazon S3 を使用するサンプル アプリケーションを起動しました。私はなんとかそれを機能させることができました。アプリケーションはgithub.comでホストされています。このアプリケーションでは、プロフィール写真付きのユーザーを作成できます。写真をアップロードすると、ウェブ アプリケーションはその写真をローカル ファイル システムではなく Amazon S3 に保存します。( heroku.comでホストする場合は非常に重要です)

しかし、ページのブラウザで「ソースを表示」すると、画像の URL が、アプリに割り当てた S3 バケット内の Amazon S3 URL であることに気付きました。URL をカット アンド ペーストしたところ、同じブラウザで画像を表示できました。別のブラウザでは、Web アプリまたは Amazon S3 へのセッションを開いていませんでした。

アプリケーションにログインしているブラウザのみがアクセスできるように、その URL (および画像) へのアクセスを制限する方法はありますか?

Amazon ACL について私が見つけた情報のほとんどは、所有者のみ、Amazon や AmazonS3 で認証されたユーザーのグループ、または匿名の全員へのアクセスに関するものにすぎません。

編集----2010年7月7日更新

Amazon は、S3 オブジェクトとバケットへのアクセスを制限する方法をさらに発表しました。とりわけ、HTTP リファラーを修飾することで、S3 オブジェクトへのアクセスを制限できるようになりました。これは面白そうです...彼らが開発者向けドキュメントを更新するのが待ちきれません。

4

4 に答える 4

10

プライバシーが実際に重要なファイルの場合、これを次のように処理します。

  • ファイルはプライベートACLで保存されます。つまり、許可されたエージェントのみがファイルをダウンロード（またはアップロード）できます。
  • ファイルにアクセスするには、にリンクしますhttp://myapp.com/download/{s3-path}。ここでdownload、はコントローラーに対応します（MVCの意味で）
  • ACLは適切に実装されているため、ログインしているユーザーのみがそのコントローラー/アクションにアクセスできます。
  • そのコントローラーは、APIを使用してファイルをダウンロードし、正しいmimeタイプ、キャッシュヘッダー、ファイルサイズなどを使用してユーザーにストリーミングします。

この方法を使用すると、必要以上に多くの帯域幅を使用することになりますが、それでもストレージを節約できます。帯域幅よりもはるかに早くストレージが不足する傾向があるため、これはうまくいきます。

プライバシーが重要なファイルの場合、URLに使用するランダムハッシュを生成します。これは基本的に隠すことによるセキュリティであり、ハッシュを推測するのが十分に難しいことに注意する必要があります。

ただし、ページのブラウザで「ソースの表示」を実行すると、画像のURLがアプリに割り当てたS3バケット内のAmazonS3URLであることに気付きました。URLを切り取って貼り付けたところ、同じブラウザーと、WebアプリまたはAmazonS3へのセッションを開いていない別のブラウザーで画像を表示できました。

これは、ドキュメントルートの他の場所に保存されている画像と同じであることに注意してください。探している種類のセキュリティが必要な場合と不要な場合があります。

于 2010-03-31T01:39:53.527 に答える
8

Amazon の Ruby SDK ( https://github.com/aws/aws-sdk-ruby ) には、これを簡単に実行できる便利なメソッドがあります。「url_for」は、それ以外の場合はプライベート S3 オブジェクトの一時的な読み取り可能な URL を生成できます。

5 分後に有効期限が切れる読み取り可能な URL を作成する方法は次のとおりです。

オブジェクト = AWS::S3.new.buckets['BUCKET'].objects['KEY']

object.url_for(:read, :expires => 300).to_s

AWS ドキュメント: http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/S3/S3Object.html#url_for-instance_method

于 2014-03-02T12:48:41.950 に答える
4

S3 は別のサービスであり、セッションについて認識しません。

一般的な解決策は、各アセットに、そのアセットへの URL の一部を形成する、個別の一意の非常に長くランダムなキーを割り当てる利点とセキュリティ プロパティを認識することです。選択した場合は、有効な 512 ビットのランダム性を持つキーを割り当てることもでき、その URL は非常に長い間推測不可能なままになります。

  • アセットにアクセスできる人tは、後で参照するためにアセットをコピーするだけでよいため、その人が URL を知り、いつでもアセットにアクセスできるようにすることは理にかなっています。
  • 同様に、その人は単にアセットをダウンロードして他の人に配布できるので、その人が他の人に URL を配布することを許可することは理にかなっています。
  • このようなアクセスはすべて読み取り専用であり、書き込みは Web サイト サーバーに制限されているため、このアクセス権を持つ人からの悪意のある「ハッキング」のリスクはありません。

これが十分なセキュリティであるかどうかを判断する必要があります。そうでない場合は、S3 が適していない可能性があります。画像をバイナリ列としてデータベースに保存し、Heroku で実行できる memcached にキャッシュする必要があるかもしれません。

于 2010-03-31T01:10:48.193 に答える
2

あなたができる最善のことは、drop.ioが行うことだと思います。データは原則として誰でもアクセスできますが、大きなランダムな URL を指定します。URL を知っている人は誰でもアクセスできますが、URL を表示できるユーザーはアプリケーションによって制御されます。

あいまいさによる一種のセキュリティ。

URL に含まれるパスワードと考えることができます。これは、セキュリティを真剣に考えている場合は、URL を機密情報として扱う必要があることを意味します。これらのリンクが検索エンジンにも漏れないようにする必要があります。

また、アクセス権を取り消すことも困難です。できることは、URL を無効にして新しい URL を割り当てることだけです。

于 2010-03-31T01:06:04.700 に答える