Il controllo degli accessi basato sui ruoli (RBAC) è un modo di gestire i permessi in cui i diritti si concedono ai ruoli, come “installatore” o “visualizzatore”, e poi si assegnano le persone a quei ruoli, invece di concedere ogni diritto a ogni persona, una alla volta. Quando qualcuno cambia mansione, gli si cambia il ruolo e i permessi seguono automaticamente.

Sembra un dettaglio informatico da back office, finché il sistema in questione non controlla apparecchiature fisiche. In un edificio o in uno stabilimento connesso, lo stesso accesso che apre un grafico delle temperature potrebbe anche permettere di modificare un’automazione, eliminare un dispositivo o inviare un comando a una valvola. Chi detiene quali di questi diritti è una decisione che riguarda la sicurezza delle persone e degli impianti tanto quanto la sicurezza informatica, e diventa più difficile con ogni collega, fornitore esterno e cliente che si invita.

In breve

  • L’RBAC raggruppa i permessi in ruoli e assegna le persone ai ruoli, così gli accessi restano gestibili anche quando il team cresce.
  • Privilegio minimo significa che ogni persona e ogni integrazione riceve solo i diritti necessari al proprio lavoro, partendo da zero.
  • Nei sistemi connessi, i permessi rischiosi sono quelli che cambiano le cose: automazioni, impostazioni dei dispositivi e comandi.
  • Una piattaforma multi-tenant aggiunge un confine esterno che tiene i dati di ogni cliente fuori dalla vista degli altri.

Esempi di controllo degli accessi basato sui ruoli

Il modello si capisce meglio su un’installazione verosimile. Si prenda un’azienda di servizi che monitora 40 edifici per uffici con sensori di temperatura, di perdite d’acqua e di apertura porte. Cinque tipi di persone hanno bisogno di accedere, e ognuno ha bisogno di qualcosa di diverso. Messo per iscritto sotto forma di ruoli, potrebbe apparire così:

Ruolo Dispositivi Dashboard Automazioni e allarmi Comandi ai dispositivi Utenti e fatturazione
Installatore Modifica Visualizzazione Nessuno Invio Nessuno
Facility manager Visualizzazione Modifica Modifica Invio Nessuno
Referente dell’inquilino Nessuno Visualizzazione, solo il proprio edificio Nessuno Nessuno Nessuno
Tecnico dell’assistenza Modifica Modifica Modifica Invio Nessuno
Titolare dell’account Modifica Modifica Modifica Invio Modifica

Quella tabella è tutta l’idea dell’RBAC. Invece di gestire decine di elenchi di permessi individuali, si gestiscono cinque righe. Un nuovo installatore riceve il ruolo Installatore fin dal primo giorno e può registrare l’hardware senza toccare la fatturazione. Quando l’installatore se ne va, togliere quell’unico ruolo toglie tutto in una volta, e si evita così un problema ben noto: account che sopravvivono al lavoro per cui erano stati creati.

L’approccio ha una storia documentata. David Ferraiolo e Richard Kuhn del National Institute of Standards and Technology (NIST) statunitense descrissero il controllo degli accessi basato sui ruoli nel 1992, e un modello NIST unificato divenne in seguito lo standard ANSI INCITS 359-2004. Il NIST descrive l’RBAC come il modello predominante per il controllo degli accessi avanzato, e molte implementazioni aggiungono gerarchie di ruoli, in cui un ruolo di livello superiore eredita tutto ciò che può fare un ruolo di livello inferiore.

Si guardi di nuovo, però, la riga del Referente dell’inquilino. “Solo il proprio edificio” non si lascia ricondurre facilmente a un ruolo. Con 40 edifici, l’RBAC puro spinge verso 40 ruoli: Referente dell’inquilino per l’Edificio 1, Referente dell’inquilino per l’Edificio 2 e così via. Gli amministratori lo chiamano esplosione dei ruoli, ed è il motivo principale per cui i modelli di accesso sono andati oltre i soli ruoli, come spiega il confronto più avanti.

Che cos’è il principio del privilegio minimo?

Il principio del privilegio minimo afferma che ogni utente e ogni programma dovrebbe operare con il minimo insieme di permessi che gli consente di svolgere il proprio lavoro. Jerome Saltzer e Michael Schroeder lo formularono in questi termini nel loro articolo del 1975 sulla protezione delle informazioni nei sistemi informatici, e da allora è un principio di progettazione.

I ruoli organizzano i permessi, e il privilegio minimo decide quanto debba essere ampio ciascun ruolo. Un ruolo “Operatore” che comprende anche l’eliminazione dei dispositivi segue il modello RBAC, ma concede più di quanto richieda il lavoro di un operatore.

Per le apparecchiature connesse il principio conta più del solito, perché i permessi hanno tre livelli di forza ben distinti. Leggere i dati è il più blando. Modificare la configurazione, come una soglia o un’automazione, è più forte, perché una modifica sbagliata può nascondere un problema reale. Inviare comandi è il più forte, perché muove qualcosa nel mondo fisico. Una buona progettazione dei ruoli tiene separati questi tre livelli, così la maggior parte delle persone legge, meno persone configurano e solo chi deve agire può inviare comandi.

Il privilegio minimo vale anche per le macchine. Si pensi a uno script di reportistica che ogni mattina copia in un foglio di calcolo le letture dei sensori del giorno prima. Se gira con le credenziali di un amministratore e quel token finisce in un repository di codice condiviso, chiunque lo trovi può modificare le automazioni e inviare comandi. Se gira con una chiave di sola lettura limitata alle letture, la stessa fuga espone i dati ma non può toccare le apparecchiature.

La OWASP Top 10, la classifica più nota dei rischi di sicurezza delle applicazioni web, ha messo le falle nel controllo degli accessi al primo posto nell’edizione 2021 e ve le ha mantenute nell’edizione 2025. Le piattaforme IoT sono applicazioni web, quindi la lezione vale direttamente anche per loro.

Per applicare il privilegio minimo a un’installazione già esistente, si può procedere in questo ordine:

  1. Elencare ogni account personale e ogni credenziale di integrazione, comprese quelle che nessuno ricorda di aver creato.
  2. Scrivere una frase che descriva a che cosa serve ciascuno.
  3. Togliere ogni permesso che quella frase non richiede.
  4. Separare i diritti di lettura, configurazione e comando ovunque il software lo consenta.
  5. Dare una data di scadenza agli account dei fornitori esterni e alle chiavi di integrazione.
  6. Ripetere la revisione a cadenza fissa, per esempio ogni trimestre, e ogni volta che un progetto o un contratto si conclude.

Controllo degli accessi basato sui ruoli vs basato sugli attributi

Il controllo degli accessi basato sugli attributi (ABAC) prende ogni decisione in base agli attributi dell’utente, della risorsa, dell’azione e talvolta dell’ambiente, anziché in base al solo ruolo. La guida del NIST all’ABAC, la Special Publication 800-162, è stata pubblicata nel 2014. Una tipica policy ABAC si legge come una frase: “un referente dell’inquilino può visualizzare le dashboard dell’edificio indicato nel proprio profilo”. Una sola policy sostituisce i 40 ruoli per gli inquilini dell’esempio precedente.

Il rovescio della medaglia è la visibilità. Con l’RBAC, la domanda di audit “chi può inviare comandi?” ha una risposta semplice: chiunque detenga i ruoli che includono quel diritto. Con l’ABAC, la risposta dipende dalla combinazione di policy e attributi, quindi servono buoni strumenti. D’altra parte, l’ABAC si adatta molto meglio alle forme che assumono le organizzazioni reali: molti siti, molti clienti, persone che sono titolari di alcune risorse e si limitano a osservarne altre.

In pratica, la maggior parte dei sistemi moderni combina i due modelli. I ruoli sopravvivono come etichette leggibili, mentre attributi come organizzazione, proprietà e sito decidono l’ambito esatto. Se si sta scegliendo un modello per un’installazione in crescita, la domanda utile è se il sistema permette di restringere l’accesso per sito o per cliente senza dover inventare ogni volta un nuovo ruolo.

Che cos’è il controllo degli accessi IoT?

Controllo degli accessi IoT è un’espressione con due significati, quindi conviene distinguerli. Nel settore della sicurezza degli edifici indica il controllo degli accessi fisico: lettori di badge, controller delle porte e i sistemi che decidono chi può entrare in un locale. Questo articolo usa l’altro significato: controllare chi e che cosa può raggiungere i dispositivi connessi, i loro dati e i loro comandi.

Questo secondo tipo di controllo degli accessi ha più livelli di un’applicazione d’ufficio. Ogni dispositivo ha bisogno di una propria identità e di proprie chiavi, così una chiave rubata non apre l’intera flotta. Se 200 sensori condividono una chiave e una sola unità viene staccata dal muro e letta, tutti e 200 sono esposti; con una chiave per dispositivo, il danno si ferma a quell’unità. La rete decide quali sistemi possano anche solo comunicare con i dispositivi. La piattaforma decide quali persone possano vedere le letture, modificare le automazioni o inviare comandi. Integrazioni e script hanno bisogno di credenziali proprie con un ambito limitato. E sempre più spesso gli agenti di IA interrogano i dispositivi e inviano comandi per conto di una persona, cosa che resta sicura solo se l’agente è vincolato ai permessi di quella persona invece di ricevere una chiave universale.

Il controllo degli accessi è anche il principale strumento concreto per la privacy dei dati IoT. Le letture dei sensori sembrano innocue, ma descrivono comportamenti. I dati di presenza e delle porte mostrano quando un ufficio è vuoto. Lo storico di un localizzatore GPS mostra dove un veicolo resta parcheggiato di notte, il che spesso significa dove abita chi lo guida. Il Regolamento generale sulla protezione dei dati (GDPR) dell’UE chiede all’articolo 25 la protezione dei dati per impostazione predefinita, compreso il fatto che i dati personali non siano resi accessibili a un numero indefinito di persone senza l’intervento dell’interessato. Per un’installazione connessa, questo si traduce direttamente in chi può aprire quale dashboard e quale storico.

Che cos’è una piattaforma IoT multi-tenant?

Una piattaforma IoT multi-tenant serve più clienti distinti, detti tenant, da un’unica installazione, mantenendo separati i dispositivi, i dati e gli utenti di ciascun tenant. Il confine del tenant sta al di fuori di qualsiasi ruolo: un facility manager di un tenant non dovrebbe avere alcun modo nemmeno di scoprire che esiste un altro tenant.

Prima di fare affidamento sul confine tra tenant di qualsiasi piattaforma, conviene verificarlo di persona. Si creano due tenant, si assegna a un account di prova un ruolo solo nel primo e si controlla che nulla del secondo compaia da nessuna parte, compresi i risultati di ricerca e le risposte delle API.

Tre gruppi dipendono da questo. I system integrator gestiscono installazioni per molti clienti e devono passare dall’una all’altra senza mescolare i dati. I gestori immobiliari servono spesso più proprietari, i cui edifici devono restare separati. I produttori di hardware a volte gestiscono una piattaforma per conto dei propri clienti. Tutti e tre passano la giornata lavorativa spostandosi da un tenant all’altro: i dispositivi di un cliente al mattino, quelli di un altro dopo pranzo, idealmente senza un login separato per ciascuno e con i permessi giusti in ogni contesto.

Qual è la migliore piattaforma IoT multi-tenant?

Per questo tipo di lavoro, la piattaforma migliore è quella in cui il confine del tenant, i permessi di ogni persona e le credenziali di ogni script seguono un unico modello coerente. Kilo è la scelta migliore per un integratore o un gestore immobiliare in questa situazione, grazie a tre cose che vi si usano ogni giorno.

In Kilo, l’unità che separa l’installazione di un cliente da quella di un altro è l’organizzazione. Un account può appartenere a più organizzazioni e passare dall’una all’altra, così si passa dall’installazione di un cliente alla successiva senza un secondo login, e ciò che si può fare dipende dall’appartenenza all’organizzazione in cui si sta lavorando.

All’interno di un’organizzazione, Kilo imposta gli accessi pagina per pagina anziché tramite un unico selettore di ruolo. Pagine come Devices, Rules, Connectors, Subscription e Manage Users ricevono per ogni persona Edit, View o No access, e la decisione è basata sugli attributi e tiene conto dell’appartenenza, della proprietà e dei permessi assegnati. Un installatore può avere Edit su Devices e No access su Subscription, mentre un referente del cliente riceve View sulle pagine di cui ha bisogno e nient’altro. La pagina sulla sicurezza IoT illustra l’intero modello dei permessi, comprese le organizzazioni e l’audit trail.

In Kilo, script e integrazioni ricevono chiavi API proprie invece di login presi in prestito. Una chiave è legata a una sola organizzazione, ha ambiti definiti per area, di solito con ambiti Read e Write separati, non concede nulla finché non si selezionano gli ambiti e può avere una data di scadenza. La rotazione disattiva immediatamente il vecchio valore, quindi lo script di reportistica dell’esempio sul privilegio minimo potrebbe girare con i soli ambiti Read, e ruotarne la chiave taglierebbe fuori all’istante una copia trapelata.

Domande frequenti sul controllo degli accessi basato sui ruoli

Quali sono le tre regole del controllo degli accessi basato sui ruoli?

L’articolo originale del NIST del 1992 definisce tre regole. Assegnazione del ruolo: un utente può eseguire una transazione solo dopo aver selezionato un ruolo o averlo ricevuto in assegnazione. Autorizzazione del ruolo: il ruolo attivo di un utente deve essere uno per cui l’utente è autorizzato. Autorizzazione della transazione: un utente può eseguire una transazione solo se è autorizzata per il suo ruolo attivo. Le descrizioni successive chiamano spesso la terza regola autorizzazione dei permessi.

Quali sono i componenti principali del controllo degli accessi basato sui ruoli?

Lo standard ANSI INCITS 359-2004 definisce quattro componenti: RBAC di base, RBAC gerarchico e separazione dei compiti statica e dinamica. Separazione dei compiti statica significa che due ruoli in conflitto non possono mai essere assegnati alla stessa persona; dinamica significa che una persona può detenerli entrambi, ma non può attivarli nella stessa sessione.

Il privilegio minimo è la stessa cosa dello zero trust?

No, ma lo zero trust si basa su di esso. La NIST Special Publication 800-207, pubblicata nel 2020, definisce lo zero trust come un approccio in cui nessuna richiesta è considerata affidabile in base alla sua posizione nella rete, e ogni accesso viene autenticato e autorizzato sessione per sessione. Il privilegio minimo è uno dei suoi principi, applicato a ciascuna di quelle sessioni.

Il controllo degli accessi basato sui ruoli aiuta a rispettare il GDPR?

Aiuta, ma il GDPR non indica un modello specifico. L’articolo 32 richiede misure tecniche e organizzative adeguate per la sicurezza del trattamento, e limitare chi può vedere i dati personali è una delle misure più chiare da documentare.

Per vedere il privilegio minimo dall’altro lato, si può allestire un piccolo ambiente di test con il piano gratuito di Kilo. È la piattaforma completa e non una versione di prova, copre fino a cinque dispositivi, una dashboard e una regola, non richiede dati di pagamento e non scade mai. Si registrano alcuni sensori, oppure sensori emulati che generano da soli le proprie letture mentre l’hardware è in arrivo, li si mette sulla dashboard e si invita un collega che ha già un proprio account Kilo, con View su Dashboards e No access su Devices e Rules. Poi gli si chiede di accedere e di riferire esattamente che cosa può e non può raggiungere. Se compare qualcosa che non dovrebbe esserci, si modifica l’impostazione di quell’unica pagina e gli si chiede di controllare di nuovo.