Il controllo degli accessi basato sui ruoli (RBAC, role-based access control) è un modo per decidere chi può fare cosa in un sistema: i permessi vengono associati ai ruoli, e le persone vengono poi assegnate a quei ruoli. Nessuno riceve permessi uno per uno. Un venditore, un controller finanziario e un responsabile del supporto ottengono ciascuno l'accesso che il proprio lavoro richiede, e nulla di più. Questa guida spiega come funziona l'RBAC, come progettare ruoli che restino gestibili, quando il controllo degli accessi basato sugli attributi (ABAC) è la scelta più adatta e che cosa cambia quando gli agenti AI iniziano a leggere e scrivere i dati della vostra azienda.

In sintesi

Indice

Che cos'è il controllo degli accessi basato sui ruoli

L'RBAC è un modello per autorizzare l'accesso a sistemi, applicazioni e dati in base al ruolo predefinito dell'utente. IBM lo descrive come un amministratore che assegna a ciascun utente uno o più ruoli, dove ogni ruolo rappresenta un insieme di permessi o privilegi.

La caratteristica distintiva è che ogni accesso passa attraverso i ruoli. Secondo le FAQ del NIST Computer Security Resource Center, un ruolo è essenzialmente una raccolta di permessi, e gli utenti ricevono permessi solo attraverso i ruoli che vengono loro assegnati o che ereditano tramite una gerarchia di ruoli. È ciò che distingue l'RBAC dai normali gruppi, in cui i permessi possono essere associati sia agli utenti sia ai gruppi. Il NIST osserva che questo crea una falla che rende difficile controllare le relazioni tra utenti e permessi.

Un esempio concreto per un'azienda SaaS:

Ruolo Accesso tipico nel CRM Accesso tipico nel sistema finanziario Accesso tipico nell'admin di prodotto
Account Executive Account e trattative propri, lettura e scrittura Nessuno Nessuno
Sales Manager Account del team, viste di forecast Stato delle fatture in sola lettura Nessuno
Finance Controller Dati degli account in sola lettura Fatturazione e reportistica complete Nessuno
Customer Success Manager Account assegnati, campi di rinnovo Stato delle fatture in sola lettura Impostazioni tenant limitate
Support Engineer Contatti degli account in sola lettura Nessuno Diagnostica del tenant
Amministratore Configurazione Configurazione Completo

Quando entra un nuovo account executive, si assegna un unico ruolo. Non occorre ricreare una dozzina di singole scelte di autorizzazione.

Come funziona l'RBAC: le tre regole e i quattro componenti

Il modello NIST si basa su tre regole, come illustrato nella pubblicazione NIST Role Engineering: Methods and Standards:

  1. Assegnazione del ruolo. Un utente può usare un'autorizzazione solo se gli è stato assegnato un ruolo.
  2. Autorizzazione del ruolo. Il ruolo attivo dell'utente deve essere autorizzato per quell'utente.
  3. Autorizzazione dei permessi. Un utente può usare un'autorizzazione solo se questa è autorizzata per il ruolo attivo dell'utente.

La stessa pubblicazione riporta che il NIST propose un modello RBAC unificato nel 2000 e che nel 2004 fu approvato come standard nazionale statunitense INCITS 359-2004.

Secondo il documento ANSI INCITS 359-2004, questo standard comprende quattro componenti:

La separazione dei compiti conta soprattutto in ambito finanziario. Chi crea un pagamento a un fornitore non dovrebbe essere la persona che lo approva. La separazione statica dei compiti lo impone al momento dell'assegnazione, che è il modo più semplice e più verificabile per farlo.

Come progettare ruoli che restino gestibili

È nella progettazione che la maggior parte dei progetti RBAC riesce o fallisce. Un insieme di ruoli che rispecchia il funzionamento dell'azienda è facile da spiegare e da rivedere. Un insieme di ruoli che rispecchia le caselle da spuntare di ogni strumento diventa un labirinto.

Partire dalle funzioni aziendali

Secondo le linee guida di implementazione di IBM, i progetti più solidi partono dalle funzioni e dai flussi di lavoro aziendali, non dai menu delle applicazioni. Invece di chiedersi quali caselle spuntare nel CRM, ci si chiede che cosa fa davvero un venditore, poi si esprimono queste attività come definizioni di ruolo che possono essere mappate su più sistemi.

Quest'ultimo punto è pratico. Un ruolo "Customer Success Manager" dovrebbe significare la stessa cosa nel CRM, nello strumento di fatturazione, nel supporto clienti e in qualsiasi portale interno. Lo si definisce una sola volta come ruolo aziendale, poi lo si mappa su ciascun sistema.

Un ruolo aziendale mappato su quattro sistemi

Scegliere un approccio di role engineering

La pubblicazione NIST sul role engineering descrive tre approcci:

Anche la documentazione di Oracle sull'identity management raccomanda l'approccio ibrido per il role mining. Per un'azienda da 20 a 200 persone, l'approccio ibrido è di solito realistico. Dedicate qualche ora al responsabile di ciascuna funzione per abbozzare i ruoli, poi esportate le autorizzazioni attuali dal CRM e dal sistema finanziario e verificate dove la realtà differisce. Combinare i due metodi evita ruoli troppo teorici ed evita di costruire ruoli attorno a pochi casi anomali.

Una sequenza pratica

  1. Inventariare sistemi e dati. Elencate i sistemi che contengono dati su clienti, ricavi e prodotto e segnate quali record sono sensibili.
  2. Abbozzare i ruoli per funzione. Partite da categorie ampie. IBM osserva che le organizzazioni spesso iniziano separando gli amministratori, gli specialisti o utenti esperti e gli utenti finali.
  3. Esportare le autorizzazioni effettive. Estraete da ciascun sistema gli accessi attuali per persona e raggruppate i modelli simili.
  4. Riconciliare. Quando qualcuno ha molti più accessi del ruolo abbozzato, decidete se è sbagliato il ruolo o se la persona ha accumulato accessi che dovrebbe perdere.
  5. Nominare un responsabile per ogni ruolo. Una persona è responsabile di ciò che il ruolo contiene.
  6. Applicare, poi rivedere. Spostate le persone sui ruoli, rimuovete le autorizzazioni dirette e pianificate la prima revisione.

Best practice RBAC per il lungo periodo

Secondo le indicazioni di IBM, la salute a lungo termine dell'RBAC dipende dalla governance: revisioni periodiche degli accessi concentrate su eccezioni e anomalie, processi joiner-mover-leaver che cambiano i ruoli automaticamente in base agli eventi HR ed eccezioni approvate e a tempo limitato per gli accessi insoliti.

Applicare il privilegio minimo attraverso la progettazione

Una guida alle best practice RBAC aziendali di Avatier elenca quattro meccanismi che producono il privilegio minimo:

Il secondo è il più trascurato. Chi cambia team accumula accessi. Dopo due o tre spostamenti, un customer success manager può avere diritti sulla pipeline di vendita e sulla fatturazione che nessuno aveva previsto.

Prevenire l’esplosione dei ruoli

La stessa fonte indica l’esplosione dei ruoli come la modalità di fallimento dominante: un nuovo ruolo su misura per ogni caso limite. Prevenire costa meno che ripulire. Assegnate a ogni ruolo un responsabile, preferite la combinazione di ruoli esistenti alla creazione di nuovi e ricertificate secondo un calendario. Un test utile: se un ruolo proposto avrebbe un solo titolare, probabilmente è un’eccezione, non un ruolo. Gestitelo come un’eccezione approvata e a tempo limitato.

Mantenere ridotta la manutenzione

Okta sottolinea che l’RBAC non richiede una manutenzione intensiva: i permessi seguono i ruoli, quindi una nuova funzione lavorativa diventa un nuovo ruolo applicato a molte persone con poco lavoro per gli amministratori. Questo vale solo se l’insieme dei ruoli resta piccolo e ordinato, ed è per questo che responsabilità e revisione contano.

Una breve checklist

RBAC vs ABAC: quale vi serve?

L’ABAC decide l’accesso valutando rispetto a una policy gli attributi dell’utente, della risorsa, dell’azione e talvolta dell’ambiente. NIST SP 800-162 lo definisce in questo modo e osserva che le ACL e l’RBAC sono per certi versi casi particolari di ABAC, in termini di attributi utilizzati.

In parole semplici: l’RBAC chiede “qual è il tuo lavoro?” L’ABAC chiede “qual è il tuo lavoro, che cosa stai toccando, quanto è in gioco e da dove?”

Il confronto di Okta afferma che l’RBAC è adatto a gruppi di lavoro piccoli e semplici nella struttura e ad ambienti con funzioni lavorative ben definite. L’ABAC si adatta a gruppi di lavoro geograficamente distribuiti o definiti nel tempo, e ai casi in cui le esigenze di accesso cambiano per documento anziché per ruolo.

Domanda RBAC ABAC
Base della decisione Ruolo Attributi di utente, risorsa, azione, contesto
Il più semplice da spiegare a un revisore Sì Richiede più impegno
Gestisce “solo trattative sotto un importo stabilito” Macchinoso, tende ad aggiungere ruoli Naturale
Gestisce “solo account della propria regione” Richiede un ruolo per regione Naturale
Impegno di configurazione Minore Maggiore

La maggior parte delle aziende SaaS in crescita non sceglie l’uno o l’altro. Il team identity di Okta osserva che molte organizzazioni usano un modello ibrido: RBAC per i livelli di accesso generali e ABAC per i controlli di dettaglio. Avatier fa la stessa osservazione dall’altro lato: l’RBAC è la base, e le decisioni sensibili al contesto, come orario, luogo, importo o dispositivo, spettano all’ABAC applicato sopra. La regola pratica è partire dall’RBAC e aggiungere regole basate sugli attributi solo dove il numero di ruoli altrimenti si moltiplicherebbe, come nei limiti regionali o per dimensione della trattativa.

Strumenti interni e RBAC

Gli strumenti interni sono il punto in cui il controllo degli accessi fallisce in silenzio. Un’esportazione in foglio di calcolo dal CRM, un pannello di amministrazione creato da un solo ingegnere, una dashboard finanziaria condivisa tramite link: ognuno è un luogo in cui i ruoli vengono aggirati. Tre abitudini aiutano:

Se sviluppate o acquistate portali interni, chiedete come vengono definiti i ruoli, chi può modificarli e se le modifiche vengono registrate. Sono le domande che farà un revisore della sicurezza o un questionario dei clienti.

L'RBAC quando entrano in scena gli agenti AI

L’AI cambia la questione dell’accesso in un modo specifico: un assistente o un agente può raggiungere molti sistemi con una sola richiesta. Se è collegato con un account di servizio con permessi ampi, può restituire dati che la persona richiedente non avrebbe mai potuto vedere.

La soluzione non è un nuovo modello di sicurezza. È applicare quello che avete già:

C'è anche un ambito in cui l'AI non deve intervenire: decidere chi ottiene l'accesso. Concedere, modificare e approvare i ruoli deve restare compito di persone identificate, che seguono la vostra policy. Un agente può preparare un elenco di revisione o segnalare le anomalie, ma la decisione spetta a una persona.

Anche la normativa va nella stessa direzione. GDPR, NIS2 e EU AI Act riguardano tutti il modo in cui dati e sistemi vengono controllati, e un controllo degli accessi ben progettato è uno degli elementi di base più comuni quando le aziende lavorano su questi temi. L'RBAC da solo non rende conforme un'azienda e questo articolo non costituisce consulenza legale. Chieda al Suo consulente legale che cosa si applica al Suo caso.

Per saperne di più su come governance e AI si integrano, consulti il nostro AI governance framework per aziende SaaS B2B.

Prospettiva

Vediamo lo stesso schema nelle aziende SaaS da 20 a 200 persone. I ruoli non sono mai stati progettati. Gli accessi sono cresciuti con ogni nuovo strumento, poi è arrivata l'AI e ha iniziato a leggere tutto.

Per questo costruiamo in un ordine preciso. Prima le fondamenta dei dati: i dati del vostro CRM e della finanza come fonte di verità condivisa, con ruoli che significano la stessa cosa in ogni sistema. Poi il livello AI, che collega quei dati all'assistente che il vostro team già usa. Quindi gli agenti di reparto per Finance, Sales e Customer Success. Ogni livello eredita le regole di accesso di quello sottostante.

Riteniamo che un agente non debba mai godere di più fiducia della persona che lo usa. Opera entro i permessi di quella persona, chiede approvazione quando un'azione è rilevante e lascia una traccia di audit. La progettazione dei ruoli non è un'attività secondaria di un progetto AI. Ne è il primo tassello.

Claus Nielsen

Dove si inserisce NordOps Consulting

Se il vostro team usa già l'AI ma nessuno è responsabile di come essa interagisce con i vostri dati, la progettazione degli accessi è un buon punto di partenza. NordOps Consulting opera come Fractional Chief AI Officer per aziende SaaS B2B in Europa: una persona identificata che decide dove l'AI rende, imposta le fondamenta dei dati e costruisce agenti che il vostro team usa in linguaggio naturale, entro i permessi e con una traccia di audit.

L'AI Readiness Assessment è un punto di partenza definito, a partire da €4,500. Per una responsabilità continuativa, il retainer Fractional CAIO parte da €1,500 al mese. Potete anche iniziare con una discovery call gratuita di 30 minuti tramite il nostro sito. Per vedere come si articola il lavoro, leggete come funziona, oppure date un'occhiata all'Admin Portal, dove ruoli e accessi degli utenti sono gestiti insieme agli agenti.

FAQ

Qual è la differenza tra un ruolo e un permesso?

Un permesso è una singola azione consentita su una risorsa, come leggere una fattura o modificare una trattativa. Un ruolo è un insieme di permessi con un nome, che corrisponde a una funzione lavorativa. Gli utenti vengono assegnati ai ruoli e i ruoli portano con sé i permessi.

L'RBAC è sufficiente o serve l'ABAC?

Per la maggior parte dei team l'RBAC è il giusto punto di partenza, perché è semplice da spiegare e da verificare. Aggiungete regole ABAC solo quando il contesto conta, ad esempio per limitare l'accesso per regione, dimensione della trattativa od orario. Molte organizzazioni usano entrambi: RBAC per i livelli generali e ABAC per i dettagli.

Quanti ruoli dovrebbe avere un'azienda?

Non esiste un numero standard. Mantenete i ruoli legati a funzioni lavorative reali, assegnate a ciascuno un responsabile e trattate le esigenze una tantum come eccezioni a tempo. Se un ruolo avesse un solo titolare, è il segno che si tratta di un'eccezione e non di un ruolo.

Con quale frequenza vanno rivisti ruoli e accessi?

Stabilite una scadenza regolare e, oltre a questa, eseguite una revisione ogni volta che qualcuno cambia mansione o lascia l'azienda. Le linee guida di IBM raccomandano revisioni periodiche degli accessi incentrate su eccezioni e anomalie, e modifiche automatiche attivate da eventi HR. Scegliete un ritmo che il vostro team riesca a mantenere, perché una revisione saltata è peggio di una più leggera.

Come vanno trattati gli agenti AI in un modello RBAC?

Trattateli come soggetti che agiscono per conto di una persona, con il ruolo di quella persona e nulla di più. Separate i permessi di lettura e di scrittura, richiedete l'approvazione per le azioni sensibili e conservate un registro di ogni azione. Le decisioni su chi ottiene l'accesso devono restare alle persone.

Fonti