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

# テナントごとのポリシーストア
<a name="avp-design-per-tenant-store"></a>

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/)」を参照してください。