Kā ieviest Multi-Tenant autorizāciju ar lomu balstītu piekļuves kontroli

Multi-tenant authorizationar 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ē.

Viens no efektīvākajiem veidiem, kā īstenot vairāku īrnieku autorizāciju, ir to apvienot arUz lomu balstīta piekļuves kontrole (RBAC)RBAC vienkāršo piekļuves pārvaldību, piešķirot lietotājiem iepriekš noteiktas lomas, kas diktē viņu atļaujas vidē.

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".

Amulti-tenant RBAC modelatrisina šīs problēmas, strukturējot lietotāju piekļuviper tenant, ļ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ā.

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ūtadminvienā organizācijā ar pilnīgu kontroli, kamēr tikai vienseditorcitā, kas ierobežota ar uzdevumu modificēšanu, bet ne lietotāju pārvaldīšanu.

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īsimimportance of Multi-Tenant Authorizationun parādīt, kā to var efektīvi īstenotPermit.io.

Mēs apspriedīsim, kā strukturēt politiku, piešķirt lomas katram īrniekam un īstenotfine-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 acloud storage platformir svarīgi īstenot stingru piekļuves kontroli, lai lietotājs no viena klienta nevarētu apskatīt vai modificēt datus no cita.

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, 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.

Projekta vadības lietotne, kurā lietotājs irEditorvienā komandā, bet tikai tad, jaViewerIeeja citā vietā.

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:

1. Lietotāju SaaS lietojumprogrammās, kur katrs lietotājs pieder atsevišķam kontam (piemēram, Google Drive, Dropbox).
2. 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).
3. 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).
4. 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.separate, manageable access controlsŠeit ir daži galvenie elementi, kas jums jādefinē, ja izmantojat RBAC modeli:

• 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 izveidotflexible and scalableautorizācijas sistēma, kas pielāgota jūsu pieteikuma vajadzībām.

Izpratne par daudzkārtējiem mērķiem

Kopš asingle user can exist in multiple tenantsSistēmai ir jānodrošina:

1. Lomu piešķīrumi ir katram īrniekam - Lietotāja atļaujas būtu jāattiecina uz konkrēto īrnieku.
2. Resursi ir saistīti ar īrniekiem - Resursiem vajadzētu piederēt konkrētam īrniekam.
3. 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āroles and policiesTradicionālajās sistēmās lomas un atļaujas bieži vien ir cieši saistītas ar lietojumprogrammas datiem.role assignmentun tāsapplication datapaši sevi

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 izmantotsingle source of truthpieņemt politiskus lēmumus.

Tā vietā, lai glabātu lomu informāciju un piekļuves noteikumus katrā pakalpojumā vai lietotāju datubāzē,Politisko lēmumu pieņemšanas punkts (PDP)darbojas kā centrālais punkts, kur tiek pieņemti visi piekļuves lēmumi.

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ērRBACnodrošina stabilu pamatu vairāku īrnieku autorizācijai, ir scenāriji, kurosUz attiecībām balstīta piekļuves kontrole (ReBAC)var piedāvāt vēl smalkāku piekļuves kontroli.

RBAC definē atļaujas, pamatojoties uz lietotājiem piešķirtām lomām, betReBACveicot soli tālāk, nosakot atļaujas, pamatojoties uzrelationshipsTas 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.

Piemēram, iedomājieties adocument management systemLietotājam ir piekļuve afolder, un šī mape satur vairākus dokumentus. ar RBAC jums vajadzētu definēt lomas, piemēram,Folder EditorvaiDocument ViewerTomēr, arReBACTo var vienkāršot, sakot:

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 varatcomplex access control scenarioskur attiecības starp lietotājiem un resursiem diktē atļaujas.

Multi-Tenant atļaujas ieviešana arAtļauja.lv

Permit.iopiedā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.

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

  

  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:

    
    

Š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šiimportance of multi-tenant authorizationKā to apvienot arRole-Based Access Control (RBAC)nodrošina efektīvāku un mērogojamu lietotāju atļauju pārvaldību izolētās vidēs.

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ē.

Permit.ioļ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).

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.