je model za upravljanje dozvolama korisnika u više naloga, organizacija ili grupa.U multi-tenancy, svaki stanar (npr. nalog ili organizacija) radi u izolovanom okruženju, što zahteva jedinstvene kontrole pristupa prilagođene specifičnim ulogama korisnika u tom okruženju. Multi-tenant authorization Један од најефикаснијих начина за имплементацију мулти-најмјесника овлашћења је комбиновањем са RBAC pojednostavljuje upravljanje pristupom tako što dodeljuje korisnicima unapred definisane uloge koje diktiraju njihove dozvole u okruženju. Контрола приступа заснована на улози (Role-Based Access Control – RBAC) Контрола приступа заснована на улози (Role-Based Access Control – RBAC) Само РБАЦ се суочава са три главне изазове као апликације скали и захтевају више фино зрна дозвола: Будући да је ограничен на улоге (а не атрибуте и односе), РБАЦ-у можда недостаје грануларност. Његове статичке улоге немају могућност скалације преко станара. Како апликације расту, број улога може постати неконтролисан, што доводи до онога што се зове "Екплозија улога". А решава ове проблеме структурирањем приступа корисника , омогућавајући динамичко додељивање улога и дозвола у изолованим окружењима. Уместо да кориснику доделите једну глобалну улогу, њихове дозволе зависе од тога у којем се станару налазе и коју улогу имају унутар тог станара. multi-tenant RBAC model per tenant Here’s a quick example of when this can be useful: Размислите о СааС платформи за управљање пројектима где корисници могу бити чланови више организација, свака са различитим нивоима приступа: Корисник може бити администратор у једној организацији са пуном контролом, док је само уредник у другој, ограничен на модификацију задатака, али не и на управљање корисницима. Размислите о СааС платформи за управљање пројектима где корисници могу бити чланови више организација, свака са различитим нивоима приступа: Корисник може бити администратор у једној организацији са пуном контролом, док је само уредник у другој, ограничен на модификацију задатака, али не и на управљање корисницима. Multi-tenant RBAC obezbeđuje da dozvole budu obuhvaćene pravim okruženjem bez nepotrebne kompleksnosti. У овом водичу ћемо истражити и показати како се може ефикасно применити користећи . importance of Multi-Tenant Authorization Дозволите ми Дозволите ми Разговараћемо о томе како структурирати политике, доделити улоге по станару и спровести . fine-grained permissions Hajde da uđemo. Zašto je važna autorizacija za više stanara? Autorizacija za više stanara je korisna za aplikacije u kojima korisnici pripadaju više nezavisnih okruženja, od kojih svaka ima svoja pravila pristupa – što je uobičajeno u većini modernih aplikacija zasnovanih na oblaku. Управљање дозволама преко изолованих окружења Са мулти-тенанцијом, сваки корисник може добити прилагођени приступ њиховој контроли приступа на основу њиховог станара.Као што корисник може имати различите улоге и одговорности преко различитих станара, употреба мулти-тенанције омогућава да се те улоге управљају и спроводе независно. To znači da možemo da koristimo autorizaciju za više stanara kako bismo održali jasne granice između okruženja, a istovremeno osigurali da korisnici imaju odgovarajuće dozvole unutar svakog okruženja. На пример, размотрите а Кључно је да се спроведе строга контрола приступа тако да корисник од једног клијента не може прегледати или модификовати податке од другог. cloud storage platform Ali zašto to ne možemo rešiti samo sa RBAC-om? Зашто традиционални РБАЦ није довољан за мулти-тенант овлашћење Много се може рећи о ограничењима РБАЦ-а. Када се бави апликацијама у производњи, РБАЦ се може показати превише ригидним и постати превише сложен за скалирање. 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 апликацијама, где сваки корисник припада независном налогу (нпр. Организације - Уобичајено у пословним апликацијама, где компанија (организација) има више корисника са различитим улогама (нпр. Grupe – Korisno za okruženja za saradnju, gde su korisnici grupisani na osnovu potreba za deljenim pristupom (na primer, GitHub timovi, radni prostori projekata). Franšize – U sistemima gde preduzeća posluju po modelu franšize, svaka franšiza funkcioniše nezavisno, ali sledi centralnu strukturu (npr. sistem upravljanja restoranima). Сваки од ових модела има користи од мулти-тенант овлашћења како би се осигурала правилна изолација и дозволе засноване на улози по станару. Разумејући предности мулти-најмодавца овлашћења, наставимо да разговарамо о имплементацији. Најбоље праксе за имплементацију мулти-тенант овлашћења Ефективне стратегије за управљање улогама, дозволама и скалирањем у изолованим окружењима у апликацијама са више станара. Планирајте своју стратегију вишенаменског овлашћења Пре него што уроните у имплементацију било чега, неопходно је планирати како ће ваш модел за више станара радити. Ево неких кључних елемената које треба дефинисати ако користите РБАЦ модел: separate, manageable access controls Корисници: Појединци који приступају систему. Сваки може припадати више станара. Станодавци: Одвојена окружења у којима корисници раде (као налог, организација или радни простор). Uloge: unapred definisane nivoe dozvola dodeljene korisnicima unutar stanara. Ресурси: објекти (нпр. фотографије, документи) са којима корисници комуницирају, контролисани дозволама. Дозволе: Правила која дефинишу акције које улоге могу да обављају на одређеним ресурсима. Узимајући у обзир ова питања рано, можете изградити систем овлашћења прилагођен потребама ваше апликације. flexible and scalable Разумевање вишенаменских циљева Од а Sistem mora da obezbedi: single user can exist in multiple tenants Додељивање улога је по станару - дозволе корисника треба да буду подељене на њиховог одређеног станара. Ресурси су повезани са станарима - Ресурси треба да припадају одређеном станару. Дозволе се процењују динамички - Када корисник направи захтев, систем проверава и њихову улогу у станару и власништво ресурса. Оптимизација мулти-тенант ауторизације: одвајање шеме од података Заједнички изазов у мулти-тенантним системима је управљање како У традиционалним системима, улоге и дозволе су често чврсто спојене са подацима апликације. Ово може створити компликације када се дозволе морају променити, јер можда ћете морати да ажурирате оба апликација. И о samom sebi. roles and policies role assignment application data За оптимизацију за скалабилност: Skladištite uloge, dodele i politike u dedikovanom sistemu za autorizaciju (kao što je Permit.io) i odvojite podatke o aplikaciji od logike za autorizaciju. Ово одвајање вам омогућава да динамички ажурирате улоге или дозволе без додиривања кључних података или базе кода апликације. Коришћење једног извора истине - ПДП (Политичка тачка одлуке) Један од критичних концепта у оптимизацији мулти-терент ауторизације је коришћење Да доносе политичке одлуке. single source of truth Уместо складиштења информација о улози и правила приступа унутар сваке услуге или корисничке базе, делује као централна тачка у којој се доносе све одлуке о приступу. Политичка тачка за одлучивање (ПДП) Политичка тачка за одлучивање (ПДП) Benefits of using a PDP: Конзистентност: ПДП осигурава да све услуге широм апликације користе исти скуп правила приликом доношења одлука о овлашћењу. Dinamička evaluacija politika: Promene politika ili dodeljivanja uloga treba da se ažuriraju samo na jednoj lokaciji – PDP. Ova centralizacija uklanja potrebu za ažuriranjem više mesta u bazi podataka. Manje rizika od grešaka: Oslanjajući se na jednu centralizovanu tačku odlučivanja, smanjujete rizik od nedoslednih dozvola preko stanara i aplikacija. Проширење РБАЦ са контролом приступа заснованим на односу (РеБАЦ) dok пружа солидну основу за мулти-најмодавца овлашћења, постоје сценарији у којима може понудити још финије зрно контролу приступа. RBAC Kontrola pristupa na osnovu odnosa (ReBAC) Kontrola pristupa na osnovu odnosa (ReBAC) RBAC дефинише дозволе на основу улога додељених корисницима, али даје још један корак даље дефинисањем дозвола заснованих на To je posebno korisno u situacijama u kojima dozvole zavise od toga kako su resursi povezani ili povezani. ReBAC relationships Na primer, zamislite a Када корисник има приступ a , а та фолдер садржи више докумената. Са РБАЦ-ом, требало би да дефинишете улоге као што су или Међутим, са Možete to pojednostaviti tako što ćete reći: document management system folder Folder Editor Document Viewer ReBAC Korisniku je dozvoljeno da uređuje dokument ako je urednik fascikle kojoj dokument pripada. Korisniku je dozvoljeno da uređuje dokument ako je urednik fascikle kojoj dokument pripada. Ово омогућава динамичније и контекстуално осјетљивије доделе дозвола без дуплирања улога за сваки ресурс. : Benefits of ReBAC Kontekstualne dozvole: Omogućava kontrolu pristupa na osnovu dinamičkih odnosa (npr. korisnik koji je urednik u projektu i stoga ima pristup svim povezanim zadatcima). Смањена експлозија улога: Не морате да креирате улоге за сваку комбинацију типа корисника и ресурса, јер релације могу да дефинишу приступ динамички. Проширењем RBAC-а са ReBAC-ом, можете да управљате где односи између корисника и ресурса диктирају дозволе. complex access control scenarios Имплементација вишенаменске овлашћења са Дозволите ми Дозволите ми nudi jednostavan način za sprovođenje autorizacije za više stanara tako što će vam omogućiti da definišete uloge, politike i pravila pristupa u različitim okruženjima. 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() функција која проверава за мулти-тенанце РБАЦ. Ево широког прегледа како се мулти-терент РБАЦ овлашћење може поставити у Пермит.ио: 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 Овде можемо видети све наше кориснике и које улоге имају у сваком станару којима припадају: Neke od prednosti korišćenja Permit.io za autorizaciju više stanara uključuju: Централизовано управљање политиком: Дефинишите и управљајте свим правилима и политикама о овлашћењу са централизоване платформе. Додељивање улога специфичних за станаре: лако доделити и управљати улогама по станару, омогућавајући корисницима да имају различите улоге у различитим окружењима (нпр. Детаљне дозволе: имплементирајте детаљне дозволе за сваки ресурс и спроводите сложене фине дозволе (као и оне засноване на атрибутима или односима) без потребе за додатном прилагођеном логиком. ReBAC Podrška: Permit.io proširuje tradicionalni model RBAC sa ReBAC, omogućavajući vam da definišete dozvole zasnovane ne samo na korisničkim ulogama, već i na odnosima između korisnika i resursa. Сумирање: Мулти-тенант овлашћење са РБАЦ-ом Na ovom blogu smo istražili Како га комбиновати са омогућава ефикасније и скалабилније управљање корисничким дозволама у изолованим окружењима. importance of multi-tenant authorization Role-Based Access Control (RBAC) Разговарали смо о изазовима традиционалног РБАЦ-а у апликацијама за више станара и како Мулти-Тенант РБАЦ решава проблеме као што су статичке улоге, експлозија улога и контрола приступа са финим зрном. Sa dozvolom za više stanara, svaki stanar može imati sopstvenu izolovanu kontrolu pristupa, osiguravajući da korisnici imaju pristup samo onome za šta su ovlašćeni u svojim specifičnim okruženjima. омогућава вам да имплементирате овлашћење за више станара на поједностављивији начин, захваљујући централизованом управљању политикама, додељивању улога специфичних за станаре, фино израженим дозволама и подршци за контролу приступа засновану на односу (РЕБАЦ). Permit.io What’s Next? Истражите документацију Permit.io да бисте започели имплементацију мулти-тенитера овлашћења у вашој апликацији. Придружите се Permit.io заједници да бисте разговарали о најбољим праксама и добили подршку.
