1,681 показания
1,681 показания

Как да реализирате мулти-наемател авторизация с контрол на достъпа, базиран на роли

от Permit.io11m2025/06/23
Read on Terminal Reader

Твърде дълго; Чета

Това ръководство показва как да се комбинират RBAC и ReBAC с помощта на Permit.io за мащабируеми, защитени и гъвкави потребителски разрешения.
featured image - Как да реализирате мулти-наемател авторизация с контрол на достъпа, базиран на роли
Permit.io HackerNoon profile picture

Multi-tenant authorizationе модел за управление на разрешенията на потребителите в множество акаунти, организации или групи.С многоквартирантността всеки наемател (например акаунт или организация) работи в изолирана среда, изисквайки уникални контроли за достъп, съобразени със специфични потребителски роли в тази среда.

Един от най-ефективните начини за реализиране на многонаемателното разрешение е чрез комбиниране сУправление на достъпа въз основа на роли (Role-Based Access Control – RBAC)RBAC опростява управлението на достъпа, като възлага на потребителите предварително определени роли, които диктуват техните разрешения в среда.

Управление на достъпа въз основа на роли (Role-Based Access Control – RBAC)

Само RBAC се сблъсква с три основни предизвикателства, тъй като приложенията се разширяват и изискват повече разрешения с фини зърна:

  • Като се ограничава до роли (а не атрибути и взаимоотношения), RBAC може да липсва гранулярност.
  • Неговите статични роли нямат способността да скалират между наемателите.
  • Тъй като приложенията растат, броят на ролите може да стане неуправляем, което води до това, което се нарича "Role Explosion".

Аmulti-tenant RBAC modelРешава тези проблеми чрез структуриране на потребителския достъпper tenant, което позволява динамично възлагане на роли и разрешения в изолирани среди. Вместо да възлагате на потребител една глобална роля, техните разрешения зависят от наемателя, в който се намират, и от ролята, която имат в този наемател.

Here’s a quick example of when this can be useful:

Помислете за платформа за управление на SaaS проекти, където потребителите могат да бъдат членове на няколко организации, всяка с различни нива на достъп:

Потребител може да бъде администратор в една организация с пълен контрол, а само редактор в друга, ограничена до модифициране на задачи, но не и управление на потребители.

Помислете за платформа за управление на SaaS проекти, където потребителите могат да бъдат членове на няколко организации, всяка с различни нива на достъп:

Потребителят може да бъдеadminв една организация с пълен контрол, докато само единeditorв друга, ограничена до модифициране на задачи, но не и за управление на потребителите.

Multi-tenant RBAC гарантира, че разрешенията са обхванати от правилната среда без ненужна сложност.

В това ръководство ще разгледамеimportance of Multi-Tenant Authorizationи показва как може да се прилага ефективно с помощта наPermit.io.

Разрешително

Ще обсъдим как да структурираме политиките, да разпределяме роли на наемател и да налагамеfine-grained permissions.

Да се потопим вътре.

Защо е важно мулти-наемателското разрешение?

Разрешаването на множество наематели е полезно за приложения, където потребителите принадлежат към множество независими среди, всяка с свои собствени правила за достъп - често срещано явление в повечето съвременни приложения, базирани на облак.

Разрешения за работа в изолирана среда

Тъй като потребителят може да има различни роли и отговорности сред различните наематели, използването на много наематели позволява тези роли да бъдат управлявани и изпълнявани независимо.

Това означава, че можем да използваме разрешенията на много наематели, за да поддържаме ясни граници между средите, като същевременно гарантираме, че потребителите имат подходящи разрешения във всяка среда.

Например, помислете за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_TeamA
    • Editor_TeamB
    • Viewer_TeamA
    • Viewer_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.

Приложение за управление на проекти, където потребителят еEditorв един отбор, но трябва да имаViewerдостъп до друг.

"Редакторите могат да променят само собствените си снимки"

Преди да се потопим в внедряването и най-добрите практики, нека споменем няколко често използвани модели за мулти-тенанси:

Общи модели на многократни наематели

Разрешението за много наематели се отнася за широк спектър от приложения. Ето някои от най-често срещаните начини на наематели са структурирани:

  1. Сметки – Използва се в потребителски SaaS приложения, където всеки потребител принадлежи към независим акаунт (напр. Google Drive, Dropbox).
  2. Организации – Често срещани в бизнес приложения, където една компания (организация) има множество потребители с различни роли (напр. Slack, Notion).
  3. Групи – Полезни за съвместни среди, където потребителите са групирани въз основа на потребностите от споделен достъп (например GitHub екипи, работни пространства на проекти).
  4. В системите, където предприятията работят по модел на франчайз, всяка франчайза функционира самостоятелно, но следва централна структура (напр. системи за управление на ресторанти).

Всеки от тези модели се възползва от разрешението Multi-Tenant, за да гарантира подходяща изолация и ролеви разрешения за всеки наемател.

Разбирайки предимствата на многонаемателното разрешение, нека продължим да обсъждаме изпълнението.

Най-добри практики за прилагане на многоквартирантните разрешителни

Ефективни стратегии за управление на роли, разрешения и мащабиране в изолирани среди в приложения с множество наематели.

Планирайте стратегията си за разрешаване на множество наематели

Преди да се потопите в изпълнението на каквото и да е, е от съществено значение да планирате как ще работи вашият модел за много наематели.separate, manageable access controlsЕто някои ключови елементи, които трябва да дефинирате, ако използвате RBAC модел:

  • Потребители: Лица, които имат достъп до системата.Всеки от тях може да принадлежи на няколко наематели.
  • Наематели: Отделни среди, в които потребителите работят (като акаунт, организация или работно пространство).
  • Роли: Предварително определени нива на разрешения, възложени на потребители в рамките на наемател.
  • Ресурси: обекти (например снимки, документи), с които потребителите си взаимодействат, контролирани от разрешения.
  • Разрешения: Правила, които определят действията, които ролите могат да изпълняват върху конкретни ресурси.

Като се справите с тези въпроси рано, можете да изградитеflexible and scalableСистема за разрешаване, съобразена с нуждите на вашето заявление.

Разбиране на многонационалните цели

От Аsingle user can exist in multiple tenantsСистемата трябва да гарантира:

  1. Ролевите възлагания са за наемател – разрешенията на потребителя трябва да бъдат обхванати от техния конкретен наемател.
  2. Ресурсите са свързани с наематели – Ресурсите трябва да принадлежат на конкретен наемател.
  3. Разрешенията се оценяват динамично – когато потребител направи заявка, системата проверява както ролята им в наемателя, така и собствеността на ресурса.

Оптимизиране на Multi-Tenant Authorization: Отключване на схема от данни

Едно от основните предизвикателства в многофункционалните системи е управлението наroles and policiesВ традиционните системи ролите и разрешенията често са тясно свързани с данните на приложението.Това може да създаде усложнения, когато разрешенията трябва да се променят, тъй като може да се наложи да актуализирате и дветеrole assignmentи наapplication dataсамия себе си.

Оптимизиране на скалацията:

  • Съхранявайте ролите, задачите и политиките в специална система за упълномощаване (като Permit.io) и съхранявайте данните на приложението отделно от логиката за упълномощаване.
  • Това отключване ви позволява да актуализирате ролите или разрешенията динамично, без да докосвате основните данни или кодовата база на приложението.

Permit.io’s no-code policy management UI allows you to make policy changes without ever touching the codebase.


This is also true for handling role assignments for multiple tenants.

Използвайте един източник на истината - PDP (Политическа точка за вземане на решения)

Една от ключовите концепции при оптимизирането на мулти-наемателското разрешение е използването наsingle source of truthза вземане на политически решения.

Вместо да съхранявате информация за роли и правила за достъп в рамките на всяка услуга или потребителска база данни,Политическа точка за вземане на решения (PDP)действа като централна точка, където се вземат всички решения за достъп.

Политическа точка за вземане на решения (PDP)


Benefits of using a PDP:

  • Съгласуваност: PDP гарантира, че всички услуги в рамките на приложението се позовават на един и същ набор от правила при вземането на решения за разрешаване.
  • Динамична оценка на правилата: Промените в правилата или възлагането на роли трябва да се актуализират само на едно място – PDP. Тази централизация премахва необходимостта от актуализиране на няколко места в вашата кодова база или бази данни.
  • По-малък риск от грешки: като разчитате на единна, централизирана точка за вземане на решения, намалявате риска от несъответстващи разрешения между наемателите и приложенията.

Разширяване на RBAC с Релационен контрол на достъпа (ReBAC)

ДокатоRBACосигурява солидна основа за разрешаване на множество наематели, има сценарии, при коитоrelationship-based access control (ReBAC)Те могат да осигурят още по-добър контрол на достъпа.

Релационен контрол на достъпа (ReBAC)

RBAC определя разрешения въз основа на роли, възложени на потребителите, ноReBACНаправете стъпка по-далеч, като дефинирате разрешенията въз основа наrelationshipsТова е особено полезно в ситуации, когато разрешенията зависят от начина, по който ресурсите са свързани или свързани помежду си.

Например, представете си, че adocument management systemКогато потребителят има достъп доfolder, и тази папка съдържа няколко документа. С RBAC ще трябва да дефинирате роли катоFolder EditorилиDocument ViewerВъпреки това, сReBACМожете да опростите това, като кажете:


"На потребителя е разрешено да редактира документ, ако той е редактор на папката, към която принадлежи документът."

"На потребителя е разрешено да редактира документ, ако той е редактор на папката, към която принадлежи документът."


Това позволява по-динамично и чувствително към контекста възлагане на разрешения без дублиране на роли за всеки ресурс.

Role derivation allows for the dynamic assignment or inheritance of roles based on certain conditions or relationships. This allows roles to be contextually derived based on a user's relation to a resource, for example.

Benefits of ReBAC:

  • Контекстуални разрешения: Позволява контрол на достъпа въз основа на динамични взаимоотношения (напр. потребител, който е редактор в проект и следователно има достъп до всички свързани задачи).
  • Намалена експлозия на роли: Не е необходимо да създавате роли за всяка комбинация от тип потребител и ресурс, тъй като връзките могат да определят достъпа динамично.

Чрез разширяване на RBAC с ReBAC можете даcomplex access control scenariosкъдето взаимоотношенията между потребители и ресурси диктуват разрешения.

Разрешаване на многократно наемане сРазрешително

Разрешително

Permit.ioпредлага лесен начин за прилагане на разрешение за множество наематели, като ви позволява да дефинирате роли, политики и правила за достъп в различни среди.

if (user.role == admin && user.tenant == resource.tenant) {
    return true;
}

Традиционно и статично if Подходът към мултидисциплинарния подход.

const permitted = await permit.check(user, "read", {
    resource: "document",
    tenant: "default"
});

if (permitted) {
    return true;
} 

чиста permit.check() Функция, която проверява за мулти-тенанси RBAC.

Ето широк преглед на това как може да се създаде разрешение за RBAC за много наематели в Permit.io:

  • 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 blog is the resource, and actions are defined for it.

  • 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.).

    The screenshot illustrates how different tenants are created and managed in Permit.io.

    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 за разрешаване на множество наематели включват:

  • Централизирано управление на правилата: Дефиниране и управление на всички правила и политики за разрешаване от централизирана платформа.
  • Наемател-специфично възлагане на роли: Лесно възлагане и управление на роли на наемател, което позволява на потребителите да имат различни роли в различни среди (напр. Администратор в един наемател, Преглеждач в друг).
  • Изпълнение на подробни разрешения за всеки ресурс и прилагане на сложни разрешения с фини зърна (като тези, базирани на атрибути или взаимоотношения) без необходимост от допълнителна логика по избор.
  • Поддръжка на ReBAC: Permit.io разширява традиционния модел на RBAC с ReBAC, което ви позволява да дефинирате разрешения въз основа не само на потребителските роли, но и на взаимоотношенията между потребителите и ресурсите.

Резюме: Разрешение за многонаемател с RBAC

В този блог ние разглеждамеimportance of multi-tenant authorizationКак да го съчетаем сRole-Based Access Control (RBAC)позволява по-ефективно и мащабируемо управление на разрешенията на потребителите в изолирани среди.

Обсъдихме предизвикателствата на традиционните RBAC в приложенията за много наематели и как Multi-Tenant RBAC решава проблеми като статични роли, експлозия на роли и фин контрол на достъпа.

С разрешението за много наематели всеки наемател може да има свой собствен изолиран контрол на достъпа, като гарантира, че потребителите имат достъп само до това, за което са упълномощени в тяхната специфична среда.

Permit.ioпозволява по-ефективно прилагане на разрешаването на множество наематели, благодарение на централизираното управление на правилата, наемател-специфичното възлагане на роли, фините разрешения и поддръжката за контрол на достъпа въз основа на взаимоотношенията (ReBAC).

What’s Next?

  • Разгледайте документацията на Permit.io, за да започнете да прилагате разрешение за много наематели в приложението си.
  • Присъединете се към общността Permit.io, за да обсъдите най-добрите практики и да получите подкрепа.


L O A D I N G
. . . comments & more!

About Author

Permit.io HackerNoon profile picture
Permit.io@permit
Never Build Permissions Again

ЗАКАЧВАЙТЕ ЕТИКЕТИ

ТАЗИ СТАТИЯ Е ПРЕДСТАВЕНА В...

Trending Topics

blockchaincryptocurrencyhackernoon-top-storyprogrammingsoftware-developmenttechnologystartuphackernoon-booksBitcoinbooks