0

Azure の Blob Storage で Shared Access Signatures を使用する場合の署名付き識別子の目的を理解しようとしています。署名付き識別子は基本的にコンテナ レベルで適用され、名前が付けられていることを知っています。さらに、(署名付き識別子を指定しない場合とは対照的に) 1 時間以上有効な共有アクセス ポリシーを提供することも知っています。私の質問は、適切なアクセス許可と有効期限を使用して、コンテナー レベルで Shared Access Signature を適用することはできないのでしょうか? すべての返信に感謝します。

わかりました、私は今得たと思います。したがって、SI を解釈する最善の方法は、SI がコンテナー レベルでのアクセス制御の別のレベルの抽象化であるということです。さらに、ポリシーが取り消されるまでのポリシーの適用期間を指定できます。明示的宣言と SI 宣言の両方で、失効はほとんど有効期限です。

次の質問は、たとえば、侵害されたポリシーがあるとします。ポリシーをすぐに取り消したり変更したりするにはどうすればよいですか (コードでこのポリシーを定義したので、コードを再デプロイせずに変更するにはどうすればよいですか)?

4

3 に答える 3

0

すべてのパラメーターを明示的に指定するのではなく、署名付き識別子を使用する主な理由は、セキュリティに関係しています。何らかの理由で、指定されたすべてのパラメーターと有効な HMAC 署名を持つ SAS が作成された場合、BLOB サービスはそれを受け入れます。有効期限に制限がなかったと想像してください。今、それが漏れると想像してください。通常の場合、ダメージを与えることができるのは最大 1 時間です。すべてのパラメーターを指定したため、変更することはできません。無制限の時間を指定できたとしても、メイン ストレージ キーを実際に変更しないと取り消すことはできません (これにより、sig が無効になり、既存のすべての SAS が破損します)。SI は、ストレージ キーをロールする必要をなくすために、もう 1 つの抽象化レイヤーを提供します。

署名された識別子 (または私がそれらを呼び出すのが好きなポリシー) は、1 時間を超えても、a.) 必要に応じてすぐに取り消すか、b.) すぐに変更できる方法です。SI を使用すると、アクセス許可を変更したり、削除したり、有効期限を変更したりできます。これらすべてにより、既存の SAS (とにかく SI を使用するもの) の寿命とアクセスをより細かく制御できます。

于 2011-05-25T13:34:10.307 に答える
0

実際、私は自分の質問に答えたところです。問題のコンテナーを参照するコードを記述し、現在コンテナーに設定されているアクセス ポリシーをクリアすることができます。

于 2011-05-25T21:56:48.293 に答える
0

署名付き識別子は、特定のコンテナで ACL を参照する方法です。これらは、BLOB への取り消し可能なアクセスを作成するために必要です。

有効期限を 1 時間より長く設定すると、Blob Service が 400 Bad Request エラーを返すか、単に有効期限を無視して 1 時間に設定する可能性があります。

これは、データが安全であることを保証するために、プラットフォームの一部として行われます。

MSDN ライブラリには、SAS の有効期間に関する詳細情報があります。

于 2011-05-25T06:23:49.810 に答える