--- term: 'Controllo degli accessi basato sui ruoli (RBAC)' seoTitle: 'RBAC: ruoli, modello NIST, esplosione dei ruoli, progettazione' headline: 'Che cos''è il controllo degli accessi basato sui ruoli (RBAC)?' slug: controllo-degli-accessi-rbac category: auth-security shortDefinition: 'Il controllo degli accessi basato sui ruoli è un modello di autorizzazione in cui i permessi si agganciano ai ruoli, mai direttamente alle persone.' relatedTerms: - access-control-lists-acl - class-level-permissions-clp - identity-access-management-iam - row-level-security contrastsWith: - access-control-lists-acl aboutTerms: - 'Role Hierarchy' - 'Separation of Duties' - 'Role Explosion' faq: - question: 'Che cos''è RBAC, in parole semplici?' answer: 'L''accesso si concede per funzione lavorativa, non per persona: i permessi si agganciano a ruoli – Editor, Admin, Support – e gli utenti ereditano tutto ciò che portano i ruoli loro assegnati. Assunzione, promozione e uscita diventano cambi di ruolo in un unico posto, invece di modifiche di permessi sparse un po'' dappertutto.' - question: 'Qual è la differenza tra RBAC e ABAC?' answer: 'RBAC decide a partire da ruoli predefiniti; il controllo degli accessi basato sugli attributi (ABAC) valuta attributi dell''utente, della risorsa e del contesto – reparto, sensibilità, orario – al momento della richiesta. RBAC è più semplice da ragionare e da verificare; ABAC è più fine e più difficile da debuggare. I sistemi maturi usano RBAC come base e aggiungono condizioni su attributi dove il contesto conta davvero.' - question: 'Qual è la differenza tra RBAC e un''ACL?' answer: 'Dove si agganciano i permessi: un''ACL appende voci soggetto-permesso a ogni oggetto; RBAC appende i permessi a ruoli validi in tutto il sistema. I due approcci si compongono invece di escludersi – una voce di ACL può nominare un ruolo, ed è così che il controllo a livello di oggetto e la gestione dei membri in un unico posto convivono.' - question: 'Quali sono i modelli di RBAC?' answer: 'Lo standard definisce RBAC di base (utenti, ruoli, permessi, sessioni), RBAC gerarchico (i ruoli senior ereditano i permessi dei ruoli junior) e RBAC vincolato (regole di separazione dei compiti – vincoli statici sull''assegnazione, vincoli dinamici su ciò che una singola sessione può attivare insieme).' - question: 'Quali sono le tre regole di RBAC?' answer: 'Vengono dalla formulazione originale del 1992: un soggetto può agire solo attraverso un ruolo selezionato (assegnazione del ruolo); il soggetto deve essere autorizzato per quel ruolo (autorizzazione del ruolo); e un''azione è lecita solo se il ruolo attivo ne detiene il permesso (autorizzazione del permesso). In sintesi: nessun accesso che non passi dai ruoli.' - question: 'Che cos''è l''esplosione dei ruoli?' answer: 'La crescita incontrollata dei ruoli quando ogni eccezione, progetto, regione o tenant genera un ruolo nuovo – Project-A-Manager-Region-West – finché i ruoli superano in numero gli utenti e nessuno riesce più a verificare il sistema. La causa profonda è codificare attributi contestuali come ruoli invece di trattarli con condizioni o con voci per singolo oggetto.' - question: 'RBAC e privilegio minimo sono la stessa cosa?' answer: 'No – il privilegio minimo è il principio, RBAC è uno dei meccanismi per perseguirlo, e solo la disciplina sui ruoli collega le due cose. Un ruolo troppo ampio viola il privilegio minimo dall''interno di RBAC; delimitare i ruoli al minimo e rivederli periodicamente è ciò che realizza davvero il principio.' - question: 'Che cos''è la separazione dei compiti in RBAC?' answer: 'Vincoli che tengono distanti poteri in conflitto: la separazione statica impedisce a un utente di detenere insieme il ruolo di creatore e quello di approvatore dei pagamenti; la separazione dinamica consente di detenerli entrambi, ma mai attivati nella stessa sessione. È prevenzione delle frodi espressa come regola sui ruoli.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'NIST Role-Based Access Control project' url: 'https://csrc.nist.gov/projects/role-based-access-control' - name: 'Ferraiolo & Kuhn — Role-Based Access Control (1992)' url: 'https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/ferraiolo-kuhn-92.pdf' - name: 'NISTIR 7316 — Assessment of Access Control Systems' url: 'https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7316.pdf' - name: 'OWASP Authorization Cheat Sheet' url: 'https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html' cta: title: 'Ruoli che puoi interrogare' text: 'Su Back4app i ruoli sono oggetti del database: aggiungi i membri con una relazione, annida i ruoli per ottenere una gerarchia e concedi i diritti tramite i permessi di classe e le ACL degli oggetti – un RBAC applicato dalla piattaforma a ogni richiesta.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-09' translationKey: role-based-access-control-rbac --- **Il controllo degli accessi basato sui ruoli è un modello di autorizzazione in cui i permessi si agganciano ai ruoli, mai direttamente alle persone.** L'indirezione è tutta l'idea: nulla viene mai concesso direttamente a una persona, così il cambiamento organizzativo diventa cambiamento di dati – una promozione è una riassegnazione di ruolo, non uno scavo archeologico fra concessioni sparse. Proposto da [Ferraiolo e Kuhn nel 1992](https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/ferraiolo-kuhn-92.pdf) come alternativa ai più vecchi modelli discrezionale e obbligatorio, è diventato lo standard ANSI/INCITS 359 e il vocabolario di autorizzazione predefinito del software aziendale. ## Punti chiave | Domanda | Risposta | | --- | --- | | L'indirezione | Utente → ruolo → permesso – mai utente → permesso direttamente | | Ruolo ≠ gruppo | Un gruppo raccoglie *utenti*; un ruolo raccoglie *permessi* | | I livelli del modello | Di base · gerarchico (ereditarietà) · vincolato (separazione dei compiti) | | Il modo in cui fallisce | L'esplosione dei ruoli – attributi codificati come ruoli finché i ruoli superano gli utenti | | La composizione | Ruoli dentro le voci di ACL: RBAC per la massa, ACL per le eccezioni | ## Utenti, ruoli, permessi – l'indirezione all'opera ```text Permessi Ruoli Utenti ───────────── ───────────── ───────────── posts:read ─┐ posts:write ├──▶ Editor ◀────── Ada, Grace posts:publish ─┘ users:manage ─┐ billing:view ├──▶ Admin ◀────── Linus posts:* ─┘ posts:read ────▶ Viewer ◀────── tutti gli altri Ada pubblica perché Editor porta posts:publish – riassegnando il suo ruolo, ogni permesso che esso portava si sposta. Una modifica, non N. ``` I ruoli come dati vivi, collegati ai permessi degli oggetti: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Roles as data: create a role, add members, grant through it const roleACL = new Parse.ACL(); roleACL.setPublicReadAccess(true); const editors = new Parse.Role('Editors', roleACL); editors.getUsers().add(adaUser); await editors.save(); // Grant by role, not by user — membership changes in one place const post = new Parse.Object('Post'); const acl = new Parse.ACL(currentUser); // owner entry acl.setRoleWriteAccess('Editors', true); // RBAC meets the object's ACL post.setACL(acl); await post.save(); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Roles as data: create a role, add members, grant through it final roleACL = ParseACL()..setPublicReadAccess(allowed: true); final editors = ParseObject('_Role') ..set('name', 'Editors') ..setACL(roleACL) ..addRelation('users', [adaUser]); await editors.save(); // Grant by role, not by user — membership changes in one place final post = ParseObject('Post'); final acl = ParseACL(owner: currentUser) // owner entry ..setRoleWriteAccess('Editors', true); // RBAC meets the object's ACL post.setACL(acl); await post.save(); ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Roles as data: create a role, add members, grant through it var editors = try ParseRole(name: "Editors") let savedRole = try await editors.save() try await savedRole.users.add([adaUser]).save() // membership = a relation // Grant by role, not by user — membership changes in one place var post = Post() var acl = ParseACL() acl.setReadAccess(user: currentUser, value: true) acl.setWriteAccess(user: currentUser, value: true) // owner entry acl.setWriteAccess(roleName: "Editors", value: true) // RBAC meets the ACL post.ACL = acl try await post.save() ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Roles as data: create a role, add members, grant through it val roleACL = ParseACL() roleACL.publicReadAccess = true val editors = ParseRole("Editors", roleACL) editors.users.add(adaUser) editors.save() // Grant by role, not by user — membership changes in one place val post = ParseObject("Post") val acl = ParseACL(ParseUser.getCurrentUser()) // owner entry acl.setRoleWriteAccess("Editors", true) // RBAC meets the object's ACL post.acl = acl post.save() ``` ## Il modello NIST, per davvero Quasi tutte le spiegazioni comprimono lo standard in un elenco puntato; la struttura reale merita trenta secondi. **RBAC di base** definisce utenti, ruoli, permessi – e le *sessioni*, l'elemento dimenticato: un utente attiva un sottoinsieme dei propri ruoli per sessione, ed è così che un amministratore può navigare per impostazione predefinita con poteri da semplice membro ed elevarsi in modo deliberato. Le tre regole dell'articolo originale tengono insieme il tutto: agire solo attraverso un ruolo, detenere solo ruoli autorizzati, fare solo ciò che il ruolo attivo permette. **RBAC gerarchico** aggiunge l'ereditarietà – i ruoli senior inglobano quelli junior (Manager ⊇ Employee), eliminando i duplicati. **RBAC vincolato** aggiunge la separazione dei compiti: le regole *statiche* vietano in blocco le assegnazioni di ruoli in conflitto (mai creatore e approvatore dei pagamenti insieme); quelle *dinamiche* consentono l'assegnazione ma vietano di attivare entrambi i ruoli in una stessa sessione. E la precisazione più tagliente del NIST, regolarmente storpiata: un **gruppo è una raccolta di utenti; un ruolo è una raccolta di permessi** – il ruolo si definisce per ciò che può fare, non per chi ne fa parte. ```mermaid flowchart LR accTitle: Struttura di RBAC con sessioni e separazione dei compiti accDescr: Agli utenti vengono assegnati dei ruoli e ne attivano un sottoinsieme per sessione. I ruoli portano permessi e possono ereditare da ruoli junior. I vincoli di separazione dei compiti limitano quali ruoli possono essere assegnati o attivati insieme, e i permessi si applicano alle risorse. U["Utente
Ada"] -->|"assegnati"| R["Ruoli
Editor · Auditor"] U -->|"attiva un sottoinsieme
per sessione"| S["Sessione
solo Editor"] R -->|"eredita"| RJ["Ruolo junior
Viewer"] R ---|"vincolo SoD:
non con Approver"| X["Ruolo in conflitto"] S -->|"permessi dei
ruoli attivi"| P["posts:write
posts:publish"] --> D[("Risorse")] ``` ## RBAC vs. ACL vs. ABAC | | RBAC | [ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/) | ABAC | | --- | --- | --- | --- | | I permessi si agganciano a | Ruoli | Ogni oggetto | Regole su attributi | | Domanda nativa | Che cosa può fare questa *funzione*? | Chi può toccare *questo oggetto*? | È lecito *in questo contesto*? | | Amministrazione | Un unico posto per ruolo | Per oggetto | Per politica | | Condivisione per oggetto | Non sa esprimerla | Il suo terreno naturale | Esprimibile, ma verbosa | | Verificare "che cosa può fare Ada?" | Leggere i suoi ruoli | Scorrere ogni oggetto | Valutare ogni regola | | Il modo in cui fallisce | Esplosione dei ruoli | Proliferazione delle liste | Politiche opache | Quello che le pagine dei fornitori seppelliscono: questi modelli **si compongono, non si escludono**. I ruoli gestiscono l'accesso che segue la funzione lavorativa; le voci di ACL gestiscono le eccezioni su singoli oggetti – e la cerniera è l'*ACE di ruolo*, una riga di ACL che nomina un ruolo invece di un utente, offrendo controllo a livello di oggetto con gestione dei membri in un unico posto. Le condizioni su attributi si sovrappongono dove il contesto (orario, tenant, stato del record) decide davvero. "Quale scegliere?" è quasi sempre la domanda sbagliata; "quale strato prende quale decisione?" è la progettazione. ## L'esplosione dei ruoli – il modo in cui RBAC fallisce La malattia caratteristica di RBAC: ogni eccezione conia un ruolo, poi ogni progetto, regione e tenant li moltiplica – `Project-A-Manager-Region-West-ReadOnly` – finché i ruoli superano in numero gli utenti e la risposta dell'audit a "chi può fare che cosa?" è "nessuno lo sa". La causa profonda è sempre la stessa: **attributi contestuali codificati come ruoli**. Le mitigazioni, nell'ordine: tenere gli attributi fuori dai nomi dei ruoli (regione e tenant sono condizioni o ambiti, non ruoli); gestire la condivisione per oggetto con le [voci di ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/), mai con ruoli per singolo oggetto; confinare i ruoli per [tenant](/glossary/it/isolamento-dei-tenant/) in modo strutturale anziché storpiando i nomi; e verificare – i ruoli che nessuno detiene, i permessi che nessun ruolo usa e le concessioni di cui nessuno si ricorda sono deriva, ed è per deriva che il privilegio minimo muore in silenzio. Un'euristica che funziona: se l'elenco dei ruoli smette di stare in uno schermo, il modello sta assorbendo lavoro che appartiene a un altro strato. ## Progettare i ruoli: top-down, bottom-up o entrambi La parte che nessuna spiegazione ben posizionata copre: da dove vengono i ruoli. L'approccio **top-down** li deriva dall'organizzazione e dai suoi processi – intervistare il business, nominare le funzioni, assegnare permessi minimi; accurato ma lento. L'approccio **bottom-up** li estrae dalle concessioni esistenti – raggruppare chi già detiene che cosa, e i ruoli candidati emergono da soli; rapido, ma riciclano in politica ufficiale gli errori del passato. La pratica è ibrida: estrarre i candidati, validarli rispetto alle funzioni, poi applicare il test 80/20 – una manciata di ruoli ampi per il grosso dell'organizzazione, con le eccezioni gestite da ACL o condizioni anziché da ruoli su misura. E una regola di implementazione che sopravvive a ogni riorganizzazione: **il codice deve controllare i permessi, non i nomi dei ruoli** – `can('posts:publish')`, non `hasRole('Editor')` – così che ridefinire un ruolo sia un cambiamento di dati e non un refactoring, con applicazione delle regole [lato server](/glossary/it/sicurezza-dati-vs-applicazione/) e rifiuto per impostazione predefinita. ## Casi d'uso tipici - **Pannelli di amministrazione e back-office** – supporto, moderatore, finanza, superamministratore: le funzioni si traducono pulitamente in ruoli. - **Flussi di contenuti e pubblicazione** – autore, editor, pubblicatore, con una separazione fra scrivere e rilasciare. - **Permessi di squadra nel SaaS B2B** – owner/admin/membro/fatturazione per spazio di lavoro, confinati per tenant. - **Operazioni soggette a conformità** – la separazione dei compiti come vincolo sui ruoli applicabile, con l'appartenenza ai ruoli come prova di audit. - **La barriera dei ruoli sugli strati dei dati** – i ruoli come il "chi" dei [permessi di classe](/glossary/it/permessi-di-classe-clp/) e delle [politiche a livello di riga](/glossary/it/sicurezza-a-livello-di-riga-rls/). ## Conviene usare RBAC? Matrice decisionale | Situazione | Orientarsi su | | --- | --- | | L'accesso segue la funzione lavorativa | RBAC – il suo terreno naturale | | Gli utenti condividono singoli record caso per caso | Le ACL – i ruoli non sanno esprimerlo | | Decide il contesto (orario, stato, tenant) | Condizioni su attributi sopra i ruoli | | Una manciata di tipi di utente, stabili | RBAC con 3–7 ruoli ampi | | Organigrammi profondi, squadre annidate | Gerarchia dei ruoli – o ReBAC a scala davvero grande | | "Solo gli admin e tutti gli altri" | Una sola barriera di ruolo – non sovramodellare | ## Limiti e trade-off - **La condivisione per oggetto resta fuori perimetro.** "Condividere questo documento con Ana" non ha risposta in RBAC, se non creando un ruolo per documento – quella decisione appartiene alle ACL. - **Stesso ruolo, stessi poteri.** Due Editor sono indistinguibili; la sfumatura individuale richiede un altro strato, non un ruolo quasi duplicato. - **L'ingegneria dei ruoli è vero lavoro iniziale.** Salterla produce ruoli che non rispecchiano né l'organizzazione né il modello di rischio – e che vengono copiati per sempre. - **I ruoli statici non vedono il rischio dinamico.** L'appartenenza a un ruolo non percepisce orari insoliti, dispositivi nuovi o stati sensibili di un record; quello è territorio degli attributi. - **La deriva è lo stato stazionario.** Senza ricertificazione periodica l'ampiezza dei ruoli può solo crescere; la verificabilità di RBAC è una possibilità, non una garanzia. ## I ruoli su Back4app Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Qui i ruoli sono **dati, non codice**: ciascuno è un oggetto della classe `_Role` con una relazione `users` per i membri e una relazione `roles` per l'annidamento – e l'annidamento è gerarchia gratis, perché i membri di un ruolo figlio ereditano tutto ciò che è concesso ai suoi ruoli padre. Le concessioni avvengono esattamente dove indica la sezione sulla composizione: i nomi dei ruoli compaiono nei [permessi di classe](/glossary/it/permessi-di-classe-clp/) per le linee generali e nelle [voci di ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/) per oggetto per le eccezioni – le schede di codice mostrano entrambe le metà – e Back4app applica il risultato a ogni richiesta REST, GraphQL e Live Query. Poiché i ruoli sono oggetti interrogabili, la gestione dei membri, gli audit e le interfacce di amministrazione diventano normale lavoro sul database: prevenire l'esplosione dei ruoli come abitudine di modellazione, non come progetto di governance.