е модел за управление на разрешенията на потребителите в множество акаунти, организации или групи.С многоквартирантността всеки наемател (например акаунт или организация) работи в изолирана среда, изисквайки уникални контроли за достъп, съобразени със специфични потребителски роли в тази среда. Multi-tenant authorization Един от най-ефективните начини за реализиране на многонаемателното разрешение е чрез комбиниране с RBAC опростява управлението на достъпа, като възлага на потребителите предварително определени роли, които диктуват техните разрешения в среда. Управление на достъпа въз основа на роли (Role-Based Access Control – 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, across an application.This means a user assigned an role might have access to edit all resources, even across tenants where they shouldn’t have permissions. roles usually apply globally Editor This problem can present itself as simply as: A project management app where a user is an in one team but should only have access in another. Editor Viewer 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: . As more users and resource types are introduced, a 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: Admin, Editor, Viewer role explosion 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. by dynamically assigning roles within each tenant instead of hardcoding them. Multi-Tenant RBAC removes the need for tenant-specific roles 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 "Редакторите могат да променят само собствените си снимки" Преди да се потопим в внедряването и най-добрите практики, нека споменем няколко често използвани модели за мулти-тенанси: Общи модели на многократни наематели Разрешението за много наематели се отнася за широк спектър от приложения. Ето някои от най-често срещаните начини на наематели са структурирани: Сметки – Използва се в потребителски SaaS приложения, където всеки потребител принадлежи към независим акаунт (напр. Google Drive, Dropbox). Организации – Често срещани в бизнес приложения, където една компания (организация) има множество потребители с различни роли (напр. Slack, Notion). Групи – Полезни за съвместни среди, където потребителите са групирани въз основа на потребностите от споделен достъп (например GitHub екипи, работни пространства на проекти). В системите, където предприятията работят по модел на франчайз, всяка франчайза функционира самостоятелно, но следва централна структура (напр. системи за управление на ресторанти). Всеки от тези модели се възползва от разрешението Multi-Tenant, за да гарантира подходяща изолация и ролеви разрешения за всеки наемател. Разбирайки предимствата на многонаемателното разрешение, нека продължим да обсъждаме изпълнението. Най-добри практики за прилагане на многоквартирантните разрешителни Ефективни стратегии за управление на роли, разрешения и мащабиране в изолирани среди в приложения с множество наематели. Планирайте стратегията си за разрешаване на множество наематели Преди да се потопите в изпълнението на каквото и да е, е от съществено значение да планирате как ще работи вашият модел за много наематели. Ето някои ключови елементи, които трябва да дефинирате, ако използвате RBAC модел: separate, manageable access controls Потребители: Лица, които имат достъп до системата.Всеки от тях може да принадлежи на няколко наематели. Наематели: Отделни среди, в които потребителите работят (като акаунт, организация или работно пространство). Роли: Предварително определени нива на разрешения, възложени на потребители в рамките на наемател. Ресурси: обекти (например снимки, документи), с които потребителите си взаимодействат, контролирани от разрешения. Разрешения: Правила, които определят действията, които ролите могат да изпълняват върху конкретни ресурси. Като се справите с тези въпроси рано, можете да изградите Система за разрешаване, съобразена с нуждите на вашето заявление. flexible and scalable Разбиране на многонационалните цели От А Системата трябва да гарантира: single user can exist in multiple tenants Ролевите възлагания са за наемател – разрешенията на потребителя трябва да бъдат обхванати от техния конкретен наемател. Ресурсите са свързани с наематели – Ресурсите трябва да принадлежат на конкретен наемател. Разрешенията се оценяват динамично – когато потребител направи заявка, системата проверява както ролята им в наемателя, така и собствеността на ресурса. Оптимизиране на Multi-Tenant Authorization: Отключване на схема от данни Едно от основните предизвикателства в многофункционалните системи е управлението на В традиционните системи ролите и разрешенията често са тясно свързани с данните на приложението.Това може да създаде усложнения, когато разрешенията трябва да се променят, тъй като може да се наложи да актуализирате и двете и на самия себе си. roles and policies role assignment application data Оптимизиране на скалацията: Съхранявайте ролите, задачите и политиките в специална система за упълномощаване (като Permit.io) и съхранявайте данните на приложението отделно от логиката за упълномощаване. Това отключване ви позволява да актуализирате ролите или разрешенията динамично, без да докосвате основните данни или кодовата база на приложението. Използвайте един източник на истината - 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 Например, представете си, че a Когато потребителят има достъп до , и тази папка съдържа няколко документа. С RBAC ще трябва да дефинирате роли като или Въпреки това, с Можете да опростите това, като кажете: document management system folder Folder Editor Document Viewer ReBAC "На потребителя е разрешено да редактира документ, ако той е редактор на папката, към която принадлежи документът." "На потребителя е разрешено да редактира документ, ако той е редактор на папката, към която принадлежи документът." Това позволява по-динамично и чувствително към контекста възлагане на разрешения без дублиране на роли за всеки ресурс. : 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 (e.g., ) to represent the type of object you want to control access to. new resource blog Specify the resource's , which will be used in your API calls. key Define the users should be able to perform on the resource (e.g., create, read, update, delete). actions The screenshot shows an example where is the resource, and actions are defined for it. blog Define the Access Control Policy: You’ll specify what actions each role can perform on each resource. For example, in the screenshot, roles like , , and are defined, and the policy is set up to specify which actions are permitted for each role. admin public Writer Define the Tenants in the Directory: Each tenant can have its own set of roles, permissions, and policies. To create tenants: Go to the screen and click on . Directory Settings Define the tenants you need (e.g., , , etc.). Tenant 1 Tenant 2 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 in the screen. Add User Directory Assign the user a unique and other user details (e.g., email, first name). key In the section, you can assign the user roles specific to the tenant to which they belong. Permissions Per Tenant For instance, the user could be an in and a in , as shown in the screenshot: Admin Tenant 1 Writer Tenant 2 Тук можем да видим всички наши потребители и какви роли имат във всеки наемател, на който принадлежат: Някои от предимствата на използването на Permit.io за разрешаване на множество наематели включват: Централизирано управление на правилата: Дефиниране и управление на всички правила и политики за разрешаване от централизирана платформа. Наемател-специфично възлагане на роли: Лесно възлагане и управление на роли на наемател, което позволява на потребителите да имат различни роли в различни среди (напр. Администратор в един наемател, Преглеждач в друг). Изпълнение на подробни разрешения за всеки ресурс и прилагане на сложни разрешения с фини зърна (като тези, базирани на атрибути или взаимоотношения) без необходимост от допълнителна логика по избор. Поддръжка на ReBAC: Permit.io разширява традиционния модел на RBAC с ReBAC, което ви позволява да дефинирате разрешения въз основа не само на потребителските роли, но и на взаимоотношенията между потребителите и ресурсите. Резюме: Разрешение за многонаемател с RBAC В този блог ние разглеждаме Как да го съчетаем с позволява по-ефективно и мащабируемо управление на разрешенията на потребителите в изолирани среди. importance of multi-tenant authorization Role-Based Access Control (RBAC) Обсъдихме предизвикателствата на традиционните RBAC в приложенията за много наематели и как Multi-Tenant RBAC решава проблеми като статични роли, експлозия на роли и фин контрол на достъпа. С разрешението за много наематели всеки наемател може да има свой собствен изолиран контрол на достъпа, като гарантира, че потребителите имат достъп само до това, за което са упълномощени в тяхната специфична среда. позволява по-ефективно прилагане на разрешаването на множество наематели, благодарение на централизираното управление на правилата, наемател-специфичното възлагане на роли, фините разрешения и поддръжката за контрол на достъпа въз основа на взаимоотношенията (ReBAC). Permit.io What’s Next? Разгледайте документацията на Permit.io, за да започнете да прилагате разрешение за много наематели в приложението си. Присъединете се към общността Permit.io, за да обсъдите най-добрите практики и да получите подкрепа.
