Hogyan lehet végrehajtani a több bérlői jogosultságot a szerepkörökön alapuló hozzáférés-ellenőrzéssel

Multi-tenant authorizationA multi-tenancy használatával minden bérlő (például egy fiók vagy szervezet) elkülönített környezetben működik, amelyhez egyedi hozzáférési vezérlőkre van szükség, amelyek az adott környezetben meghatározott felhasználói szerepekhez igazodnak.

Az egyik leghatékonyabb módja annak, hogy végrehajtsa a többbérlő engedélyezés kombinálásávalRole-Based Access Control (RBAC) alapú hozzáférési szabályozásAz RBAC egyszerűsíti a hozzáférésmenedzsmentet azáltal, hogy előzetesen meghatározott szerepeket rendel a felhasználókhoz, amelyek meghatározzák a hozzáférési engedélyeket a környezetben.

Az RBAC-nak egyedül három fő kihívással kell szembenéznie, mivel az alkalmazások méretezik és több finom engedélyt igényelnek:

• Mivel a szerepekre korlátozódik (és nem a tulajdonságokra és a kapcsolatokra), az RBAC hiányozhat a részletességtől.
• A statikus szerepek nem rendelkeznek azzal a képességgel, hogy skálázzanak a bérlők között.
• Ahogyan az alkalmazások növekednek, a szerepek száma kezelhetetlenné válhat, ami egy úgynevezett „Role Explosion”-t eredményez.

Amulti-tenant RBAC modelmegoldja ezeket a problémákat a felhasználói hozzáférés strukturálásávalper tenant, amely lehetővé teszi a dinamikus szerepfelosztásokat és engedélyeket elszigetelt környezetekben. ahelyett, hogy egy felhasználónak egyetlen globális szerepet rendelne, az engedélyek attól függnek, hogy melyik bérlőben vannak, és milyen szerepet töltenek be az adott bérlőben.

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

Gondoljunk egy SaaS projektmenedzsment platformra, ahol a felhasználók több szervezet tagjai lehetnek, amelyek mindegyike különböző hozzáférési szinteket tartalmaz:

Egy felhasználó lehet adminisztrátor az egyik szervezetben teljes ellenőrzéssel, míg csak szerkesztő a másikban, csak a feladatok módosítására korlátozódik, de nem kezeli a felhasználókat.

Gondoljunk egy SaaS projektmenedzsment platformra, ahol a felhasználók több szervezet tagjai lehetnek, amelyek mindegyike különböző hozzáférési szinteket tartalmaz:

Egy felhasználó lehet adminisztrátor az egyik szervezetben teljes ellenőrzéssel, míg csak szerkesztő a másikban, csak a feladatok módosítására korlátozódik, de nem kezeli a felhasználókat.

A több bérlő RBAC biztosítja, hogy az engedélyek a megfelelő környezetbe kerüljenek, anélkül, hogy szükségtelenül bonyolultak lennének.

Ebben az útmutatóban felfedezzük aimportance of Multi-Tenant Authorizationmegmutatja, hogyan lehet hatékonyan alkalmazni aEngedélyezze.

Megvitatjuk, hogyan strukturáljuk a politikákat, hozzárendeljük a szerepeket bérlőenként, és érvényesítsükfine-grained permissions.

Merüljünk el benne!

Miért fontos a több bérlői engedély?

A többbérlői engedélyezés hasznos olyan alkalmazásokhoz, ahol a felhasználók több független környezethez tartoznak, mindegyik saját hozzáférési szabályokkal rendelkezik - ez a legtöbb modern felhőalapú alkalmazásban gyakori.

Az elszigetelt környezeteken átívelő engedélyek kezelése

Mivel a felhasználónak különböző szerepei és felelősségei lehetnek a különböző bérlők között, a multi-tenancy használata lehetővé teszi, hogy ezeket a szerepeket önállóan kezeljék és érvényesítsék.

Ez azt jelenti, hogy több bérlői engedélyt használhatunk a környezetek közötti egyértelmű határok fenntartására, miközben biztosítjuk, hogy a felhasználók mindegyikben rendelkezzenek a megfelelő engedélyekkel.

Vegyük például acloud storage platformahol minden ügyfél (bérlő) érzékeny adatokat tárol.Fontos a szigorú hozzáférés-ellenőrzés végrehajtása, hogy az egyik ügyfél felhasználója ne láthassa vagy módosítsa a másik felhasználó adatait.

De miért nem tudjuk ezt csak az RBAC-val megoldani?

Miért nem elég a hagyományos RBAC a több bérlő engedélyezéséhez

Sokat lehet mondani az RBAC korlátairól. A termelési alkalmazásokkal való foglalkozás során az RBAC túlságosan merevnek bizonyulhat, és túlságosan összetetté válhat a skálázáshoz.

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

Projektmenedzsment alkalmazás, amelyben a felhasználóEditoregy csapatban, de csak aViewerhozzáférést egy másikhoz.

"A szerkesztők csak a saját fényképeiket módosíthatják"

Mielőtt belemerülnénk a megvalósításba és a bevált gyakorlatokba, említsünk néhány gyakran használt multi-tenancy modellt:

Multi-Tenant közös modellek

A több bérlői felhatalmazás széles körű alkalmazásokra vonatkozik. Íme néhány a leggyakoribb módja a bérlők felépítésének:

1. Fiókok – A fogyasztói SaaS-alkalmazásokban használják, ahol minden felhasználó egy független fiókhoz tartozik (például Google Drive, Dropbox).
2. Szervezetek – Az üzleti alkalmazásokban gyakori, ahol egy vállalatnak (szervezetnek) több felhasználója van különböző szerepekkel (például Slack, Notion).
3. Csoportok – Hasznos az együttműködő környezetekhez, ahol a felhasználókat a megosztott hozzáférési igények alapján csoportosítják (például GitHub csapatok, projektmunkaterületek).
4. Franchise – Olyan rendszerekben, ahol a vállalkozások egy franchise modell alapján működnek, minden franchise önállóan működik, de követi a központi struktúrát (pl. éttermi menedzsment rendszerek).

Ezeknek a modelleknek mindegyike profitál a Multi-Tenant engedélyezésből, hogy biztosítsa a megfelelő elszigeteltséget és a szerep alapú engedélyeket bérlőenként.

Megértve a többbérleti engedélyezés előnyeit, folytassuk a végrehajtás megvitatását.

A Multi-Tenant Authorization megvalósításának legjobb gyakorlata

Hatékony stratégiák a szerepek, engedélyek és skálázás kezelésére elszigetelt környezetekben több bérlő alkalmazásokban.

Tervezze meg Multi-Tenant engedélyezési stratégiáját

Mielőtt belevetné magát bármi megvalósításába, elengedhetetlen, hogy megtervezze, hogyan fog működni a több bérlő modellje.separate, manageable access controlsÍme néhány kulcsfontosságú elem, amelyet meg kell határoznia, ha RBAC modellt használ:

• Felhasználók: A rendszerhez hozzáférő egyének. mindegyik több bérlőhöz tartozhat.
• Bérlők: Különálló környezetek, amelyekben a felhasználók működnek (például fiók, szervezet vagy munkaterület).
• Szerepek: A bérlőn belüli felhasználók számára előzetesen meghatározott jogosultsági szintek.
• Erőforrások: Olyan objektumok (például fényképek, dokumentumok), amelyekkel a felhasználók kölcsönhatásba lépnek, amelyeket engedélyek irányítanak.
• Engedélyek: szabályok, amelyek meghatározzák azokat a műveleteket, amelyeket a szerepek végrehajthatnak egy adott erőforráson.

Ha ezeket a kérdéseket korán megválaszolja, akkor egyflexible and scalableengedélyezési rendszer az Ön kérelmének igényeihez igazítva.

Multi-Tenant célok megértése

Mivel asingle user can exist in multiple tenantsA rendszernek biztosítania kell:

1. A szerepfelosztás bérlőenként történik – a felhasználó jogosultságát a konkrét bérlőre kell kiterjeszteni.
2. Az erőforrások a bérlőkhez kapcsolódnak – Az erőforrásoknak egy adott bérlőhöz kell tartozniuk.
3. A jogosultságokat dinamikusan értékelik – Amikor egy felhasználó kérést tesz, a rendszer ellenőrzi mind a bérlőben betöltött szerepét, mind az erőforrás tulajdonjogát.

Multi-Tenant Authorization optimalizálása: Schema leválasztása az adatokból

Egy közös kihívás a multi-tenant rendszerekben az, hogy hogyan kell kezelniroles and policiesA hagyományos rendszerekben a szerepek és engedélyek gyakran szorosan kapcsolódnak az alkalmazásadatokhoz. Ez komplikációkat okozhat, amikor az engedélyeket meg kell változtatni, mivel előfordulhat, hogy mindkét alkalmazást frissíteni kell.role assignmentÉs aapplication datasaját maga

A skálázhatóság optimalizálása:

• Tárolja a szerepeket, megbízásokat és politikákat egy dedikált engedélyezési rendszerben (például Permit.io), és tartsa az alkalmazásadatokat elkülönítve az engedélyezési logikától.
• Ez az eltávolítás lehetővé teszi a szerepek vagy engedélyek dinamikus frissítését anélkül, hogy megérintené az alkalmazás alapadatát vagy kódbázisát.

Az Igazság Egy Forrásának Használata - A PDP (Policy Decision Point)

Az egyik kritikus koncepció a többbérlő engedélyezésének optimalizálásában asingle source of truthpolitikai döntések meghozatalára.

Ahelyett, hogy szerepadatokat és hozzáférési szabályokat tárolnánk minden egyes szolgáltatásban vagy felhasználói adatbázisban, aPolitikai döntéshozatali pont (PDP)Központi pontként működik, ahol minden hozzáférési döntést meghoznak.

Benefits of using a PDP:

• Összhang: A PDP biztosítja, hogy az összes szolgáltatás az alkalmazáson belül ugyanazokat a szabályokat alkalmazza az engedélyezési döntések meghozatalakor.
• Dinamikus szabályzatértékelés: A szabályzatok vagy szerepfelosztások módosításait csak egy helyen kell frissíteni, azaz a PDP-ben.
• Kevesebb hiba kockázata: Az egyetlen, központosított döntéshozatali pontra támaszkodva csökkentheti a bérlők és alkalmazások közötti eltérő engedélyek kockázatát.

Kapcsolati alapú hozzáférés-ellenőrzés (Relationship-Based Access Control, ReBAC)

MiközbenRBACszilárd alapot biztosít a többbérleti engedélyezéshez, vannak olyan forgatókönyvek, amelyekbenrelationship-based access control (ReBAC)Még szűkebb hozzáférési szabályozást is kínálhat.

Az RBAC a felhasználókhoz rendelt szerepek alapján határozza meg az engedélyeket, deReBACegy lépéssel tovább, az engedélyek meghatározásával arelationshipsEz különösen olyan helyzetekben hasznos, amikor az engedélyek attól függenek, hogy az erőforrások hogyan kapcsolódnak vagy kapcsolódnak egymáshoz.

Például képzeljük el adocument management systemHa a felhasználó hozzáfér afolder, és ez a mappák több dokumentumot tartalmaznak. Az RBAC-val olyan szerepeket kell definiálnia, mintFolder EditorvagyDocument ViewerAzonban, aReBACEzt egyszerűsítheted azzal, hogy azt mondod:

„A felhasználó akkor szerkesztheti a dokumentumot, ha a dokumentumhoz tartozó mappának szerkesztője.”

„A felhasználó akkor szerkesztheti a dokumentumot, ha a dokumentumhoz tartozó mappának szerkesztője.”

Ez lehetővé teszi a dinamikusabb és kontextus-érzékenyebb engedélyek hozzárendelését anélkül, hogy az egyes erőforrásokhoz duplikált szerepeket kellene hozzárendelni.

Benefits of ReBAC:

• Kontextuális engedélyek: A dinamikus kapcsolatokon alapuló hozzáférésszabályozás lehetővé tétele (például egy felhasználó, aki egy projekt szerkesztője, és így hozzáférhet az összes kapcsolódó feladathoz).
• Csökkentett szerepek robbanása: Nem kell szerepeket létrehozni a felhasználó és az erőforrás típusainak minden egyes kombinációjára, mivel a kapcsolatok dinamikusan határozzák meg a hozzáférést.

Az RBAC kiterjesztésével a ReBAC segítségével kezelheti acomplex access control scenariosahol a felhasználók és az erőforrások közötti kapcsolatok meghatározzák az engedélyeket.

Multi-Tenant engedélyek bevezetéseEngedélyezze

Permit.ioEgy egyszerű módja annak, hogy több bérlői engedélyt hajtson végre, lehetővé téve a szerepek, irányelvek és hozzáférési szabályok meghatározását különböző környezetekben.

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

A hagyományos, statikus if A multidiszciplináris megközelítés.

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

if (permitted) {
    return true;
} 

A tiszta permit.check() Ez a funkció ellenőrzi a multi-tenance RBAC-t.

Íme egy átfogó áttekintés arról, hogyan lehet több bérlő RBAC engedélyt beállítani a Permit.io-ban:

• 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:

    
    

Itt láthatjuk az összes felhasználónkat, és milyen szerepük van az egyes bérlőkben, akikhez tartoznak:

A Permit.io használatának néhány előnye a több bérlői engedélyezéshez a következők:

• Központosított irányelvek kezelése: Az összes engedélyezési szabályt és irányelvet egy központosított platformról határozza meg és kezeli, ez egyszerűsíti a irányelvek módosítását és biztosítja a bérlők közötti következetes végrehajtást.
• Bérlő-specifikus szerepfelosztás: Könnyen hozzárendelhet és kezelhet szerepeket bérlőenként, lehetővé téve a felhasználók számára, hogy különböző szerepeket töltsenek be különböző környezetekben (például Admin egy bérlőben, Viewer egy másikban).
• Részletes engedélyek végrehajtása az egyes erőforrásokhoz, és bonyolult, részletes engedélyek érvényesítése (például attribútumokon vagy kapcsolatokon alapuló engedélyek) anélkül, hogy további egyéni logikára lenne szükség.
• ReBAC támogatás: A Permit.io kiterjeszti a hagyományos RBAC modellt a ReBAC-val, lehetővé téve, hogy ne csak a felhasználói szerepekre, hanem a felhasználók és az erőforrások közötti kapcsolatokra is alapozva engedélyeket határozzon meg.

Összefoglalva: Multi-Tenant Authorization with RBAC

Ebben a blogban felfedeztük aimportance of multi-tenant authorizationHogyan kombináljuk aRole-Based Access Control (RBAC)Lehetővé teszi a felhasználói engedélyek hatékonyabb és skálázhatóbb kezelését elszigetelt környezetekben.

Megvitattuk a hagyományos RBAC kihívásait a több bérlő alkalmazásokban, és hogyan oldja meg a Multi-Tenant RBAC olyan kérdéseket, mint a statikus szerepek, a szereprobbanás és a finom hozzáférés-ellenőrzés.

A több bérlői engedéllyel minden bérlő saját elkülönített hozzáférési szabályozással rendelkezhet, biztosítva, hogy a felhasználók csak arra férjenek hozzá, amire az adott környezetükben jogosultak.

Permit.ioLehetővé teszi több bérlő engedélyezésének egyszerűsítését a központosított irányelvkezelésnek, a bérlő-specifikus szerepfelosztásnak, a finomhangolt engedélyeknek és a Relationship-Based Access Control (ReBAC) támogatásának köszönhetően.

What’s Next?

• Fedezze fel a Permit.io dokumentációját, hogy elkezdje végrehajtani a többbérlői engedélyezést az alkalmazásában.
• Csatlakozzon a Permit.io közösséghez, hogy megvitassák a legjobb gyakorlatokat és támogatást kapjanak.