1

Amazon S3にいくつかの画像をアップロードし、ユーザの購読に基づいて、これらの画像の一部を閲覧できるアクセス権を与えたいと考えています。 Amazon S3のドキュメントを読んだ後、私はこれらのソリューションが出ている:Amazon S3のプライベートデータを保護する

  1. は、Amazon S3の内の1人のIAMユーザーに自分のアプリケーション内の各ユーザーに割り当て、その後、何へのアクセス権を持つユーザーを管理するために、ユーザポリシーまたはバケットポリシーを定義します。しかし、2つの欠点があります:まず、ユーザーまたはバケットポリシーのサイズに制限があり、ユーザーとイメージの数が非常に多いので、その制限を超過する必要があります。次に、AWSアカウントあたりのIAMユーザー数は5000に制限されています。アプリケーションにはさらに多くのユーザーがいます。

  2. Amazon S3では、IAMユーザーと同じように機能する一時的なセキュリティ資格情報を定義できます。クライアント側からサーバーへの要求を要求することができます。特別なポリシーを使用してIAMユーザー用に一時的なIAMユーザーを作成し、資格情報を渡してから、資格情報を使用してS3に要求を直接送信し、リソース。しかし、問題はこれらのユーザーが15分から1時間の間持続するため、クライアントは一時的なIAMユーザーを作成するために少なくとも1時間ごとにサーバーを要求する必要があるということです。

  3. 私はいくつかの画像を提供したいので、できるだけ早くコンテンツを提供するために、Amazon CloudfrontとS3の組み合わせを使用することをお勧めします。プライベートコンテンツを提供するためのCloudfrontのドキュメントも読んでおり、そのソリューションが署名済みのURLまたは署名付きのCookieを使用していることがわかりました。私はS3リソースへのアクセスを拒否し、クラウドフロントはS3からのデータの読み取りにアクセスできる唯一のユーザーであり、ユーザーがアプリケーションにサインインするたびに、署名するために必要な資格情報を送信しますURLまたは私はそれらに必要なクッキーを送信します。彼らは自分が持っている情報で必要なリソースを要求することができ、この情報は自分のアプリケーションにサインインするまで続きます。しかし、私はいくつかのセキュリティ上の懸念があります。アクセス制御に関する情報のほとんどは(クッキーなどで)クライアントに送信されるため、簡単にアクセス制御を変更してより多くのアクセス許可を与えることができます。しかし、それは大きな懸念ですが、私は、リソースの読み込み時間を減らすためにクラウドフロントを使用しなければならないと思います。

これらのソリューションのどちらが他のソリューションよりも妥当で優れていると思います。他のAmazon Webサービスを使用している可能性があります。

答えて

2

S3上のプライベートコンテンツを提供するために私自身のアプローチは、どちらか署名したURLでまたは署名クッキー(または、時には、その両方)をCloudFrontのを使用することです。 は、は、あなたの場合のように、多数のユーザーに対してIAMユーザーまたは一時的な資格情報を使用しないでください。

あなたがここでこのトピックについての詳細を読むことができます: Serving Private Content through CloudFront

署名URLまたは署名したクッキーを使用するかどうかの選択は、以下に依存します。

Choosing Between Signed URLs and Signed Cookies

CloudFrontのは、URLに署名したとクッキーを締結し、同じ基本 機能を提供します。彼らはあなたのコンテンツにアクセスできるユーザーを制御することができます。 CloudFrontを通じてプライベートコンテンツを提供したい場合、 は署名済みのURLを使用するか署名済みのCookieを使用するかを決定しようとしています。 は以下を考慮します。あなたは、RTMPディストリビューションを使用したい

  • 使用は、次のような場合にURLを署名しました。署名されたCookieは、RTMPディストリビューションの場合は には対応していません。

  • アプリケーションのインストールダウンロードなど、個々のファイルへのアクセスを制限する必要があります。
  • ユーザーは、 がクッキーをサポートしていないクライアント(たとえば、カスタムHTTPクライアント)を使用しています。

使用は、次の場合にクッキーを締結:

  • を使用すると、複数の制限されたファイルへのアクセスを提供したい、例えば、 をHLS形式のビデオのためのすべてのファイルや内のすべてのファイルウェブサイトの サブスクライバー領域
  • 現在の のURLを変更したくないです。お使いのセキュリティ上の問題については

は、CloudFrontのは、署名されたクッキーに署名を検証すると、クッキーが改ざんされていないことを確認するために、公開鍵を使用しています。署名が無効な場合、要求は拒否されます。

this pageの最後のガイドラインに従って、署名付きCookieの誤用を防ぐこともできます。

+0

セキュリティの問題をどうやって管理するのですか?クッキーを持っているユーザーは、S3 @ – user3070752

+0

@ user3070752のリソースへのアクセスを許可されていないものとして悪用する可能性があります。署名されたクッキーは安全です。エンドユーザーは、無効にすることなくクッキーを変更することはできません。私の更新された答えを見てください。 –

+0

あなたの答えをありがとう。私は公開 - 秘密鍵のセキュリティ方法にあまり精通していません。エンドユーザに希望のカスタムポリシーでプライベートキーを送信すると(たとえポリシーがハッシュされていても、元のポリシーを何とか取得してポリシーのインスタンスのリソースキーを変更することができるかもしれません)、クラウドフロントはどのように公開しますかキーは、ユーザーがCookieを変更していないことを確認します。実際にCloudfrontのドキュメントを読んだ後でも、クラウドフロントがエンドユーザーが自分の情報を悪用することができないことをどうやって確認するのかはまだ不明です。 – user3070752

関連する問題