翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 1 つの共有マルチテナントポリシーストア
<a name="avp-design-shared-store"></a>

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 リクエスト*をモニタリングして、制限を超えないようにすることをお勧めします。このクォータの引き上げをリクエストできます。