OPA ドキュメントモデルによるテナント分離

OPA はドキュメントを使用して決定を行います。これらのドキュメントにはテナント固有のデータを含めることができるため、テナントデータの分離を維持する方法を検討する必要があります。OPA ドキュメントは、基本ドキュメントと仮想ドキュメントで構成されます。ベースドキュメントには、外部からのデータが含まれています。これには、OPA に直接提供されるデータ、OPA リクエストに関するデータ、および入力として OPA に渡される可能性のあるデータが含まれます。仮想ドキュメントはポリシーによって計算され、OPA ポリシーとルールが含まれます。詳細については、OPA ドキュメントを参照してください。

マルチテナントアプリケーション用に OPA でドキュメントモデルを設計するには、まず OPA で決定する必要があるベースドキュメントのタイプを考慮する必要があります。これらのベースドキュメントにテナント固有のデータが含まれている場合は、このデータが誤ってクロステナントアクセスにさらされないように対策を講じる必要があります。幸い、多くの場合、OPA でテナント固有のデータを決定する必要はありません。次の例は、入力ドキュメントに示されているように、API を所有しているテナントと、ユーザーがテナントのメンバーであるかどうかに基づいて API へのアクセスを許可する架空の OPA ドキュメントモデルを示しています。

このアプローチでは、どのテナントが API を所有しているかに関する情報を除き、OPA はテナント固有のデータにアクセスできません。この場合、OPA がアクセス決定を行うために使用する唯一の情報は、ユーザーのテナントとの関連付けとテナントの APIs との関連付けであるため、OPA によるクロステナントアクセスの促進には懸念はありません。このタイプの OPA ドキュメントモデルをサイロ化された SaaS モデルに適用できます。これは、各テナントが独立したリソースを所有するためです。

ただし、多くの RBAC 認可アプローチでは、クロステナントで情報が公開される可能性があります。次の例では、架空の OPA ドキュメントモデルにより、ユーザーがテナントのメンバーであるかどうか、およびユーザーが API にアクセスするための正しいロールを持っているかどうかに基づいて、API へのアクセスが許可されます。

このモデルでは、クロステナントアクセスのリスクが生じます。これは、承認の決定を行うために、 と で複数のテナントのロールdata.tenant1.user_rolesとアクセス許可を OPA にアクセスできるようにするためdata.tenant2.user_rolesです。テナントの分離とロールマッピングのプライバシーを維持するために、このデータは OPA 内に存在しないでください。RBAC データは、データベースなどの外部データソースに存在する必要があります。さらに、事前定義されたロールを特定のアクセス許可にマッピングするために OPA を使用しないでください。これにより、テナントが独自のロールとアクセス許可を定義することが難しくなります。また、認可ロジックをリジッドにし、継続的な更新も必要になります。RBAC データを OPA 意思決定プロセスに安全に組み込む方法のガイダンスについては、このガイドの後半にある「テナントの分離とデータプライバシーに関する推奨事項」セクションを参照してください。

テナント固有のデータを非同期ベースドキュメントとして保存しないことで、OPA でのテナント分離を簡単に維持できます。非同期ベースドキュメントは、メモリに保存され、OPA で定期的に更新できるデータです。OPA 入力などの他の基本ドキュメントは同期的に渡され、決定時にのみ使用できます。例えば、クエリへの OPA 入力の一部としてテナント固有のデータを提供することは、テナント分離の違反にはなりません。これは、そのデータが決定プロセス中に同期的にしか利用できないためです。