每租户策略存储

Amazon Verified Permissions 中的每租户策略存储设计模型将 SaaS 应用程序中的每个租户与其自己的策略存储区相关联。此模型类似于 SaaS 孤岛隔离模型。两种模式都要求创建租户特定的基础设施，并且具有相似的优缺点。这种方法的主要好处是基础设施强制的租户隔离，支持每个租户的独特授权模式，消除了邻居的噪音担忧，以及缩小了策略更新或部署失败的影响范围。这种方法的缺点包括更复杂的租户入职流程、部署和运营。如果解决方案对每个租户都有唯一的策略，则推荐使用按租户策略存储的方法。

如果您的 SaaS 应用程序需要，按租户策略存储模型可以提供一种高度孤立的租户隔离方法。您也可以将此模型与池隔离配合使用，但是您的 Verified Permissions 实现不会共享更广泛的池隔离模型的标准优势，例如简化的管理和操作。

在每租户策略存储中，租户隔离是通过在用户注册过程中将租户的策略存储标识符映射到用户的 SaaS 身份来实现的，如前所述。这种方法将租户的策略存储与用户主体紧密地联系在一起，并提供了一种在整个 SaaS 解决方案中共享映射的一致方式。您可以将 SaaS 应用程序作为 IdP 的一部分或外部数据源（例如 DynamoDB）进行维护，从而将其提供到 SaaS 应用程序的映射。这还可以确保委托人是租户的一部分，并且使用租户的策略存储。

此示例说明了如何将包含用户policyStoreId和tenant的 JWT 从 API 端点传递到授权方中的策略评估点， AWS Lambda 授权方将请求路由到正确的策略存储。

以下示例策略说明了每租户策略商店的设计范例。Alice属于的用户还TenantA.会 policyStoreIdstore-a映射到的租户身份，Alice,并强制使用正确的策略存储。这样可以确保使用TenantA的策略。

注意

每租户策略存储模型隔离了租户的策略。授权会强制执行允许用户对其数据执行的操作。任何使用此模型的假设应用程序所涉及的资源都应使用其他隔离机制进行隔离，如Well-Architected Fr amework，SaaS Lens AWS 文档中所定义。

在此策略中，Alice有权查看所有资源的数据。

permit (
    principal == MultiTenantApp::User::"Alice",
    action == MultiTenantApp::Action::"viewData",
    resource
);

要提出授权请求并使用已验证权限策略开始评估，您需要提供与映射到租户的唯一 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":[]
            }
         ]
      ]
   }
}

该用户Bob属于租户 B， policyStoreIdstore-b并且还映射到的租户身份Bob，这会强制使用正确的策略存储。这样可以确保使用租户 B 的策略。

在此策略中，Bob有权自定义所有资源的数据。在此示例中，customizeData可能是仅针对租户 B 的操作，因此该策略对租户 B 来说是唯一的。每租户策略存储模型本质上支持基于每个租户的自定义策略。

permit (
    principal == MultiTenantApp::User::"Bob",
    action == MultiTenantApp::Action::"customizeData",
    resource
);

要提出授权请求并使用已验证权限策略开始评估，您需要提供与映射到租户的唯一 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":[]
            }
         ]
      ]
   }
}

使用已验证的权限，可以将 IdP 与策略存储集成，但不是必需的。这种集成允许策略将身份存储中的委托人明确引用为策略的主体。有关如何作为已验证权限的 IdP 与 Amazon Cognito 集成的更多信息，请参阅已验证权限文档和 Amazon Cognito 文档。

将策略存储与 IdP 集成时，每个策略存储只能使用一个身份源。例如，如果您选择将已验证权限与 Amazon Cognito 集成，则必须镜像用于隔离已验证权限策略存储和 Amazon Cognito 用户池的租户策略。策略存储库和用户池也必须位于同一位置 AWS 账户。

在操作层面上，每租户策略存储具有审计优势，因为您可以轻松地为每个租户AWS CloudTrail 单独查询已记录的活动。但是，我们仍然建议您将每个租户维度上的其他自定义指标记录到 Amazon CloudWatch。

按租户策略存储方法还需要密切关注两个已验证的权限配额，以确保它们不会干扰 SaaS 解决方案的运行。这些配额是每个账户每个区域的策略存储量和每个账户每个区域的每秒IsAuthorized 请求数。您可以申请提高两个配额。

有关如何实现按租户策略存储模型的更详细示例，请参阅 AWS 博客文章 SaaS 访问控制使用每租户策略存储的 Amazon Verified Permis sions。