1 つの共有マルチテナントポリシーストア

1 つの共有マルチテナントポリシーストア設計モデルは、SaaS ソリューション内のすべてのテナントに対して Amazon Verified Permissions の 1 つのマルチテナントポリシーストアを使用します。このアプローチの主な利点は、管理と運用の簡素化です。特に、テナントのオンボーディング中に追加のポリシーストアを作成する必要がないためです。このアプローチの欠点は、ポリシーの更新やデプロイの失敗やミスによる影響範囲の拡大、ノイズの多い近隣への影響の増大です。さらに、ソリューションがテナントごとに一意のポリシーを必要とする場合、このアプローチはお勧めしません。この場合、正しいテナントのポリシーが使用されるように、代わりにテナントごとのポリシーストアモデルを使用します。

1 つの共有マルチテナントポリシーストアアプローチは、SaaS プール分離モデルに似ています。SaaS アプリケーションが必要とする場合、テナント分離にプールアプローチを提供できます。SaaS ソリューションがサイロ化された分離をマイクロサービスに適用する場合は、このモデルを使用することもできます。モデルを選択するときは、テナントデータ分離の要件と、SaaS アプリケーションに必要な Verified Permissions ポリシーの構造を個別に評価する必要があります。

SaaS ソリューション全体でテナント識別子を共有する一貫した方法を適用するには、前述のように、ユーザー登録中に識別子をユーザーの SaaS ID にマッピングすることをお勧めします。このマッピングは、IdP の一部として、または DynamoDB などの外部データソースに維持することで、SaaS アプリケーションに提供できます。また、共有ポリシーストア ID をユーザーにマッピングすることをお勧めします。ID はテナント分離の一部としては使用されませんが、将来の変更が容易になるため、これは良い方法です。

次の例は、API エンドポイントが、異なるテナントに属しているがBob、承認store-multi-tenantのためにポリシーストア ID とポリシーストアを共有するユーザーAliceと に JWT を送信する方法を示しています。すべてのテナントは単一のポリシーストアを共有するため、ポリシーストア ID をトークンまたはデータベースに保持する必要はありません。すべてのテナントは単一のポリシーストア ID を共有するため、アプリケーションがポリシーストアを呼び出すために使用できる環境変数として ID を指定できます。

次のサンプルポリシーは、1 つの共有マルチテナントポリシー設計パラダイムを示しています。このポリシーでは、親MultiTenantApp::Userを持つプリンシパルには、すべてのリソースのデータを表示するアクセス許可MultiTenantApp::RoleAdminがあります。

permit (
    principal in MultiTenantApp::Role::"Admin",
    action == MultiTenantApp::Action::"viewData",
    resource
);

単一のポリシーストアが使用されているため、Verified Permissions ポリシーストアは、プリンシパルに関連付けられているテナンシー属性がリソースに関連付けられているテナンシー属性と一致することを確認する必要があります。これは、次のポリシーをポリシーストアに含めて、リソースとプリンシパルに一致するテナンシー属性を持たないすべての認可リクエストが拒否されるようにすることで実現できます。

forbid(
    principal, 
    action, 
    resource
)
unless {
    resource.Tenant == principal.Tenant
};

1 つの共有マルチテナントポリシーストアモデルを使用する認可リクエストの場合、ポリシーストア ID は共有ポリシーストアの識別子です。次のリクエストでは、 UserAliceは 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 ドキュメントと Amazon Cognito ドキュメントを参照してください。

ポリシーストアを IdP と統合する場合、ポリシーストアごとに 1 つの ID ソースのみを使用できます。例えば、Verified Permissions を Amazon Cognito と統合する場合は、Verified Permissions ポリシーストアと Amazon Cognito ユーザープールのテナント分離に使用される戦略をミラーリングする必要があります。ポリシーストアとユーザープールも同じ に存在する必要があります AWS アカウント。

運用上および監査上の観点から、1 つの共有マルチテナントポリシーストアモデルには欠点があります。これは、ログに記録された AWS CloudTrail各 CloudTrail 呼び出しが同じポリシーストアを使用するため、 のログに記録されたアクティビティがテナントの個々のアクティビティを除外するために、より関連性の高いクエリを必要とするという点です。このシナリオでは、テナントごとのディメンションに関する追加のカスタムメトリクスを Amazon CloudWatch に記録して、適切なレベルのオブザーバビリティと監査機能を確保すると便利です。

1 つの共有マルチテナントポリシーストアアプローチでは、SaaS ソリューションのオペレーションに干渉しないように、Verified Permissions クォータにも細心の注意が必要です。特に、アカウントクォータごとにリージョンごとに 1 秒あたりの IsAuthorized リクエストをモニタリングして、制限を超えないようにすることをお勧めします。このクォータの引き上げをリクエストできます。