ar multi-tenancy, katrs īrnieks (piemēram, konts vai organizācija) darbojas izolētā vidē, kas prasa unikālas piekļuves kontroles, kas pielāgotas konkrētām lietotāja lomām šajā vidē. Multi-tenant authorization Viens no efektīvākajiem veidiem, kā īstenot vairāku īrnieku autorizāciju, ir to apvienot ar RBAC vienkāršo piekļuves pārvaldību, piešķirot lietotājiem iepriekš noteiktas lomas, kas diktē viņu atļaujas vidē. Uz lomu balstīta piekļuves kontrole (RBAC) Uz lomu balstīta piekļuves kontrole (RBAC) Vienīgi RBAC saskaras ar trim galvenajām problēmām, jo pieteikumi paplašinās un prasa vairāk smalku atļauju: Būdams ierobežots ar lomām (nevis ar atribūtiem un attiecībām), RBAC var trūkst granularitātes. Tās statiskajām lomām trūkst spējas mērogot pa īrniekiem. Kad lietojumprogrammas aug, lomu skaits var kļūt pārvaldāms, izraisot to, ko sauc par "Role Explosion". A atrisina šīs problēmas, strukturējot lietotāju piekļuvi , ļaujot dinamisku lomu piešķiršanu un atļaujas izolētās vidēs. Tā vietā, lai piešķirtu lietotājam vienu globālu lomu, viņu atļaujas ir atkarīgas no tā, kurā īrniekā viņi atrodas un kāda loma viņiem ir šajā īrniekā. multi-tenant RBAC model per tenant Here’s a quick example of when this can be useful: Iedomājieties SaaS projektu vadības platformu, kurā lietotāji var būt vairāku organizāciju locekļi, katrs ar atšķirīgiem piekļuves līmeņiem: Lietotājs var būt administrators vienā organizācijā ar pilnīgu kontroli, bet tikai redaktors citā, kas ir ierobežots ar uzdevumu modificēšanu, bet ne lietotāju pārvaldīšanu. Iedomājieties SaaS projektu vadības platformu, kurā lietotāji var būt vairāku organizāciju locekļi, katrs ar atšķirīgiem piekļuves līmeņiem: Lietotājs var būt vienā organizācijā ar pilnīgu kontroli, kamēr tikai viens citā, kas ierobežota ar uzdevumu modificēšanu, bet ne lietotāju pārvaldīšanu. admin editor Vairāku nomnieku RBAC nodrošina, ka atļaujas tiek aptvertas pareizajā vidē bez nevajadzīgas sarežģītības. Šajā ceļvedī mēs izpētīsim un parādīt, kā to var efektīvi īstenot . importance of Multi-Tenant Authorization Permit.io Atļauja.lv Mēs apspriedīsim, kā strukturēt politiku, piešķirt lomas katram īrniekam un īstenot . fine-grained permissions Mēģināsim ienirt iekšā. Kāpēc ir svarīga vairāku īrnieku atļauja? Vairāku īrnieku autorizācija ir noderīga lietojumprogrammām, kurās lietotāji pieder vairākām neatkarīgām vidēm, katrai no tām ir savi piekļuves noteikumi - tas ir bieži sastopams lielākajā daļā mūsdienu mākonī balstītu lietojumprogrammu. Atļaujas izmantošana izolētās vidēs Ar multi-tenancy, katrs lietotājs var saņemt pielāgotu pieeju savu piekļuves kontroli, pamatojoties uz savu īrnieku. kā lietotājs var būt dažādas lomas un atbildības dažādos īrniekiem, izmantošana multi-tenancy ļauj šīs lomas ir jāpārvalda un īsteno neatkarīgi. Tas nozīmē, ka mēs varam izmantot vairāku īrnieku atļaujas, lai saglabātu skaidras robežas starp vidēm, vienlaikus nodrošinot, ka lietotājiem ir atbilstošas atļaujas katrā no tām. Piemēram, apsveriet a ir svarīgi īstenot stingru piekļuves kontroli, lai lietotājs no viena klienta nevarētu apskatīt vai modificēt datus no cita. cloud storage platform Bet kāpēc mēs to nevaram atrisināt tikai ar RBAC? Kāpēc tradicionālā RBAC nav pietiekama vairāku īrnieku atļaujai Daudz var teikt par RBAC ierobežojumiem. Kad runa ir par lietojumiem ražošanā, RBAC var izrādīties pārāk stingrs un kļūt pārāk sarežģīts, lai mērogotu. 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. Projekta vadības lietotne, kurā lietotājs ir vienā komandā, bet tikai tad, ja Ieeja citā vietā. Editor Viewer Izdevēji var mainīt tikai savas fotogrāfijas Pirms mēs iegremdēsimies īstenošanā un paraugpraksē, pieminēsim dažus bieži izmantotos multi-tenancy modeļus: Kopējie daudzvietējie modeļi Vairāku īrnieku atļauja attiecas uz plašu pieteikumu klāstu. Šeit ir daži no visbiežāk sastopamajiem veidiem, kā īrnieki ir strukturēti: Lietotāju SaaS lietojumprogrammās, kur katrs lietotājs pieder atsevišķam kontam (piemēram, Google Drive, Dropbox). Organizācijas - Parasti uzņēmējdarbības lietojumprogrammās, kur uzņēmumam (organizācijai) ir vairāki lietotāji ar dažādām lomām (piemēram, Slack, Notion). Grupas – noderīga sadarbības vidēs, kur lietotāji ir grupēti, pamatojoties uz kopīgām piekļuves vajadzībām (piemēram, GitHub komandas, projektu darba telpas). Franšīzes – sistēmās, kurās uzņēmumi darbojas saskaņā ar franšīzes modeli, katra franšīze darbojas neatkarīgi, bet seko centrālai struktūrai (piemēram, restorānu pārvaldības sistēmām). Katrs no šiem modeļiem gūst labumu no Multi-Tenant atļaujas, lai nodrošinātu pareizu izolāciju un uz lomu balstītas atļaujas katram īrniekam. Izprotot vairāku īrnieku atļaujas priekšrocības, pārejam pie apspriešanās par īstenošanu. Labākā prakse daudzkārtējas autorizācijas īstenošanai Efektīvas stratēģijas lomu, atļauju un mēroga pārvaldībai izolētās vidēs daudzviet lietojumprogrammās. Plānojiet savu vairāku īrnieku autorizācijas stratēģiju Pirms niršanas kaut ko īstenot, ir svarīgi plānot, kā darbosies jūsu vairāku īrnieku modelis. Šeit ir daži galvenie elementi, kas jums jādefinē, ja izmantojat RBAC modeli: separate, manageable access controls Lietotāji: indivīdi, kas piekļūst sistēmai. katrs var piederēt vairākiem īrniekiem. Izīrētāji: Atsevišķas vides, kurās lietotāji darbojas (piemēram, konts, organizācija vai darba telpa). Lomas: Iepriekš definēti atļauju līmeņi, kas piešķirti lietotājiem īrnieka iekšienē. Resursi: objekti (piemēram, fotogrāfijas, dokumenti), ar kuriem lietotāji mijiedarbojas, ko kontrolē atļaujas. Atļaujas: Noteikumi, kas nosaka darbības, ko lomas var veikt konkrētos resursos. Atbildot uz šiem jautājumiem agri, jūs varat izveidot autorizācijas sistēma, kas pielāgota jūsu pieteikuma vajadzībām. flexible and scalable Izpratne par daudzkārtējiem mērķiem Kopš a Sistēmai ir jānodrošina: single user can exist in multiple tenants Lomu piešķīrumi ir katram īrniekam - Lietotāja atļaujas būtu jāattiecina uz konkrēto īrnieku. Resursi ir saistīti ar īrniekiem - Resursiem vajadzētu piederēt konkrētam īrniekam. Atļaujas tiek novērtētas dinamiski – kad lietotājs iesniedz pieprasījumu, sistēma pārbauda gan viņu lomu īrniekā, gan resursu īpašumtiesības. Multi-Tenant autorizācijas optimizēšana: shēmas atvienošana no datiem Visbiežāk sastopamā problēma multi-tender sistēmās ir pārvaldīt, kā Tradicionālajās sistēmās lomas un atļaujas bieži vien ir cieši saistītas ar lietojumprogrammas datiem. un tās paši sevi roles and policies role assignment application data Lai optimizētu skalojamību: Glabā lomas, uzdevumus un politikas īpašā autorizācijas sistēmā (piemēram, Permit.io) un saglabā pieteikuma datus atsevišķi no autorizācijas loģikas. Šī atvienošana ļauj dinamiski atjaunināt lomas vai atļaujas, neietekmējot lietojumprogrammas pamatdatu vai koda bāzi. Izmantojiet vienu patiesības avotu - PDP (Policy Decision Point) Viens no kritiskajiem jēdzieniem, optimizējot vairāku īrnieku autorizāciju, ir izmantot pieņemt politiskus lēmumus. single source of truth Tā vietā, lai glabātu lomu informāciju un piekļuves noteikumus katrā pakalpojumā vai lietotāju datubāzē, darbojas kā centrālais punkts, kur tiek pieņemti visi piekļuves lēmumi. Politisko lēmumu pieņemšanas punkts (PDP) Politisko lēmumu pieņemšanas punkts (PDP) Benefits of using a PDP: Konsekvence: PDP nodrošina, ka visi pakalpojumi visā pieteikumā atsaucas uz to pašu noteikumu kopumu, pieņemot lēmumus par atļaujām. Dinamiskā politikas novērtēšana: politikas vai lomu piešķiršanas izmaiņas jāatjaunina tikai vienā vietā — PDP. Mazāks kļūdu risks: paļaujoties uz vienu centralizētu lēmumu pieņemšanas punktu, jūs samazināt neatbilstīgu atļauju risku starp īrniekiem un lietojumprogrammām. RBAC paplašināšana ar attiecībām balstītu piekļuves kontroli (ReBAC) Kamēr nodrošina stabilu pamatu vairāku īrnieku autorizācijai, ir scenāriji, kuros var piedāvāt vēl smalkāku piekļuves kontroli. RBAC Uz attiecībām balstīta piekļuves kontrole (ReBAC) Uz attiecībām balstīta piekļuves kontrole (ReBAC) RBAC definē atļaujas, pamatojoties uz lietotājiem piešķirtām lomām, bet veicot soli tālāk, nosakot atļaujas, pamatojoties uz Tas ir īpaši noderīgi situācijās, kad atļaujas ir atkarīgas no tā, kā resursi ir savienoti vai savstarpēji saistīti. ReBAC relationships Piemēram, iedomājieties a Lietotājam ir piekļuve a , un šī mape satur vairākus dokumentus. ar RBAC jums vajadzētu definēt lomas, piemēram, vai Tomēr, ar To var vienkāršot, sakot: document management system folder Folder Editor Document Viewer ReBAC Lietotājam ir atļauts rediģēt dokumentu, ja viņš ir tās mapes redaktors, kurai pieder dokuments. Lietotājam ir atļauts rediģēt dokumentu, ja viņš ir tās mapes redaktors, kurai pieder dokuments. Tas ļauj dinamisku un kontekstveidīgu atļauju piešķiršanu bez lomu dublēšanas katram resursam. : Benefits of ReBAC Kontekstuālās atļaujas: Atļauj piekļuves kontroli, pamatojoties uz dinamiskām attiecībām (piemēram, lietotājs ir projekta redaktors un tādējādi ir piekļuve visiem saistītajiem uzdevumiem). Samazināta lomu eksplozija: Jums nav jāizveido lomas katrai lietotāja un resursu tipa kombinācijai, jo attiecības var definēt piekļuvi dinamiski. Paplašinot RBAC ar ReBAC, jūs varat kur attiecības starp lietotājiem un resursiem diktē atļaujas. complex access control scenarios Multi-Tenant atļaujas ieviešana ar Atļauja.lv Atļauja.lv piedāvā vienkāršu veidu, kā īstenot vairāku īrnieku autorizāciju, ļaujot jums definēt lomas, politiku un piekļuves noteikumus dažādās vidēs. Permit.io if (user.role == admin && user.tenant == resource.tenant) { return true; } Tradicionālā, statiskā if Attiecības ar multi-tenance. const permitted = await permit.check(user, "read", { resource: "document", tenant: "default" }); if (permitted) { return true; } Tīrs permit.check() Funkcija, kas pārbauda multi-tenance RBAC. Šeit ir plašs pārskats par to, kā Permit.io var iestatīt vairāku īrnieku RBAC autorizāciju: 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 Šeit mēs varam redzēt visus mūsu lietotājus un kādas lomas viņiem ir katrā īrniekā, kam viņi pieder: Dažas no Permit.io izmantošanas priekšrocībām vairāku īrnieku autorizācijai ir: Centralizēta politikas pārvaldība: definējiet un pārvaldiet visus autorizācijas noteikumus un politiku no centralizētas platformas. Vienkārši piešķir un pārvalda lomas katram īrniekam, ļaujot lietotājiem veikt dažādas lomas dažādās vidēs (piemēram, administrators vienā īrniekā, skatītājs citā). Smalki sagrieztas atļaujas: īsteno detalizētas atļaujas katram resursam un īsteno sarežģītas smalki sagrieztas atļaujas (piemēram, tās, kas balstītas uz atribūtiem vai attiecībām) bez nepieciešamības izmantot papildu pielāgotu loģiku. ReBAC atbalsts: Permit.io paplašina tradicionālo RBAC modeli ar ReBAC, ļaujot jums definēt atļaujas, pamatojoties ne tikai uz lietotāja lomām, bet arī attiecībām starp lietotājiem un resursiem. Summing Up: Multi-Tenant atļauja ar RBAC Šajā blogā mēs esam izpētījuši Kā to apvienot ar nodrošina efektīvāku un mērogojamu lietotāju atļauju pārvaldību izolētās vidēs. importance of multi-tenant authorization Role-Based Access Control (RBAC) Mēs esam apsprieduši tradicionālo RBAC izaicinājumus vairāku īrnieku lietojumprogrammās un to, kā Multi-Tenant RBAC atrisina tādus jautājumus kā statiskās lomas, lomu eksplozijas un smalki graudu piekļuves kontrole. Ar vairāku īrnieku atļauju katram īrniekam var būt sava izolēta piekļuves kontrole, nodrošinot, ka lietotājiem ir piekļuve tikai tam, kam viņi ir pilnvaroti savā konkrētajā vidē. ļauj vienkāršāk īstenot vairāku īrnieku autorizāciju, pateicoties centralizētai politikas pārvaldībai, īrnieka specifiskai lomu piešķiršanai, smalki sagrieztām atļaujām un atbalstu attiecībām balstītai piekļuves kontrolei (ReBAC). Permit.io What’s Next? Izpētīt Permit.io dokumentāciju, lai sāktu īstenot vairāku īrnieku autorizāciju savā pieteikumā. Pievienojieties Permit.io kopienai, lai apspriestu labāko praksi un saņemtu atbalstu.
