本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 使用 OPA 文档模型进行租户隔离
<a name="opa-design-isolation"></a>

OPA 使用文件来做出决定。这些文档可能包含租户特定的数据，因此您必须考虑如何保持租户数据隔离。OPA 文档由基础文档和虚拟文档组成。基础文档包含来自外部世界的数据。这包括直接提供给 OPA 的数据、有关 OPA 请求的数据以及可能作为输入传递给 OPA 的数据。虚拟文档由策略计算，包括 OPA 政策和规则。有关更多信息，请参阅 [OPA 文档。](https://www.openpolicyagent.org/docs/latest/philosophy/)

要在 OPA 中为多租户应用程序设计文档模型，必须首先考虑在 OPA 中做出决策所需的基础文档类型。如果这些基础文档包含租户特定的数据，则必须采取措施确保这些数据不会意外暴露给跨租户访问。幸运的是，在许多情况下，在OPA中做出决策不需要租户特定的数据。以下示例显示了一个假设的 OPA 文档模型，该模型允许根据哪个租户拥有 API 以及用户是否为租户成员来访问 API，如输入文档所示。

![基本 OPA 文档模型](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/opa-doc-model-1.png)


在这种方法中，除了有关哪些租户拥有 API 的信息外，OPA 无法访问任何租户特定的数据。在这种情况下，不必担心 OPA 会促进跨租户访问，因为 OPA 用于做出访问决策的唯一信息是用户与租户的关联以及租户与租户的关联。 APIs您可以将这种类型的 OPA 文档模型应用于孤立的 SaaS 模型，因为每个租户都拥有独立资源的所有权。

但是，在许多 RBAC 授权方法中，有可能跨租户泄露信息。在以下示例中，假设的 OPA 文档模型允许根据用户是否为租户成员以及该用户是否具有访问 API 的正确角色来访问 API。

![跨租户用例的 OPA 文档模型](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/opa-doc-model-2.png)


这种模式引入了跨租户访问的风险，因为现在`data.tenant2.user_roles`必须允许 OPA 访问`data.tenant1.user_roles`和中的多个租户的角色和权限才能做出授权决定。为了保持租户隔离和角色映射的隐私，这些数据不应存在于 OPA 中。RBAC 数据应位于外部数据源（例如数据库）中。此外，不应使用 OPA 将预定义的角色映射到特定权限，因为这会使租户难以定义自己的角色和权限。它还会使您的授权逻辑变得僵化，需要不断更新。有关如何将 RBAC 数据安全地纳入 OPA 决策过程的指导，请参阅本指南后面的[租户隔离和数据隐私建议](devops-isolation-privacy.md)部分。

通过不将任何租户特定的数据存储为异步基础文档，您可以轻松地在 OPA 中保持租户隔离。异步基础文档是存储在内存中的数据，可以在 OPA 中定期更新。其他基础文档（例如 OPA 输入）是同步传递的，并且仅在决策时才可用。例如，将租户特定的数据作为 OPA 输入的一部分提供给查询并不构成违反租户隔离的行为，因为这些数据只能在决策过程中同步获得。