正しいモデルは1つもありませんリソースに焦点を当てる複合許可マルチテナンシーを検討するポリシー範囲にデータを入力します。すべてのリソースをコンテナに入れる。プリンシパルとリソースを分離リレーションシップの表現きめ細かな許可認証を問い合わせるその他の理由

認証モデルを設計するためのベストプラクティス

ソフトウェアアプリケーション内で Amazon Verified Permissions サービスを使用する準備をしていると、最初のステップとしてポリシーステートメントをすぐに作成するのが難しい場合があります。これは、アプリケーションが何をすべきかを完全に決定する前に、SQLステートメントまたはAPI仕様を記述することで、アプリケーションの他の部分の開発を開始するのに似ています。代わりに、ユーザーエクスペリエンスから始めて、アプリケーション UI で権限を管理する際にエンドユーザーに表示されるべき内容を明確に理解する必要があります。次に、その経験から逆算して実装アプローチにたどり着きます。

この作業を進めていくと、次のような質問をすることになります。

私のリソースは何でしょうか？それらは互いに関係を持っていますか？たとえば、ファイルはフォルダ内に存在しますか?
プリンシパルは各リソースに対してどのようなアクションを実行できますか?
プリンシパルはどのようにしてこれらの権限を取得するのでしょうか?
エンドユーザーに「Admin」、「Operator」、ReadOnly「」などの事前定義されたアクセス許可から選択させたいですか、それともアドホックポリシーステートメントを作成すべきですか？それとも両方一緒ですか？
親フォルダから権限を継承するファイルなど、権限はリソース全体に継承されるべきですか?
ユーザーエクスペリエンスを実現するためにはどのような種類のクエリが必要ですか? たとえば、プリンシパルがそのユーザーのホームページを表示するためにアクセスできるすべてのリソースを一覧表示する必要があるでしょうか？
ユーザーが誤って自分のリソースからロックアウトされてしまうことはありませんか? それを回避する必要がありますか？

この作業の最終成果は承認モデルと呼ばれ、プリンシパル、リソース、アクションを定義し、それらがどのように相互に関連しているかを定義します。このモデルを作成するのに、Cedar や Verified Permissions サービスに関する独自の知識は必要ありません。その代わり、他のモデルと同様、何よりもまずユーザーエクスペリエンスの設計作業であり、インターフェースのモックアップ、論理図、権限が製品内でユーザーに表示される内容にどのように影響するかについての全体的な説明などの成果物として現れることがあります。Cedar は、Cedar の実装に合わせてモデルを不自然に曲げさせるのではなく、あるモデルで顧客に対応できる柔軟性を備えるように設計されています。そのため、希望するユーザー体験を的確に把握することが、最適なモデルを導き出す最善の方法です。

このセクションでは、設計作業への取り組み方、注意すべき点、検証済み権限をうまく使用するためのベストプラクティスに関する一般的なガイダンスを提供します。

ここで紹介するガイドラインに加えて、Cedar ポリシー言語リファレンスガイドのベストプラクティスを考慮することを忘れないでください。

正規の「正しい」モデルはありません

認証モデルを設計する場合、一意に正しい回答は 1 つもありません。アプリケーションが異なれば、似たような概念でも異なる認証モデルを効果的に使用できますが、これは問題ありません。たとえば、コンピューターのファイルシステムの表現について考えます。Unix のようなオペレーティングシステムでファイルを作成する場合、親フォルダから自動的にアクセス許可を継承しません。これとは対照的に、他の多くのオペレーティングシステムやほとんどのオンラインファイル共有サービスでは、ファイルは親フォルダーの権限を継承します。どちらの選択肢も、アプリケーションが最適化する状況に応じて有効です。

認証ソリューションの正しさは絶対的なものではありませんが、顧客が求めるエクスペリエンスをどのように提供するか、また期待どおりにリソースを保護するかどうかという観点から考える必要があります。認証モデルがこれを実現できれば、成功と言えるでしょう。

そのため、望ましいユーザーエクスペリエンスから設計を開始することが、効果的な認証モデルを作成する上で最も役立つ前提条件となります。

API オペレーション以外のリソースに集中する

消費者向けのほとんどのアプリケーションでは、権限はアプリケーションがサポートするリソースをモデルにしています。たとえば、ファイル共有アプリケーションでは、権限をファイルまたはフォルダに対して実行できるアクションとして表現する場合があります。これは、基盤となる実装とバックエンドAPIオペレーションを抽象化する優れたシンプルなモデルです。

対照的に、他のタイプのアプリケーション、特にウェブサービスは、APIオペレーション自体に関するアクセス許可を頻繁に設計します。例えば、ウェブサービスが APIという名前のを提供する場合createThing()、認証モデルは対応するアクセス許可、またはという名前の Cedar actionのを定義できますcreateThing。これは多くの状況に当てはまり、権限を理解しやすくなります。createThingオペレーションを呼び出すには、createThingアクション権限が必要です。簡単でしょう？

Verified Permissions コンソールの開始Amazon Verified Permissions の開始方法プロセスには、から直接リソースとアクションを構築するオプションが含まれていますAPI。これは便利なベースラインです。ポリシーストアとポリシーストアが承認APIする間の直接マッピングです。

ただし、この APIに焦点を当てたアプローチは最適ではない場合があります。これは、 APIs が、顧客が真に保護しようとしているもの、つまり基盤となるデータとリソースのプロキシにすぎないためです。複数のが同じリソースへのアクセスAPIsを制御する場合、管理者がそれらのリソースへのパスについて推論し、それに応じてアクセスを管理するのは難しい場合があります。

たとえば、組織のメンバーを含むユーザーディレクトリを考えてみましょう。ユーザーはグループにまとめられますが、セキュリティ上の目標の 1 つは、権限のない第三者によるグループメンバーの発見を禁止することです。このユーザーディレクトリを管理するサービスには、次の 2 つのAPIオペレーションがあります。

listMembersOfGroup
listGroupMembershipsForUser

顧客は、これらの操作のいずれかを使用してグループメンバーシップを確認できます。そのため、権限管理者は両方の操作へのアクセスを調整することを忘れないようにする必要があります。後で次のような追加のユースケースに対応するために新しいAPIオペレーションを追加することを選択した場合、これはさらに複雑になります。

isUserInGroups （ユーザーが 1 つ以上のグループに属しているかどうかをすばやくテストAPIする新しい )

セキュリティの観点から見ると、グループメンバーシップを検出するための 3 番目のパスがAPI開き、慎重に作成された管理者のアクセス許可が中断されます。

API セマンティクスは無視し、基盤となるデータとリソース、およびそれらの関連付けオペレーションに集中することをお勧めします。このアプローチをグループメンバーシップの例に適用すると、などの抽象的なアクセス許可が生成されviewGroupMembershipます。この 3 つのAPIオペレーションはそれぞれを参照する必要があります。

API 名前	アクセス許可
`listMembersOfGroup`	グループに`viewGroupMembership`権限が必要です。
`listGroupMembershipsForUser`	ユーザーに`viewGroupMembership`権限が必要です。
`isUserInGroups`	ユーザーに`viewGroupMembership`権限が必要です。

この 1 つの権限を定義することで、管理者はグループメンバーシップを検索するためのアクセスを現在および永久に正常に制御できます。トレードオフとして、各APIオペレーションで必要になる可能性のある複数のアクセス許可を文書化し、管理者はアクセス許可を作成するときにこのドキュメントを参照する必要があります。セキュリティ要件を満たすために必要がある場合、これは有効なトレードオフになります。

複合認証は正常

複合認証とは、アプリケーションのインターフェースのボタンをクリックするなどの単一のユーザーアクティビティで、そのアクティビティが許可されているかどうかを判断するために複数の個別認証クエリが必要になる場合に発生します。たとえば、ファイルシステムの新しいディレクトリにファイルを移動する場合、ソースディレクトリからファイルを削除する権限、移動先ディレクトリにファイルを追加する権限、およびファイル自体を操作する権限 (アプリケーションによって異なります) という 3 つの異なる権限が必要になる場合があります。

認証モデルの設計に慣れていない場合、認証に関するすべての決定は 1 つの認証クエリで解決可能でなければならないと考えるかもしれません。しかし、これではモデルが過度に複雑になり、ポリシーステートメントが複雑になる可能性があります。実際には、複合認証を使用すると、より単純な認証モデルを作成するのに役立ちます。適切に設計された認証モデルの 1 つの基準は、個々のアクションを十分に分解すれば、ファイルの移動などの複合操作をプリミティブの直感的な集合体で表現できることです。

複合認証が発生するもう 1 つの状況は、権限を付与するプロセスに複数の関係者が関与する場合です。ユーザーがグループのメンバーになることができる組織ディレクトリを考えてみましょう。簡単な方法は、グループオーナーに誰でも追加できる権限を与えることです。しかし、まずユーザーに追加に同意してもらいたい場合はどうすればよいのでしょうか。これにより、ユーザーとグループの両方がメンバーシップに同意しなければならないというハンドシェイク契約が導入されます。これを実現するために、ユーザーにバインドされた別の権限を導入して、ユーザーを任意のグループに追加できるのか、特定のグループに追加できるのかを指定できます。呼び出し元が後でメンバーをグループに追加しようとする場合、アプリケーションは権限の両側を強制する必要があります。つまり、呼び出し元には指定されたグループにメンバーを追加する権限があり、追加される個々のユーザーには追加する権限があるということです。N ウェイハンドシェイクが存在する場合、合意の各部分を強制するために N 複合認証クエリを監視するのが一般的です。

複数のリソースが関わっていて、権限をモデル化する方法が不明な設計上の課題に直面している場合、複合認証シナリオを使用している可能性があります。このような場合は、操作を複数の個別認証チェックに分解することで解決策が見つかるかもしれません。

マルチテナンシーに関する考慮事項

アプリケーションを使用する企業やテナントなど、複数のお客様が使用するアプリケーションを開発し、Amazon Verified Permissions と統合したい場合があります。承認モデルを開発する前に、マルチテナント戦略を開発してください。顧客のポリシーは、1 つの共有ポリシーストア で管理することも、テナントごとのポリシーストア を割り当てることもできます。

1 つの共有ポリシーストア

すべてのテナントは 1 つのポリシーストアを共有します。アプリケーションは、すべての認証リクエストを共有ポリシーストアに送信します。
テナントごとのポリシーストア

各テナントには専用のポリシーストアがあります。アプリケーションは、リクエストを行うテナントに応じて、異なるポリシーストアに承認の決定をクエリします。

どちらの戦略も、 AWS 請求書に影響を与える可能性のある比較的大量の認証リクエストを作成しません。では、どのようにアプローチを設計すればよいでしょうか。以下は、Verified Permissions マルチテナンシー認証戦略の一因となる一般的な条件です。

テナントポリシーの分離: テナントデータを保護するためには、各テナントのポリシーを他のテナントから分離することが重要です。各テナントに独自のポリシーストアがある場合、それぞれに独自のポリシーセットがあります。
承認フロー: 承認リクエストを行うテナントは、テナントごとのポリシーストアを使用して、リクエスト内のポリシーストア ID で識別できます。共有ポリシーストアでは、すべてのリクエストが同じポリシーストア ID を使用します。
テンプレートとスキーマ管理: ポリシーテンプレートとポリシーストアスキーマは、各ポリシーストアに設計とメンテナンスのオーバーヘッドのレベルを追加します。
グローバルポリシー管理: 一部のグローバルポリシーをすべてのテナントに適用できます。グローバルポリシーの管理のオーバーヘッドレベルは、共有ポリシーストアモデルとテナントごとのポリシーストアモデルによって異なります。
テナントオフボーディング: 一部のテナントは、スキーマやポリシーに、そのケースに固有の要素を提供します。テナントが組織でアクティブでなくなり、データを削除する場合、労力のレベルは他のテナントからの分離のレベルによって異なります。
サービスリソースクォータ: Verified Permissions には、マルチテナンシーの決定に影響を与える可能性のあるリソースとリクエストレートのクォータがあります。クォータの詳細については、「リソースのクォータ」を参照してください。

共有ポリシーストアとテナントごとのポリシーストアの比較

各考慮事項では、共有ポリシーストアモデルとテナントごとのポリシーストアモデルで、独自の時間とリソースコミットメントのレベルが必要です。

考慮事項	共有ポリシーストアの労力レベル	テナントごとのポリシーストアの労力レベル
テナントポリシーの分離	Medium。ポリシーと承認リクエストにテナント識別子を含める必要があります。	低。分離はデフォルトの動作です。テナント固有のポリシーは、他のテナントからはアクセスできません。
承認フロー	低。すべてのクエリは 1 つのポリシーストアをターゲットとします。	Medium。各テナントとそのポリシーストア ID 間のマッピングを維持する必要があります。
テンプレートとスキーマ管理	低。すべてのテナントに対して 1 つのスキーマを機能させる必要があります。	高。スキーマとテンプレートは個別にはそれほど複雑ではないかもしれませんが、変更にはより多くの調整と複雑さが必要です。
グローバルポリシー管理	低。すべてのポリシーはグローバルで、一元的に更新できます。	高。オンボーディングの各ポリシーストアにグローバルポリシーを追加する必要があります。多くのポリシーストア間でグローバルポリシーの更新をレプリケートします。
テナントオフボーディング	Medium。テナント固有のポリシーのみを識別して削除する必要があります。	低。ポリシーストアを削除します。
サービスリソースクォータ	高。テナントは、スキーマサイズ、リソースあたりのポリシーサイズ、ポリシーストアあたりのアイデンティティソースなどのポリシーストアに影響するリソースクォータを共有します。	低。各テナントには専用のリソースクォータがあります。

選択方法

マルチテナントアプリケーションはそれぞれ異なります。アーキテクチャを決定する前に、2 つのアプローチとその考慮事項を慎重に比較してください。

アプリケーションがテナント固有のポリシーを必要とせず、単一の ID ソースを使用する場合、すべてのテナントに 1 つの共有ポリシーストアが最も効果的なソリューションである可能性があります。これにより、認証フローとグローバルポリシー管理が簡素化されます。アプリケーションはテナント固有のポリシーを削除する必要がないため、1 つの共有ポリシーストアを使用してテナントをオフボーディングする手間が省けます。

ただし、アプリケーションでテナント固有のポリシーが多数必要な場合、または複数の ID ソースを使用している場合、テナントごとのポリシーストアが最も効果的である可能性があります。テナントごとのアクセス許可を各ポリシーストアに付与する IAM ポリシーを使用して、テナントポリシーへのアクセスを制御できます。テナントのオフボーディングでは、ポリシーストアを削除する必要があります。 shared-policy-store環境では、テナント固有のポリシーを検索して削除する必要があります。

可能な場合は、ポリシースコープを入力します。

ポリシースコープは、Cedar ポリシーステートメントの permit または forbid キーワードの後と開き括弧の間にある部分です。

可能な限り、principalおよびresourceの値を入力することをお勧めします。これにより、Verified Permissions がポリシーをインデックス化してより効率的に取得できるようになり、パフォーマンスが向上します。同じアクセス権限を多くの異なるプリンシパルまたはリソースに付与する必要がある場合は、ポリシーテンプレートを使用してプリンシパルとリソースの各ペアに添付することをお勧めします。

1 つのwhen句にプリンシパルとリソースのリストを含む大規模なポリシーを 1つ作成することは避けてください。そうすると、スケーラビリティの限界や運用上の課題にぶつかる可能性があります。たとえば、ポリシー内の大きなリストから 1 人のユーザーを追加または削除するには、ポリシー全体を読み取り、リストを編集し、新しいポリシーをすべて記述し、ある管理者が別の管理者の変更を上書きした場合の同時実行エラーを処理する必要があります。対照的に、きめ細かな権限を多数使用すれば、ユーザーを追加または削除するのは、そのユーザーに適用される 1 つのポリシーを追加または削除するのと同じくらい簡単です。

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

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

プリンシパルをリソースコンテナから分離する

リソース階層を設計する際、特に消費者向けアプリケーションによくある傾向の 1 つは、顧客のユーザー ID を顧客アカウント内のリソースのコンテナとして使用することです。

この戦略はアンチパターンとして扱うことをおすすめします。これは、機能が豊富なアプリケーションでは、アクセスを他のユーザーに委任する傾向が自然にあるためです。たとえば、他のユーザーがアカウントリソースを共有できる「ファミリー」アカウントを導入することを選択できます。同様に、企業の顧客は、複数の従業員をアカウントの一部の運営者に指定したい場合があります。また、アカウントの所有権を別のユーザーに移したり、複数のアカウントのリソースを統合したりする必要が生じる場合もあります。

ユーザー ID をアカウントのリソースコンテナとして使用すると、以前のシナリオを実現するのが難しくなります。さらに憂慮すべき点は、この方法で他のユーザーにアカウントコンテナへのアクセス権が付与されると、ジェーンの電子メールやログイン認証情報の変更など、ユーザー ID 自体を変更するためのアクセス権限を誤って付与されてしまう可能性があることです。

そのため、可能な場合は、プリンシパルをリソースコンテナから切り離し、「管理者権限」や「所有権」などの概念を使用してプリンシパルをリソースコンテナから分離し、プリンシパル間の接続をモデル化するのがより回復力のあるアプローチです。

プリンシパルとリソースを、リソースを関連するプリンシパルにリンクするリソース属性で分離しました。

既存のアプリケーションではこのような切り離されたモデルを実現できない場合は、承認モデルを設計する際にできる限りそれを模倣することを検討することをおすすめします。たとえば、ユーザー ID、ログイン資格情報、および所有するリソースをカプセル化する Customer という名前の 1 つの概念だけを持つアプリケーションは、これを Customer Identity の 1 つの論理エンティティ (名前、電子メールなどを含む) を含む認可モデルにマッピングできます。 Customer Resources または Customer Account 用の別個の論理エンティティは、それらが所有するすべてのリソースの親ノードとして機能します。両方のエンティティは同じ Id を共有できますが、Type は異なります。

プリンシパルとリソースを分離し、より汎用的なリソースコンテナをプリンシパルに関連付けた。

属性またはテンプレートを使用して関係を表す

リソース間の関係を表現するには、主に 2 つの方法があります。一方または他方を使用するタイミングは、リレーションがアプリケーションデータベースにすでに保存されていて、コンプライアンスなどの他の理由で使用されているかどうかによって異なります。その場合は、属性ベースのアプローチを使用します。そうでない場合は、テンプレートベースのアプローチを取ります。

属性ベースの関係

属性は、プリンシパルと 1 つ以上のリソースの関係を表すための承認決定への入力として使用できます。

このパターンは、アクセス許可の管理だけでなく、関係が追跡および管理される場合に適しています。例えば、Know Your Customer ルールの財務コンプライアンスには、プライマリアカウント所有者の記録が必要です。アクセス許可は、これらの関係から派生します。関係データは認証システムの外部で管理され、認証の決定時に入力として取得されます。

次の例は、ユーザーがプライマリアカウント所有者であるAlice多数のアカウントとの関係をどのように表せるかを示しています。


// Using a user attribute to represent the primary account holder relationship 
{
  "id": "df82e4ad-949e-44cb-8acf-2d1acda71798",
  "name": "alice",  
  "email": "alice@example.com",  
  "primaryOnAccounts": [
    "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"",
    "Account::\"b8ee140c-fa09-46c3-992e-099438930894\""
  ]
}

そして、その後にポリシー内でその属性を使用する:


// Derived relationship permissions
  permit (
    principal,
    action in Action::"primaryAccountHolderActions",
    resource
  )when {
    resource in principal.primaryOnAccounts
  };

逆に、同じ関係を、ユーザーのセットprimaryAccountHoldersを含むというリソースの属性として表すことができます。

プリンシパルとリソースの間に複数のリレーションシップタイプがある場合、これらは異なる属性としてモデル化する必要があります。例えば、アカウントが署名者も承認でき、これらの個人がそのアカウントに対して異なるアクセス許可を持っている場合、これは別の属性として表されます。

上記の場合、は 3 番目のアカウントの署名権限者であるAlice可能性もあります。次の例は、この表現方法を示しています。


// Using user attributes to represent the primary account holder and authorized signatory relationships 
{
  "id": "df82e4ad-949e-44cb-8acf-2d1acda71798",
  "name": "alice",  
  "email": "alice@example.com",  
  "primaryOnAccounts": [
    "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"",
    "Account::\"b8ee140c-fa09-46c3-992e-099438930894\""
  ],
  "authorizedSignatoryOnAccounts": [
    "Account::\"661817a9-d478-4096-943d-4ef1e082d19a\""
  ]
}

対応するポリシーは次のとおりです。


// Derived relationship permissions

  permit (
    principal,
    action in Action::"primaryAccountHolderActions",
    resource
  )when {
    resource in principal.primaryOnAccounts
  };
  permit (
    principal,
    action in Action::"authorizedSignatoryActions",
    resource
  )when {
    resource in principal.authorizedSignatoryOnAccounts
  };

テンプレートベースの関係

リソース間の関係がアクセス許可管理のみを目的として存在する場合は、この関係をテンプレートにリンクされたポリシーまたはテンプレートとして保存することをお勧めします。これらのテンプレートは、特定のリソースに割り当てられたロールと考えることもできます。

例えば、ドキュメント管理システムでは、ドキュメント所有者はAlice、別のユーザーにドキュメントに貢献Bobするためのアクセス許可を付与することを選択できます。これにより、Bob と Alice のドキュメントの間の寄稿者の関係が確立されます。この関係の唯一の目的は、ドキュメントを編集してコメントするアクセス許可を付与することであるため、この関係はテンプレートとして表現できます。このような場合、推奨されるアプローチは、関係のタイプごとにテンプレートを作成することです。次の例では、 Contributorとの 2 つのリレーションシップタイプがあるためReviewer、2 つのテンプレートがあります。

次のテンプレートを使用して、個々のユーザー用のテンプレートにリンクされたポリシーを作成できます。


  // Managed relationship permissions - Contributor template
  permit (
    principal == ?principal,  
    action in Action::"DocumentContributorActions",
    resource in ?resource
  );
    
  // Managed relationship permissions - Reviewer template
  permit (
    principal == ?principal,  
    action in Action::"DocumentReviewerActions",
    resource in ?resource
  );

次のテンプレートを使用して、ユーザーのグループのテンプレートにリンクされたポリシーを作成できます。個々のユーザーのテンプレートとの違いは、の代わりに in演算子を使用することだけです==。


  // Managed relationship permissions - Contributor template
  permit (
    principal in ?principal,  
    action in Action::"DocumentContributorActions",
    resource in ?resource
  );

  // Managed relationship permissions - Reviewer template
  permit (
    principal in ?principal,  
    action in Action::"DocumentReviewerActions",
    resource in ?resource
  );

その後、これらのテンプレートを使用して、ドキュメントへのアクセスが付与されるたびに管理関係のアクセス許可を表す、次のようなポリシーを作成できます。


  //Managed relationship permissions
  permit (
    principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",  
    action in Action::"DocumentContributorActions",
    resource in Document::"c943927f-d803-4f40-9a53-7740272cb969"
  );

  permit (
    principal in UserGroup::"df82e4ad-949e-44cb-8acf-2d1acda71798",
    action in Action::"DocumentReviewerActions",
    resource == Document::"661817a9-d478-4096-943d-4ef1e082d19a"
  );

  permit (
    principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",
    action in Action::"DocumentContributorActions",
    resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894"
  );

Amazon Verified Permissions は、認証評価中およびモノのモデリング中に、きめ細かなポリシーの多くを効率的に処理できます。つまり、Verified Permissions は AWS CloudTrail、すべての認証決定の監査ログをに保持します。

モデルではきめ細かな権限を、ユーザーインターフェースでは集約した権限を優先します

設計者が後で後悔することが多い戦略の 1 つは、Read や Write などの非常に広範なアクションを含む認可モデルを設計し、後でより詳細なアクションが必要であることに気づくことです。より細かい詳細度の必要性は、よりきめ細かいアクセス制御を求める顧客のフィードバックによって、または最小権限のアクセス許可を奨励するコンプライアンスおよびセキュリティ監査によって促進される可能性があります。

きめ細かい権限があらかじめ定義されていないと、アプリケーションコードやポリシーステートメントをユーザーによりきめ細かく設定した権限に変更するために、複雑な変換が必要になる可能性があります。たとえば、以前にコースベースのアクションに対して承認されたアプリケーションコードを、詳細なアクションを使用するように変更する必要があります。さらに、移行を反映するようにポリシーを更新する必要があります。


permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    // action  ==  Action::"read",              -- coarse-grained permission -- commented out
    action in [                       //        -- finer grained permissions
        Action::"listFolderContents", 
        Action::"viewFile"
    ],
    resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

このようなコストのかかる移行を回避するには、事前にきめ細かい権限を定義したほうがよいでしょう。ただし、後でエンドユーザーが多数のきめ細かい権限を理解せざるを得なくなった場合、特にほとんどの顧客がReadやWriteなどのきめ細かな制御に満足している場合、これはトレードオフにつながる可能性があります。両方の利点を最大限に活用するには、ポリシーテンプレートやアクショングループなどのメカニズムを使用して、きめ細かいアクセス許可を Read や Write などの事前定義されたコレクションにグループ化できます。このアプローチを使用すると、顧客にはコースベースの権限のみが表示されます。しかし、舞台裏では、きめ細かなアクセス許可を粒度の細かいアクションの集合としてモデル化することで、アプリケーションの将来性を確保しています。顧客または監査人のどちらかが要求すると、きめ細かい権限が公開される可能性があります。

認証を問い合わせる他の理由も検討してください

通常、承認チェックはユーザーのリクエストと関連付けられます。このチェックは、ユーザーにそのリクエストを実行する権限があるかどうかを判断する方法です。ただし、認証データを使用してアプリケーションのインターフェースの設計に影響を与えることもできます。たとえば、エンドユーザーがアクセスできるリソースのみのリストを表示するホーム画面を表示したい場合があります。リソースの詳細を表示するときに、ユーザーがそのリソースに対して実行できる操作だけをインターフェースに表示したい場合があります。

このような状況では、承認モデルにトレードオフが生じる可能性があります。例えば、属性ベースのアクセスコントロール (ABAC) ポリシーに大きく依存すると、「誰が何にアクセスできるか」という質問にすぐに答えるのが難しくなる可能性があります。これは、その質問に答えるには、各ルールをすべてのプリンシパルとリソースと照らし合わせて調べ、一致するものがあるかどうかを判断する必要があるからです。その結果、ユーザーがアクセス可能なリソースのみを一覧表示するために最適化する必要がある製品は、ロールベースのアクセスコントロール (RBAC) モデルを使用することを選択できます。を使用するとRBAC、ユーザーにアタッチされたすべてのポリシーを繰り返し処理して、リソースへのアクセスを判断することが容易になります。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

APIにリンクされたポリシーストアを作成する

ポリシーストア