Con multi-tenancy, ogni inquilino (ad esempio, un account o un'organizzazione) funziona in un ambiente isolato, richiedendo controlli di accesso unici su misura per ruoli specifici dell'utente all'interno di quel ambiente. Multi-tenant authorization Uno dei modi più efficaci per implementare l'autorizzazione multi-tenant è combinandola con RBAC semplifica la gestione dell'accesso assegnando agli utenti ruoli predefiniti che dettano le loro autorizzazioni all'interno di un ambiente. Controllo di accesso basato su ruoli (RBAC) Controllo di accesso basato su ruoli (RBAC) Solo RBAC affronta tre grandi sfide in quanto le applicazioni crescono e richiedono autorizzazioni più sottili: Essendo limitato ai ruoli (e non agli attributi e alle relazioni), il RBAC può mancare di granularità. I suoi ruoli statici mancano della capacità di scalare tra gli inquilini. Con la crescita delle applicazioni, il numero di ruoli può diventare incontrollabile, con il risultato di una cosiddetta “Role Explosion”. a risolve questi problemi strutturando l'accesso utente , consentendo assegnazioni di ruoli e autorizzazioni dinamiche all'interno di ambienti isolati. Invece di assegnare a un utente un singolo ruolo globale, le loro autorizzazioni dipendono da quale inquilino si trovano e quale ruolo hanno all'interno di quel inquilino. multi-tenant RBAC model per tenant Here’s a quick example of when this can be useful: Pensate a una piattaforma di gestione del progetto SaaS in cui gli utenti possono essere membri di più organizzazioni, ognuna con livelli di accesso distinti: Un utente potrebbe essere un amministratore in un'organizzazione con il controllo completo, mentre solo un editor in un'altra, limitato a modificare le attività ma non a gestire gli utenti. Pensate a una piattaforma di gestione del progetto SaaS in cui gli utenti possono essere membri di più organizzazioni, ognuna con livelli di accesso distinti: Un utente potrebbe essere un amministratore in un'organizzazione con il controllo completo, mentre solo un editor in un'altra, limitato a modificare le attività ma non a gestire gli utenti. RBAC multi-tenant assicura che le autorizzazioni siano estese all'ambiente giusto senza inutili complessità. In questa guida, esploreremo il e mostrare come può essere implementato in modo efficiente . importance of Multi-Tenant Authorization Permit.io Permesso io Discuteremo di come strutturare le politiche, assegnare ruoli per inquilino e applicare . fine-grained permissions Andiamo a immergersi. Perché è importante l’autorizzazione multinazionale? L'autorizzazione multi-tenant è utile per le applicazioni in cui gli utenti appartengono a più ambienti indipendenti, ognuno con le proprie regole di accesso - un fenomeno comune nella maggior parte delle moderne applicazioni basate sul cloud. Permessi di gestione in ambienti isolati Con multi-tenancy, ogni utente può ricevere un approccio su misura al controllo dell'accesso in base al suo inquilino. Poiché un utente potrebbe avere ruoli e responsabilità diversi tra diversi inquilini, l'uso di multi-tenancy consente che questi ruoli debbano essere gestiti e applicati in modo indipendente. Ciò significa che possiamo utilizzare l'autorizzazione multi-tenant per mantenere limiti chiari tra gli ambienti, assicurando al contempo che gli utenti abbiano le autorizzazioni appropriate all'interno di ciascuno. Per esempio, considerare a È fondamentale imporre un rigoroso controllo di accesso in modo che un utente di un cliente non possa visualizzare o modificare i dati di un altro. cloud storage platform Ma perché non possiamo risolvere questo con il RBAC? Perché il RBAC tradizionale non è sufficiente per l'autorizzazione multi-tenant Molto si può dire sulle limitazioni del RBAC. Quando si tratta di applicazioni in produzione, il RBAC può rivelarsi troppo rigido e diventare troppo complesso per scalare. 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. Un’applicazione di gestione del progetto in cui un utente è un in una sola squadra, ma dovrebbe essere accesso ad un altro. Editor Viewer "Gli editori possono modificare solo le proprie foto" Prima di immergersi nell'implementazione e nelle migliori pratiche, menzioneremo alcuni modelli di multi-tenancy comunemente usati: Modelli multi-tenant comuni L'autorizzazione a più inquilini si applica a una vasta gamma di applicazioni. Ecco alcuni dei modi più comuni in cui i inquilini sono strutturati: Conti – Utilizzati nelle applicazioni SaaS di consumo, in cui ogni utente appartiene a un account indipendente (ad esempio, Google Drive, Dropbox). Organizzazioni – comune nelle applicazioni aziendali, dove un'azienda (organizzazione) ha più utenti con ruoli diversi (ad esempio, Slack, Notion). Gruppi – Utile per gli ambienti collaborativi, dove gli utenti sono raggruppati in base alle esigenze di accesso condiviso (ad esempio, team GitHub, spazi di lavoro del progetto). In sistemi in cui le imprese operano in base a un modello di franchising, ogni franchising funziona in modo indipendente ma segue una struttura centrale (ad esempio, sistemi di gestione del ristorante). Ciascuno di questi modelli beneficia dell'autorizzazione Multi-Tenant per garantire un adeguato isolamento e autorizzazioni basate su ruoli per inquilino. Comprendendo i vantaggi dell'autorizzazione multi-tenant, procediamo a discutere dell'implementazione. Le migliori pratiche per l’autorizzazione multi-tenant Strategie efficaci per la gestione dei ruoli, delle autorizzazioni e della scalabilità in ambienti isolati in applicazioni multi-tenant. Pianifica la tua strategia di autorizzazione multi-tenant Prima di immergersi nell'implementazione di qualsiasi cosa, è essenziale pianificare come funzionerà il modello multi-tenant. Ecco alcuni elementi chiave che dovresti definire se stai usando un modello RBAC: separate, manageable access controls Utenti: individui che accedono al sistema. Ognuno può appartenere a più inquilini. Locatari: ambienti separati in cui gli utenti operano (come account, organizzazione o spazio di lavoro). Ruoli: livelli di autorizzazione predefiniti assegnati agli utenti all'interno di un inquilino. Risorse: oggetti (ad esempio foto, documenti) con cui gli utenti interagiscono, controllati da autorizzazioni. Permessi: regole che definiscono le azioni che i ruoli possono eseguire su risorse specifiche. Rispondendo a queste domande in anticipo, si può costruire un sistema di autorizzazione adattato alle esigenze della tua applicazione. flexible and scalable Comprendere gli obiettivi multi-tenant Dal momento che a Il sistema deve garantire: single user can exist in multiple tenants Le assegnazioni di ruoli sono per inquilino – Le autorizzazioni di un utente dovrebbero essere estese al loro inquilino specifico. Le risorse sono collegate ai locatari – le risorse dovrebbero appartenere a un locatario specifico. I permessi vengono valutati dinamicamente: quando un utente effettua una richiesta, il sistema controlla sia il loro ruolo nel locatore che la proprietà della risorsa. Ottimizzazione dell'autorizzazione multi-tenant: disconnettere lo schema dai dati Una sfida comune nei sistemi multi-tenant è quello di gestire come In sistemi tradizionali, ruoli e autorizzazioni sono spesso strettamente associati ai dati dell'applicazione. Questo può creare complicazioni quando le autorizzazioni devono cambiare, in quanto potrebbe essere necessario aggiornare entrambi i dati dell'applicazione. e il di sé. roles and policies role assignment application data Per ottimizzare la scalabilità: Conservare ruoli, assegnazioni e politiche in un sistema di autorizzazione dedicato (come Permit.io) e tenere separati i dati dell'applicazione dalla logica di autorizzazione. Questa disconnessione consente di aggiornare i ruoli o le autorizzazioni in modo dinamico senza toccare i dati di base o la base di codice dell'applicazione. Usare una fonte di verità - il PDP (Political Decision Point) Uno dei concetti critici nell'ottimizzazione dell'autorizzazione multi-tenant è l'utilizzo di un per prendere decisioni politiche. single source of truth Invece di memorizzare le informazioni di ruolo e le regole di accesso all'interno di ciascun servizio o database utente, il agisce come il punto centrale in cui vengono prese tutte le decisioni di accesso. Policy Decision Point (PDP) Il punto di decisione politica (PDP) Benefits of using a PDP: Consistenza: il PDP assicura che tutti i servizi in tutta l'applicazione si riferiscono allo stesso insieme di regole quando si prendono decisioni di autorizzazione. Valutazione dinamica delle politiche: le modifiche alle politiche o alle assegnazioni di ruoli devono essere aggiornate solo in una posizione, il PDP. Questa centralizzazione elimina la necessità di aggiornare più posizioni nel database o nel codice. Meno rischio di errori: affidandosi a un unico punto decisionale centralizzato, si riduce il rischio di autorizzazioni inconsistenti tra inquilini e applicazioni. Controllo di accesso basato su relazioni (ReBAC) Mentre fornisce una solida base per l'autorizzazione multi-tenant, ci sono scenari in cui può offrire un controllo di accesso ancora più fine-grain. RBAC relationship-based access control (ReBAC) Controllo di accesso basato sulle relazioni (ReBAC) RBAC definisce le autorizzazioni in base ai ruoli assegnati agli utenti, ma un ulteriore passo per definire le autorizzazioni basate sul Questo è particolarmente utile in situazioni in cui le autorizzazioni dipendono dal modo in cui le risorse sono collegate o associate tra loro. ReBAC relationships Per esempio, immaginate a Quando un utente ha accesso a , e quella cartella contiene più documenti. Con RBAC, dovresti definire ruoli come o Tuttavia, con Potresti semplificarlo dicendo: document management system folder Folder Editor Document Viewer ReBAC “Un utente può modificare un documento se è un editor della cartella alla quale appartiene il documento.” “Un utente può modificare un documento se è un editor della cartella alla quale appartiene il documento.” Ciò consente assegnazioni di autorizzazioni più dinamiche e sensibili al contesto senza duplicare ruoli per ogni risorsa. : Benefits of ReBAC Permessi contestuali: consente il controllo dell'accesso basato su relazioni dinamiche (ad esempio, un utente che è un editor in un progetto e quindi ha accesso a tutte le attività correlate). Riduzione dell'esplosione dei ruoli: non è necessario creare ruoli per ogni combinazione di tipo utente e risorsa, poiché le relazioni possono definire l'accesso in modo dinamico. Estendendo RBAC con ReBAC, è possibile gestire dove le relazioni tra utenti e risorse dettano autorizzazioni. complex access control scenarios Implementazione dell'autorizzazione multinazionale con Permesso io Permesso io offre un modo semplice per implementare l'autorizzazione a più inquilini, consentendo di definire ruoli, politiche e regole di accesso in diversi ambienti. Permit.io if (user.role == admin && user.tenant == resource.tenant) { return true; } Tradizionale e statica if L’approccio per la multi-tenance. const permitted = await permit.check(user, "read", { resource: "document", tenant: "default" }); if (permitted) { return true; } Una pulizia permit.check() funzione che controlla per multi-tenance RBAC. Ecco un'ampia panoramica di come l'autorizzazione RBAC multi-tenant può essere impostata in Permit.io: 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 Qui, possiamo vedere tutti i nostri utenti e quali ruoli hanno in ciascun inquilino a cui appartengono: Alcuni dei vantaggi dell'utilizzo di Permit.io per l'autorizzazione multi-tenant includono: Gestione centralizzata delle politiche: definire e gestire tutte le regole e le politiche di autorizzazione da una piattaforma centralizzata. Assegnazione di ruoli specifici per inquilini: assegna e gestisce facilmente ruoli per inquilino, consentendo agli utenti di avere ruoli diversi in ambienti diversi (ad esempio, amministratore in un inquilino, visualizzatore in un altro). Implementare autorizzazioni dettagliate per ciascuna risorsa e imporre autorizzazioni complesse a grani sottili (come quelle basate su attributi o relazioni) senza la necessità di ulteriori logiche personalizzate. Supporto ReBAC: Permit.io estende il tradizionale modello RBAC con ReBAC, consentendo di definire autorizzazioni basate non solo sui ruoli degli utenti, ma anche sulle relazioni tra utenti e risorse. Questo è particolarmente utile quando hai bisogno di autorizzazioni contextuali, come consentire l'accesso a risorse a seconda della loro struttura organizzativa o gerarchie. Summing Up: Autorizzazione Multi-Tenant con RBAC In questo blog abbiamo esplorato il Come combinare con consente una gestione delle autorizzazioni degli utenti più efficiente e scalabile in ambienti isolati. importance of multi-tenant authorization Role-Based Access Control (RBAC) Abbiamo discusso delle sfide del RBAC tradizionale nelle applicazioni multi-tenant e di come Multi-Tenant RBAC risolve problemi come i ruoli statici, l'esplosione del ruolo e il controllo dell'accesso a grani sottili. Con l'autorizzazione a più inquilini, ogni inquilino può avere il proprio controllo di accesso isolato, assicurando che gli utenti abbiano accesso solo a ciò per cui sono autorizzati all'interno dei loro ambienti specifici. consente di implementare l'autorizzazione a più inquilini in modo più semplificato, grazie alla gestione centralizzata delle politiche, allocazione di ruoli specifici per inquilini, autorizzazioni a grano sottile e supporto per il controllo di accesso basato sulla relazione (ReBAC). Permit.io What’s Next? Esplora la documentazione di Permit.io per iniziare a implementare l'autorizzazione multi-tenant nella tua applicazione. Unisciti alla comunità Permit.io per discutere le migliori pratiche e ottenere supporto.
