6

Azure でホストされるアプリケーションを作成しています。このアプリケーションでは、ユーザーは自分のコンテンツをアップロードできます。また、ファイルを読み取ることができる他の信頼できるアプリ ユーザーのリストを構成することもできます。ストレージを設計する方法を理解しようとしています。

各ユーザーのアプリケーション ID にちなんだ名前のストレージ コンテナーを作成し、そこにファイルをアップロードできるようにすると思います。私の質問は、ユーザーがアクセスできるすべてのファイルへの読み取りアクセスを許可する方法に関するものです。私は共有アクセス署名について読んでいますが、私が達成しようとしていることにぴったりのようです。ただし、ユーザーにアクセスを許可する最も効率的な方法を評価しています。保存されたアクセス ポリシーが役立つ可能性があると思います。しかし、具体的には：

1 つの Shared Access Signature (または保存されたアクセス ポリシー) を使用して、ユーザーに複数のコンテナーへのアクセスを許可することはできますか? 非常に関連性が高いと思われる情報を 1 つ見つけました。

http://msdn.microsoft.com/en-us/library/windowsazure/ee393341.aspx

「コンテナー、キュー、またはテーブルには、最大 5 つの格納されたアクセス ポリシーを含めることができます。各ポリシーは、任意の数の共有アクセス シグネチャで使用できます。」

しかし、それを正しく理解しているかどうかはわかりません。ユーザーが 20 人の他のユーザーと接続している場合、20 個の特定のコンテナーへのアクセスを許可できますか? もちろん、20 個の保存されたアクセス ポリシーを個別に生成することもできますが、それはあまり効率的ではないようです。ユーザーが最初にログインしたときに、他のすべての信頼できるアプリ ユーザーからのコンテンツの概要を表示する予定です。一度に 20 の署名 (私の理解が正しければ)。

提案をありがとう... -ベン

4

1 に答える 1

11

ユーザーごとに 1 つのコンテナーを用意することになるため (ここでは、ユーザーをユーザー アプリケーション ID と同一視します)、これは、多くのユーザー用にさまざまなコンテナーを格納できるストレージ アカウントを用意することを意味します。アプリケーションに 1 つの特定のコンテナーにのみアップロードする機能を持たせたい場合は、多くの 2 つのオプションから読み取ることが考えられます。

最初: すべてのリクエストを処理する API を作成します。API の背後では、コードはストレージ アカウント全体に完全にアクセスできるため、ビジネス ロジックは、アクセスできるものとできないものを決定します。これの利点は、Shared Access Signature (SAS) をまったく作成する必要がないことです。アプリは API との対話方法しか認識していません。アプリケーションからの 1 回の呼び出しでさまざまなコンテナーからコンテンツを取得するための並列呼び出しを行うことで、コンテンツの概要に表示されるデータを結合することもできます。欠点は、これらのすべての呼び出しを仲介する必要があるこの API サービスをホストしていることです。そのルートに行く場合は、SAS を生成するために API サービスが必要です。

2 番目: SAS ルートに進み、必要に応じて SAS を生成しますが、これには少し注意が必要です。

コンテナーごとに最大 5 つの保存されたアクセス ポリシーしか作成できません。これら 5 つのうちの 1 つに対して、コンテナの「所有者」に 1 つのポリシーを作成し、読み取りと書き込みのアクセス許可を付与します。ここで、ユーザーが他のユーザーに読み取りアクセス許可を与えることを許可しているため、同じポリシーを読み取りに再利用しない限り、ポリシー数の制限に達しますが、ユーザーが誰かを削除した場合、ポリシーを取り消すことはできません。読者の「信頼できる」リスト。たとえば、Bob と James の両方にコンテナーへのアクセス許可を与え、両方とも読み取り SAS のコピーを渡された場合、Bob を削除する必要がある場合、共有している読み取りポリシーをキャンセルして、新しい読み取り SAS を再発行する必要があります。ジェームズへ。アプリはアクセス許可がなくなったことを検出し、更新された SAS を要求できるため、それほど悪い問題ではありません。

いずれにせよ、ポリシーを短命にしたいのです。信頼できる読者からボブを削除した場合、すぐに彼を遮断したいと思います。これは、更新された SAS をかなり頻繁に取得し、署名付きアクセス署名を再作成することになるため、署名付きアクセス ポリシーの有用性が低下することを意味します。これは、ポリシーを存続させることを計画している期間と、誰かが「信頼されていない」場合にどれだけ早く遮断したいかによって異なります。

ここで、アドホック署名を作成することをお勧めします。アドホック署名は実際に必要な数だけ持つことができますが、取り消すことはできず、最大 1 時間持続できます。それらを短命にするので、長さや取り消しの欠如は問題になりません。そのルートに行くということは、アプリケーションが必要に応じてそれらを取得するために戻ってくることを意味しますが、誰かが削除され、SAS を使い果たしたい場合について上で述べたことを考えると、これは大したことではないかもしれません. ただし、指摘したように、多くの SAS を生成しているため、これにより複雑さが増します。ただし、これらはアドホックであるため、実際に追跡する必要はありません。

SAS ルートを使用する場合は、API が必要に応じてアドホックな API を生成することをお勧めします。コンテナーへのアクセス許可が削除される可能性があり、アップロードとダウンロードを実際に実行するためのホストされたサービスの負荷を軽減するだけなので、数分以上続くべきではありません。繰り返しますが、誰かが見ることができるコンテナーを処理するためのすべてのロジックは引き続き API サービスにあり、アプリケーションは短期間使用できる署名を取得するだけです。

于 2014-01-19T02:26:32.897 に答える