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

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

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

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

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

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

どちらの戦略も、AWS請求に影響する可能性のある比較的大量の承認リクエストを作成します。では、どのようにアプローチを設計すべきですか？ Verified Permissions マルチテナンシー認証戦略に影響する可能性のある一般的な条件を次に示します。

テナントポリシーの分離

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

認証フロー

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

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

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

グローバルポリシー管理

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

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

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

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

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

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

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

考慮事項	共有ポリシーストアのエフォートレベル	テナントごとのポリシーストアのエフォートレベル
テナントポリシーの分離	中。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.	中。 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 ソース を使用する場合、すべてのテナントに 1 つの共有ポリシーストアが最も効果的なソリューションです。これにより、承認フローとグローバルポリシー管理がよりシンプルになります。1 つの共有ポリシーストアを使用してテナントをオフオンボーディングすると、アプリケーションがテナント固有のポリシーを削除する必要がないため、労力が軽減されます。

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