Multi-tenant authorization複数のアカウント、組織、またはグループ間でユーザーの権限を管理するためのモデルです。Multi-tenancyでは、それぞれのレンダー(例えば、アカウントまたは組織)は、その環境内の特定のユーザーの役割に合わせたユニークなアクセスコントロールを必要とする孤立した環境で動作します。
Multi-tenant authorization を実装する最も効果的な方法の1つは、それを組み合わせることです。Role-Based Access Control(RBAC)についてRBAC は、環境内の権限を規定する事前定義された役割をユーザーに割り当てることによって、アクセス管理を簡素化します。
Role-Based Access Control(RBAC)についてRBACだけでは、アプリケーションの規模が拡大し、より細かい許可を必要とする3つの主要な課題に直面しています。
- 役割(属性や関係ではなく)に限定されているため、RBACは細部性が欠けている可能性があります。
- 静的な役割は、レンタンの間でスケールする能力が欠けています。
- アプリケーションが拡大するにつれて、役割の数は管理不能になり、いわゆる「役割爆発」が起こります。
Amulti-tenant RBAC modelユーザーアクセスの構造化によってこれらの問題を解決します。per tenant単一のグローバルロールをユーザーに割り当てる代わりに、彼らの権限は、彼らがどのレンダーにいるか、そして彼らがそのレンダー内でどのような役割を持っているかに依存します。
Here’s a quick example of when this can be useful:
SaaS プロジェクト管理プラットフォームを考えると、ユーザーはそれぞれ異なるアクセスレベルを持つ複数の組織のメンバーになることができます。
ユーザーは、1つの組織で完全なコントロールを有する管理者であり、別の組織では編集者でしかありませんが、タスクを変更することに限定されますが、ユーザーを管理することはありません。
SaaS プロジェクト管理プラットフォームを考えると、ユーザーはそれぞれ異なるアクセスレベルを持つ複数の組織のメンバーになることができます。
ユーザーは、1つの組織で完全なコントロールを有する管理者であり、別の組織では編集者でしかありませんが、タスクを変更することに限定されますが、ユーザーを管理することはありません。
複数のレンタン RBAC は、不必要な複雑さなしにライセンスが適切な環境に分配されることを保証します。
このガイドでは、私たちは、importance of Multi-Tenant Authorization効率的に実施する方法を示す許可.
許可我々は、政策を構造化し、賃貸人ごとに役割を割り当て、実施する方法について議論する。fine-grained permissions.
入り込んでみよう。
なぜ複数のレンタンの認証が重要なのか?
Multi-tenant authorization は、ユーザーが複数の独立した環境に属するアプリケーションにとって有用であり、それぞれが独自のアクセスルールを持っています - ほとんどの現代のクラウドベースのアプリケーションで一般的です。
孤立した環境での許可の取り扱い
Multi-tenancy を使用すると、各ユーザーは、レンタカーに基づいてアクセス制御のためのカスタマイズされたアプローチを受け取ることができます。
これは、複数のレンタント権限を使用して、環境間の明確な境界線を維持し、ユーザーがそれぞれの環境内で適切な権限を持っていることを保証することを意味します。
例えば、Aを考える。cloud storage platformそれぞれの顧客(賃貸人)が機密データを保管している場所で、一方の顧客のユーザーが他の顧客のデータを表示または変更できないように、厳格なアクセスコントロールを実施することが重要です。
しかし、なぜRBACでこれを解決できないのか。
なぜ、伝統的なRBACは複数のレンタントの承認には不十分なのか
RBACの限界について多くのことが言えます。生産におけるアプリケーションに対処する際、RBACはあまりにも硬く、スケールするには複雑すぎる可能性があります。
-
Static Roles Don't Scale Across Tenants:
In a traditional RBAC implementation, roles usually apply globally across an application.This means a user assigned an Editor role might have access to edit all resources, even across tenants where they shouldn’t have permissions.
This problem can present itself as simply as:
A project management app where a user is an Editor in one team but should only have Viewer access in another.
Multi-Tenant RBAC allows roles to be scoped per tenant, so a user can be an Editor in one organization and a Viewer in another without unnecessary role duplication. Speaking of role duplication -
-
The Role Explosion Problem
A basic RBAC model can start simple: Admin, Editor, Viewer. As more users and resource types are introduced, a role explosion can occur. If we take our previous example where a single user needs to be an Editor in one team but a Viewer in another, you can easily end up with something like this:
Editor_TeamAEditor_TeamBViewer_TeamAViewer_TeamB- … and so on for every additional team / potential tenant.
This makes the system hard to manage and difficult to update without breaking access rules.
Multi-Tenant RBAC removes the need for tenant-specific roles by dynamically assigning roles within each tenant instead of hardcoding them.
-
Multi-Tenant Authorization Requires Granularity
RBAC is often too restricted when handling permissions at a granular level. It typically lacks built-in mechanisms to define resource-level or conditional access policies.
Think of this policy:
"Editors can only modify their own photos"
How simple is that? The thing is - there’s no way RBAC can support such a policy without implementing additional logic. Especially at scale.
プロジェクトマネジメントアプリで、ユーザーがEditor1つのチームでしかないが、Viewer別のところにアクセス。
「編集者は自分の写真だけを修正できる」
実装とベストプラクティスに浸透する前に、いくつかの一般的に使用されるマルチテナンスモデルを挙げましょう。
マルチテナントモデル
Multi-tenant authorization は、さまざまなアプリケーションに適用されます. Here are some of the most common ways tenants are structured:
- アカウント - 消費者の SaaS アプリケーションで使用され、各ユーザーは独立したアカウントに属します(例えば、Google ドライブ、Dropbox)。
- 組織 - ビジネスアプリケーションで一般的で、企業(組織)には、さまざまな役割(例えば、Slack、Notion)を持つ複数のユーザーがあります。
- グループ - ユーザーが共有アクセスのニーズに基づいてグループ化されるコラボレーション環境(例えば、GitHub チーム、プロジェクトワークスペース)に有用です。
- フランチャイズ - 企業がフランチャイズモデルに基づいて運営しているシステムでは、各フランチャイズは独立して機能しますが、中央構造(例えば、レストラン管理システム)に従います。
これらのモデルのそれぞれは、適切な隔離とレンタカーごとの役割ベースの許可を確保するために、Multi-Tenant認可の恩恵を受けます。
マルチレンタント認証の利点を理解すると、実装の議論に進みましょう。
マルチテナント認証の実施のためのベストプラクティス
複数のレンタントアプリケーションにおける孤立した環境における役割、許可、スケーリングを管理するための効果的な戦略。
Multi-Tenant Authorization 戦略
何でも実装する前に、あなたのマルチレンタントモデルがどのように機能するかを計画することが不可欠です。separate, manageable access controlsRBAC モデルを使用している場合は、以下に定義するべきいくつかの重要な要素があります。
- ユーザー: システムにアクセスする個人. それぞれが複数のレンタリーに属する場合があります。
- 利用者:ユーザーが動作する個別の環境(アカウント、組織、ワークスペースなど)
- 役割: レンタンのユーザーに割り当てられた事前定義のライセンスレベル。
- リソース:ユーザーがインタラクションするオブジェクト(写真、ドキュメントなど)は、権限によって制御されます。
- 許可: 特定のリソースで役割が実行できるアクションを定義するルール。
これらの質問を早期に解決することで、あなたは構築することができます。flexible and scalableあなたのアプリケーションのニーズに合わせた認証システム。
複数のターゲットを理解する
以来Asingle user can exist in multiple tenantsシステムは、以下を確保する必要があります:
- Role assignments are per tenant - A user's permissions should be scopeed to their specific tenant. 役割の割り当ては、賃貸人あたりです。
- Resources are linked to tenants - Resources should belong to a specific tenant. リソースは、特定の賃貸人に属する必要があります。
- ライセンスはダイナミックに評価されます - ユーザーがリクエストを提出するとき、システムは、レンタンの役割とリソースの所有権の両方をチェックします。
マルチテナント認証の最適化:データからスケジュールを切り離す
マルチレンタントシステムの共通の課題は、どのように管理するかです。roles and policies従来のシステムでは、役割と許可はしばしばアプリケーションデータと密接に結びついているため、許可を変更する必要がある場合に合併症を引き起こす可能性があります。role assignmentそして、Theapplication data自己
スケーラビリティを最適化するには:
- ロール、割り当て、およびポリシーを専用認証システム(Permit.io など)に格納し、アプリケーションデータを認証ロジックから別々に保管します。
- このデコープリングにより、アプリケーションのコアデータやコードベースに触れることなく、役割や許可をダイナミックに更新できます。
「One Source of Truth - The PDP (Policy Decision Point)」
Multi-tenant authorization を最適化するための重要なコンセプトの1つは、asingle source of truth政策決定をすること。
役割情報やアクセスルールを各サービスまたはユーザーデータベース内に保存する代わりに、政策決定ポイント(PDP)すべてのアクセス決定が行われる中心的なポイントとして機能します。
政策決定ポイント(PDP)
Benefits of using a PDP:
- 一貫性:DPDは、アプリケーション全体のすべてのサービスが許可決定時に同じルールセットを参照することを保証します。
- ダイナミック ポリシー 評価: ポリシーまたは役割割の変更は、PDP という 1 つの場所でのみ更新する必要があります。
- エラーのリスクを減らす:単一の集中的な決定ポイントに依存することで、レンタカーやアプリケーション間で不一致な許可のリスクを減らすことができます。
RBAC(Relationship-Based Access Control)について
たとえRBACマルチレンタント認証のための堅固な基盤を提供し、そこにシナリオがあります。関係に基づくアクセス制御(ReBAC)さらに優れたアクセスコントロールを提供することができます。
関係に基づくアクセス制御(ReBAC)RBACは、ユーザーに割り当てられた役割に基づいて許可を定義しますが、ReBACさらに一歩踏み出し、その根拠に基づく許可を定義することによって、relationshipsこれは、リソースがどのように接続されているかまたは相互に関連付けられているかによって許可が依存する状況において特に有用です。
たとえば、Imagine adocument management systemユーザーがAにアクセスできる場合folder, そのフォルダには複数のドキュメントが含まれています. RBAC を使用すると、Rolls を定義する必要があります。Folder EditorまたはDocument Viewerしかしながら、WithReBACこれを単純化して言えば、
「ユーザーは、文書が属するフォルダの編集者である場合に文書を編集することができます。
「ユーザーは、文書が属するフォルダの編集者である場合に文書を編集することができます。
これにより、各リソースの役割を複製することなく、よりダイナミックで文脈に敏感な許可割り当てが可能になります。
Benefits of ReBAC:
- Contextual Permissions: Dynamic relationships (e.g. a user being an editor in a project, and therefore having access to all related tasks) に基づくアクセス制御を可能にします。
- 役割の爆発を減らす: リソース型とユーザ型のすべての組み合わせに役割を作成する必要はありません。
RBAC を ReBAC で拡張すると、complex access control scenariosユーザとリソースの関係が許可を規定する。
Multi-Tenant Authorization について許可
許可Permit.ioさまざまな環境で役割、ポリシー、アクセスルールを定義することを可能にすることで、複数のレンタンの権限を実装する簡単な方法を提供します。
if (user.role == admin && user.tenant == resource.tenant) {
return true;
}
伝統的、静的 if Multi-tenancy について説明します。
const permitted = await permit.check(user, "read", {
resource: "document",
tenant: "default"
});
if (permitted) {
return true;
}
クリーン permit.check() Multi-tenancy RBAC をチェックする機能。
Permit.io で複数のレンタンの RBAC 認証を設定する方法の幅広い概要は以下の通りです。
- Define Roles, Resources, and Actions: To get started, first define your resources (e.g., documents, photos, tasks) and the actions that can be performed on them (e.g., create, read, update, delete).
- Add a new resource (e.g.,
blog) to represent the type of object you want to control access to. - Specify the resource's key, which will be used in your API calls.
- Define the actions users should be able to perform on the resource (e.g., create, read, update, delete).
- The screenshot shows an example where
blogis the resource, and actions are defined for it.
- Add a new resource (e.g.,
-
Define the Access Control Policy:
You’ll specify what actions each role can perform on each resource. For example, in the screenshot, roles like admin, public, and Writer are defined, and the policy is set up to specify which actions are permitted for each role.
-
Define the Tenants in the Directory:
Each tenant can have its own set of roles, permissions, and policies.
To create tenants:
- Go to the Directory screen and click on Settings.
- Define the tenants you need (e.g., Tenant 1, Tenant 2, etc.).
Create Users and Assign Roles:
Once the tenants are defined, you can create users and assign them roles specific to each tenant. This ensures that the same user can have different roles in each tenant, depending on what permissions they need.
To create a new user:
-
Click Add User in the Directory screen.
-
Assign the user a unique key and other user details (e.g., email, first name).
-
In the Permissions Per Tenant section, you can assign the user roles specific to the tenant to which they belong.
For instance, the user could be an Admin in Tenant 1 and a Writer in Tenant 2, as shown in the screenshot:
ここでは、私たちのすべてのユーザーと、彼らが所属する各レンタンの役割を見ることができます:
Permit.io を使用してマルチレンタント認証のいくつかの利点には、以下が含まれます。
- 集中的なポリシー管理:中央のプラットフォームからすべての権限規則とポリシーを定義し、管理します. This simplifies policy changes and ensures consistent enforcement across your tenants.
- 賃貸人特有の役割割り当て:賃貸人ごとに役割を簡単に割り当て、管理し、ユーザーが異なる環境で異なる役割を果たすことを可能にします(例えば、1賃貸人の管理者、もう1人のViewer)。
- Fine-Grained Permissions: 詳細な許可を各リソースに実装し、追加のカスタマイズされた論理を必要とせずに複雑なフィン・グリーンな許可(属性や関係に基づくものと同様)を適用します。
- ReBAC サポート: Permit.io では、従来の RBAC モデルを ReBAC に拡張し、ユーザーの役割だけでなく、ユーザーとリソースの関係に基づいてライセンスを定義できます。
概要:RBACとのマルチテナント認証
このブログでは、私たちは、importance of multi-tenant authorizationそれをどう組み合わせるかというと、Role-Based Access Control (RBAC)孤立した環境でより効率的かつスケーラブルなユーザーライセンス管理を可能にします。
Multi-Tenant RBACが静的役割、役割爆発、細かいアクセスの制御などの問題をどのように解決するかについて、伝統的なRBACの課題について議論しました。
マルチレンタント権限により、各レンタは独自の孤立したアクセス制御を有し、ユーザーは特定の環境内で許可されているものにのみアクセスできるようにします。
Permit.io集中的なポリシー管理、賃貸人特定の役割割割り当て、細かい許可、Relationship-Based Access Control(ReBAC)のサポートのおかげで、より簡素化された方法で複数の賃貸人権限の実装を可能にします。
What’s Next?
- Permit.io のドキュメントを参照して、アプリケーションに複数のレンタント認証を導入します。
- Permit.io コミュニティに参加して、ベストプラクティスを議論し、サポートを受けることができます。
