Chi può fare cosa: utenti e permessi in un’applicazione gestionale

«Ci scambiamo la password»

L’account condiviso non è una scelta: è ciò che rimane quando l’applicazione non offre nient’altro. Funziona bene per alcuni mesi, poi presenta il conto, e sempre nel momento peggiore.

Tre conseguenze, tutte meccaniche. Revocare l’accesso a una singola persona obbliga a cambiare la password di TUTTI, quindi a riaggiornare un’intera squadra proprio il giorno in cui qualcuno lascia l’azienda, cioè il giorno in cui meno vogliamo occuparcene. In secondo luogo, nessuno riesce più a rispondere alla domanda «chi ha modificato questa riga?», perché tutti sono la stessa persona agli occhi dell’applicazione. Infine, non è possibile concedere un accesso parziale: chi deve solo consultare un dato riceve esattamente gli stessi poteri di chi emette fatture.

Il punto non è quindi la sicurezza nel senso spettacolare del termine, nessuno attacca un’applicazione usata da quindici persone. È l’irreversibilità: un account condiviso non si può sfilacciare, ma solo sostituire; e più si aspetta, più la sostituzione diventa onerosa.

• Revocare l’accesso a una persona = cambiare la password di tutti.
• Nessuna risposta possibile a «chi ha fatto questo?»: un solo account, un’unica identità.
• Nessun accesso in sola lettura: consultare e modificare attribuiscono gli stessi diritti.

Tre ruoli, e il confine preciso tra loro

Non appena l’applicazione richiede un accesso, include veri account separati e tre ruoli. Sono pochi, ed è intenzionale: un sistema di permessi che non si capisce a colpo d’occhio è un sistema che si configura male.

L’amministratore può fare tutto ed è l’unico a gestire gli account: li crea, li disattiva, ne reimposta la password. L’utente lavora all’interno dell’applicazione, crea, modifica ed elimina dati, ma non vede mai la gestione degli account. Il ruolo in sola lettura consulta: naviga ovunque, apre schede, legge dashboard e non può scrivere nulla.

Ciò che conta non è la lista, ma dove viene posto il rifiuto. Per il ruolo in sola lettura, il blocco non è un pulsante nascosto a schermo: ogni richiesta di scrittura viene respinta prima di raggiungere la route, tramite il middleware, con codice 403. Un pulsante nascosto si aggira con la tastiera o uno strumento da sviluppatore; un rifiuto impostato in anticipo, no. È la differenza tra un’interfaccia che suggerisce e un’applicazione che applica rigidamente le regole.

Il ruolo viaggia nel cookie di sessione firmato, il che permette questa verifica senza interrogare il database a ogni richiesta. E un visitatore senza sessione non passa oltre: le pagine lo reindirizzano alla schermata di login ricordando dove stava andando, mentre le chiamate API ricevono un 401.

• Amministratore: tutto, più la gestione degli account.
• Utente: crea, modifica ed elimina dati; nessun accesso agli account.
• Sola lettura: naviga e consulta; ogni scrittura respinta con codice 403 prima della route.
• Senza sessione: 401 sull’API, reindirizzamento alla login sulle pagine.

Aprire un accesso: un identificativo, un ruolo, una password temporanea

La creazione di un account richiede tre informazioni, e nessuna di esse è un indirizzo email. L’amministratore inserisce un identificativo (da 2 a 31 caratteri: lettere, cifre, punto, trattino, underscore), sceglie il ruolo e l’applicazione genera autonomamente una password temporanea.

Questa password viene mostrata una sola volta, in quel momento. Non è recuperabile successivamente, né nella lista degli account, né altrove: viene conservato solo il suo hash. Se viene persa prima di essere trasmessa, l’amministratore ne genera una nuova, operazione che richiede dieci secondi. L’account viene inoltre contrassegnato come soggetto a cambio obbligatorio di password: la persona dovrà scegliere la propria alla prima connessione, quindi l’amministratore non conoscerà mai la password dei colleghi.

Nessuna email viene inviata, e conviene saperlo prima di organizzarsi: l’applicazione non dispone di alcun servizio di invio. Spetta all’amministratore trasmettere identificativo e password temporanea con i propri mezzi. La conseguenza pratica è più fastidiosa dell’assenza di email in sé: non esiste un flusso automatizzato di « recupero password ».: chi la perde deve rivolgersi all’amministratore, che la reimposta.

Il primo account, invece, viene creato insieme all’applicazione: identificativo «admin», password «admin», e lo stesso obbligo di cambio alla prima connessione. Si tratta di una password di avvio, non di una password vera e propria, e l’applicazione non vi permetterà di mantenerla.

• Identificativo + ruolo: è tutto ciò che l’amministratore inserisce.
• Password temporanea generata dall’applicazione, mostrata UNA SOLA VOLTA.
• Cambio obbligatorio alla prima connessione, l’amministratore non la conoscerà successivamente.
• Nessuna email: trasmissione e reimpostazione passano entrambe per l’amministratore.

Chiudere un accesso senza bucare la cronologia

Un account non viene eliminato, ma disattivato, e successivamente riattivato. Non è una scorciatoia tecnica, ma la stessa scelta adottata per il cestino dei dati: un record cancellato definitivamente porta via con sé tutto ciò che vi è collegato, e ci si accorge del problema solo mesi dopo, quando si cerca qualcosa che non esiste più.

Due rifiuti sono codificati esplicitamente, e sono proprio quelli che evitano di restare chiusi fuori. Non è possibile disattivare il proprio account, l’azione più facile da compiere per sbaglio mentre si pulisce una lista. E non è possibile disattivare l’ultimo amministratore attivo: un’applicazione senza amministratori è un’applicazione in cui nessuno potrà mai più aprire un nuovo accesso, nemmeno per sé stesso. Il rifiuto è esplicito, non si limita a fallire.

Un addio si gestisce quindi con un solo gesto, senza toccare le password degli altri e senza cancellare tracce. Una sostituzione richiede due passaggi: disattivare, poi creare.

• Disattivazione reversibile anziché eliminazione.
• Impossibile disattivare il proprio account.
• Impossibile disattivare l’ultimo amministratore attivo.
• Reimpostazione della password da parte dell’amministratore, in qualsiasi momento.

Cosa non fa, e conviene saperlo prima

I permessi sono globali all’applicazione. Un account possiede un ruolo, e tale ruolo non è associato a nessuna entità, area o campo. Non esiste quindi alcun modo per esprimere frasi come «questo commerciale vede solo i propri clienti», «questa persona accede alle interventi ma non alla fatturazione» o «questo campo è nascosto ai non manager». I tre ruoli coprono bene la domanda «consultare o modificare», ma non affrontano affatto la domanda «quale parte».

L’applicazione registra QUANDO un dato è stato modificato, mai CHI lo ha modificato. Ogni record contiene automaticamente la data di creazione e quella dell’ultima modifica, ma nessuna colonna memorizza l’autore. Account separati rispondono quindi alla domanda «chi può entrare», non a «chi ha scritto questa riga», sono due domande diverse, e viene trattata solo la prima. È il limite più facilmente scambiato per una funzionalità già inclusa, perché avere account nominativi dà l’impressione di disporre di una tracciabilità completa.

L’accesso avviene tramite identificativo e password, e nient’altro. Niente login tramite account Google o Microsoft, niente single sign-on aziendale, niente autenticazione a due fattori. Per una squadra che già gestisce le proprie identità altrove, significa tenere un elenco aggiuntivo di account.

Questi quattro limiti non sono dimenticanze da aggirare: sono i confini di ciò che viene fornito, e scriverli è più utile che lasciarli scoprire. Hanno tutti un unico rimedio, che è anche la ragion d’essere del prodotto, il codice dell’applicazione è vostro. Si tratta di un progetto standard Next.js e Prisma, esportabile in ZIP o da pushare sul vostro repository: aggiungere una colonna per l’autore, un isolamento per team o un’autenticazione aziendale è un lavoro di sviluppo ordinario, su codice di vostra proprietà, che nessun editore può impedirvi di realizzare. E se l’isolamento è strutturale per il vostro business, va descritto fin dall’inizio, è il vostro testo a definire le entità e i loro legami.

• Permessi globali: nessun isolamento per entità, sezione o campo.
• Data di modifica registrata, autore non registrato.
• Solo identificativo + password: né SSO, né login esterni, né secondo fattore.
• Rimedio comune: il codice è vostro, queste estensioni sono sviluppo ordinario.