翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
アプリケーションの認証モデルの設計
ソフトウェアアプリケーション内で Amazon Verified Permissions サービスを使用する準備をしていると、最初のステップとしてポリシーステートメントをすぐに作成するのが難しい場合があります。これは、アプリケーションが何をすべきかを完全に決定する前に、SQL ステートメントや API 仕様を記述して、アプリケーションの他の部分の開発を開始するのと似ています。代わりに、ユーザーエクスペリエンスから始めて、アプリケーション UI で権限を管理する際にエンドユーザーに表示されるべき内容を明確に理解する必要があります。次に、その経験から逆算して実装アプローチにたどり着きます。
この作業を進めていくと、次のような質問をすることになります。
-
私のリソースは何でしょうか？ それらは互いに関係を持っていますか？ たとえば、ファイルはフォルダ内に存在しますか?
-
プリンシパルは各リソースに対してどのようなアクションを実行できますか?
-
プリンシパルはどのようにしてこれらの権限を取得するのでしょうか?
-
エンドユーザーに「Admin」、「Operator」、ReadOnly「」などの事前定義されたアクセス許可から選択させたいですか、それともアドホックポリシーステートメントを作成すべきですか？ それとも両方一緒ですか？
-
親フォルダから権限を継承するファイルなど、権限はリソース全体に継承されるべきですか?
-
ユーザーエクスペリエンスを実現するためにはどのような種類のクエリが必要ですか? たとえば、プリンシパルがそのユーザーのホームページを表示するためにアクセスできるすべてのリソースを一覧表示する必要があるでしょうか？
-
ユーザーが誤って自分のリソースからロックアウトされてしまうことはありませんか? それを回避する必要がありますか？
この作業の最終成果は承認モデルと呼ばれ、プリンシパル、リソース、アクションを定義し、それらがどのように相互に関連しているかを定義します。このモデルを作成するのに、Cedar や Verified Permissions サービスに関する独自の知識は必要ありません。その代わり、他のモデルと同様、何よりもまずユーザーエクスペリエンスの設計作業であり、インターフェースのモックアップ、論理図、権限が製品内でユーザーに表示される内容にどのように影響するかについての全体的な説明などの成果物として現れることがあります。Cedar は、Cedar の実装に合わせてモデルを不自然に曲げさせるのではなく、あるモデルで顧客に対応できる柔軟性を備えるように設計されています。そのため、希望するユーザー体験を的確に把握することが、最適なモデルを導き出す最善の方法です。
このセクションでは、設計作業への取り組み方、注意すべき点、検証済み権限をうまく使用するためのベストプラクティスに関する一般的なガイダンスを提供します。
ここで紹介するガイドラインに加えて、Cedar ポリシー言語リファレンスガイドのベストプラクティス
トピック
