すべてのリソースはコンテナ内にあります - Amazon Verified Permissions

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

すべてのリソースはコンテナ内にあります

承認モデルを設計するときは、すべてのアクションを特定のリソースに関連付ける必要があります。viewFileのようなアクションでは、それを適用できるリソースは直感的です。個々のファイルでも、フォルダ内の複数のファイルでもかまいません。ただし、createFileのような操作は直感的ではありません。ファイルを作成する機能をモデル化する場合、どのリソースに適用されますか? ファイルがまだ存在していないため、ファイルそのものであってはなりません。

これはリソース作成に関する一般的な問題の一例です。リソース作成はブートストラップの問題です。リソースがまだ存在しない場合でも、リソースを作成する権限を何かに付与する方法が必要です。解決策は、すべてのリソースは必ず何らかのコンテナ内に存在しなければならず、権限のアンカーポイントとなるのはコンテナ自体であることを認識することです。たとえば、システムにフォルダがすでに存在する場合、ファイルの作成機能はそのフォルダに対する権限としてモデル化できます。なぜなら、そのフォルダは新しいリソースをインスタンス化するための権限が必要な場所だからです。

permit ( principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", action == Action::"createFile", resource == Folder::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" );

しかし、フォルダーが存在しない場合はどうなるでしょうか? これは、リソースがまだ存在しないアプリケーションのまったく新しい顧客アカウントかもしれません。このような状況でも、「顧客はどこで新しいファイルを作成できるのか」と尋ねれば直感的に理解できるコンテキストがまだ残っています。ランダムな顧客アカウント内でファイルを作成できないようにしたくはないでしょう。むしろ、暗黙のコンテキストがあります。それは、顧客自身のアカウント境界です。したがって、アカウント自体がリソース作成のコンテナであり、これを次の例のようなポリシーで明示的にモデル化できます。

// Grants permission to create files within an account, // or within any sub-folder inside the account. permit ( principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", action == Action::"createFile", resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" );

しかし、アカウントも存在しない場合はどうなるでしょうか? 顧客登録ワークフローを設計して、システム内に新しいアカウントを作成することもできます。その場合は、プロセスでアカウントを作成できる一番外側の境界を格納するコンテナが必要になります。このルートレベルのコンテナはシステム全体を表し、「システムルート」のような名前を付けることもできます。ただし、これが必要かどうか、またどのような名前を付けるかは、アプリケーションオーナーの判断に委ねられます。

したがって、このサンプルアプリケーションでは、結果のコンテナ階層は次のようになります。

アカウントを含むシステムルートを含むファイル階層。各アカウントにはフォルダが含まれ、そのフォルダにもファイルを格納できます。

これは 1 つのサンプル階層です。他のものも有効です。覚えておくべきことは、リソースの作成は常にリソースコンテナのコンテキスト内で行われるということです。これらのコンテナはアカウントの境界のように暗黙的である場合があり、見落としがちです。承認モデルを設計するときは、これらの暗黙的な前提条件を必ず書き留めて、承認モデルで正式に文書化して表現できるようにしてください。