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

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

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

• 私のリソースは何でしょうか？ どのように整理されていますか？ たとえば、ファイルはフォルダ内に存在しますか?

• リソースの組織は、アクセス許可モデルに関与していますか？

• プリンシパルは各リソースに対してどのようなアクションを実行できますか?

• プリンシパルはどのようにしてこれらの権限を取得するのでしょうか?

• エンドユーザーは「管理者」、「オペレータ」、ReadOnly「」などの事前定義されたアクセス許可から選択するか、アドホックポリシーステートメントを作成する必要がありますか？ それとも両方一緒ですか？

• ロールはグローバルですか、それともスコープ対象ですか？ 例えば、「オペレータ」は 1 つのテナント内で制限されていますか、「オペレータ」はアプリケーション全体のオペレータを意味しますか？

• ユーザーエクスペリエンスを実現するためにはどのような種類のクエリが必要ですか? たとえば、プリンシパルがそのユーザーのホームページを表示するためにアクセスできるすべてのリソースを一覧表示する必要があるでしょうか？

• ユーザーが誤って自分のリソースからロックアウトされてしまうことはありませんか? それを回避する必要がありますか？

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

質問に答えて最適なモデルになるには、以下を実行します。

• Cedar ポリシー言語リファレンスガイドの「Cedar 設計パターン」を参照してください。

• Cedar ポリシー言語リファレンスガイドのベストプラクティスを検討してください。

• このページに含まれるベストプラクティスを検討してください。

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

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

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

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

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

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

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

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

ただし、モデルをさらに開発するにつれて、この APIに焦点を当てたアプローチは、顧客が本当に保護しようとしているもの、つまり基盤となるデータとリソースのプロキシAPIsにすぎないため、非常に詳細な承認モデルを持つアプリケーションには適していない可能性があります。同じリソースへの複数のAPIsコントロールアクセスがある場合、管理者がそれらのリソースへのパスについて理由を説明し、それに応じてアクセスを管理することは困難です。

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

• listMembersOfGroup

• listGroupMembershipsForUser

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

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

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

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

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

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

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

アプリケーションを使用する企業やテナントなど、複数の顧客が使用するアプリケーションを開発し、Amazon Verified Permissions と統合したい場合があります。認可モデルを開発する前に、マルチテナント戦略を開発してください。顧客のポリシーを 1 つの共有ポリシーストア で管理することも、テナントごとのポリシーストア を割り当てることもできます。詳細については、AWS 「規範ガイダンス」の「Amazon Verified Permissions マルチテナント設計に関する考慮事項」を参照してください。

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

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

2. テナントごとのポリシーストア

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

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

テナントポリシーの分離

テナントデータを保護するためには、各テナントのポリシーを他のテナントから分離することが重要です。各テナントに独自のポリシーストアがある場合、それぞれに独自のポリシーセットがあります。

認証フロー

承認リクエストを行うテナントは、リクエスト内のポリシーストア ID とテナントごとのポリシーストアで識別できます。共有ポリシーストアでは、すべてのリクエストが同じポリシーストア ID を使用します。

テンプレートとスキーマの管理

アプリケーションに複数のポリシーストアがある場合、ポリシーテンプレートとポリシーストアスキーマは、各ポリシーストアに設計とメンテナンスのオーバーヘッドのレベルを追加します。

グローバルポリシー管理

一部のグローバルポリシーをすべてのテナントに適用できます。グローバルポリシーの管理のオーバーヘッドレベルは、共有ポリシーストアモデルとテナントごとのポリシーストアモデルによって異なります。

テナントオフボーディング

一部のテナントは、ケースに固有のスキーマとポリシーに要素を提供します。テナントが組織でアクティブでなくなり、データを削除する場合、労力のレベルは他のテナントからの分離のレベルによって異なります。

サービスリソースクォータ

Verified Permissions には、マルチテナンシーの決定に影響を与える可能性のあるリソースとリクエストレートのクォータがあります。クォータの詳細については、「リソースのクォータ」を参照してください。

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

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

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

選択方法

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

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

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