A 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. Multi-tenant authorization Az egyik leghatékonyabb módja annak, hogy végrehajtsa a többbérlő engedélyezés kombinálásával Az 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. Role-Based Access Control (RBAC) alapú hozzáférési szabályozás Role-Based Access Control (RBAC) alapú hozzáférési szabályozás 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. A megoldja ezeket a problémákat a felhasználói hozzáférés strukturálásával , 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. multi-tenant RBAC model per tenant 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 a megmutatja, hogyan lehet hatékonyan alkalmazni a . importance of Multi-Tenant Authorization Engedélyezze Engedélyezze Megvitatjuk, hogyan strukturáljuk a politikákat, hozzárendeljük a szerepeket bérlőenként, és érvényesítsük . fine-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 a ahol 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. cloud storage platform 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,   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. Projektmenedzsment alkalmazás, amelyben a felhasználó egy csapatban, de csak a hozzáférést egy másikhoz. Editor Viewer "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: 
 
 
 
 
 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). 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). 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). 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. Íme néhány kulcsfontosságú elem, amelyet meg kell határoznia, ha RBAC modellt használ: separate, manageable access controls 
 
 
 
 
 
 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 egy engedélyezési rendszer az Ön kérelmének igényeihez igazítva. flexible and scalable Multi-Tenant célok megértése Mivel a A rendszernek biztosítania kell: single user can exist in multiple tenants 
 
 
 
 A szerepfelosztás bérlőenként történik – a felhasználó jogosultságát a konkrét bérlőre kell kiterjeszteni. Az erőforrások a bérlőkhez kapcsolódnak – Az erőforrásoknak egy adott bérlőhöz kell tartozniuk. 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 kezelni A 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. És a saját maga roles and policies role assignment application data 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 a politikai döntések meghozatalára. single source of truth Ahelyett, hogy szerepadatokat és hozzáférési szabályokat tárolnánk minden egyes szolgáltatásban vagy felhasználói adatbázisban, a Központi pontként működik, ahol minden hozzáférési döntést meghoznak. Politikai döntéshozatali pont (PDP) Politikai döntéshozatali pont (PDP) 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özben szilárd alapot biztosít a többbérleti engedélyezéshez, vannak olyan forgatókönyvek, amelyekben Még szűkebb hozzáférési szabályozást is kínálhat. RBAC relationship-based access control (ReBAC) Kapcsolaton alapuló hozzáférés-ellenőrzés (ReBAC) Az RBAC a felhasználókhoz rendelt szerepek alapján határozza meg az engedélyeket, de egy lépéssel tovább, az engedélyek meghatározásával a Ez 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. ReBAC relationships Például képzeljük el a Ha a felhasználó hozzáfér a , és ez a mappák több dokumentumot tartalmaznak. Az RBAC-val olyan szerepeket kell definiálnia, mint vagy Azonban, a Ezt egyszerűsítheted azzal, hogy azt mondod: document management system folder Folder Editor Document Viewer ReBAC 
 
 „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 a ahol a felhasználók és az erőforrások közötti kapcsolatok meghatározzák az engedélyeket. complex access control scenarios Multi-Tenant engedélyek bevezetése Engedélyezze Engedélyezze Egy 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. Permit.io 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   (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 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 a Hogyan kombináljuk a Lehetővé teszi a felhasználói engedélyek hatékonyabb és skálázhatóbb kezelését elszigetelt környezetekben. importance of multi-tenant authorization Role-Based Access Control (RBAC) 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. Lehető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. Permit.io 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.

Ez a hanganyag a történet eredeti nyelvén készült!

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

About Author

HOZZÁSZÓLÁSOK

HANG TAGOK

EZT A CIKKET BEMUTATTA

Related Stories

THE LAST DAY OF NEW YORK

INTRODUCTION

A SECOND ENIGMA

Hubble Protocol, a DeFi project on Solana Raises $10 Million Led By Crypto.com Capital, DCG and CMS

THE LAST DAY OF NEW YORK

INTRODUCTION

A SECOND ENIGMA

Hubble Protocol, a DeFi project on Solana Raises $10 Million Led By Crypto.com Capital, DCG and CMS

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps