In un’applicazione B2B, decidere chi può consultare, modificare o approvare una risorsa influisce sul prodotto, sulle operazioni e sul rischio. Un modello troppo semplice può concedere accessi eccessivi; uno troppo dettagliato può essere difficile da gestire e spiegare. Scegliere tra ruoli e permessi contestuali non significa selezionare un’etichetta tecnica: significa rappresentare le regole reali del business in modo comprensibile, verificabile e sostenibile.
L’opzione adatta dipende da quanto variano gli accessi tra utenti, risorse e situazioni, e da chi dovrà gestire queste differenze. Conviene partire dai casi reali, non da un elenco di controlli. In seguito si può adottare il modello più semplice che li copre e definire segnali concreti per la sua evoluzione.
Autenticazione e autorizzazione rispondono a domande diverse
L’autenticazione verifica chi è l’utente, per esempio tramite una sessione o un provider di identità. L’autorizzazione determina che cosa può fare quell’identità su una risorsa specifica. Aver effettuato l’accesso non implica poter visualizzare tutte le fatture, i progetti o i dati di un’azienda.
Per progettare l’autorizzazione, descrivete ogni decisione con quattro elementi: l’attore, l’azione, la risorsa e le condizioni applicabili. Per esempio: «Una persona con il permesso di fatturazione può scaricare le fatture della propria organizzazione». Questa frase obbliga a chiarire se il permesso si applica a tutte le organizzazioni, a una specifica organizzazione selezionata o soltanto a determinati documenti.
È inoltre opportuno definire fin dall’inizio l’ambito dei dati. In un prodotto utilizzato da più aziende clienti, un controllo corretto del ruolo non basta se la query restituisce risorse appartenenti a un altro cliente. L’autorizzazione deve coprire sia l’azione sia l’accesso alla risorsa e la sua appartenenza all’ambito corrispondente.
Permessi basati sui ruoli: chiarezza quando gli schemi si ripetono
Nel controllo degli accessi basato sui ruoli, o RBAC, i permessi vengono raggruppati in ruoli, che a loro volta vengono assegnati agli utenti. Un ruolo come «amministratore dell’organizzazione» potrebbe consentire di gestire membri e impostazioni; un altro, come «analista», potrebbe dare accesso in sola lettura ai report. L’applicazione verifica se il ruolo dell’utente include il permesso necessario per l’azione.
Questo approccio funziona bene quando le posizioni o le responsabilità all’interno del prodotto si ripetono e le differenze tra gli utenti sono relativamente stabili. Semplifica la spiegazione degli accessi nell’interfaccia, la creazione di profili comuni e la revisione delle assegnazioni. Offre anche un vocabolario condiviso tra prodotto, assistenza e tecnologia: è più facile discutere di «editor» che mantenere un elenco opaco di permessi individuali.
I ruoli, però, non dovrebbero diventare automaticamente etichette professionali. La stessa persona può avere responsabilità diverse in ciascuna organizzazione, e un ruolo globale può concedere accessi eccessivi. Spesso il ruolo ha un ambito specifico: per esempio, «amministratore» all’interno di un’organizzazione, non dell’intera piattaforma. Definite con precisione chi assegna i ruoli, a quali risorse si applicano e se una persona può cumularne più di uno.
Scegliete i ruoli quando i permessi formano gruppi riconoscibili, cambiano poco e possono essere gestiti senza creare un nuovo ruolo per ogni eccezione. Se le combinazioni si moltiplicano («editor con accesso solo a due progetti, tranne durante un’approvazione»), forse il ruolo sta cercando di rappresentare troppe dimensioni.
Regole contestuali: accesso in base all’utente, alla risorsa o alla situazione
Una regola contestuale prende in considerazione attributi oltre all’identità o al ruolo. L’accesso può dipendere da chi richiede l’azione, dalla risorsa che intende utilizzare e dalle condizioni in cui lo fa. Per esempio, si potrebbe consentire la modifica di un progetto solo se la persona appartiene al team assegnato e il progetto è in stato di bozza. Questo approccio è spesso associato al controllo degli accessi basato sugli attributi, o ABAC.
Le regole contestuali sono utili quando gli stessi utenti hanno permessi diversi su risorse differenti o quando lo stato del business modifica ciò che è consentito. Possono rappresentare l’appartenenza a un team, la proprietà di un record, la classificazione dei dati o la fase di approvazione. In questo modo si evita di creare un ruolo diverso per ogni combinazione di utente e risorsa.
La flessibilità ha un costo: le decisioni diventano meno visibili se dipendono da attributi sparsi o da condizioni difficili da spiegare. Una regola può non funzionare perché lo stato della risorsa non è aggiornato, manca un dato o non è stato definito il comportamento da adottare quando un valore è sconosciuto. Per ogni condizione, individuate la fonte, il responsabile, la frequenza di aggiornamento e la gestione degli errori. Se manca un dato necessario per concedere l’accesso, la policy deve negare l’azione in modo sicuro.
«Permessi contestuali» non significa necessariamente implementare un motore complesso. In una piccola applicazione può bastare un controllo esplicito dell’appartenenza e dello stato. L’importante è che la regola sia coerente, centralizzabile e verificabile, non che adotti una determinata architettura.
Come confrontare gli approcci in casi reali
Preparate una piccola matrice con utenti rappresentativi, azioni e risorse. Includete casi comuni ed eccezioni: un utente appartenente a due organizzazioni, una risorsa condivisa, una persona che cambia team e un’azione di approvazione. Per ogni riga, annotate il risultato atteso e il motivo. Confrontate quindi quanto costa esprimere e gestire le regole nei diversi approcci.
- Variabilità: i permessi dipendono soprattutto da responsabilità stabili oppure cambiano in base alla risorsa e al suo stato?
- Gestione: un amministratore del cliente può comprendere e mantenere le assegnazioni senza assistenza tecnica costante?
- Eccezioni: sono occasionali e gestibili oppure si ripetono fino a formare un secondo sistema informale di ruoli?
- Verificabilità: potete spiegare perché un’operazione è stata consentita o negata e ricostruire quale regola è stata applicata?
- Impatto degli errori: quali dati verrebbero esposti o quale operazione verrebbe bloccata se una condizione fosse configurata in modo errato?
Non confrontate soltanto il numero di ruoli o di regole. Un modello con pochi elementi può essere difficile da comprendere se i loro effetti si combinano in modo implicito. Valutate anche l’esperienza di chi configura gli accessi e la facilità con cui si può rispondere a una domanda di assistenza: «Perché questa persona non riesce ad aprire questo documento?».
Segnali di eccesso e di complessità prematura
È probabile che i ruoli stiano diventando eccessivi quando compaiono nomi quasi identici per piccole variazioni, quando ogni cliente richiede un ruolo esclusivo o quando le condizioni relative alle risorse vengono codificate come eccezioni all’interno dei ruoli. È un segnale anche il fatto che nessuno sappia spiegare la differenza tra due profili senza consultare il codice.
Al contrario, le regole contestuali possono essere premature se quasi tutti gli utenti condividono gli stessi permessi, non esiste un’esigenza di accesso per singola risorsa e il team non dispone di dati affidabili per valutare gli attributi. In questo scenario, costruire un sistema generale di policy aggiunge punti di errore e costi di manutenzione senza risolvere un problema concreto.
Usate questi segnali come motivo per rivedere il modello, non come ordine automatico di migrazione. Potrebbe bastare raggruppare i ruoli, chiarirne gli ambiti o correggere le assegnazioni. Se le eccezioni esprimono differenze legittime e ricorrenti, allora vale la pena progettare regole più esplicite.
Evolvere senza compromettere i permessi esistenti
Un’evoluzione graduale riduce le sorprese. Per prima cosa, censite i permessi attuali e descrivete i casi attesi con degli esempi. Separate le policy di autorizzazione dalla presentazione dell’interfaccia: nascondere un pulsante migliora l’esperienza, ma non sostituisce il controllo sul server ogni volta che viene eseguita l’azione.
- Definite una decisione centralizzata: stabilite come verificare se un attore può compiere un’azione su una risorsa, evitando controlli contraddittori distribuiti nell’applicazione.
- Scrivete test degli accessi: coprite i casi consentiti e negati, i confini tra organizzazioni, i cambiamenti di stato e gli attributi mancanti. Verificate anche le operazioni di lettura e scrittura.
- Confrontate prima di sostituire: durante la transizione, valutate il nuovo modello in parallelo con quello precedente e registrate le discrepanze, senza concedere accessi aggiuntivi in base al confronto.
- Migrate per casi circoscritti: trasferite una singola azione o tipologia di risorsa, verificate i risultati con i responsabili del business e mantenete un modo controllato per annullare la modifica.
- Registrate le decisioni rilevanti: conservate le informazioni utili per analizzare dinieghi o accessi sensibili, evitando di inserire nei log dati personali non necessari.
Prima del rilascio, chiedetevi: chi può concedere l’accesso e con quale ambito? Che cosa succede quando una persona viene rimossa da un team? Come si comporta il sistema se manca un attributo? Un’organizzazione può accedere alle risorse di un’altra? È possibile spiegare e verificare ogni eccezione? Se le risposte non sono chiare, il passo successivo è precisare le regole, non aggiungere altri ruoli o condizioni.
Come criterio pratico, iniziate dai ruoli quando le responsabilità sono stabili e comprensibili. Aggiungete regole contestuali quando un’esigenza ricorrente dipende da risorse o circostanze che i ruoli non rappresentano bene. In entrambi i casi, date priorità ad ambiti espliciti, diniego sicuro, test e gestione comprensibile. Il modello migliore è il più semplice che rifletta le decisioni reali del business e possa essere rivisto quando cambiano.