翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 認可モデルを設計するためのベストプラクティス
ソフトウェアアプリケーション内で Amazon Verified Permissions サービスを使用する準備をしていると、最初のステップとしてポリシーステートメントをすぐに作成するのが難しい場合があります。これは、アプリケーションが何をすべきかを完全に決定する前に、SQL ステートメントや API 仕様を記述して、アプリケーションの他の部分の開発を開始するのと似ています。代わりに、ユーザーエクスペリエンスから始める必要があります。次に、その経験から逆算して実装アプローチにたどり着きます。
この作業を進めていくと、次のような質問をすることになります。
+ 私のリソースは何でしょうか？ どのように整理されていますか? たとえば、ファイルはフォルダ内に存在しますか?
+ リソースの組織はアクセス許可モデルに関与していますか?
+ プリンシパルは各リソースに対してどのようなアクションを実行できますか?
+ プリンシパルはどのようにしてこれらの権限を取得するのでしょうか?
+ エンドユーザーに「管理者」、「オペレーター」、「ReadOnly」などの定義済みの権限から選択してもらいたいですか、それともアドホックなポリシーステートメントを作成すべきですか？ それとも両方一緒ですか？
+ ロールはグローバルですか、それともスコープ内ですか? たとえば、「オペレータ」は単一のテナント内で制限されていますか、「オペレータ」はアプリケーション全体でオペレータを意味しますか?
+ ユーザーエクスペリエンスを実現するためにはどのような種類のクエリが必要ですか? たとえば、プリンシパルがそのユーザーのホームページを表示するためにアクセスできるすべてのリソースを一覧表示する必要があるでしょうか？
+ ユーザーが誤って自分のリソースからロックアウトされてしまうことはありませんか? それを回避する必要がありますか？
**この作業の最終成果は承認モデルと呼ばれ**、プリンシパル、リソース、アクションを定義し、それらがどのように相互に関連しているかを定義します。このモデルを作成するのに、Cedar や Verified Permissions サービスに関する独自の知識は必要ありません。代わりに、何よりもまず、他のものと同様に、ユーザーエクスペリエンス設計の演習であり、インターフェイスモックアップ、論理図、アクセス許可が製品でユーザーができることにどのように影響するかの全体的な説明などのアーティファクトにマニフェストできます。Cedar は、Cedar の実装に合わせてモデルを不自然に曲げさせるのではなく、あるモデルで顧客に対応できる柔軟性を備えるように設計されています。そのため、希望するユーザー体験を的確に把握することが、最適なモデルを導き出す最善の方法です。
質問に答えて最適なモデルにたどり着くには、次の操作を行います。
+ [Cedar ポリシー言語リファレンスガイドの「Cedar 設計パターン](https://docs.cedarpolicy.com/overview/patterns.html)」を参照してください。
+ Cedar ポリシー言語リファレンスガイドの[ベストプラクティス](https://docs.cedarpolicy.com/bestpractices/bp-naming-conventions.html)を検討してください。
+ このページに含まれるベストプラクティスを検討してください。
**Topics**
+ [正規の「正しい」モデルはありません](#design-no-canonical-correct-model)
+ [404 個の見つからないエラーではなく、403 個の禁止エラーを返す](#resource-existence-errors)
+ [API オペレーション以外のリソースに集中する](#design-focus-on-data-beyond-apis)
+ [マルチテナンシーに関する考慮事項](#design-multi-tenancy-considerations)
## 正規の「正しい」モデルはありません
認可モデルを設計する場合、単一の一意に正しい回答はありません。アプリケーションが異なれば、似たような概念でも異なる認可モデルを効果的に使用できますが、これは問題ありません。たとえば、コンピューターのファイルシステムの表現について考えます。Unix のようなオペレーティングシステムでファイルを作成する場合、親フォルダからアクセス許可を自動的に継承しません。これとは対照的に、他の多くのオペレーティングシステムやほとんどのオンラインファイル共有サービスでは、ファイルは親フォルダーの権限を継承します。どちらの選択肢も、アプリケーションが最適化する状況に応じて有効です。
認可ソリューションの正しさは絶対的なものではありませんが、顧客が求めるエクスペリエンスをどのように提供するか、また期待どおりにリソースを保護するかどうかという観点から考える必要があります。認可モデルがこれを実現できれば、成功と言えるでしょう。
そのため、望ましいユーザーエクスペリエンスから設計を開始することが、効果的な認可モデルを作成する上で最も役立つ前提条件となります。
## 404 個の見つからないエラーではなく、403 個の禁止エラーを返す
エンティティ、特に 4*04 Not found エラーではなくポリシーに対応していないリソースを含むリクエストには、403 Forbidden* エラーを返すことをお勧めします。 **これにより、リクエストがポリシーストア内のポリシーのポリシー条件を満たしていないだけで、エンティティが存在するかどうかを公開しないため、最高レベルのセキュリティが提供されます。
## API オペレーション以外のリソースに集中する
ほとんどのアプリケーションでは、アクセス許可はサポートされているリソースを中心にモデル化されています。たとえば、ファイル共有アプリケーションでは、権限をファイルまたはフォルダに対して実行できるアクションとして表現する場合があります。これは、基礎となる実装とバックエンド API 操作を抽象化した、優れた、シンプルなモデルです。
これとは対照的に、他の種類のアプリケーション、特にウェブサービスでは、API 操作自体を中心に権限を設計することがよくあります。たとえば、Web サービスが `createThing()` という名前の API を提供する場合、認可モデルは対応する権限、または Cedar の `createThing` という名前の `action` を定義する可能性があります。これは多くの状況に当てはまり、権限を理解しやすくなります。`createThing`オペレーションを呼び出すには、`createThing`アクション権限が必要です。簡単でしょう？
Verified Permissions コンソール[の開始](getting-started-first-policy-store.md)プロセスには、API から直接リソースとアクションを構築するオプションが含まれています。これは便利なベースラインです。ポリシーストアとポリシーストアが認可する API 間の直接マッピングです。
ただし、モデルをさらに開発するとき、API はお客様が本当に保護しようとしているもの、つまり基盤となるデータとリソースのプロキシにすぎないため、この APIs に焦点を当てたアプローチは、非常に詳細な認可モデルを持つアプリケーションには適していない可能性があります。複数の API が同じリソースへのアクセスを制御している場合、管理者がそれらのリソースへのパスを判断し、それに応じてアクセスを管理することが難しくなる可能性があります。
たとえば、組織のメンバーを含むユーザーディレクトリを考えてみましょう。ユーザーはグループにまとめられますが、セキュリティ上の目標の 1 つは、権限のない第三者によるグループメンバーの発見を禁止することです。このユーザーディレクトリを管理するサービスには、次の 2 つの API オペレーションがあります。
+ `listMembersOfGroup`
+ `listGroupMembershipsForUser`
顧客は、これらの操作のいずれかを使用してグループメンバーシップを確認できます。そのため、権限管理者は*両方*の操作へのアクセスを調整することを忘れないようにする必要があります。次のような他のユースケースに対応するために後から新しい API オペレーションを追加することになった場合、これはさらに複雑になります。
+ `isUserInGroups`*(ユーザーが 1 つ以上のグループに属しているかどうかをすばやくテストするための新しい API)*
セキュリティの観点から見ると、この API はグループメンバーシップを発見するための 3 つ目の方法となり、管理者が巧妙に作り上げた権限を妨害することになります。
基盤となるデータとリソース、およびそれらの関連付けオペレーションに集中することをお勧めします。この方法をグループメンバーシップの例に適用すると、3 つの API オペレーションがそれぞれ参照しなければならないような`viewGroupMembership`、抽象的な権限になってしまいます。
| API 名 | アクセス許可 |
| --- | --- |
| listMembersOfGroup | グループにviewGroupMembership権限が必要です。 |
| listGroupMembershipsForUser | ユーザーにviewGroupMembership権限が必要です。 |
| isUserInGroups | ユーザーにviewGroupMembership権限が必要です。 |
この 1 つの権限を定義することで、管理者はグループメンバーシップを検索するためのアクセスを現在および永久に正常に制御できます。トレードオフとして、各 API 操作で必要になる可能性のある複数の権限を文書化する必要があります。管理者は権限を作成する際にこのドキュメントを参照する必要があります。セキュリティ要件を満たすために必要がある場合、これは有効なトレードオフになります。
## マルチテナンシーに関する考慮事項
アプリケーションを使用する企業や*テナント*など、複数の顧客が使用するアプリケーションを開発し、Amazon Verified Permissions と統合することもできます。認可モデルを開発する前に、マルチテナント戦略を開発してください。顧客のポリシーは、1 *つの共有ポリシーストア*で管理することも、*テナントごとのポリシーストア*を割り当てることもできます。詳細については、「 規範ガイダンス」の[「Amazon Verified Permissions マルチテナント設計上の考慮事項](https://docs.aws.amazon.com/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/avp-design-considerations.html)」を参照してください。 *AWS *
1.
**1 つの共有ポリシーストア**
すべてのテナントは 1 つのポリシーストアを共有します。アプリケーションは、すべての認可リクエストを共有ポリシーストアに送信します。
1.
**テナントごとのポリシーストア**
各テナントには専用のポリシーストアがあります。アプリケーションは、リクエストを行うテナントに応じて、異なるポリシーストアに承認の決定をクエリします。
どちらの戦略も AWS 請求書に大きな影響を与えません。では、どのようにアプローチを設計すべきですか? 以下は、Verified Permissions マルチテナンシー認可戦略に寄与する可能性のある一般的な条件です。
**テナントポリシーの分離**
テナントデータを保護するためには、各テナントのポリシーを他のテナントから分離することが重要です。各テナントに独自のポリシーストアがある場合、それぞれに独自のポリシーセットがあります。
**認可フロー**
承認リクエストを行うテナントは、リクエスト内のポリシーストア ID とテナントごとのポリシーストアで識別できます。共有ポリシーストアでは、すべてのリクエストが同じポリシーストア ID を使用します。
**テンプレートとスキーマの管理**
アプリケーションに複数のポリシーストアがある場合、[ポリシーテンプレート](policy-templates.md)と[ポリシーストアスキーマ](schema.md)は、各ポリシーストアに設計とメンテナンスのオーバーヘッドのレベルを追加します。
**グローバルポリシー管理**
一部の*グローバル*ポリシーをすべてのテナントに適用できます。グローバルポリシーの管理のオーバーヘッドレベルは、共有ポリシーストアモデルとテナントごとのポリシーストアモデルによって異なります。
**テナントのオフボーディング**
一部のテナントは、そのケースに固有のスキーマとポリシーに要素を提供します。テナントが組織でアクティブでなくなり、データを削除する場合、労力のレベルは他のテナントからの分離のレベルによって異なります。
**サービスリソースクォータ**
Verified Permissions には、マルチテナンシーの決定に影響を与える可能性のあるリソースとリクエストレートのクォータがあります。クォータの詳細については、「[リソースのクォータ](quotas.md#quotas-resources)」を参照してください。
### 共有ポリシーストアとテナントごとのポリシーストアの比較
各考慮事項には、共有ポリシーストアモデルとテナントごとのポリシーストアモデルにおける独自の時間とリソースコミットメントのレベルが必要です。
|
|
| 考慮事項 | 共有ポリシーストアの労力レベル | テナントごとのポリシーストアの労力レベル |
| --- |--- |--- |
| テナントポリシーの分離 | Medium。Must include tenant identifiers in policies and authorization requests. | 低。 Isolation is default behavior. Tenant-specific policies are inaccessible to other tenants. |
| 認可フロー | 低。 All queries target one policy store. | Medium。 Must maintain mappings between each tenant and their policy store ID. |
| テンプレートとスキーマの管理 | 低。 Must make one schema work for all tenants. | 高 Schemas and templates might be less complex individually, but changes require more coordination and complexity. |
| グローバルポリシー管理 | 低。 All policies are global and can be centrally updated. | 高 You must add global policies to each policy store in onboarding. Replicate global policy updates between many policy stores. |
| テナントのオフボーディング | 高 Must identify and delete only tenant-specific policies. | 低。 Delete the policy store. |
| サービスリソースクォータ | 高 Tenants share resource quotas that affect policy stores like schema size, policy size per resource, and identity sources per policy store. | 低。 Each tenant has dedicated resource quotas. |
### 選択方法
マルチテナントアプリケーションはそれぞれ異なります。アーキテクチャを決定する前に、2 つのアプローチとその考慮事項を慎重に比較します。
アプリケーションがテナント固有のポリシーを必要とせず、単一の [ID ソース](identity-sources.md#identity-sources.title)を使用する場合、すべてのテナントに対して 1 つの共有ポリシーストアが最も効果的なソリューションである可能性があります。これにより、認可フローとグローバルポリシー管理が簡素化されます。1 つの共有ポリシーストアを使用してテナントをオフボーディングする場合、アプリケーションがテナント固有のポリシーを削除する必要がないため、より少ない労力で済みます。
ただし、アプリケーションが多くのテナント固有のポリシーを必要とする場合、または複数の [ID ソース](identity-sources.md#identity-sources.title)を使用する場合、テナントごとのポリシーストアが最も効果的である可能性があります。テナントごとのアクセス許可を各ポリシーストアに付与する IAM ポリシーを使用して、テナントポリシーへのアクセスを制御できます。テナントのオフボーディングにはポリシーストアの削除が含まれます。shared-policy-store環境では、テナント固有のポリシーを見つけて削除する必要があります。