翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Verified Permissions マルチテナント設計に関する考慮事項 マルチテナント SaaS ソリューションで Amazon Verified Permissions を使用して認可を実装するときに考慮すべき設計オプションがいくつかあります。これらのオプションを検討する前に、マルチテナント SaaS コンテキストでの*分離*と*認可*の違いを明確にしましょう。テナントを[分離すると](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html)、インバウンドデータとアウトバウンドデータが間違ったテナントに公開されるのを防ぐことができます。認可により、ユーザーにテナントへのアクセス許可が付与されます。 Verified Permissions では、ポリシーはポリシーストアに保存されます。[Verified Permissions ドキュメント](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/design-multi-tenancy-considerations.html)で説明されているように、テナントごとに個別のポリシーストアを使用してテナントのポリシーを分離するか、すべてのテナントに単一のポリシーストアを使用してテナントにポリシーの共有を許可できます。このセクションでは、これら 2 つの分離戦略の利点と欠点について説明し、階層型デプロイモデルを使用してデプロイする方法を説明します。その他のコンテキストについては、Verified Permissions ドキュメントを参照してください。 このセクションで説明する基準は Verified Permissions に焦点を当てていますが、一般的な概念は[分離の考え方](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/isolation-mindset.html)とそれが提供するガイダンスに基づいています。SaaS アプリケーションは常に[テナント分離](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html)を設計の一部として考慮する必要があります。この一般的な分離の原則は、SaaS アプリケーションに Verified Permissions を含めることにも及びます。このセクションでは、サイロ化された SaaS モデルや[プールされた SaaS モデルなどのコア SaaS ](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html)分離モデルも参照します。 [ SaaS ](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) 詳細については、 AWS 「 Well-Architected フレームワーク、SaaS レンズ」の[「コア分離の概念](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html)」を参照してください。 マルチテナント SaaS ソリューションを設計する際の主な考慮事項は、テナント分離とテナントオンボーディングです。テナントの分離は、セキュリティ、プライバシー、耐障害性、パフォーマンスに影響します。テナントオンボーディングは、運用オーバーヘッドとオブザーバビリティに関連する運用プロセスに影響します。SaaS ジャーニーを実行したり、マルチテナントソリューションを実装したりする組織は、SaaS アプリケーションによるテナンシーの処理方法を常に優先する必要があります。SaaS ソリューションは特定の分離モデルに傾いている可能性がありますが、SaaS ソリューション全体で必ずしも一貫性が必要なわけではありません。たとえば、アプリケーションのフロントエンドコンポーネント用に選択した 分離モデルは、マイクロサービスまたは認可サービス用に選択した分離モデルとは異なる場合があります。 **Topics** + [テナントオンボーディングとユーザーテナント登録](avp-design-onboarding-registration.md) + [テナントごとのポリシーストア](avp-design-per-tenant-store.md) + [1 つの共有マルチテナントポリシーストア](avp-design-shared-store.md) + [階層型デプロイモデル](avp-design-tiered.md) # テナントオンボーディングとユーザーテナント登録 SaaS アプリケーションは [SaaS アイデンティティ](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-identity.html)の概念に従い、[ユーザーアイデンティティをテナントアイデンティティにバインド](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/general-design-principles.html)するという一般的なベストプラクティスに従います。バインドでは、テナント識別子を ID プロバイダーのユーザーのクレームまたは属性として保存します。これにより、ID をテナントにマッピングする責任が各アプリケーションからユーザー登録プロセスに移行されます。その後、認証された各ユーザーは、JSON ウェブトークン (JWT) の一部として正しいテナント ID を持ちます。 同様に、認可リクエストの正しいポリシーストアの選択は、アプリケーションロジックによって決定しないでください。特定の認可リクエストで使用するポリシーストアを決定するには、ユーザーのポリシーストアへのマッピング、またはテナントのポリシーストアへのマッピングを維持します。これらのマッピングは通常、アプリケーションが参照する Amazon DynamoDB や Amazon Relational Database Service (Amazon RDS) などのデータストアに保持されます。これらのマッピングを ID プロバイダー (IdP) のデータで提供または補足することもできます。テナント、ユーザー、ポリシーストア間の関係は通常、認可リクエストに必要なすべての関係を含む JWT を通じてユーザーに提供されます。 この例では、テナントに属`TenantA`し`Alice`、承認`ps-43214321`のためにポリシーストア ID を持つポリシーストアを使用するユーザー に対して JWT がどのように表示されるかを示します。 ``` { "sub":"1234567890", "name":"Alice", "tenant":"TenantA", "policyStoreId":"ps-43214321" } ``` # テナントごとのポリシーストア Amazon Verified Permissions のテナントごとのポリシーストア設計モデルは、SaaS アプリケーションの各テナントを独自のポリシーストアに関連付けます。このモデルは、SaaS [サイロ分離](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html)モデルと似ています。どちらのモデルもテナント固有のインフラストラクチャの作成を義務付けており、同様の利点と欠点があります。このアプローチの主な利点は、インフラストラクチャが強制するテナントの分離、テナントごとに固有の認可モデルのサポート、[ノイズの多い近隣の](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html)懸念の排除、ポリシーの更新やデプロイにおける障害の影響範囲の縮小です。このアプローチの欠点には、より複雑なテナントオンボーディングプロセス、デプロイ、運用などがあります。テナントごとのポリシーストアは、ソリューションにテナントごとに一意のポリシーがある場合に推奨されるアプローチです。 SaaS アプリケーションが必要とする場合、テナントごとのポリシーストアモデルは、テナント分離に対して高度にサイロ化されたアプローチを提供できます。[プール分離](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html)でこのモデルを使用することもできますが、Verified Permissions の実装では、管理やオペレーションの簡素化など、より広範なプール分離モデルの標準的な利点は共有されません。 テナントごとのポリシーストアでは、前述のように、テナントのポリシーストア識別子をユーザー登録プロセス中にユーザーの SaaS ID にマッピングすることで、テナントの分離が達成されます。このアプローチは、テナントのポリシーストアをユーザープリンシパルに強く結び付け、SaaS ソリューション 全体でマッピングを共有する一貫した方法を提供します。マッピングを IdP の一部として、または DynamoDB などの外部データソースに維持することで、SaaS アプリケーションへのマッピングを提供できます。これにより、プリンシパルがテナントの一部であること、およびテナントのポリシーストアが使用されることも保証されます。 この例では、`tenant`ユーザーの `policyStoreId`と を含む JWT が API エンドポイントから AWS Lambda オーソライザーのポリシー評価ポイントに渡され、リクエストが正しいポリシーストアにルーティングされる方法を示します。 ![\[Amazon Verified Permissions のテナントごとのポリシーストアモデル\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-per-tenant.png) 次のサンプルポリシーは、テナントごとのポリシーストア設計パラダイムを示しています。ユーザーは に`Alice`属しています。policyStoreId `TenantA.` `store-a`は のテナント ID にもマッピング`Alice,`され、正しいポリシーストアの使用を強制します。これにより、 のポリシー`TenantA`が使用されます。 **注記** テナントごとのポリシーストアモデルは、テナントのポリシーを分離します。認可は、ユーザーがデータに対して実行できるアクションを適用します。このモデルを使用する架空のアプリケーションに関連するリソースは、[AWS Well-Architected Framework、SaaS レンズドキュメント](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html)で定義されているように、他の分離メカニズムを使用して分離する必要があります。 このポリシーでは、 `Alice`にはすべてのリソースのデータを表示するアクセス許可があります。 ``` permit ( principal == MultiTenantApp::User::"Alice", action == MultiTenantApp::Action::"viewData", resource ); ``` 認可リクエストを行い、Verified Permissions ポリシーを使用して評価を開始するには、テナントにマッピングされた一意の ID に対応するポリシーストア ID を指定する必要があります`store-a`。 ``` { "policyStoreId":"store-a", "principal":{ "entityType":"MultiTenantApp::User", "entityId":"Alice" }, "action":{ "actionType":"MultiTenantApp::Action", "actionId":"viewData" }, "resource":{ "entityType":"MultiTenantApp::Data", "entityId":"my_example_data" }, "entities":{ "entityList":[ [ { "identifier":{ "entityType":"MultiTenantApp::User", "entityId":"Alice" }, "attributes":{}, "parents":[] }, { "identifier":{ "entityType":"MultiTenantApp::Data", "entityId":"my_example_data" }, "attributes":{}, "parents":[] } ] ] } } ``` ユーザーはテナント B に`Bob`属し、policyStoreId `store-b`は のテナント ID にもマッピングされるため`Bob`、正しいポリシーストアが使用されます。これにより、テナント B のポリシーが使用されます。 このポリシーでは、 `Bob`にはすべてのリソースのデータをカスタマイズするアクセス許可があります。この例では、 はテナント B にのみ固有の`customizeData`アクションである可能性があるため、ポリシーはテナント B に対して一意になります。テナントごとのポリシーストアモデルは、テナントごとに本質的にカスタムポリシーをサポートします。 ``` permit ( principal == MultiTenantApp::User::"Bob", action == MultiTenantApp::Action::"customizeData", resource ); ``` 認可リクエストを行い、Verified Permissions ポリシーを使用して評価を開始するには、テナントにマッピングされた一意の ID に対応するポリシーストア ID を指定する必要があります`store-b`。 ``` { "policyStoreId":"store-b", "principal":{ "entityType":"MultiTenantApp::User", "entityId":"Bob" }, "action":{ "actionType":"MultiTenantApp::Action", "actionId":"customizeData" }, "resource":{ "entityType":"MultiTenantApp::Data", "entityId":"my_example_data" }, "entities":{ "entityList":[ [ { "identifier":{ "entityType":"MultiTenantApp::User", "entityId":"Bob" }, "attributes":{}, "parents":[] }, { "identifier":{ "entityType":"MultiTenantApp::Data", "entityId":"my_example_data" }, "attributes":{}, "parents":[] } ] ] } } ``` Verified Permissions では、IdP をポリシーストアと統合することは可能ですが、必須ではありません。この統合により、ポリシーは ID ストアのプリンシパルをポリシーのプリンシパルとして明示的に参照できます。Verified Permissions の IdP として Amazon Cognito と統合する方法の詳細については、[Verified Permissions ドキュメント](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html)と [Amazon Cognito ドキュメント](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)を参照してください。 ポリシーストアを IdP と統合する場合、ポリシーストアごとに 1 つの [ID ソース](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html)のみを使用できます。例えば、Verified Permissions を Amazon Cognito と統合する場合は、Verified Permissions ポリシーストアと Amazon Cognito ユーザープールのテナント分離に使用される戦略をミラーリングする必要があります。ポリシーストアとユーザープールも同じ に存在する必要があります AWS アカウント。 ![\[テナントごとの設計モデルでの Verified Permissions と Amazon Cognito の統合\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-per-tenant.png) 運用レベルでは、テナントごとのポリシーストアには監査上の利点があります。これは、[記録されたアクティビティをテナントごとに で](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html)AWS CloudTrail 個別に簡単にクエリできるためです。ただし、テナントごとのディメンションに追加のカスタムメトリクスを Amazon CloudWatch に記録することをお勧めします。 テナントごとのポリシーストアアプローチでは、2 つの [Verified Permissions クォータ](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html)に細心の注意を払って、SaaS ソリューションのオペレーションに干渉しないようにする必要があります。これらのクォータは、アカウント*ごとのリージョンごとのポリシーストアと、アカウント*ごとの*リージョンごとの 1 秒あたりの IsAuthorized リクエストです*。両方のクォータの引き上げをリクエストできます。 テナントごとのポリシーストアモデルを実装する方法の詳細な例については、 AWS ブログ記事[「Amazon Verified Permissions with atenant policy store SaaS](https://aws.amazon.com/blogs/security/saas-access-control-using-amazon-verified-permissions-with-a-per-tenant-policy-store/)」を参照してください。 # 1 つの共有マルチテナントポリシーストア 1 つの共有マルチテナントポリシーストア設計モデルは、SaaS ソリューション内のすべてのテナントに対して Amazon Verified Permissions の 1 つのマルチテナントポリシーストアを使用します。このアプローチの主な利点は、管理と運用の簡素化です。特に、テナントのオンボーディング中に追加のポリシーストアを作成する必要がないためです。このアプローチの欠点は、ポリシーの更新やデプロイの失敗やミスによる影響範囲の拡大、[ノイズの多い近隣](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html)への影響の増大です。さらに、ソリューションがテナントごとに一意のポリシーを必要とする場合、このアプローチはお勧めしません。この場合、正しいテナントのポリシーが使用されるように、代わりにテナントごとのポリシーストアモデルを使用します。 1 つの共有マルチテナントポリシーストアアプローチは、SaaS [プール分離](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html)モデルに似ています。SaaS アプリケーションが必要とする場合、テナント分離にプールアプローチを提供できます。SaaS ソリューションが[サイロ化された分離](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html)をマイクロサービスに適用する場合は、このモデルを使用することもできます。モデルを選択するときは、テナントデータ分離の要件と、SaaS アプリケーションに必要な Verified Permissions ポリシーの構造を個別に評価する必要があります。 SaaS ソリューション全体でテナント識別子を共有する一貫した方法を適用するには、前述のように、ユーザー登録中に識別子をユーザーの SaaS ID にマッピングすることをお勧めします。このマッピングは、IdP の一部として、または DynamoDB などの外部データソースに維持することで、SaaS アプリケーションに提供できます。また、共有ポリシーストア ID をユーザーにマッピングすることをお勧めします。ID はテナント分離の一部としては使用されませんが、将来の変更が容易になるため、これは良い方法です。 次の例は、API エンドポイントが、異なるテナントに属しているが`Bob`、承認`store-multi-tenant`のためにポリシーストア ID とポリシーストアを共有するユーザー`Alice`と に JWT を送信する方法を示しています。すべてのテナントは単一のポリシーストアを共有するため、ポリシーストア ID をトークンまたはデータベースに保持する必要はありません。すべてのテナントは単一のポリシーストア ID を共有するため、アプリケーションがポリシーストアを呼び出すために使用できる環境変数として ID を指定できます。 ![\[Verified Permissions 共有設計モデル\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-shared.png) 次のサンプルポリシーは、1 つの共有マルチテナントポリシー設計パラダイムを示しています。このポリシーでは、親`MultiTenantApp::User`を持つプリンシパルには、すべてのリソースのデータを表示するアクセス許可`MultiTenantApp::Role``Admin`があります。 ``` permit ( principal in MultiTenantApp::Role::"Admin", action == MultiTenantApp::Action::"viewData", resource ); ``` 単一のポリシーストアが使用されているため、Verified Permissions ポリシーストアは、プリンシパルに関連付けられているテナンシー属性がリソースに関連付けられているテナンシー属性と一致することを確認する必要があります。これは、次のポリシーをポリシーストアに含めて、リソースとプリンシパルに一致するテナンシー属性を持たないすべての認可リクエストが拒否されるようにすることで実現できます。 ``` forbid( principal, action, resource ) unless { resource.Tenant == principal.Tenant }; ``` 1 つの共有マルチテナントポリシーストアモデルを使用する認可リクエストの場合、ポリシーストア ID は共有ポリシーストアの識別子です。次のリクエストでは、 `User``Alice`は `Role`の を持ち`Admin`、リソースとプリンシパルに関連付けられた`Tenant`属性は両方とも であるため、 へのアクセスが許可されます`TenantA`。 ``` { "policyStoreId":"store-multi-tenant", "principal":{ "entityType":"MultiTenantApp::User", "entityId":"Alice" }, "action":{ "actionType":"MultiTenantApp::Action", "actionId":"viewData" }, "resource":{ "entityType":"MultiTenantApp::Data", "entityId":"my_example_data" }, "entities":{ "entityList":[ { "identifier":{ "entityType":"MultiTenantApp::User", "entityId":"Alice" }, "attributes": { { "Tenant": { "entityIdentifier": { "entityType":"MultitenantApp::Tenant", "entityId":"TenantA" } } } }, "parents":[ { "entityType":"MultiTenantApp::Role", "entityId":"Admin" } ] }, { "identifier":{ "entityType":"MultiTenantApp::Data", "entityId":"my_example_data" }, "attributes": { { "Tenant": { "entityIdentifier": { "entityType":"MultitenantApp::Tenant", "entityId":"TenantA" } } } }, "parents":[] } ] } } ``` Verified Permissions では、IdP をポリシーストアと統合することは可能ですが、必須ではありません。この統合により、ポリシーは ID ストア内のプリンシパルをポリシーのプリンシパルとして明示的に参照できます。Verified Permissions の IdP として Amazon Cognito と統合する方法の詳細については、[Verified Permissions ドキュメント](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html)と [Amazon Cognito ドキュメント](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)を参照してください。 ポリシーストアを IdP と統合する場合、ポリシーストアごとに 1 つの [ID ソース](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html)のみを使用できます。例えば、Verified Permissions を Amazon Cognito と統合する場合は、Verified Permissions ポリシーストアと Amazon Cognito ユーザープールのテナント分離に使用される戦略をミラーリングする必要があります。ポリシーストアとユーザープールも同じ に存在する必要があります AWS アカウント。 ![\[共有設計モデルでの Verified Permissions と Amazon Cognito の統合\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-shared.png) 運用上および監査上の観点から、1 つの共有マルチテナントポリシーストアモデルには欠点があります。これは、[ログに記録された AWS CloudTrail](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html)各 CloudTrail 呼び出しが同じポリシーストアを使用するため、 のログに記録されたアクティビティがテナントの個々のアクティビティを除外するために、より関連性の高いクエリを必要とするという点です。このシナリオでは、テナントごとのディメンションに関する追加のカスタムメトリクスを Amazon CloudWatch に記録して、適切なレベルのオブザーバビリティと監査機能を確保すると便利です。 1 つの共有マルチテナントポリシーストアアプローチでは、SaaS ソリューションのオペレーションに干渉しないように、[Verified Permissions クォータ](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html)にも細心の注意が必要です。特に、アカウントクォータごとに*リージョンごとに 1 秒あたりの IsAuthorized リクエスト*をモニタリングして、制限を超えないようにすることをお勧めします。このクォータの引き上げをリクエストできます。 # 階層型デプロイモデル 階層型デプロイモデルを作成することで、優先度の高い「エンタープライズ階層」テナントを、潜在的に大量の「スタンダード階層」顧客から分離できます。このモデルでは、ポリシーストアのポリシーにデプロイされた変更を階層ごとに個別にロールアウトできます。これにより、各階層の顧客を階層外の変更から分離できます。階層型デプロイモデルでは、通常、ポリシーストアはテナントのオンボーディング時にデプロイされるのではなく、各階層の初期インフラストラクチャプロビジョニングの一部として作成されます。 ソリューションがプールされた分離モデルを主に使用する場合は、追加の分離またはカスタマイズが必要になる場合があります。たとえば、各テナントが独自のテナント階層インフラストラクチャを取得する「プレミアム階層」を作成できます。これにより、テナントが 1 つしかないプールされたインスタンスをデプロイすることでサイロ化されたモデルが作成されます。これは、ポリシーストアを含む完全に分離された「プレミアム層テナント A」インフラストラクチャと「プレミアム層テナント B」インフラストラクチャの形式になる可能性があります。このアプローチにより、最高レベルの顧客に対してサイロ化された分離モデルが作成されます。 階層型デプロイモデルでは、各ポリシーストアは個別にデプロイされますが、同じ分離モデルに従う必要があります。複数のポリシーストアが使用されているため、SaaS ソリューション全体でテナントに関連付けられているポリシーストア識別子を一貫した方法で共有する必要があります。テナントごとのポリシーストアモデルと同様に、ユーザー登録時にテナント識別子をユーザーの SaaS ID にマッピングすることをお勧めします。 次の図は、`Standard Tier`、、 `Enterprise Tier`の 3 つの階層を示しています`Premium Tier 1`。各階層は独自のインフラストラクチャに個別にデプロイされ、階層内に 1 つの共有ポリシーストアを使用します。標準階層とエンタープライズ階層には複数のテナントが含まれています。 `TenantA`と `TenantB`は にあり`Standard Tier`、 `TenantC`と `TenantD`はエンタープライズ階層にあります。 `Premium Tier 1` には のみが含まれているため`TenantP`、ソリューションが完全にサイロ化された分離モデルであるかのようにプレミアムテナントを提供し、カスタマイズされたポリシーなどの機能を提供できます。新しいプレミアム階層の顧客をオンボーディングすると、`Premium Tier 2`インフラストラクチャが作成されます。 **注記** プレミアム階層のアプリケーション、デプロイ、テナントオンボーディングは、標準階層とエンタープライズ階層と同じです。唯一の違いは、プレミアム階層のオンボーディングワークフローが新しい階層インフラストラクチャのプロビジョニングから始まることです。 ![\[Verified Permissions 階層型デプロイモデル\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-tiered-deployment.png)